Spring RTS Engine

Hoijui, that does not fix anything in Evolution RTS. The crash still happens.

http://code.google.com/p/evolutionrts/s ... ptions.lua

I also noticed this in debuglog: Spring is in isolation mode... Why is unitsync returning C:\Users\Forboding Angel\AppData\Local\springsettings.cfg?

if you still crash without cursed, then it might be an other mod, or a compleetly other problem, thus we would need a new translated/translatable stack trace.

D:\Evolution RTS Standalone clone\

Is a clone of my standalone Desura installer (Desura is implementing standalone installs). All it is is Evo + maps.

Can I run the debugger on my end easily without having to have some sort of +5 IDE whatsawhosit compiler hoohaa of brokenness?

If absolutely necessary I can zip of my clone so you can dl it.

Does modoptions have anything to do with maps? Could unitsync be reporting it as modoptions issues when it's actually mapoptions issues?

Unfortunately I'm utterly powerless to test that theory atm. I'll give it a try tomorrow if I can.

As I said in the post linked here, I identified same crash in getMapOptionCount with certain maps, so yes I would say it can be some of your maps which trigger this crash too.

It's not a map causing this. Left only evo 196 and small divide remake in and it still crashes.

It's a lobby bug. Confirmed and now I know how to reproduce it.

I left only evo 196 installed and small divide remake in. Deleted .lobby, and ran it. Started up fine and let me join the game correctly (except it was saying that I was unsynced). I closed the lobby, restarted it, tried to join the same game, boom crash.

Easy to reproduce.

Yes. It's a lobby bug, because first start is incorrect. When you see "unsynced" state it's mean that getModOptionCount not called. In second launch you catch crash. I'll try to launch evo mod (evo:revision:196) and submit backtrace.

I check option.cpp source and found as in previous crash was caused by thrown exception: throw content_error().
In case of evo:revision:196. It's called in Option.cpp:153 But It must be catched in try...catch block of function

option_parseOptionsInternal

at Option.cpp:187. Instead it cause crash.

That's pretty useless to everybody that cannot access your source, isn't it?

The function above is from Spring git. https://github.com/spring/spring/blob/d ... Option.cpp
I can share my test code, but to compile and run it you should install Qt libraries. I'm use (4.7.4 version).
I think error's reason is different compilers. Notalobby used mingw 4.4.0 and unitsync - 4.4.4. I'll try new compiler version.

Finally someone begins to understand the problem ...
It is not a (pure) unitsync issue, unitsync throws an exception _but_ it should get catched _in_ the unitsync. So if this doesn't happen it must be a problem between lobby & unitsync.
So lobby devs need to do a little bit more than saying "it crashes".

Is it perhaps a problem that the unitsync gets build with dwarf2 exception handling and the lobby uses sjlj? and if so does it matter if the unitsync is static or dynamic linked??

Sorry for noobish troubleshooting )))
Lobby used dwarf2 exception handling and unitsync.dll linked dynamicly. But unitsync and lobby use different libgcc_s_dw2-1.dll due different mingw version.

I found the solution to this problom. It is cause by games that have an old version of engineoptions.lua which has the option for diminishing mms.

Obviously it returns to unitsync with unknown because that no longer exists, However, unitsync should be smart enough to pass by without throwing an exception. Or maybe throw a soft warning. As it is now, unitsync causes everything to implode.

To fix it, just copy and pasta engineoptions.lua from spring base content into game (actually, it is quite possible that the game doesn't even need engineoptions as it is in base content anyway).

Unitsync code is right. It uses exceptions to catch "soft" error (bad options) not checking error status by value like Qt way.

In NotaLobby "try catch" doesn't work in shared library (UnitSync) - mingw problem.
Not confirmed

any news an this issue?

we need to fix some little issues.
and then we try to rebuild using microsoft compiler first, then another version of mingw
news will be these weekends or next week

We compiled Qt libraries using compiler msvc2010, and built NotaLobby using them. The crashes was gone!
Then we used mingw 4.6.1 with sjlj exceptions from TDM bundle to recompile Qt and NotaLobby again. All works fine! Crashes did not appeared.