Bump.

Also in a previous version of V6 using a normal gani animation as a gani attribute was always displaying above the player, it's now displaying below the player if drawn near the top of the player. This change obscures something I was using, which was more efficient than using a scripted display.

I've just noticed:

Which is quite handy.
If anyone's not sure how this works you just open the gani as a text file and write LAYER #.

Is that fixing your problem?

It is, apparently. Don't forget addressing the whole "no sound when Graal is minimized as an option" thing, though.

I've noticed a bug in v6 where the shift and ctrl keys can become "stuck" when you tab out of the Graal window while holding them. Scripts act as if the shift or ctrl buttons are being held down until you press them again. This does not seem to have any effect on built in features such as the emoticons from holding ctrl and pressing a key, but only on scripted features. It is causing some problems on Unholy Nation where they have custom emoticons, and certain scripts like the hotkeys that require you to not be holding shift when you activate them.

Is this new to v6? I've been experiencing problems like this for many years.

Fullscreen mode doesn't seem to work at all on dual monitors, just goes black. Ideally the screen with the Graal client on should be the only screen going fullscreen mode.

The fact that filenamecache.txt is no longer used with the new V6 makes usage of the Level and Gani editors somewhat more annoying when it comes to loading new images, as you either have to explicitly select the image within the Level Editor, or copy an image into the same folder as Gani Editor.

Or is the goal to force players to pay to use online tools?

What does it use instead?

Not sure exactly but it seems files are scanned for whenever they are required.

Priority #1 UDP Support

I bet UDP was scrapped partly because flash doesn't support it(?).

It wasn't supported on other platforms as well. Graal's use of UDP wasn't optimal anyway. Ideally Stefan would spend time implementing UDP in the way that it would benefit the game most—but that seems unlikely since it can't be used in Flash and probably won't be used with the iOS devices (although I think it could be).

About file scanning: v6 is loading files from the location where it would download them to, also reduced the number of file access operations to make it fast.
About UDP: the complex part is the peer-to-peer nature of the old UDP mode. We have plans to introduce a server-based UDP system sometime (data exchange server independent from the actual graal server), like we do in our game Dinosmash.

What about some hard-coded interpolation for player/NPC movement?

Would this new UDP mode make players smooth again? The V5 and before UDP made the game very smooth, would be nice to see this again.

Few things I've been noticing on v6 or would like to see:

Scripted RC:
-The playerlist button on it doesn't work (I'm using external playerlist on v6)
-I want the scripted RC to open as an external window and appear in the toolbar (would be nice if it also stayed in the bottom-right toolbar like old RC does)
-Seems like the server options window's resize doesn't save when you re-open it.
-/openrights window doesn't resize its contents properly (stays small even though the window gets bigger)

Font:
-Still a bit strange. I find player chat to be more readable and closer to v5 when you change the size to 20 on v6, even though on v5 it's size 24.

For Facebook Graal:
-Remove the first loading screen and where you select a server, because currently you can only click one server and that's iClassic. Make it so it automatically begins loading your game like on the iPhone.
-Remove the loading song, it's not required and the client should load much faster without the first loading screen, loading screen map, and song.
-Option to hide the bottom friends bar. It's nice that it stops refreshing but it's only wasting space and players don't use this bar. When they want to contact Graalians they either use Facebook's own messenger or they use Graal's in-built friendlist.

It'd make players consideribly smoother than what we have right now in v6, but not to the same degree as the peer-to-peer UDP in v5. But peer-to-peer stuff has no place here, from a programming, security, and arguably gameplay perspective.

I don't see why not. UDP between the client and the server (and not between clients) is going to do very little to improve the game unless you commonly experience packet loss. You won't get better connections to people geographically closer to you like you used to since they still have to go through the server (rather than directly connecting to you).

Crono was talking about the smoothness. Packet loss is what causes jaggedness when you have a TCP connection , not latency. All latency will cause is a fixed delay.

