@Hepps The ones you can see here, yes, representing high mountains/peaks. But there will also be a mountain territory effect, preventing blitz and buffing some unit types and garrisons.

@Makalakalane i'm down i need more practice with that map. let me know what you're thinking in terms of details.

@redrum: Miscaclulated Egypt and needed to edit.

@wc_sumpton I meant if the matter was needing two different kind of support/units to get supported, it seems more logical doing it directly rather than 0.5 + 0.5 and ignoring if only one 0.5. Also that would allow for support or nothing when it is a +2 or more. But I have to say several times I wished for something like this, especially when you have land transported units.

Also, how about having air-only connections in the narrow sea passages, meaning: Questos - Northern Baldoria Blood Islands - Blood Hills North Goronmok - Stormcrag and so on? However, in this case, you'll need to visually indicate such air only connections on the map (with arrows or such, preferably as decorations), as I see in the map there are a lot of possible cases. So, let me know if you like this idea or not (basically, if you have a strait that it is about as narrow as a river, you may want air to move across with a single movement, as well). If yes, you will have to give me the full list of such other air only connections too.

@Roman-Dumych yeah you cant really play this map versus bots at all.

@Frostion The only way I can think if to achieve this (without having a unique Swiss Infantry unit) would be to create another hypothetical unit... call it "Swiss Advantage" (it could even be invisible) This unit could then just support the Swiss infantry units... and you could trigger it to be added and removed each turn based on where Swiss infantry meet the condition of being in a mountain terrain.

1915 has 1 ottoman factory that belong to the enemy. it also does not save unplaced units, and does not alert the player not to overbuild.

@prastle Thanks @jgamer !

TripleA Turn Summary: Italians round 13 TripleA Turn Summary for game: World War II Global 1940 2nd Edition, version: 4.0 Game History Round: 13 Combat Move - Italians Turn Complete - Italians Combat Hit Differential Summary : Savegame

@lenzls You could cache the results and/or compute them in the background on game launch. Overall though, I'd stick to the rule of thumb: "working, clean, fast - in that order". I think we need to eventually have bigger updates to make game data broken up and store the history data as delta's and independent of the immutable data such as base game rules and map options. That would give many benefits, a compability for a custom save-game format that does not rely on serialization, smaller save games, and much faster game clone operations which cause many delays. Hence, IMO it might be okay to just cache the results and let it be somewhat slow until we can get those deeper changes in place. Grant it, if there is a way to cleanly make the rendering fast, then it would be very difficult to wait or object to that.

@redrum said in suicide/munitions unit with support?: @Cernel Yeah, they are closely related but one key aspect is that AA rolls happen before v3+ units can hide/submerge where first strike happens after. Eventually it would be good to merge these concepts together and have some sort of battlePhaseOrder where you could specify in what order and which units roll together/separately. So right now you really have something like this: AA - battlePhaseOrder=1 v3 canHide - battlePhaseOrder=2 firstStrike - battlePhaseOrder=3 normal - battlePhaseOrder=4 That seems like something it would be good having written in pos2...

