Terran Accellerators models?

[Imperial Good]

I don't understand why you guys so much against save game incompatibility !
They are a lot of games that make you have to restart a new game with very big updates, You guys gave us 4 years of great improvements and always kept save game compatibility, I think after 4 years you can make an update that's not save game compatible and tell people "okey if you want to finish your last game don't update or revert your game version to 4.2 and those want new stuff update to 5.0"...

Because this is one of the most trivial reasons to cause save game incompatibility. Literally it is model swapping some accelerators which functionally work fine as is.

[Matterom]

So the problems i can think of.. and the few that i ran into while looking for a scripting solution..

There is no way to replace the specific object after it is baked into the save. The solution to this is probably an external script or an engine level update script that selects the specific locations in the save file and performs the save surgery.

I'd hoped to try and swap the model through a destroy create object swap, because when you change the macro in the way the mod is implemented it will change the resulting gate dynamic, its looking for a connected object that is not matching the object in the location so it breaks the link. But when you destroy the model it still breaks the link anyway. The solution to fix that method would be to have a inbuilt way to create new gate connections and remove old ones. Which is probably a good addition anyway but that's definitely some hub level stuff.

The third way i can see fixing this, is again deleting the accel gates, but creating a whole new set of accels to replace them afterwards. Quite a bit more involved and definitely a dirty fix, and probably not new save game compatible either.... lot of problems with that one but it would update existing saves.

[mr.WHO]

IMO "fake" restart where you import your stats, assets and universe composition as accurate as possible (but not perfect if not viable) would be good trade-off if it would allow more advance updates that breake save-game compactibility.

This could be new form of budgeted gamestart where you load unmodified save game and the game try to import as much as possible from it (again as I said perfection is not required, just good enought approximation).

[Bozz11]

I don't understand why you guys so much against save game incompatibility !
They are a lot of games that make you have to restart a new game with very big updates, You guys gave us 4 years of great improvements and always kept save game compatibility, I think after 4 years you can make an update that's not save game compatible and tell people "okey if you want to finish your last game don't update or revert your game version to 4.2 and those want new stuff update to 5.0"...

Because this is one of the most trivial reasons to cause save game incompatibility. Literally it is model swapping some accelerators which functionally work fine as is.

sur but they are other things like solar energy production, I would like that in every systeme would add more strat. planing for your factories

[xant]

I think this is where X-22 comes in, which I hope is a standalone expansion that includes all the features that would otherwise break save game compatibility.

Because yeah, keeping everything compatible for 4 years, onyl to break it for a small model swap? That would be absurd.

[Imperial Good]

sur but they are other things like solar energy production, I would like that in every systeme would add more strat. planing for your factories

And that needs a save wipe? I think editing the values carries straight through as the link is to the data and not save file.

[mr.WHO]

sur but they are other things like solar energy production, I would like that in every systeme would add more strat. planing for your factories

And that needs a save wipe? I think editing the values carries straight through as the link is to the data and not save file.

Leaving 100% solar power was not due to save-game compactibility, but because Egosoft didn't wanted to aggro people who build mega-complexes to find they self-sufficient super-base now doesn't have enough solar panels.

Personally I think it's non-issues as, if you have megacomplex then moving and adding some solar panels is easy thing.

Still there is a stack of many such things already:
- Terran Accelerators
- Solar power in various sectors
- copy/paste stats for existing ship
- medium turrets copy/paste of bullet stats

I do hope for X-22 to be next X4 stand alone.
Currently we do know it's a stand alone game, but it could be unrelated to X4 or completely different (e.g. Mobile or Multi-Player).

[Raptor34]

I think this is where X-22 comes in, which I hope is a standalone expansion that includes all the features that would otherwise break save game compatibility.

Because yeah, keeping everything compatible for 4 years, onyl to break it for a small model swap? That would be absurd.

