94.1 + r3824


Watched it my own self now.
It was around 18:55 on the lower middle elevated hill (transport truck was on top of the hill). This time the units were indeed going all over the place. There were earlier instances of the bug happening, but they didn’t affect gameplay. For example, one time the walls of the same hill caught the units that were unleashed near the base of it.

Otherways the gameplay was not so very great at all, might have had to do with the fact that it was vy late at night and both of us were rather tired. We both totally ignored the lower pathway… propably because of the game on the last replay, where that place had been mined solid.

Desyncs… that win/lenooks/osx pointer bug affecting replays isn’t the only one I suppose. We both playing on 94.0 64 bits multithreaded gave us live desyncs every time, and he playing with own compiled version of 94.1 on 64 bits debian (instead of the official statically compiled binaries) gave us desyncs at least every other time.

Which spring version introduced the turret hits problem?
I know Nemo is on osx nowadays but imo we’d be all better off if we went back to 91.+patchlevel until these nasties have been caught.


Yeah, unfortunately we don’t really have anything set up to take advantage of lobby support for multiple engine versions. Maybe I should start working harder on my little lobby project and investigate taking a little more infrastructure responsibility.


I see no trouble in that regard. AFAIK the lobby protocol only cares about one official release version that it thinks everybody should be playing but it is really up to the clients (SL,TASC,ZKL,QTL…) to implement it.

So it is up to the players themselves that they agree on the engine version. SL only wants a “DisableVersionCheck=1” in “~/.springlobby/springlobby.conf”; which should be changed only while SL is not running, otherways it might smack it (overwrite the conf file itself) when it exits.

There are two actual shortcomings still.
1.) There’s no widely agreed upon way to have multiple instances of spring installed on the same system. I’ve been doing this on lenooks but it is cumbersome to change between them (switch over a few symlinks; quit, reconfigure and restart SL). Of course this, and the fact that very often players in different “battlerooms” are already utilizing different engine versions, leads us to:
2.) Engine version should be “battleroom” specific and should be set forth in the lobby protocol foremost.

This would duly end our problems with the peregrination of engine development innovation.
That all said, there is no need for another lobby, nor for customizing one. Both clients I’ve dealt with (TASC and SL) provide battlelist filtering, and can ignore the lobby protocol enforced engine version that was talked about earlier. For now, this means that the used engine version has to be uttered in battle description.

A shorter replay(14min/453KB), other metainfo being the same as with the previous one. urki.anapnea.net/tmp/20130730_23 … _v2_94.sdf
I had asked Yuritch to spec as he could then record a demo on win32, but he had been unable to connect :frowning:
It occurred odd to me that G.I.-s seemed to single handedly blow away every single transport truck that drove past… thus no flying inf this time.


Well, they’ve made it happen. :open_mouth: I’ll take my words back. I’ll endorse #sy doing whatever they want with the engine.