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

@Contango right on 🙂 i had forgot about that. Glad you got it working

@Schulz Check this thread... worked beautifully for @ebbe

https://forums.triplea-game.org/topic/2115/total-global-world-war-ii-fusion-clean-up-project/93?page=5

@Contango No, but the feature has been requested before. You should make a formal feature request.

As workaround you could have a trigger based upon control of a specific number of a list of territories. I don't know what would happen if the same territory appeared on the list more than once.

"Economic Victory" allows you to do this, but only for ending the game with a victory.

I only play against the AI. I would agree with RogerCooper the more units the slower the AI. I would add that if a lot of the units move 2+ this will also slow the game down.

@TorpedoA I think Hepps uses 12 in total world war. Gives a lot more flexibility. I've never done it myself. Just mod existing games

@TorpedoA You'd have to test this... but I fear you may run into issues as there is no way trigger a unit change in the midst of the combat phase. Not sure how the scramble and Kamikaze attachments will interact when the unit remains in the territory it scrambled to.

@JOSEPH-PRINCE @Hepps Thanks guys for the images.... I am ending this Thread and will move to a new one with the name:
GLOBAL WWII OIL & SNOW-Project

( https://forums.triplea-game.org/topic/2592/global-wwii-oil-snow-project ) as I am heading for sharing on github soon.... ( and having plans for a side project next month )
thanks al for sharing , teaching and feedbacking me so far!

One does not simply take a very good looking "big" multi-coloured image and shrink it down to about 48 per 48 pixels to obtain a very good looking "small" image. The likely result is a bad looking image.

The way the eyesight works is that the colour from a point is decreasingly spread over nearby visual areas in our perceived image, so images using few pixels have each pixel dirtying with its colour all nearby pixels, whereas such effect is virtually irrelevant for big images.

@beelee

Hi, I did all steps including upload and changing ownership

can you check this? Hope I've done all correctly

@LaFayette can anybody do this ? Or is there a bot person that one can ask to update ? I think prastle used to do bot stuff but not anymore.

At any rate, thanks for the explanation.