Limits to total number of animation sequences?
by Chris Calef · in Torque Game Engine · 01/29/2005 (9:33 pm) · 25 replies
Does anyone have experience running a player with a large number of dsq sequences included in the player.cs file? I'm getting an "out of range write" error (core/bitstream.cc) whenever I try to increase the number of animations past forty or so. The number is variable depending on which animations I include, but there is always a point where it breaks.
I came across a forum thread regarding this error (fix involved increasing a buffer size in game/gameConnectionEvents.cc) and the fix helped a little, but didn't solve the problem. (It went from a cap of thirty or so to a cap of forty or so, but I need a lot more than that.)
Any information as to what's going on here would be most welcome!
I came across a forum thread regarding this error (fix involved increasing a buffer size in game/gameConnectionEvents.cc) and the fix helped a little, but didn't solve the problem. (It went from a cap of thirty or so to a cap of forty or so, but I need a lot more than that.)
Any information as to what's going on here would be most welcome!
About the author
#2
I have 47 animation on my player for now .
It works but i dont know how this influence a gameplay with 32 player .
01/30/2005 (7:14 am)
@Chris i use that fix you talking about with a buffer size of 2000.I have 47 animation on my player for now .
It works but i dont know how this influence a gameplay with 32 player .
#3
"clever would probably mean making Torque aware of your naming convention"
Aha, yes, that would be clever indeed. Thanks!
@Billy: yeah, in the forties is where I ended up. I tried increasing it the buffer to ridiculous sizes and it didn't get any better, not to mention the fact that it would be a pretty dumb idea to get crazy with that particular size limit.
01/30/2005 (9:04 am)
@Ben:"clever would probably mean making Torque aware of your naming convention"
Aha, yes, that would be clever indeed. Thanks!
@Billy: yeah, in the forties is where I ended up. I tried increasing it the buffer to ridiculous sizes and it didn't get any better, not to mention the fact that it would be a pretty dumb idea to get crazy with that particular size limit.
#4
01/30/2005 (12:53 pm)
Even at 2000 bytes you're liable to start running into MTU problems. :-/
#5
I been testing this alot with 6 players online , thats the limit i have in my game.
To approach this in another way is far to complex for me , if you have another way or some example how i can get around this then i would be
very happy .
I really need all animations i have !
This maybe is obvious for Chris but not for me :(
01/30/2005 (1:10 pm)
@BenI been testing this alot with 6 players online , thats the limit i have in my game.
To approach this in another way is far to complex for me , if you have another way or some example how i can get around this then i would be
very happy .
I really need all animations i have !
This maybe is obvious for Chris but not for me :(
#6
I would also like to be able to use many more regular animations, however, without running into this limit, so I'm going to look into alternative ways to load lists of animations. (Will talk to Ben about it). I'll come back here and post what I come up with.
01/30/2005 (7:00 pm)
@Billy: it's easier for me, because in my particular application I have a whole series of animations that are different only in the angle that they are applied -- i.e. for a certain force applied, I want eight animations, one for each forty-five degree increment around the circle. (see my .plans for what I'm doing). I would also like to be able to use many more regular animations, however, without running into this limit, so I'm going to look into alternative ways to load lists of animations. (Will talk to Ben about it). I'll come back here and post what I come up with.
#7
I tweaked the buffer to 1560 default is 1500 .
Hope i dont get any problems later because of this.
But so far it works .
01/31/2005 (3:08 am)
Sounds great Chris.I tweaked the buffer to 1560 default is 1500 .
Hope i dont get any problems later because of this.
But so far it works .
#8
So, the first thing I did was strip that path out of my network data (in packData) and then put it back in when we get to unpackData, using the path from the baseShape.
(in TSShapeConstructor.cc)
void TSShapeConstructor::packData(BitStream* stream)
{
char *subtext;
Parent::packData(stream);
stream->writeString(mShape);
S32 count = 0;
for (S32 b=0; b
if (mSequence[b])
count++;
stream->writeInt(count,NumSequenceBits);
for (S32 i=0; i
if (mSequence[i]) {
subtext = dStrrchr(mSequence[i],'/');
stream->writeString(subtext);
}
}
void TSShapeConstructor::unpackData(BitStream* stream)
{
int strLen,endLen,pathLen;
char shapePath[90],pathedSeq[90];
char *subtext;
Parent::unpackData(stream);
mShape = stream->readSTString();
strLen = (int)dStrlen(mShape);
subtext = dStrrchr(mShape,'/');
endLen = (int)dStrlen(subtext);
//pathLen = (strLen - endLen) + 1 ;// +1 to get the slash as well
pathLen = (strLen - endLen) ;//OOPS, don't want slash
dStrncpy(shapePath,mShape,pathLen);
shapePath[pathLen] = '\0';//need null terminator
S32 i = 0, count = stream->readInt(NumSequenceBits);
for (; i
mSequence[i] = stream->readSTString();
dSprintf(pathedSeq,90,"%s%s",shapePath,mSequence[i]);
//dStrcpy(mSequence[i],pathedSeq);//OOPS, can't treat the string table like this!!
mSequence[i] = StringTable->insert(pathedSeq);
}
while (i
mSequence[i++] = NULL;
}
The path is 30 characters whereas the names of the sequences are generally under 20, so this should get you one and a half times more sequences.
To go farther, I also recommend, dumb as it sounds, giving your sequences very short names. :-\
If I come up with anything more general purpose or overall more elegant, I'll let you know, but this should be useful for a workaround at least. I'm up to 56 sequences so far, and it should go a lot higher now.
PS sorry about the formatting, should have linked to a separate file.
01/31/2005 (5:54 pm)
Okay, don't sue me if this breaks anything, but here is my first modification to allow more sequences. I found out that the problem is actually the amount of text that TSShapeConstructor has to shovel across the network in one packet of 1500 (or slightly more) bytes. Furthermore, it turns out that it's sending the entire path of every sequence, which is the same every time if you are keeping all your sequences in the same directory as the base shape, which I believe most people do, at least I do.So, the first thing I did was strip that path out of my network data (in packData) and then put it back in when we get to unpackData, using the path from the baseShape.
(in TSShapeConstructor.cc)
void TSShapeConstructor::packData(BitStream* stream)
{
char *subtext;
Parent::packData(stream);
stream->writeString(mShape);
S32 count = 0;
for (S32 b=0; b
count++;
stream->writeInt(count,NumSequenceBits);
for (S32 i=0; i
subtext = dStrrchr(mSequence[i],'/');
stream->writeString(subtext);
}
}
void TSShapeConstructor::unpackData(BitStream* stream)
{
int strLen,endLen,pathLen;
char shapePath[90],pathedSeq[90];
char *subtext;
Parent::unpackData(stream);
mShape = stream->readSTString();
strLen = (int)dStrlen(mShape);
subtext = dStrrchr(mShape,'/');
endLen = (int)dStrlen(subtext);
//pathLen = (strLen - endLen) + 1 ;// +1 to get the slash as well
pathLen = (strLen - endLen) ;//OOPS, don't want slash
dStrncpy(shapePath,mShape,pathLen);
shapePath[pathLen] = '\0';//need null terminator
S32 i = 0, count = stream->readInt(NumSequenceBits);
for (; i
dSprintf(pathedSeq,90,"%s%s",shapePath,mSequence[i]);
//dStrcpy(mSequence[i],pathedSeq);//OOPS, can't treat the string table like this!!
mSequence[i] = StringTable->insert(pathedSeq);
}
while (i
}
The path is 30 characters whereas the names of the sequences are generally under 20, so this should get you one and a half times more sequences.
To go farther, I also recommend, dumb as it sounds, giving your sequences very short names. :-\
If I come up with anything more general purpose or overall more elegant, I'll let you know, but this should be useful for a workaround at least. I'm up to 56 sequences so far, and it should go a lot higher now.
PS sorry about the formatting, should have linked to a separate file.
#9
Ye i know about the short names already :)
Time for some testing.
I owe you a virtual beer if this works or atleast i put your name in my credit list if i ever reach my goal :)
01/31/2005 (6:21 pm)
Avesome Chris !Ye i know about the short names already :)
Time for some testing.
I owe you a virtual beer if this works or atleast i put your name in my credit list if i ever reach my goal :)
#10
Back to the lab, I'll let you know what I find out.
We need a better solution anyway... I want LOTS of sequences!!
01/31/2005 (6:30 pm)
Uh oh... upon further testing, I find that this works great for a local client-server (i.e. torque on one machine) but crashes when a remote client tries to join the server.Back to the lab, I'll let you know what I find out.
We need a better solution anyway... I want LOTS of sequences!!
#11
The main problem was you can't go arbitrarily changing text that's already in the string table... instead we're now just inserting new entries. This could be changed at some point, as we're now wastign a little space, but it works.
PS what's this about virtual beer?? I want real beer! :-)
01/31/2005 (7:25 pm)
Okay... thanks again to Ben Garney the Torque Master, he pointed out (one of) my problem(s). (I found two more on my own.) I have edited the above functions, so go back up and try again with the new text. I left the original code in there in comments to help you see what to change.The main problem was you can't go arbitrarily changing text that's already in the string table... instead we're now just inserting new entries. This could be changed at some point, as we're now wastign a little space, but it works.
PS what's this about virtual beer?? I want real beer! :-)
#12
01/31/2005 (9:26 pm)
I'm not so much the Torque Master as just good at nitpicking... :P
#13
@everyone: more research results
a) solution posted above seems to be working well
b) I'm reducing my sequence names to three characters. For me this works fine because they're autogenerated and arranged in patterns, but for people with large sets of ordinary animations (ala halflife etc) what I would recommend at this point is giving them very short (i.e. three or four character) code names and then maybe making a table or something on the script side that translates these codes back to long names. (Lots of ways you could implement that, up to user discretion).
The other way, as Ben suggested above, would be to split the transmission of the names into multiple packets, but I'm not going to deal with that for what I need.
Finally, I'm testing this now but it looks like the ending sequence name is optional, if you leave it out it looks like it will just use the dsq name.
Other improvements that could be made: ".dsq" could be assumed, and hence cut off the string in packUpdate and reapplied in unpackData, as in:
dSprintf(pathedSeq,90,"%s%s.dsq",shapePath,mSequence[i]);
So you could have something like
sequenceN = "./a3f.dsq";
in your .cs file, at which point you should be able to stuff up to five hundred sequences into 1500 bytes of network traffic.
Okay, rambling on! Hope this snippet has been useful.
02/01/2005 (12:38 pm)
@Ben: yeah, whatever Ben. Torque Master.@everyone: more research results
a) solution posted above seems to be working well
b) I'm reducing my sequence names to three characters. For me this works fine because they're autogenerated and arranged in patterns, but for people with large sets of ordinary animations (ala halflife etc) what I would recommend at this point is giving them very short (i.e. three or four character) code names and then maybe making a table or something on the script
The other way, as Ben suggested above, would be to split the transmission of the names into multiple packets, but I'm not going to deal with that for what I need.
Finally, I'm testing this now but it looks like the ending sequence name is optional, if you leave it out it looks like it will just use the dsq name.
Other improvements that could be made: ".dsq" could be assumed, and hence cut off the string in packUpdate and reapplied in unpackData, as in:
dSprintf(pathedSeq,90,"%s%s.dsq",shapePath,mSequence[i]);
So you could have something like
sequenceN = "./a3f.dsq";
in your .cs file, at which point you should be able to stuff up to five hundred sequences into 1500 bytes of network traffic.
Okay, rambling on! Hope this snippet has been useful.
#14
02/01/2005 (1:10 pm)
500 sequences. . . .I am sure artist are trembling just hearing that
#15
02/01/2005 (1:16 pm)
@anthony: ROFL
#16
02/01/2005 (1:28 pm)
Would that be trembling in anticipation, or in fear of their teams' rising expectations? :-)
#17
A question though: Why do we even need to send the list? The server should just be able to say 'play jump, knowing the client has a jump animation. If the client doesn't for some hacked reason, the player will assume a default null animation, perhaps hanging his head in shame.
02/01/2005 (2:00 pm)
Many games are 300+ animations. An enum table matching a scripted table of numbers probably could work well.A question though: Why do we even need to send the list? The server should just be able to say 'play jump, knowing the client has a jump animation. If the client doesn't for some hacked reason, the player will assume a default null animation, perhaps hanging his head in shame.
#18
02/01/2005 (2:32 pm)
You could definitely do that, too. The way it is, it's designed to have a higher degree of flexibility, without people having to hardcode all their possible animation sequences. But you're right, you could just put everything on the code side and have as many as you want.
#19
1) in order to increase total number of sequences past 128, you also have to go into tsShapeConstruct.h, line 27, and change "NumSequenceBits = 7;" to something higher. 8=256, 9=512, etc.
2) finally, in game/player.h, line 160 (or so), find "NumExtraActionAnims = 60," and make it bigger. 90 is working for me right now, but make it whatever you need. This is number of animations besides the ones that are in the action table, which looks like it's just eight but I could be wrong on that. Make this big enough to give yourself some room. (You will get a dialogue box saying "too many action animations!" if you don't set this.)
02/02/2005 (12:08 pm)
Okay, hopefully last post on this thread! Just wanted to report a couple other things I forgot to mention (well, one that I forgot and one that came up later.)1) in order to increase total number of sequences past 128, you also have to go into tsShapeConstruct.h, line 27, and change "NumSequenceBits = 7;" to something higher. 8=256, 9=512, etc.
2) finally, in game/player.h, line 160 (or so), find "NumExtraActionAnims = 60," and make it bigger. 90 is working for me right now, but make it whatever you need. This is number of animations besides the ones that are in the action table, which looks like it's just eight but I could be wrong on that. Make this big enough to give yourself some room. (You will get a dialogue box saying "too many action animations!" if you don't set this.)
#20
but i'm running into this and have a hopefully easy Q -
does anyone know if the 1500-byte limit is per-character or for all characters ?
like, can i have 500 3-character animations (or whatever the limit is for me) in one character
and a different set of 500 3-character animations in another ? and another ?
Chris' posts on this topic are awesome, btw. thanks Chris.
tia,
orion
01/03/2006 (3:34 pm)
Sorry to resurrect this old thread,but i'm running into this and have a hopefully easy Q -
does anyone know if the 1500-byte limit is per-character or for all characters ?
like, can i have 500 3-character animations (or whatever the limit is for me) in one character
and a different set of 500 3-character animations in another ? and another ?
Chris' posts on this topic are awesome, btw. thanks Chris.
tia,
orion
Associate Kyle Carter
You can either split stuff up into multiple updates/NetEvents, or you can do something clever (for your application, clever would probably mean making Torque aware of your naming convention so it can autogenerate the list of animations it has to load rather than sending it explicitly).