ski bug fixed? part two

awhile back i posted in tribes talk that we thought we might have fixed the ski bug in x64 tribes

since then we've done a lot of skiing trying to reproduce the ski bug on x64 and it still does happen but it is quite rare - so there must be another place in tribes that needs a fix.

here is an interesting screen shot of my most recent ski bug moment. notice that i seem to have been skiing above and in parallel to a terrain boundary. ski bug #1 seemed to occur when we skied into a terrain boundary perpendicularly.

ski bugs_

skiing killed tribes

Where's the screen shit

:Hmm:

bugs do you know what AntiSkip does? did it actually work?

hyung said:

bugs do you know what AntiSkip does? did it actually work?

Click to expand...

I think Andrew was trying to fix the condition where a scout would collide with the capper and then the flag would do bizarre movement until the server was rebooted.

Antiskip would export all the info about the flag object to a (slow) disk file, delete the object, and then recreate the object with the data that was exported.

It may have helped but there was still a lot of flag weirdness that occurred after a scout collision (and as i later discovered if the flag touched an elevator).

I also worry about the condition where a flag is tossed to another player and it bounces off the receiver's weapon. LT servers would hardly ever have a flag/scout collision but they still have flag weirdness that AntiSkip doesn't seem to fix.

I decided I didn't like AntiSkip very much because you get lag effects when a flag changes state and zadmin touches the much slower hard disk.

Doing the lords work bugs_ Thank you.

i have been testing x64 with the old fstat mod lately and i noticed that fstat 1.41 has a flag skipping fix that is similar to the zadmin antiskip but it seems more efficient. i like it better.

he writes the flag objects out to disk at the beginning of the map only.

when it is time to perform the flag skip freaky copies the flag object values into temporary variables instead of exporting/writing it to disk.

he then deletes the object and creates it again by exec-ing the earlier flag object from disk.

once that happens he then fills in the flag object values from the temporary variables created earlier.

so he doesn't write to disk every flag event but does do a read - but it is likely this data will be in the operating system's memory cache with 0 lag.

zadmin does a write/close each flag event which is normally expensive in terms of lag.

fyi for opsayo this could be a compromise antiskip that would have the same level of help without the possible lag.