So, I disagree with you. Switching to UDP will consideribly help smoothness over a lossy connection (which is the cause of jaggedness 95% of the time). Presumably, that's an improvement to the game.


To eliminate delays, yes, peer-to-peer connections would be required. But aside from the security nightmare, it's annoying to get working properly (you need to do NAT punchthrough, and then hope they don't have any bad firewall rules, other sorts of filtering, evil NAT, etc.), and more importantly, I think it's actually detremental to the gaming experience (although this is an opinion).

I think it's detremental because, although it might help eliminate delays in certain cases, it will increase delays in other cases, and it will also totally destroy your ability to predict other people's movements when you're fighting multiple people, since the delay will vary incredibly highly, and it'll be impossible to get a good idea of what other people are seeing on their screens (it's already hard enough to explain to players how hit detection works without introducing peer-to-peer connections).

Basically, you'd be trading the predictibility of the client-server model for improved delays (in some cases) -- and being able to accurately predict things is half of the fun, at least on traditional servers like GTA.


But that aside, I think even from the security and programming perspectives it wouldn't be the best idea ever.

You're right and we don't disagree—I just didn't read what he said carefully and figured he was talking about latency. UDP still is probably not going to help much, though, since packet loss is comparatively rare. It will get rid of some overhead, of course, but in my experience it doesn't trim down on latency by much.

UDP helps tremendously on V5 with smoothness as well as registration.

Isn't v5 using peer-to-peer UDP, though? I was talking about server-client UDP for stuff like movement data.

Ya, v5 uses peer-to-peer. As a player, the only concern I have is smoothness. I do suppose that it's just part of Graal's nature to have lag and jaggy-movement. Graal isn't an RTS game or something where everything can be made serverside, so it'll always have this issue. Sadly. :(!

No sound when you open the playerlist.

Whelp, if v6 is officially released, then shouldn't we have a v6 Bug Report thread?

Well we have a whole dedicated forum for it now :D (renamed the v5 bug forum)

When using warpto(); on a Database or Local NPC and you've already seen the NPC on your client, it does not appear on your client when you enter the new level.

Warpto() to a different level or gmap?

A different level, no gmap.

Yeah, with a clientside database NPC it requires a reconnect to see changes for whatever reason.

It seems that with a layer 1 particle image object, a moving particles drawing layer doesn't update in relation to other players/NPCs, which it does in V5.

Some files which exist within folders offline but are not online as mainfiles are not found by the client.

For instance in Graal/levels/ganis/

there are images such as:

glare1.mng
skip.png
gralats.png

which the f2 window reports as not found.
On a related note my f2 window stopped appearing a few times while testing this, I had to restart the client, no idea why.

I realize for efficiency you are rendering lumps of tiles(4x4?) to textures and rendering the quads for tiles on v6. However can you look into changing the sampling for tiles to nearest neighbor and no AA? As it is now when you are zoomed in sprites are crisp but tiles and npcs are very blurry. Besides the fact the blurring looks bad it also causes a lot of visual bugs with edges and such bleeding with transparency.

I mean the latest update fixed most of the major rendering bugs with zooming but this one still bugs me.

Cozy fat trees :D who made those?

Doesn't look like a rendering bug, seems the tile gfx is bugged.

Yours truly.

I'm not talking about the gass tiles. I'm talking about how the tiles are blurry, which also causes the trees(and many npcs) to blur at the edge of transparency and cause those outlines at the bottom of the trees.

Mostly ganis = crisp. Npcs and tiles = blurry. It just looks bad in my opinion.

http://i0.kym-cdn.com/photos/images/...43/462/79a.gif

Very nice tree btw :D

Problem is that tiles are often repeated often and zooming it can create very bad moiré effects, but we can see if we can improve it. On Android you sometimes have a bad zoom factor and then you can see this, a "blurry" version of the tiles look better but of course we need to avoid the effect of tile borders.

I think you should simply draw all layers up to layer 3, then scale it up as a whole, then draw the UI layers on it.