@sammysleeth The following line has an unnecessary space at the beginning of the unitattachment:
<attachment name="unitAttachment" attachTo="militia" javaClass=" games.strategy.triplea.attachments.UnitAttachment" type=" unitType">
<attachment name="unitAttachment" attachTo="militia" javaClass="games.strategy.triplea.attachments.UnitAttachment" type=" unitType">
Great tips @Hepps & @Frostion! Since the maximum amount of units I could ever have in each territory is limited to 8 (Infantry, Hepp's Highlander, Artillery, Tank, Factory, AA, Fighter, Bomber) that would mean I should consider each territory to have room for 8 x 54 pixels each. I think that's workable. Like I said the other day I am still working redrawing and scaling the map properly. But perhaps I should be drawing the 3 conflict zones first (Ontario, Quebec & the Maritimes). Again, thanks for the help. I will get back to you guys when I've made some progress.
@VonnVary It appears that you potentially started creating the map with an older version of TripleA as you need to make sure in the XML that its "attachment" instead of "attatchment". Here is a list of potentially changes you need to fix when upgrading to TripleA 1.9: https://github.com/triplea-game/triplea/wiki/Upgrade-Maps-Information
If you still see errors after fixing that then feel free to post your XML for us to look at.
I have found the problem. These are new lines of code that need to be there:
<property name="Units Repair Hits Start Turn" value="true" editable="true">
<property name="Units Repair Hits End Turn" value="false" editable="true">
The old ones referring to battleships repairing at start or end don't hurt anything if they are there but they no longer work for units in 1.9.
I will elaborate in more detail:
My map has 9 levels of political relationship. All players start neutral to each other and each turn it is possible to either upgrade or downgrade a particular relationship. From neutral you can downgrade to uncooperative, then to unfriendly, then to hostile, and finally to war. Or you can upgrade from neutral to cooperative, friendly, aligned, and finally to allied.
Yes, I previously requested a feature whereby when you view political relationships these various stages could be color coded so that it is easier to see exactly where they stand. Right now they show in red when they are hostile or war, and in green when aligned or allied, but gray for everything else. This is because the color is hard set by the arch_relationship in the engine. I have looked at the code and think it would be fairly easy to change it but I'm not a java programmer so I don't know. In any event, that was an earlier thing but the subject of this thread is different:
I also have 18 players (countries). My game is a free-for-all, so often I am playing with a lot of AI players. Each turn the human players have to endure a lot of popup messages saying things like "Brazil is annoyed with Russia and has downgraded its relationship to uncooperative", or "Austria and India have improved their relationship to friendly". Unless the message concerns the nation I am playing I usually don't care about it. I realize it would be complicated to tailor it to individual players, so all I'm wanting (hoping is already possible) is at the player level to globally turn on or off all political messages. That way human players can decide if they want to see them or not as the game progresses.
@redrum said in Query about the Engine:
I went back and looked at the old forum. The 2 main threads I found talking about features/priorities/etc are:
Some of those ideas are in the github issues list:
As partially said in the linked post, my first 3 items I wish some developers would do are:
Allow for deliberate retreating; in that when you win a battle you get asked how much units you want to consolidate and can somewhat retreat all the others (it is dumb that in dice you cannot retreat if you were "too" lucky or in LL you have to pile up exactly that power to get the "hit-all-but-one" result).
Having units that didn't move at all gaining a (settable and unit distinctive on board) defence bonus (related to the above, as it would be silly that if you attack and retreat then all your stack is just as ready to defend as if it stayed there on the ready).
Having ammunition consumption; in that you have a "suicide" unit that can actually attack only as long as there is another unit in the same battle, in a 1:1 or more ratio for suicide:suicidator (shells:artillery) units; this should also work that you may require such a "suicide" unit for AA attacks (like your AA guns fire only as long as they have a "shell" unit to use, that suicides).
I want to point out that in WW2 the cost of shells was normally much higher than the cost of the artilleries firing them (especially for AA guns) and in medieval times the cost of a warbow was about the same as 24 arrows, which you can loose in a couple minutes.
But having a way to deliberately surely strafe in great superiority, without having to play Low Luck in order to be safe to do so, is really almost a fix, as Low Luck basically already allows it, and dice should allow it too.
Also, another item would be fully supporting the ability to have units moving faster during non combat than combat move, as that is very important, for realism (already supported and possible, as you can give bonus movement in non combat, but there are a few issues).
@thephalanx1453 Np. FYI, most XML editing tools can be used to validate the XML against the "game.DTD" to ensure its valid before trying to start a game: https://github.com/triplea-game/triplea/blob/master/src/main/resources/games/strategy/engine/xml/game.dtd
This will often give you hints on what the issue is.
I think what needs to be added to the game at some point is "attack animations or cut sequences". These, by default would be on, but could be turned off by a user. Right now the only way to approximate this is in specific scenarios using kamikaze type attacks or pre-programmed choices.
@theredbaron So I actually think the part that needs documented better is the "process" and what tools people use today. While documenting the different mechanics and the POS 2 XML would be useful, I think we really need to evaluate map making process as a whole before sinking lots of time into something like that.
I'd really like to vastly improve the map making tools but currently don't even have a good feel for how folks actually create maps.
@Zim-Xero That's probably pretty accurate. I think maybe the better question is we have a few different tools and none of them work that well but what are the useful pieces of each one. I think the goal is to decide what needs to be kept and then figure out how to integrate what we have together. Then we can look to hopefully make some significant improvements.
@Idodoappo said in cannot load a map i created:
games.strategy.engine.data.GameParseException: MapName: file:/M:/TripleA_188.8.131.52.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_184.108.40.206.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
Another example of the sloppyness of using units as pseudo-resources (for tech or whatever) is that, then, the Unit Help tab in the menu becomes not really helping anymore. You can see what I mean if you click on Help/Unit Help in Age of Tribes, and see all the various actual units and develop-units mixed up at random.
This would be solved if only a developer would add for conditions the ability to test for resources (still not as good as having a good tech phase for it, but at least better than using units as tech tokens).