I'll rather they wait tbh. Figure out all these little things.
Remember that back in X3 almost anything breaks save compatibility.

[Caedes91]

Is it possible to create a savegame updater/converter?

[mr.WHO]

I'll rather they wait tbh. Figure out all these little things.

IMO, given the previous timelines and reveals, unless there would be some delay, we should expect X-22 reveal somewhere around September/October.

Alternatively, Egosoft might decide to milk X4 more with additional DLCs, but I think the main reason for X-22 is because they are coming close to eat their own tail with DLCs (good example of such is Stellaris that kinda fall under it's DLC weight last year or two).


This is just a guess, but it might also make sence to go with X-22 in order to make game work with Borons.

[adeine]

This seems like the best way to handle cases like this.

I do not think it is that easy. I think the problem is that only some of the data is saved in the save file while the rest is pulled from the game data files. Updating the model in the game data files causes it to be inconsistent with the associated data stored in save files, hence rendering the save incompatible. Usually some form of migration script is used to make the data consistent after loading an older save but in this case it might not be possible or enough to support this change.

So the problems i can think of.. and the few that i ran into while looking for a scripting solution..

There is no way to replace the specific object after it is baked into the save. The solution to this is probably an external script or an engine level update script that selects the specific locations in the save file and performs the save surgery.

I'd hoped to try and swap the model through a destroy create object swap, because when you change the macro in the way the mod is implemented it will change the resulting gate dynamic, its looking for a connected object that is not matching the object in the location so it breaks the link. But when you destroy the model it still breaks the link anyway. The solution to fix that method would be to have a inbuilt way to create new gate connections and remove old ones. Which is probably a good addition anyway but that's definitely some hub level stuff.

The third way i can see fixing this, is again deleting the accel gates, but creating a whole new set of accels to replace them afterwards. Quite a bit more involved and definitely a dirty fix, and probably not new save game compatible either.... lot of problems with that one but it would update existing saves.

This seems like an oversight in what ingame scripts can do rather than an inherent limitation. In other words, something you couldn't fix with a mod, but not really an insurmountable obstacle when you have access to the engine to add such a function.

You wouldn't want to change the model in the data files in the first place since you're not trying to replace all of the accelerators, just those in certain sectors. So you'd want to edit the data in the save game to point to the other model and update any associated data.

Presumably you can already do this with other types of objects (otherwise I don't think a lot of the updates we've had would have been savegame patchable), but the accelerators actually linking sectors is the sticking point? Again, this seems like something the engine should definitely support - otherwise you'd never be able to implement anything like the hub plot, or any sort of dynamic gate remapping. Obviously I don't know the underlying code, but assuming it's decently structured it shouldn't be too hard to implement.

[Imperial Good]

This seems like an oversight in what ingame scripts can do rather than an inherent limitation. In other words, something you couldn't fix with a mod, but not really an insurmountable obstacle when you have access to the engine to add such a function.

It is not so much a case of being possible, but a case of being viable. Any sort of engine change needs work and if that work is spent on one thing it cannot be spent on another. Adding support for this would mean some other engine feature or game change would be delayed by the required amount. All to change a model on a gate that does function correctly as is. The priority could be quite low, especially given the approaching launch of Tides of Avarice.

[adeine]

This seems like an oversight in what ingame scripts can do rather than an inherent limitation. In other words, something you couldn't fix with a mod, but not really an insurmountable obstacle when you have access to the engine to add such a function.

It is not so much a case of being possible, but a case of being viable. Any sort of engine change needs work and if that work is spent on one thing it cannot be spent on another. Adding support for this would mean some other engine feature or game change would be delayed by the required amount. All to change a model on a gate that does function correctly as is. The priority could be quite low, especially given the approaching launch of Tides of Avarice.

If the issue is sector connections cannot be created or broken by scripts, it's much more than just an aesthetic change. Seems worth bumping up the priority queue, especially when considering new expansions that may want to use the feature.