@Frostion We aren't removing/changing any functionality just clarifying how things currently work.
@CrazyG Yeah, I think adding it to the Pact of Steel 2 XML would be good.
I think priority for targeting or defending VCs should definitely be at the top of the list. Basically where the AI does everything it can to capture VCs or prevent the enemy from doing so in a given round.
Since many games have Victory conditions that are based on controlling a certain number of VCs at the end of the game round, it seems like a pretty important feature for the AI. There would also be some overlap there with prioritizing capitals and objectives (since those are often VC territories) so would be a nice place to start.
Maybe it could be hacked that the AI doesn't actually think about it, but when, at start turn, it has a major chance to get the needed VC and keep till end round, then it goes for it. I tend to think VC should not make you play very differently, until the last moment. Actually, VC driven victories got very little favour both with custom maps and players, as I believe most mapmakers and players just prefer to fight till someone is obviously the winner, for raw stats (in custom maps, often VC are totally absent or set at a value to just formalise an achieved victory, like we did in the new WaW (I believe any games should have some kind of victory conditions, even if not supposed to be ever reached, before the other side surrenders)).
There is also the consideration that the game is usually about beating the AI, not being beated by it, so I'm not sure how many people would ever play on till seeing the AI actually winning by VC. Probably a bigger item would be the AI making the last stand for not losing by VC too early.
This is essentially what I plan to do. Have checks if the AI is either close to losing or winning in terms of VCs and only then take it into account.
@Black_Elk @Cernel I think VCs actually aren't that important as most games either don't really use them or the game is already decided by the time they come into play (but there are a few that do actually use them especially in unbalanced map where say the Axis needs to try and win quickly). I think the bigger impact would be objectives as those make a major difference on lots of maps but are fairly complex as they very a lot across maps.
@CrazyG Good point on being able to use massive carrierCapacity and small carrierCost for having units that require little carrier space. I'm fine with leaving the functionality as it works today but would like to document this somewhere so its more explicit not just something that happens to work.
@Frostion Given the current system, I think units being transported should essentially be defenseless and not provide any attack/defense/support/bonuses to the transporting unit. The main reason is simplicity and avoiding strange situations where say you have a ground unit that can support air units (say some kind of AA unit). Now you transport that AA unit (think of it all packed up in cargo) and end up in a naval battle that includes planes. It would end up providing support to the planes even though its just being transported. I think its currently more intuitive that "transported" units are defenseless and not providing abilities.
IMO, if we want transported units to provide support/abilities/bonuses to transporting or other units in battles then we need additional parameters such as "providesAbilitiesWhileTransported" which defaults to false. Or create a separate system from traditional transporting units that would indicate they aren't cargo but really some sort of enhancement.
games.strategy.engine.data.GameParseException: MapName: file:/M:/TripleA_18.104.22.168.3453/maps/4chan/games/TumblrChan.xml, Error setting property:victoryCity cause:Attachments: true is not a valid int value
Here is the error: games.strategy.engine.data.GameParseException: MapName: file:/M:/TripleA_22.214.171.124.3453/maps/4chan/games/TumblrChan.xml, Error setting property:victoryCity cause:Attachments: true is not a valid int value
It appears you are setting the "victoryCity" property to true instead of an int value which is invalid.
From pact of steel 2 XML (https://github.com/triplea-maps/the_pact_of_steel/blob/master/map/games/pact_of_steel_2.xml
victoryCity - values: a victory city is typically used for victory conditions. Is actually an integer, so you can set it to 0, or 1, or 2, or greater numbers. victoryCity uses an image located in the "misc" folder of a map called "vc.png", and the location is determined in a file called "vc.txt" in the map's root directory
@Black_Elk Yeah, that is what the placement bonus would do. The thought behind it is the AI struggles on some maps to use all its bonus income so increase placement (production) capacity. You might be right that having a separate parameter for that would make it more flexible. Though I don't want to create too many AI bonus parameters as it gets confusing and many are often not used.
@Black_Elk @Cernel I'm thinking of just removing the attack/defense bonuses as I don't think they really make much sense. It would unbalance most maps pretty extremely. I really think income/production or initial bid is the best way to give the AI some bonuses that are pretty intuitive.
@Cernel My thought is to make it so you do individual bonuses per player (human and AI) and allow positive/negative values so you could either increase the AI's income or decrease the player's income to try to give the AI an advantage.
The current AI bonus settings available are pretty limited and some work kind of strangely. I'd like to have a discussion some folks can provide thoughts/ideas on the current settings and what they would like to see in the future. These changes will be done in several phases.
Changes Implemented So Far
My end goal for bonus settings is something similar to HOI4 as I think its one of the better systems I've seen: https://forum.paradoxplaza.com/forum/index.php?threads/hoi4-development-diary-12th-of-august-2016-read-op-edit.962543/
I'm planning to move the AI bonuses out of the settings window and into the player selection window as it makes more sense there. Then simplify them to focus on an income percentage for all resources and a flat PU bonus.
I'll go ahead and share my secret.
You need the unit to be able to move onto both land and sea, so you make it an airunit. You purchase it and place it on land like any other air unit.
Then you give it carrierCost=0, which lets it land in empty sea zones as if there was a carrier there. So on the next you move your hull into the sea zone and it should land just fine (isKamikaze could work as well but this seems cleaner). Then you buy the battleship, and it should consume the hull just like it would consume a sea unit version.
In version 1.8 I had an XML with this working, life got in the way before I could share it though.
That is pretty creative and interesting. I wasn't aware that "carrierCost=0" allows air units to land in empty sea zones with carriers. I would definitely consider this somewhat of an edge case that is really just an outcome of how the current code was written.
I think the question here is what should "carrierCost=0" really mean and be used for? Should it allow air units to land in sea zones with no carrier? Or should it require a carrier but just take up no carrier capacity? Or something I'm not even thinking of? Whatever we come to a consensus on should probably be added to the Pact of Steel 2 comments so its spelled out somewhere.
PS. It would be great for some of the awesome map makers to take ownership of that Pact of Steel 2 XML to help me keep it up to date as many of you know the game XML better than I do.