call for testers of sync branch tvo3

[Tobi]

Hello,

To keep development of branches/tvo3 going (where I'm solving sync errors), I need testing input. Basically, I need A LOT of testing input, so I need your help.

As my first goal is getting it synced on linux vs. linux (where compiler version, architecture & distribution don't matter), I post here, in the linux forum.

So, what do I need?

Basically there must be played a lot of games (1 vs 1 should be good enough for now) on different mods & maps, using the code in branches/tvo3. Here follows a quick walkthrough:

1) Clean your current compile:

Code: Select all

scons -c

2) Switch to branches/tvo3, e.g. run from your trunk checkout dir:

Code: Select all

svn switch https://taspring.clan-sy.com/svn/spring/branches/tvo3

3) Then, follow the instructions in my how to sync debug document to build spring, run spring & postprocess the data outputted by the sync debugger if the game desynced.

4) Report the result here. Include, once for each client in the game:
a) gcc version (3 digits, e.g. 4.0.3), or other compiler name & full version
b) architecture (ie. i386 or x86_64)
c) linux distribution name & version (if applicable)
d) exact used "scons configure" line (yes, you must run scons configure after switching to my branch and before building it!)
And include once for each game played:
e) which mod was played? (e.g. XTA v7)
f) which map was played? (e.g. SmallDivide.smf)
g) which client was host?
h) did the game desync? (yes/no)
i) if the game did desync, get the infolog2.txt as it results from the steps in above pdf to me (e-mail, pastebin, [ code][/ code] block here, whatever you like)
j) comments (if you noticed anything exceptional)
k) Added: SVN revision number!

Forgetting any of these will severely cripple the use of the report, so please include all information.

Thanks in advance!

[malric]

Just an idea: as it can be hard for testers to 'sync' on the schedule, I tried to run spring from two X servers on the same computer and it worked.

I will try (eventually) to connect one game with the other, and to use two different versions of gcc to compile the different binaries.

Question: if I manage to start AI-s in both 'hosts' would it be ok for you ? (so that I do not have to play with myself :D)

[Tim Blokdijk]

Hello,

To keep development of branches/tvo3 going (where I'm solving sync errors), I need testing input. Basically, I need A LOT of testing input, so I need your help.

...

Can't this be automated?

[keithjr]

I get the following error when I try to switch to tvo3:

Code: Select all

keithjr@helios:~/src/trunk$ svn switch https://taspring.clan-sy.com/svn/spring/branches/tvo3
svn: 'https://taspring.clan-sy.com/svn/spring/branches/tvo3'
is not the same repository as
'svn://svn.berlios.de/taspring-linux'

That sounds like a stupid error... of course it's not the same! I'm trying to switch it!

::

[malric]

Can't this be automated?

That was the idea I tried to do also... But as I read on the forum that the rendering part can't be separated easily and I have just one computer available I will try running two games on one computer that play with each other.

That sounds like a stupid error... of course it's not the same! I'm trying to switch it!

I think you should first do:

Code: Select all

svn switch --relocate svn://svn.berlios.de/taspring-linux/trunk https://taspring.clan-sy.com/svn/spring/trunk trunk

The svn used now is on clan-sy, not the one on berlios (that ran out of disk space and for the time being is not usable). So it says you can't switch from berlios to a branch on clan-sy.

[malric]

Ok, me kind of stupid (or influenced by fullscreen play :D).

I started two games in windowed mode and connected one to another. (I have display problems in windowed mode - like trees looking funny and problems with resize so I do not like playing like that, but for testing it should do).

If I can get AI to play, probably I could automate all steps Tobi listed (I assume there is info about desynincg in infolog, so that after a desync spring can be killed and a new test game be started in an automatic fashion).

[AF]

Oh you can get rid of the rendering.

In a recent commit, rendering was disabled when spring was minimized so as not to waste resources on graphics that cant be seen.

This combined with a Virtual machine setup.......

[Tobi]

Just an idea: as it can be hard for testers to 'sync' on the schedule, I tried to run spring from two X servers on the same computer and it worked.
[... ]
Question: if I manage to start AI-s in both 'hosts' would it be ok for you ? (so that I do not have to play with myself :D)

I use the first thing myself too. You don't even need two X servers... just compile two binaries and run one as server, the other as client (preferably in separate data directories too or they'll overwrite each other's infolog.txt).

About AI's: Yeah that's fine (as long as you make sure the AI are actually doing something )

Not all tests should be AI only tho. Theres a chance AI exhibit certain behaviour patterns that are never performed by humans, or the other way round.

Also theres the "Random enemies 2" script I added more or less for this purpose (tho the talk about behaviour patterns applies even more here).

Can't this be automated?

I don't have all existing linux distributions installed here (and don't feel like doing that), so I need help anyway...

