[image: hilltype2y.png] Okej, managed to adapt the hills relief; personally I think better than the previous one, but still not completely satisfied..... anyway, back to coding; this is acceptable in the mean while....

No map maker should be relying on the engine to generate any of these files for them. That behavior will go away, it's only there so that players do not need to redownload maps. These are not that many changes necessarily, but the explanation has been too complex.. Game notes, map.yml and description.html are the only new things.

@Schulz Sorry, none that I am aware of. You can set the Player to AI with 'defaultType="AI"'. This can be selected by the player at the start of the game. Cheers...

@torpedoa Nice solution though.

@rogercooper Thank you very much. I plan on starting work on this again this weekend. I tested it and it works. Thank you for your kindness.

@hepps Oh yes. Thats a point. I will try that.

@thedog Thank you.

I definitely have too much time. You can notice that by the variety on some unit images with no purpose. [image: WARRIORTEMP - Kopie (2) - Kopie - Kopie - Kopie.png] [image: WARRIORTEMP - Kopie (2) - Kopie - Kopie - Kopie - Kopie.png] [image: Unbenannt.png] [image: Thor - Kopie.png] [image: templatese - Kopie (3).png] [image: templatese - Kopie (2).png] [image: templatese - Kopie - Kopie.png] [image: templatese - Kopie - Kopie (2).png] [image: Principes_O.png] [image: Elephantes.png]

@TheDog I am glad you enjoy my postings. Note that I avoid numerical ratings, as my tastes may differ from others. I suspect that most users download the boardgame conversions and I think that they should have their own category. I don't think there is any place for broken maps in the repository. If a developer is having a problem with a map, they can zip it up and post it to Google drive where the community can download and help. Even if the map is basically meant as a resource, such as 100 x 100 hex grid, it takes little effort to create a simple scenario to use the resource.

@TorpedoA Oh yes! it was very fun. But now I don't have time to play it, because it was happening 24/7 and so you had to plan raids at specific times regardless of your personal schedule Now that I have a job and kids I can't do it any more. Since TripleA supports different resource types, I really like this idea of a building-heavy game where the buildings themselves produce different resource types (wood, wheat, iron, etc.) which can be used to build the units (and then the fancier buildings can produce fancier upgraded units), more like Tribal Wars, Age of Empires, etc. instead of the typical- territories = money, money buys units. Very clever!

@RogerCooper - No, ordering does not matter

@TorpedoA yes those guys are good. Frostion too. In case you don't have it, here's Veqryn's and the Brown folder is Joe Pants. See if this works. Had to go sendspace route. Too big for here. https://www.sendspace.com/file/3o140c

Some very nice innovation here. I believe it's time for experiments. Just modifying a map, adding some of the new mechanics without overthinking it, and seeing how it plays out. I don't think it's possible to design an entirely new system without some trial and error. In fact, I expect that it'll take years and multiple maps along the way until this goldmine is fully explored.

@TorpedoA Only if territory B is owned by the land isSub unit. Because the unit does not have canEvade, it can not remain hidden, and thus could not take control of B during the noncombat movement. Nor could the unit enter into A or C and remain there. During the combat move it could pass through A or C and take control of B. If the units in A and C wanted to attack territory D, and B and C connect to D, then this would stop the units in A from joining the attack by blitzing through B. Cheers...

@Hepps You could place a hostile munitions type unit that targets all units in the territory with a 50% chance of hitting on an AA type of attack.

@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'.

@Schulz @RogerCooper Thanks for the responses. I was thinking about going the notification route as well.

I think the version discussion boils down to utility vs complexity (specifically the complexity to understand and communicate how to use the map.yml version field). There is a discussion open in github issues whether to bake categories into map.yml which would put it under map maker control and alleviate the map admin team from an ongoing upkeep task. Deployment wise, remaining we'll need to generate a map.yml for every repo and upload it presumably to the top-most directory of each map. FWIW this should be not that bad, currently the map engine is now rigged to generate a map.yml file for any downloaded maps that do not have it, we'd only need to take the generated file and upload it. Otherwise, does the current map.yml look good and is it clear? The XML path I think is maybe the most error prone and it's the path of any game XML relative to the map.yml file. If the map.yml file is at the top level of a map (expected), then the XML path is really just the path to the XML file from the map folder.. Last, hopefully it's also well understood that game and map name will now come from the map.yml file and the corresponding XML attributes would be considered deprecated and no longer read by 2.6+ engines. The map.yml also removes the need for a map repository or map zip to have any kind of specific naming to match the map name in the XML, the map repo and zip could have any reasonable name and would essentially no longer matter.