General 2.6 Discussion

LaFayette

@rogercooper The map.yml can have comments. It'll be odd though to put those comments for version changes as it's unclear which game.xml file, if any was changed. The map description file is likely a much better place for comments intended for users, otherwise the 'git commit' comment is exactly the right place for such change comments, that is 100%what that is for (and it stores the author, the exact diff of what was changed, and timestamp automatically without cluttering up any data files).

RogerCooper

@lafayette I would soon be ready with my hoard of collected scenarios. The majority of these scenarios use the map information from some existing mod. It makes sense to collect the xml's in something like World War II Global Variants. If I add new xml to a mod, it would be good to have a place where I can show that explicitly, not just change the version number.

Cernel

@lafayette said in General 2.6 Discussion:

@Cernel the map.yml file should be at the top level. The engine will only look for XML files specified in map.yml. This will actually break maps that do not have one, though, there is the code to auto-generate a map.yml file in place if a map is missing the file. At some point it would be great if we could re-aggregate all maps such that we can upload the map.yml and then won't have any problems when the map.yml auto-generation code is removed.

Top level? You mean that a map in the format of
downloadedMaps/the_pact_of_steel/games
will have the
map.yml
file together with the
map.properties
file, wherease a map in the format of
downloadedMaps/the_pact_of_steel/map/games
will have the
map.yml
file a folder behind the
map.properties?
If so, that is highly inconsistent, especially with the fact that, currently, all files that stay in a directory like
downloadedMaps/the_pact_of_steel
if there is no
map
folder inside the directory,
are meant otherwise to stay in
downloadedMaps/the_pact_of_steel/map.

I think it is rather obvious that something called map.yml should stay in the same folder as something called map.properties, that is both should stay immediately within the map folder if the map.properties is reputed to be in the right place. How is it not going to be confusing having two "map" files (one yml and the other one properties) in different places?

This links up with the fact that, as I said, instead of having
270bc_wars/map/games/270BC_Wars.xml
you should have
270bc_wars/map/games/270bc_wars/rules.xml.

About the version number, it should never be called as just version (to avoid confusion with the game version, which (you want it or not) will remain something defined by at least some map-makers, no matter if you remove it, because every time you change a map's game without changing the game's name you have a new version of the same-named game, and this is a fact no matter if the program misses to inform the users about any difference before starting the game) and should be at least a two digit one: the first digit for non-backward compatible changes (meaning that your saved games may be not anymore playable if you update the map) and the second digit for backward compatible changes (meaning you should be safe to update the map with no fear of being then unable to continue your saved games).

LaFayette

@rogercooper Who is the target audience for seeing the info that a new XML was added? AFAIK it's most interesting when downloading the map, making a note in the download description seems to be a good place. Are you thinking of somewhere else?

LaFayette

@cernel said in General 2.6 Discussion:

downloadedMaps/the_pact_of_steel

In this example, the map.yml file goes right under the map folder, downloadedMaps/the_pact_of_steel/map.yml. That is true no matter which current or legacy folder structure that is used.

About the version number, it should never be called as just version (to avoid confusion with the game version, which (you want it or not) will remain something defined by at least some map-makers, no matter if you remove it, because every time you change a map's game without changing the game's name you have a new version of the same-named game, and this is a fact no matter if the program misses to inform the users about any difference before starting the game) and should be at least a two digit one: the first digit for non-backward compatible changes (meaning that your saved games may be not anymore playable if you update the map) and the second digit for backward compatible changes (meaning you should be safe to update the map with no fear of being then unable to continue your saved games).

This is nothing new at all with 2.6. Be what it may:

I don't know if the game engine ever used the version value found in map XML for anything beyond a label.
Each map maker having their own versioning system is not sustainable for maintaining maps. If they all need to be updated, nobody is capable of divining all the different version number strategies
It's not important to define a version number'ing strategy and teaching everyone it when it is not enforced by the engine
Maps should never be made non-compatible. TripleA has NEVER supported this, (it is a major design flaw present since day 1) - it is a very bad move for a map maker to do this. Whenever we have made incompatible changes, it's always been incredibly painful. Instead a person needs to create an entirely new map copy and note that it is an updated version in the map title.

LaFayette

A heads up, getting pretty ready to turn on the maps server. We're removing 'version' from the map.yml file and the out-of-date check will be based on timestamps of the maps folder and the last commit date in the repo. After we merge that update, anyone with an older version of 2.6 that downloads a map could see issues reading 'version' from newly downloaded maps.

Next, will be working on a toolbox console to be able to manage maps. I'm thinking to keep it simpler that we perhaps just merge the map admin and mod team together. Map management would be in the same toolbox window that moderators access. The map toolbox window will allow moderators (map admins) to update map category and to disable maps from download. I'm leaning to enable this toolbox window to be able to create map tags and we'll be able to use that to assign era's to maps as well. To support this there will need to be a bit of a pivot in how downloaded information is displayed in TripleA clients so that it is tag based.

Once that is done there are some additional minor features that we can try and squeeze in but it'll be properly time to try and polish everything up, find as many issues as we can and then launch 2.6

LaFayette

FYI to all, I just generated a map.yml file for all maps and have uploaded it to the map repositories.

I'm reminded that notes can be extracted to their own file, that is another item for mass upload.

beelee

@lafayette right on
so are yaml PRs different as of now ? Or does it not take effect until 2.6 is the stable ?

LaFayette

@beelee The YAML file is read by 2.5 and below, so long as we are supporting those versions a person will need to update the YAML. My thinking is once 2.6 is launched we'll simply stop updating the YAML file.

Cernel

For the record, I still think that grouping all game-specific items into a single folder per game would be much advisable.

The current system means that, if you have a map with 6 games, you will have 12 files and the need specifically to recognize which is for what game. It would be cleaner to have 6 sub-folders to the game folder, each of them having inside two files (which would be generically named).

Then this could be expanded to any skin item, like the mentioned "objectives.properties", that is currently kind of a code nightmare, with lines like
World_War_II_Global_1940_Alpha_3.TABLEGROUP.01;Germans=objectiveAttachment_Germans_1_Trade_with_Russia;objectiveAttachment_Germans_2_Control_Novgorod_Or_Volgograd_Or_Russia;objectiveAttachment_Germans_3_Control_Caucasus;triggerAttachment_Germans_4_Presence_In_Egypt;triggerAttachment_Germans_5_Swedish_Iron_Ore;objectiveAttachment_Germans_6_Control_Iraq_Or_Persia_Or_Northwest_Persia
(and it is also using the arguably bad hack to have underscores to refer both to underscores and spaces, as the referred "World_War_II_Global_1940_Alpha_3" game is actually called "World War II Global 1940 Alpha 3")

Alternatively, for consistency, since currently we have files, like the "objectives.properties", which are in the main "map" folder and each contains the codes for every game needing some, then there should rather be one single notes file in the main "map" (not one or more in the "games") folder and this file should contain the notes of every game, much in the same way as the "objectives.properties" work (I think this would be worse.).

LaFayette

@cernel A single file for game notes could be difficult because then you have to encode the HTML in some way. You no longer could open the notes file in an web browser to get a preview of how it would render.

With 2.6, if you want to organize games into folders with generic names, AFAIK you can do that now. You could not previously to 2.6