Spring RTS Engine

Ok. I finally compiled with gcc-4.1.1 and played some small games but they went smooth, no problems. I will try to do test with AI so that I can add more players, and leave the computer running...

I assume you tried with multiple clients, preferable binaries compiled by different compiler versions?

Yes. One gcc-3.4.6 vs gcc-4.1.1. (in two windows, and I played both for 10m or so). No sync errors. As I can't play this way to long I will try with AI.

Ah that's nice, maybe you can try random enemies 2, at least no chance for crashes (I still don't really trust AI's ). Just ignore it if some side wins and leave it running for 2 hours in game time or so. If it then still hasn't desynced then that's good :D.

E: Btw if trying random enemies 2, useful ingame commands are .setmaxspeed 10, .cheat, .spectator, and the plus key to actually increase speed to whatever your computer can handle. That way you can play 2 hours in game time in 15-30 minutes real time

Thanks for the info, the game was already started with speed around 6 (but looking at processor stats with window minimised I think I can increase it...)

So 55:00 game time and no sync errors.


Do you think it would be better to test several games (I mean run a game for two hours game time and then restart) ?

Or should I let it run one night and see if they will be sync errors ?

A full night would be interesting

but actually I got the experience that if you don't have sync errors within 30 minutes or so, it's very unlikely they pop up later. So I'll leave it up to you.. if you don't care about the electricity bill / noise of your PC.. go ahead

Ok. So after 4 hours of realtime running (I do not remember exactly how much game time was), there were no sync errors.

I will try next several games (with the game time limitation set to 1 or 2 hours), and afterward I will play with map/mod/script settings or AI.

I will post of course if (or when :p) I will get sync errors.

(About running at night - I sometimes leave the computer running when downloading things as I do not have the best internet connection in the world.)

try nanoblobz .53 or cvc 0.02, they seem to show up things differently and might expose a few errors

I've some good news too: just ran a 140 minutes "random enemies 2" game on SmallDivide with XTAPE V7, was me on Windows with a MinGW build (gcc 3.4.2) vs. Demitar on Linux (gcc 4.0.3 build), without any sync errors.

Also we played a XTAPE V7 game on SmallDivide but that was finished after 30 minutes (no sync errors).

Then we played an AA 2.11 game on Mars but that crashed because of an floating point exception after approx. 15 minutes , no sync errors tho.

That's really good news !

If that cotninues does that mean all linux/Mac and windows mingw32 x86 builds are sync compatible? Thus leaving only powerPC and VS7/8 builds to test?

If by Mac you mean Intel Mac (which I assume because you mention PPC later), then yes.

yay!

This is starting to sound truely promising.

I am getting all excited again.

Great to see it works! Also nice that you did not invest all this work only to find out it would not work. You spend several months on this.

noooo
Blah, guess pull all 1->2 all nighters over weekend on getting lobby support into spring-gui. (note some support, see how much can get done)

No pressure, we still need a few good open source mods

Well we don't have to have open source mods, why would we?

I may be asking a stupid question there.

And haha @ hollow, more work for you

It's better if we have - if we don't have, then we just have an "empty" engine which can't do anything by default, and users must first go to some random website to grab content. That would easily scare away new users. Even if the default mod isn't popular, there still must be one (an open source one), just because in the end you want it to be "install & run". At the same time I think that a really bad default mod could maybe scare away even more users.

hollowsoul, no need to hurry, it's not as if this gets merged in trunk tomorrow, there's still a lot to do: There needs to be more testing, esp. with mods != XTA. I (or someone else) needs to fix compiler errors with MSVC, try to find the right combination of options so it works most of the time, and then debug the desyncs (because I'm convinced MSVC vs GCC will give some desyncs again). Also the build system must be made less hackish or maybe even rewritten because mixing make & scons as I do now in my branch isn't a really good idea after all , and quite possibly I forgot some stuff which needs fixing before a merge.

Well i don't see why the current XTA wouldn't do as the defualt mod like it is on windows?

Just because linux is open source and a lot of programs and games for it are, doesn't mean the mods to an open source game have to be open source to start off with for linux gamers.