String and parameter bugs

Graal Reborn Tech. Support
1

I have had several problems with server strings and player parameters like #P2 being cut off or overflowing into other strings and parameters after they reach a certain length. With server strings, sometimes the string will simply be cut off near the beginning if I look at it in the server string window of the RC, and other times the information the string contains will just be on a blank line with no string name. With parameters like #P2, when they become too long they start to overflow into things like the players x or y coordinates, or even the body colors or level name.

After the server strings start being cut off, players are usually disconnected from the server, but sometimes their character is still displayed frozen in place.

2

Try to keep all strings short, like… 255 chars short.
Also you didn’t mention which GServer o_o

The old old GServer used to have such a bug, could be “activated” with long chat text. lol

3

[QUOTE=Nalin;15012]Hmm. I should make another pass at the player props and trim off the ends of any string over 223 characters. That will prevent data corruption. But yeah. Make things in Graal have fun hidden limits. Player properties that are strings are capped at 223 characters.[/QUOTE]

Hope that 223 limit doesn’t bugger up some of my systems that are hopeful of a 255 cap. lol

4

;D lol No biggie.
Only thing it could cut into is chat text, and thats not really hindered.

5

This happens on gserver version 0.7.0, using the 2.2.2.0 client. Would breaking long strings up into more than 1 string solve the problem, or would Graal still run into problems due to it sending just as much (or slightly more) data in each packet?

6

Its the way the client wants to receive the packet.

7

Beholder: Will this cap mess up the Map System that Sentinel uses if there’s too many players on the server?

8

Of course.
That’s why I had the important strings compacted into separate strings.
Instead of a levelnames, I had it “xxxx,yyyy,l(layer)”, that’s also why I had it record account names, instead of nicknames (nicknames would generally be longer).

The map system will probably break with 30~50 players. (As opposed to 10~ players)

Nalin’s system uses about the same prevention methods and notably, his would encounter the same errors.
You could have the GServer chop up the strings. Have it print out something like

server.string0=length,account,name,ap,x,y,level,account,name,ap,x,y,level,account,name,ap,x,y,level,…
server.string1=account,name,ap,x,y,level,account,name,ap,x,y,level,account,name,ap,x,y,level,…

Have the client search server.string indexes from 0 to length/223.
Question then, would you have strings attempt to append together on the client (“acco” + “unt” = “account”).
Or to complicate things further by tokenizing each part so each “player” partition remains unviolated.

The client itself has a maximum length. For variable arrays, its 4096. (Which makes sense actually. 4096 tiles in the tileset and 4096 tiles on a level.)
I don’t specifically know the maximum length for strings (on clientside) though. Would be nice if we found the magical packet though.

Too bad the packets didn’t have a bit for “appending”.
stringname,0,trim(0,223,string) - start
stringname,1,trim(223,223,string) - append to ‘stringname’

Hey Nalin, any odd looking “bits” in the packet formula we might be over looking? D:…

9

[QUOTE=Nalin;15073]Actually, my system creates a separate server.string for each player, so it wouldn’t run into problems like that.[/QUOTE]
(overkill ;o) …Neat :open_mouth:

Lousy shmit packets. lol
Thanks for the tutorial anyway ;O

10

We’re both spammy bastards. hahaha