mapName Deprecated

RogerCooper

Recent changes in the prerelease have deprecated the mapName property. Mods will no longer work unless all the files are with the mod, you can no longer use mapName to point to another mod.

I do not like this change. XML-only mods are a definite convenience and disallowing them will force needless duplication of files and increase the file size of mods.

Multi-map mods become impossible. For example if I wanted to have a mod that adds upkeep costs to variety of scenarios, I would need to have a separate mod for each map.

For some discussion of this see the following GitHub thread.

What do people think? Is mapName obsolete or a useful feature?

SilverBullet

@RogerCooper i am not into the "tech side" but i am hoping things get easier for you guys, good luck.

LaFayette

These two threads also discuss the transition of map-name:

I'll be working on some documentation for 2.6 to help explain the differences and changes to map folders to help keep it more concise. Look for that in the coming weeks.

Re: map-name, for more context. Official support for 'variants', AKA mods, was ended nearly 4 years ago. Though we never broke the mechanism that allowed one map-folder to fake the resource loading to come from another folder. Hence, unofficial variants still worked.

In 2.6, instead of using a map-name attribute to find a folder, the engine will scan maps to find one with that same map-name. To try and explain, previously the 'xml-attribute' specified which map folder the XML lived in. The XML basically said, "use this map folder" to find the map assets. One implication to this is the engine does not actually know where an XML came from. There are further implications to this for both auto-download of missing maps and further reducing save-game size (which is the dominating factor (the dominating slow-down) for AI performance).

In 2.6 and post, the 'map-name' field will be used to both identify and find maps. The map-name property will still be stored with the XML saves (.tsvg) files, and instead of using that property to find a folder, the engine will scan for a matching 'mapName' property. There are a number of implications to this, but one notably is that XML files will no longer each need a 'mapName' property.

I believe the real question at hand is whether it can be expected for unofficial variants to be kept working without modification in 2.6 and above, something where official support ended some time ago. There are some options available, but perhaps at a cost. I don't know if unofficial variants could escape without requiring some sort of changes. I think then it's a balance to weigh whether those variants should be fixed up in one way, or whether they too should be fixed how official variants were and have assets copied into those maps.

LaFayette

@LaFayette said in mapName Deprecated:

There are further implications to this for both auto-download of missing maps and further reducing save-game size (which is the dominating factor (the dominating slow-down) for AI performance).

I'd like to clarify this. AI performance is dominated by battle calculations. Any battle calculation begins by first taking a full save of the existing game. It's been measured that over 80% of the time involved in battle calculation is at this step. This implies that AI is slow at later game stages as this full copy and load is slower and slower the more game history there is.

A save-game contains most of the data found from an XML. This data is expanded into game objects that take up a fair amount of space. We are designing a change to save-games so that the engine only saves the differences to game state after initial load. This should result in a drastically smaller save game file, and importantly it allows for much greater compatibility between game releases. It is very possible that after we make this change, all future TripleA games will be save game compatible. It will also be a boon to development, currently very seemingly innocent changes break save-game compatibility, the inability to make those changes create other headaches and essentially trashes the ability to fix core code architecture and design. Long story short, at some point the engine will need to know where the original XML file is located when loading save games as it will need to load in data from that XML file.

TL;DR, with 'delta' save-game files we expect save-game compatibility will be maintained for many releases going forward and no longer a year at a time. It will be a major benefit for code development and increase developer productivity. And, AI is expected to get something of a 10x boost in performance.

To do 'delta' save-games, I think we can likely do so without needing to modify existing maps. Having that work for 'variants' was not considered (until now it's been something of a distant memory). We would need to fix variants in some way if they were to keep working like this. Long term though there is already a different solution envisioned where all games XML files would be released independently of map files and map files would become 'graphics packs' that XMLs could pick and choose. The engine would automatically determine which 'graphic packs' are required for a given XML and download them automatically.

My hope is that delta-save games could be released before the end of 2023. It's a much higher priority than graphics packs. Meanwhile having a maps-server, a requirement for a graphics pack, which provides additional benefits, will be released likely in the next month or two.

TL;DR: delta-saves will not work at all for unofficial variants, they need to be modified one way or another. Long term there is another solution envisioned that will 'fix' variants so that game XML files are already independent of map assets. 'Delta-save-games' is currently planned to be released first before map 'graphic-packs'.