Small Mack Pack error

#1 ..bmp

#2 Buuuump

#3 Jermaine, have you tried to get through to the BrokeAssGames guys again yet? Do they have a support email address?

#4 Hi Jermaine,

I'll have the coder geeks look at this asap. Hopefully we can get them to respond here. What engine are you using?

Jondo

Edit: About our forums... we do have a bug right now we are trying to resolve it with our hosts that is preventing members from posting in our forums.

#5 Jermaine,

I discussed the issue with Chris Calef and he is pretty sure what the cause is. I am not a programmer but I am going to post the changes he did to our game project (Ruin Online - TGE1.52), which he is "pretty-sure" will resolve this problem.

There weren't any code changes in the MACK patch, however more animations were added, now over 100 are called in the constructor scripts. Because the are animations are shared between multiple players, we keep them in a different directory and the path names + the large number of animations are probably causing a packet that's too big (again, I am not a coder).

Chris's fix for this makes it so it does not have to send the pathname for each animation as part of the packet....

These changes are for Ruin, but it should point you in the right direction to fix it. Of course, if this works, we will update the pack (or make the changed files available prior to the next patch). So, here goes...

(Note the directory structure is based on Ruin Online, so modify them from your project.)

TsShapeConstruct.cc

line 140
char human_path[255];
char short_path[255];

dStrcpy(human_path,"main/client/data/shapes/player/humans");

line 170
//or, for ruin in particular, see if the shapepath has "main\client\data\shapes\player\Humans" in it..
//if so, save "../Animations/"
else if (dStrncmp(shape_path,human_path,dStrlen(human_path)) == 0)
{
U32 seq_path_len = (dStrlen(mSequence[i]) - dStrlen(dStrrchr(mSequence[i],'/'))) ;
const char* subtext = mSequence[i] + seq_path_len;
dSprintf(short_path,255,".%s",subtext);

line 214
else if (seq_name[0] == '.')
{//Ruin special case, player/humans/Animations
char full_seq_name[255];
char human_path[255];
dStrcpy(human_path,"main/client/data/shapes/player/humans/Animations");
dSprintf(full_seq_name, 255, "%s%s", human_path, seq_name + 1);
 mSequence[i] = StringTable->insert(full_seq_name);

K, that was painful, hopefully a BAG programmer will come and co-sign on this thread soon.

Jondo

#6 Thanks for the responses I'm not a programmer either, but I will try this.

thanks

#7 Is this the TGE fix? I think I have this problem and need the TGEA fix ;) Maybe with some code either side of the changes as well ;)

Cheers,

Andy

#8 Yes this is for TGE. Fairly sure this is the fix, but waiting for confirmation.

Jondo

#9 OK. Looking forward to the TGEA fix as well then :)

Andy

#10 Andy -- are you running TGEA 1.7.1? I unfortunately am not at the right computer to test this right now, but looking at the code for tgea 1.7.1 at least, it appears that they have already implemented a more complete fix for this problem than what I wrote for TGE -- it's in two functions, Platform::makeRelativePathName and makeFullPathName, in platformFileIO.cpp. I'm not sure when that entered TGEA, but see if you have them, and see if they are called from tsShapeconstruct.cpp. If so, then your problem might be something else.

#11 Hi Chris,

Thanks for chatting about this, I'll get a little more specific.

I run TGEA 1.7.1 with AFX 1.1. I have integrated MACK 1.1 into this codebase.

At the moment I am trying to get the melee working. In server:client mode all is great, I can load MACK advanced and have great battles, wonderful animation :)

When I try to run my dedicated servers and connect a client all runs OK, I can connect to my character creation server and select the MACK advanced character. My problem comes then when I leave creation and try to connect to a zone server. The zone loads and I get this error "You do not have the correct version of ........ Missing sequence scriptsAndAssets/data/shapes/ACK/male/ for scriptsAndAssets/data/shapes/ACK/male/advanced.dts"

In the zone server console I see this:

No such file 'scriptsAndAssets/data/shapes/ACK/animationspdttttttttttttttttttttttt'
No such file 'scriptsAndAssets/data/shapes/ACK/male'

So it seems the zone server is not sending a meaningful animation and the client bombs out.

I looked at the code fixes here, and that prompted my question about TGEA, as it seemed TGEA was already doing what you suggested. So I got all confused!

Hope you can help Chris ;)

Cheers,

Andy

#12 < * Chris is busy right now but is thinking about this problem and will take a look at it later today * >

#13 I can help here. Chris's fix is right for TGE. The redone system in TGEA is also good, and works well. Any other problems are probably due to your use of autoload in AFX. It's a beautiful system that seriously speeds up animation dev time; but it does introduce a 'problem'. When it is constructing the actual datablock, it fills in the data with full path names, rather than leaving them at say "./animations/run_forward.dsq". Neither TGE (with Chris's fix) nor TGEA is stripping this extra garbage out, thus you are blowing out the buffer stream.
The 1500->2000 change helped you a bit, allowing a few more animations, but increasing the amount of data sent to the client at one time is not a good idea for a multiplayer game.

#14 Erik's explanation is perfect, I had this problem when working with another resource with many animations. Using really short animation file names, and having a simple and short directory structure can be a quick fix to the problem, but it will come up again once your dts gets more moves.

If you are making a multiplayer game, I don't think you should be increasing the buffer size at all, else your users might start losing data over the wire. Even old servers that relay your data on the Internet love an 1500 big packet, so that's an ideal setting.

The problem must be addressed either by cutting back on your dsq animations' path length, or - the best approach would be - to completely rewrite the part where animation filenames are sent. Should be maybe packed, and the possibility to send via several packets should be added to make it work properly.

I'll join in and see if I can find something out tomorrow - today is a bit late for me already.

#15 There's a simple one-line solution for this, already built into TGE 1.5.2:

In engine\ts\tsShapeConstruct.cc, on line 11 there is the define:
#define TS_IS_RELATIVE_SEQUENCES 0

if you change that to read
#define TS_IS_RELATIVE_SEQUENCES 1

then the paths will be stripped from the animation names, and you will be able to use a much greater number of animations for your shape.

The only downside to using it is that all of the animations that a shape uses must be in the same folder as the shape (so no sharing sequences from a common animations folder).

I've not checked if that define is also present in TGEA

#16 @Guy: Yes, it is also present in TGEA, and set to 0 by default.

#17 Hey Andy,

If you're still stuck on this, a quick fix is just to remove a few animations. Jon is going to pick some and reduce it in the pack, but if you go to one of your .cs files (advance.cs, etc) and take off the last few. or any other ones and then renumber them, then it should work. I think we're just hitting the maximum even with the path removal. You just can't have an infinite number of sequences until somebody rewrites the network code to handle putting them across several packets, instead of cramming all the names into one.

#18 Hi Chris,

OK, I'll give that a try. Many thanks :)

Cheers,

Andy