Attack of Save/Load functionality is back

[Xeroxyster]

This is one of the oldest and dead-est horses but it still needs beating.

There are currently many bugs that cause Spring to crash (RAI random and Multiple AI's come to mind). These can ruin BOTH Single Player skirmishes and Multiplayer games. Having a manual save/load functionality would prevent A LOT of headaches.

Before anyone says it: Yes, I know that saving is possible, but loading is broken out the wazzo. While a multiplayer save/load function would be complicated to implement, getting a single player save/load is a good stepping stone.

P.S. Didn't we have single player save/load back in Spring v0.76 ??? I think remember loading a single player game once.

[lurker]

It's also worth trying to change the communication structure of some AIs to be nearly unable to take spring down with them.

[hoijui]

well.. there are lots of things i have to fix.
i already added some stuff that lets AIs fail gracefully. The thing is.. 80% of the crashes happen because of SIGSEGVS or similar stuff. on a SIGSEGV, i cna not do naything, and the whole game is doomed to crash. the only thing that coudl be done agaisnt this, is running AIs in their own processes. And honestly, this is too much work to be worthwhile. A much better approach is having more Java AIs, or other AIs running in a VM, which will throw Exceptions instead of crashing the whole application.
The application can still crash, but in 99% of the cases it will be cause of a bug in the engine (i assume the JVM(s) to be quite some more bug free then spring ).

short:
of course it would be nice if AIs were not able to take the engine down, but this wont ever happen for native AIs.
save & load could probably be fixed relatively easy (with little code), IF you knew where it is going wrong

i am currently heavily changing AI instance management, and if i am in the mood, will try to fix load & save once more after that, somewhen. before this, it makes no sense.

[REVENGE]

Right, so do we have any idea where the saving/loading is going wrong?

Also, how much of this has to do with the resync code that's been talked about for a long time? What's still needed to make it happen?

[lurker]

on a SIGSEGV, I can not do anything

...why?

[hoijui]

on a SIGSEGV, I can not do anything

...why?

What could i do then?
You seem to know something i dont; please enlighten me!

[eyu100]

on a SIGSEGV, I can not do anything

...why?

What could i do then?
You seem to know something i dont; please enlighten me!

You could ignore it...

[hoijui]

that is not possible, and if it would be, it would be a very bad idea to do it.
it can be catched, dan then could be ignored, but not for AIs only, and as said.. it would be stupid anyway.

[Xeroxyster]

I can see from the above posts that the AI loading problems are obviously very complex, but if we just leave those to the AI developers they will eventually be fixed. The Spring-wide problem is getting a basic save-load functionality. The AI-devs can fix their AI's after we fix the engine.

Getting back the to the meaty-side of my request:

Saving works fine (exempting AI's not saving their current state). I am very greatfull to the developers for that.

The problems I see are on the loading side (some may have the root problem in saving... I don't know enough to say). The ultimate bug/error (which stops all the work-arounds I've read and tried) is the "pause" effect when you reload the save manually, via the testspring.exe. If I understand the posts correctly this is not actually a "pause" but rather spring never advancing to the next frame. Whatever it is it prevents all commands to units and freezes all unit-actions.

I (and other players) wouldn't mind having to go through testspring.exe to manually load saved games, but it is important that it become possible to Load/Save if not convenient... the convenience will come in time but it first must be possible.

[hoijui]

i am currently heavily changing AI instance management, and if i am in the mood, will try to fix load & save once more after that, somewhen. before this, it makes no sense.

[Xeroxyster]

Opps, sorry. I missed that part of your post.

Thank You Hoijui!

[eyu100]

that is not possible, and if it would be, it would be a very bad idea to do it.

(on Linux)

Code: Select all

#include <signal.h>

signal(SIGSEGV, SIG_IGN);

I didn't say that it was a good idea, just that it was possible.

EDIT: changed code

[hoijui]

as i already described, this catches the signal process wide, which includes the engine and all of its AIs. capturing that only in the AIs is not possible as long as they are not running in separate processes, which is, as i said, never going to to happen cause it is to much work with practically no benefit. if you really want that AIs are unable to take down the engine, the best solution is to make a headless spring and run the AIs in a separate instance of the engine, which connects as a separate client.
-> less work & all fial safetly comes for free & we get a headless spring which is usefull for other stuff too

[Auswaschbar]

if you really want that AIs are unable to take down the engine, the best solution is to make a headless spring and run the AIs in a separate instance of the engine, which connects as a separate client.
-> less work & all fial safetly comes for free & we get a headless spring which is usefull for other stuff too

This is also usefull for multicore CPUs, as you have to do the sim at least twice. Finally people could max out all their cores.

[jK]

if you really want that AIs are unable to take down the engine, the best solution is to make a headless spring and run the AIs in a separate instance of the engine, which connects as a separate client.
-> less work & all fial safetly comes for free & we get a headless spring which is usefull for other stuff too

This is also usefull for multicore CPUs, as you have to do the sim at least twice. Finally people could max out all their cores.

and finally your new 4GB DDR3 could be maxed out, too

[hoijui]

thats the big downside, which i though would be seen by anyone anyway.. but yeah i should have mentioned it maybe :D

thing is, this is still the best solution
or better said: the only one which is somewhat realistic to ever happen.
except.. the already mentioned best scenario of having only virtual machined AIs.
does a C++ virtual machine abstraction layer framework exist?
or just use sane languages with Virtual machines.

[lurker]

In a signal handler you can't check which thread caused it or a global var of 'in an AI' or the stack trace and then continue the normal abort path if it wasn't an AI? And then if it was an AI I would think you'd throw an exception to back out of it, or if it's a thread just kill it.

I think by default using a separate signal stack is off and you can just throw without any real effort? If anyone has a good reference please link it.

[imbaczek]

there's zero guarantee that a sigsegv sent while in an AI callback is actually caused by the AI. it can be caused by a spring callin or any library the AI links to. additionally, Java VM uses the SEGV for garbage collection IIRC.

[lurker]

If it's caused by spring, then by not crashing you lose early detection before spring itself has an error. Not a big deal.

If it's caused by a library that an AI links to, well, I don't really see why that matters. It either caused the error in AI data or in spring data, and that's what I care about.

That could be an issue with Java. How does it handle it if you use something else with the same GC method, or have multiple instances of Java? Will it chain handlers if you set up Spring's before you init Java?

Edit: Finally found it, a debugging guide says it uses SIGPWR and SIGXCPU, nice harmless signals. If that's wrong show me.

[imbaczek]

re java, i recall discussing issues with hoijui. nevermind.

libraries are a bigger deal than you make them - a lot of them have global state in dlls and if somehow an AI uses the same dll that spring uses, it's not going to end up pretty.