I've also tested that, as long as you have the "Transport Casualties Restricted" property true, if you send only these units: <attachment name="unitAttachment" attachTo="catapult" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType"> <option name="movement" value="1"/> <option name="attack" value="4"/> <option name="attackRolls" value="0"/> </attachment> into a territory with only these units: <attachment name="unitAttachment" attachTo="wall" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType"> <option name="movement" value="0"/> </attachment> All defending units are immediately destroyed, so there is no stalemate, despite both sides actually having no power (if by power we mean strength multiplied by rolls). Of course, instead, if these units are sent: <attachment name="unitAttachment" attachTo="catapult" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType"> <option name="movement" value="1"/> <option name="attack" value="0"/> <option name="attackRolls" value="1"/> </attachment> into a territory with only these units: <attachment name="unitAttachment" attachTo="wall" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType"> <option name="movement" value="0"/> </attachment> Then, they stalemate. Instead, sending only these units: <attachment name="unitAttachment" attachTo="catapult" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType"> <option name="movement" value="1"/> <option name="attack" value="0"/> </attachment> into at territory with only these units: <attachment name="unitAttachment" attachTo="wall" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType"> <option name="movement" value="0"/> <option name="defense" value="1"/> <option name="defenseRolls" value="0"/> </attachment> has, in fact, a behaviour I see as inconsistent, as: If the attacking units cannot retreat, they are autodestroyed. If the attacking units can retreat, they are stalemated, without a chance to retreat (so they cannot actually retreat, but this is the issue of the wrong handling of stalemate). I think the first case is fine with the rest, but I think that the second case behaves inconsistently, and, to be consistent with looking at attack/defence values, not at rolls, it should never stalemate, but just keep offering me the option to retreat (that I will have eventually to take, to go on with the game). What I'm guessing is that here there is this inconsistency between the handling of the autodestruction and the handling of the stalemate: The autodestruction behaviour, that depends on the mentioned property to happen at all, looks only at the attack/defence values, not at the rolls, to determine if anything is going to be autodestroyed. This, in turn, happens always if we have a defenceless against a non-offenceless and happens only if there is no retreat in case we have an offenceless against a non-defenceless. The stalemate behaviour, that doesn't depend on any properties, looks at the units having no attack/defence value or no related rolls (or both), to decide if the units are actually offenceless/defenceless. It happens immediately, also negating your ability to retreat, in this case (this is wrong). The autodestruction behaviour is tested, and immediately applied, in case, before the stalemate behaviour, as far as I can tell, thus in a situation in which both the autodestruction and the stalemate behaviours would both happen (due to their inconsistencies), you have the autodestruction behaviour only (I warn you I'm very far from sure on this point, so here I would very much need a developer to confirm or deny this point). Overall, what I understand, from limited testing, is that the autodestruction and the stalemate behaviours appear like they have been added to the program independently, maybe at different points in time or by different developers, with little concern regarding having them consistent, despite being two highly related matters, clearly. Also pointing out this being merely my higly uninformed judgment (I'm not a developer). Regarding the fact that the autodestruction behaviour is related to the mentioned property, while the stalemate behaviour is not: The fact that the autodestruction behaviour is related to the mentioned property (beside the obnoxious facts of not having documented this at all and that the property is only losely related to it, or arguably completely unrelated, as one would think that is a property for sea units only) is wrong, as this is a v3+ property, while autodestruction existed in Classic, albeit only for offensive units, since there were no defenceless ones, though at least having a property dependency may be good (if documented!), as it allows mapmakers to decide whether to have the behaviour or noth, though a dedicated property would be better (with special reference to the case of having AA only units that are not infrastructures (for example, if I make "aaGun" units that are exactly the same as those of the v5 game, except for the fact that they fire each combat round, then one may want avoiding them being autodestroyed if remaining as the only defending units against any attacking composition also comprising air units) (or a mapmaker may just prefer allowing the strafing of defenceless only unit, as a strategy)). The fact that the stalemate behaviour is (as far as I know) universal, makes sense to me, despite the fact that stalemate exists only from v3 onwards, but this is only because you didn't have both offenceless and defenceless units before then, which cannot be assumed for v1 and v2 custom maps too, of course, in the moment mapmakers can have defenceless units too, if they so wish. However, I would have a custom property for this case too, so that mapmakers may decide the matter sperifically for their games. Practically, the program only looks at the attack/defence values, not at the actual powerfulness of the units involved, as far as the autodestruction (but not the stalemating) of non-infrastructure units go. I definitely like this particular behaviour, and suggest the stalemate one being harmonized, the same way, as it allows mapmakers to manage the matter as they wish (by making units offenceless/defenceless because of 0 value itself or because of 0 dice, depending if they want stalemate or autodestruction), so I'd like to fully document it in pos2, to make it more of something supported, or even intended, rather than just existent. Also, I've tested that the autodestruction behaviour happens after AA attacks (this means you cannot retreat from defenceless if all non defenceless were killed by AA offensive attacks, while you can if they were killed normally (though this last behaviour, that I actually like too, is contrary to the intended rules (that open for the, in my opinion, strange possibility of removing your non defenceless units to impede your enemy retreating), as already reported by @Panther in the program's repository)).

I think balance is quite fine the way it is. If you play dice anything can happen so its balanced. As a evil player you have too set up your strategie regardless of good play early on, you have first move and can dictate the pace. Angmar is not a problem, remember no capitals so you can flee with your units somewhere else if you feel uncomfortable over there, walls will keep your cities up for 6 turns. So far with evil i prefer too take Rivendall with Orcs, too prevent eagle number going up too fast. I send Saruman too block Tharbad since with a wall hobits have no way too break through. Eventually in later stage i tried too support or invade rohan with mordor since they have a free hand vs Saruman. Its a roll over defense concept, while Orcs carry the attack, i tried too support them with Angmar and Saruman, then mordor supports Saruman. Rhun have enough speed too support Mordor lines too. Evil has a fighting chance, just remember that you need hills or forest for defense. Enjoy the map, and give me a shout if you want too play.

@Frostion These two statements seem to contradict each other: Before people are qualified to comment on removal or function of highlight buttons, they should actually use the scroller during play. I think that there might be made more interest in regards to the unit scroller buttons and the unit highlight feature if there were some actual updates that could be tested out. You're right though there have not been too many updates. The focus has been on 2.0 infrastructure and bug fixes to enable the launch. Still a WIP as we have some issues to hammer out. In the meantime, the window for feedback is still open. Considering it's about 5-10 hours of work to do the remaining unit scroller work, spending an hour or two to discuss what needs to happen now is much preferable compared to the work being redone.