Oolite Bulletins

If he wants to rewrite game saves completrely then I guess its cool.

We *really* want to maintain backward compatability for existing save games. Also, if anyone (Frame?) does do this, then they should be aware that people will be mighty annoyed if a savegame ever gets corupted or fails to work as expected, and there will almost certainly be a large amount of support called for -- so I dont think anyone should volunteer lightly.

Edit: I dont use save-anywhere, so I dont know how it works. What happens if I dock with a station from an OXP, save, and then remove the OXP and reload? Does it randomly select another station? Will it still work if there is no main station at all.

Maintaining backwards compatibility is reasonably simple (one of the nice things of XML) - just add a new section 'system' to the save-file. If it doesn't exist, spawn-generate the system data, otherwise populate the current system using the data in the save-file. This way even an older version of Oolite can load a 'new' savefile - it would just ignore the new data.

As for size, we could just zip up the savefile - it's what OpenOffice does for example.

However, those are just the 'simple' issues. There are loads of avenues for trickier problems, such as ensuring all loaded entities are in correct AI states, escorts have the correct mother, etc. etc. etc. It certainly wouldn't be a trivial task to ensure it all works correctly.

Cmd. Cheyd wrote:

On potential caveat...

It would likely require recoding of all the "Look and Feel" OXP's... Could you imagine making the harrowing journey to a new system, never before encountered by GalCop society... And finding a Mall-Wart ConStore in orbit? Talk about a mood-killer

Since this is on the hard-code level... we could "disable" custom stations from spawning, unless they specific are flagged as "Frontier-station", that could even be implemented into roles.

Regarding me writing anything for Oolite Src. At this stage, the only thing I would promise was me tinkering with the code since, I only know C++. Java i picked up via Oolite, but it is much like C++. as is the Oolite code.

In fact, right now, I do not know the name of the language that Oolite was written in.

But it would be fun to tinker with... And I'm sure I would find a solution.. and regarding all that stuff with viewing code as "relics".. My response to that.. Why reinvent the wheel... ? You cannot possibly compare software to hardware...

Writing Oolite was a massive effort, therefore a rewrite of some of the fundamentals would not be without effort.

Galaxy Expansion, hell yeah, but with reasonable caution. in regard to continuity and everything else.

Its funny, cause i have project going on, in my text editor, that is an OXP for Oolite, that will use the jump-gate code, to create places that you can explore.. But on a much simpler level.. than creating solar systems...

Of which many bugs that prevented it from being completed has since been, solved by Kaks I believe. And I may return to that, when 1.73 is released..oO { and I fix that major error I found }

Oolite is Objective C, not C++, the differences are enough to get you into trouble...

DaddyHoggy wrote:

Oolite is Objective C, not C++, the differences are enough to get you into trouble...

my middle name.. ..

Well I started with C, but was quickly turned to C++

@Cmdr James
Complete with typos , I could list the code for these checks too, but they are there...

If save-anywhere requires a main station, then is it still posssible to adapt this approach to work in "new regions of space" where there is no main station.

I guess there is always a way. We could have alient "stations", which dont even need to have a dock but would work from a saving perspective.