Spring RTS Engine

As a widget?

Yes. Mainly because IIRC, Gadgets still aren't allowed to use io (unless that was fixed).

Save current game will never be universal as long as it rely on a gadget.

Well, then perhaps I need to write that entire Gadget code into a script.txt. I mean, my saves are just raw instructions, should be possible to stick it in.

Can valid Lua be put there, if you terminate it with ; ?

If not, I was thinking I'd just write the script.txt to use a ModOption that a Gadget would read and then read a savegame- still would require mod-side support, but meh, it'd be so easy at that point that I could just post, "hey, savegame support is here" in their sub-forums and voila, everybody would have savegames on their next release.

And yes, Universal AI is a joke

wouldn't that interface be more useful implemented in lobby?

See other topic: Engine devs don't want to code any save/load system.

Even if they did suddenly say, "hey, that might not be a bad idea", I would still want a solution that wasn't hardcoded and inflexible, tbh.

zwzsg wrote:See other topic: Engine devs don't want to code any save/load system.

Not entirely accurate. Engine devs DO want to work on this, however most are busy doing other things. Some (game devs) are working on it but progress is slow because the task is difficult.

Argh wrote:

zwzsg wrote:Save current game will never be universal as long as it rely on a gadget.

Well, then perhaps I need to write that entire Gadget code into a script.txt. I mean, my saves are just raw instructions, should be possible to stick it in.

Can valid Lua be put there, if you terminate it with ; ?

Uh, must be an Arghuism.

Argh wrote:If not, I was thinking I'd just write the script.txt to use a ModOption that a Gadget would read and then read a savegame

Yo dawg I herd you like script.txt so we put script.txt in your script.txt so you can reload while you reload? Personnaly I just dump all the info the savegame need as modoption in the script.txt.

Argh wrote:I'll filter out the rest of that type of orders from this code, but I am certainly open to looking at your system if you can build a UI that's stand-alone, so that BA / CA / NOTA / etc. can just drag-drop a file or two, and have instant universal savegame support.

That's basically what I've done in GUNDAM1.21SP4.sd7.

gadget cannot write files
widget cannot see the enemy units

So at least two files would need to be included in each mod.

That mockup is ghastly, I hate how they just have a list of names for savegames

They could at least put a thumbnail with a minimap or a screenshot so we dont have to guess what the arbitrary name is

Take a screenshot and render it with a game time in the corner along with player name and faction logo

I've a patch that adds support for zip file reading and writing. I planned to make the engine create such a userdatum and pass it to new LuaRules call-ins Save and Load, but didn't get around to that yet.

Is it useful if I finish this, so loading can actually be integrated with lobbies etc. without countless hacks, or do you rather just implement everything yourself?

IDK whether that's a good idea or not.

The Lobbies aren't really designed to be frontends. They've had SP functionality (where Save/Load matters) added to them, but it was added as an afterthought, and it's never been presented well.

Any RTS in the commercial world can and does put SP first, and their entire designs are predicated on presenting that in as simple a way as possible. So... tbh, it's like putting fancy paint on a Yugo, imo- the Lobbies are well-designed for their main task, but I think they should get out of the SP business entirely, because they'd both need to be substantially re-written to do it all that well.

I'm open to argument about this, but I'd like to invite people to open their minds, open either of the Lobbies, and count how many clicks it takes to play a SP game (and how intuitive the process is) vs. the clicks / flow of starting a SP game of WarCraft III, Dawn of War, etc. It's a completely different experience, and most of that reflects design choices, not how much more amazing those commercial coders are. Personally, I don't think it's appropriate to put a lot of effort there, but who knows, maybe this discussion will be productive in that regard, or new developments will make it moot.

Ok good, that saves me some work

Good luck getting it all to work in Lua only

I already have most of the savegame format working.

It filters stuff like Guard and performs a delayed search to pick up valid unitIDs at this point. However, some of those Commands, even if re-issued, are failing even when it has a valid unitID, and I don't know why just yet, so I'm still working on that aspect.

After that... it's just a matter of writing the savegame's startscript and the restart commands and building a proper UI.

OK, I've written the savegame Gadget, which writes the appropriate script, using a Widget to handle writing. That part took a bit, mainly because of the method I ended up choosing to use to make it all work as planned.

Now I just have to write the reference to the right savegame, write the startscript and the final loader code and a simple GUI to handle it (short of the kind of UI I'd like, I'll just develop a quickie button one that's reasonably pretty), and I'm done. Should be able to hand out the source for this soonish. The final code will consist of one Gadget and one Widget that handles everything (will not require configs or anything, just drag-drop-done), I think, and some media files for the UI and background, so it will look OK. Still have to figure out how I'm going to present certain information to end-users, but I'll cross that bridge tomorrow when I'm dealing with the UI.

Your missing the blatant problem that to work with your system requires heavy AI customization for any AIs that do more than the basic command task chains

That is a problem AI developers are responsible for solving.

If their AI is so poorly designed that it can't handle simple save states, then I guess they need to fix that.

saving/loading MUST be engine side ... stop doing lua crap and work on the engine

Lua save states are just fine, and don't require an engine dev to fix in the event that they get broken.

If the AI's can handle getting re-initialized, then that's pretty sad.

Satirik wrote:saving/loading MUST be engine side ... stop doing lua crap and work on the engine

what about mods that have to use lua ais?

because that is where my project is going and frankly, it would make more sense to use a lua based save.

smoth wrote:

Satirik wrote:saving/loading MUST be engine side ... stop doing lua crap and work on the engine

what about mods that have to use lua ais?

because that is where my project is going and frankly, it would make more sense to use a lua based save.

it should be engine side, and provide some lua function to extend the system to what cannot be done engine side

There's a GetSyncData() call-in defined in LuaHandleSynced.cpp.
It's was never finished, but the idea was to allow the synced side
of a script to save the data it required to reload from a replay
file. You might be able to use something like the lua Pluto library
to help generate the state data (but be wary of userdata and the
such).

it should be engine side, and provide some lua function to extend the system to what cannot be done engine side

Why? That isn't a functional requirement, and it would make everything a lot more complicated and harder to debug than what I have thus far, which is only about 300 lines of code (it'll double, I'm sure, by the time I'm done writing the UI, but it's a pretty short program and a very clean design).

The design I'm building uses a standard location for saves, no matter what game you've been playing. It may or may not become a "standard feature", and I am certainly not claiming that this code is anything like final- this is just the second attempt to solve this major problem with Spring's design, after all- but if something like this becomes the standard, then Lobbies can just read the data from the same locations my Widget does.

Let's cross that bridge when I have something that's fully functional to present. For that matter, it would be wise once I can show this to compare / contrast it to the methods zswsg's using- there are advantages and disadvantages to both, I'm sure, and we can and should talk about that before deciding on anything.