It's a good point though, I was already thinking about integrating the filtering of infolog.txt into the sync debugger (a little more automation), also I'll add a few commandline switches to help this.

I get the following error when I try to switch to tvo3:
[...]

You must relocate the repository to the new location first (see announcement in development forum), use (in your checkout dir).

Code: Select all

svn switch --relocate <current repo url> https://taspring.clan-sy.com/svn/spring/

Get the <current repo url> from "svn info". After that you'll be able to switch to branches/tvo3 on that server.

This combined with a Virtual machine setup.......

If my machine can handle that... I guess I'd just use chroots in that case... much more lightweight.

Anyway, I guess I'll work a bit more on automation. As AF says it's relatively easy to disable drawing code totally now so I'll make a commandline switch for that. Also I'll add a switch to automatically quit spring after someone won/lost or a sync error occured, plus I'll integrate the infolog.txt filtering in sync debugger (at least if that quit switch is used..).

[malric]

Great, please post here after you add the switches, so that I can try to test.

[Tobi]

I added a '--quit=T' / '-q T' switch. (Quits on game over or after T minutes [real time, not game time] have passed, whichever comes first)

I've decided disabling drawing totally is a bit to much work now (probably means I need to add a fully working console to it.. as no window would mean no mouse/keyboard input either).

You can exploit the current code tho by minimizing the window after game started: instead of drawing it will sleep a bit, making it much more lightweight then with window open.

E: bah I don't think straight... this would defeat purpose of automation of course because you'd have to manually minimize the window. I'll see if I can make a switch "start minimized" that minimizes the window as soon as the game is loaded.

I'm working on integration between --quit and sync debugger so the sync debugger triggers a quit too after it's handled a desync.

After that I'll see if I can make it filter the infolog all by itself too.

[Tobi]

Added a -m / --minimise switch, causes spring to start minimised. Don't be surprised by the trees if you open the window.

Also --quit now causes sync debugger to trigger a quit after handling one desync.

So now you have no more excuses to escape testing

[Tobi]

bah. Now I got some problems with FPU control words again, so if you get a failed assertion in Game.cpp, that's the cause. I'm investigating.

[Tobi]

Everything should be fine now.

E: bah... nothing is fine... even trunk with equal binaries desyncs currently, so no need to test until that's fixed & merged to my branch. I'll post here once that's done.

[patmo98]

I added a '--quit=T' / '-q T' switch. (Quits on game over or after T minutes [real time, not game time] have passed, whichever comes first)

Any chance this could be merged into the main tree? I think it could be used to pre-path maps overnight. Horridly ineficant, but noone would care if it was run overnight.

[Tobi]

Check the SVN log before asking!
I made it in trunk and then merged it to branches/tvo3 actually.

And yeah, it can be used for that. Just have a script generate valid startscripts each with a different mapname and start spring in sequence for each of them with '--quit=1' (linux) or '/quit 1' (windows). I just noticed --quit=0 gives a race condition so better use some time >0 for it (unless I feel like debugging it before release or you don't mind it crashing everytime).

[Tobi]

Finally I hunted down the (2 !) sync errors in trunk. All committed & merged to branches/tvo3 too so the testing can start.

[malric]

Ok, so I understood the different gcc versions should be used to obtain sync erros.

I will try to test:

gcc-3.4.6 (what I have)

with

gcc-3.3.6 (will hopefully emerge this night)

I could also try gcc-3.2.3 and gcc 3.1.1 ... What other people test ?

[Tobi]

I personally usually test 4.0.3 vs 3.4.6, either 32 bit or 64 bit (tho somehow spring stopped working from my 32 bit chroot so I haven't tested that for a while). With latest revision of my branch it didn't desync in a 100 minute random enemies 2 game.

[malric]

I will then try something similar (a gcc 4.x something I mean) as anyhow I'm having problems of emerging older versions of gcc...

(I would prefer installing gcc with Gentoo slot feature rather than 'by hand'...)

[Tobi]

Additionally I'm not even sure below gcc below 3.4 compiles spring correctly. At least I haven't tested that anymore for a long time.