@Cernel Mind you that, this way, removed attacking units will turn into zombies owned by the attacking player, if you retreat, or owned by the defending player, if you lose the battle without retreating.
For the losing battle without retreating part, you can have a trigger conquering the territory in favour of the "Zombies" player before the infrastructure unit repairs and, immediately thereafter, another trigger re-establishing ownership without conquering the territory (just check that a battle has happened for the attacker but the territory is owned by an enemy of the attacker, if you have a basic 2 sides scenario).
For the retreat part, you can hack it by having the intermediate infrastructure unit being a movement 0 air unit (so it won't retreat with the rest and will never move out of it), but I personally strongly disagree on the current behaviour that attacking air infrastructures are conquered (since they are hovering the territory, they should not be influenced by any ownership changes, until after they landed on it, which they never can) (I believe a @Frostion map uses this behaviour for Nuke, if I recall correctly, but I consider this being a case of exploiting a wrong engine behaviour (bug)).
@Frostion thanks for the info I wasn't sure. Yeah in the yaml its version 1 so I'll pull it now and update it. I've already updated the repository on github (getting used to that as I am a noob there too ).
I doubt it would make better combats. Expensive units are already mostly redundant and this property would make them even worse since they could get hit too before sacrificing cannon fodders. But the on the other hand battles would force people to adopt more different situations plus no cheesy boring attaks like 2 inf+1 fighter anymore.
Ah yes.. I see the problem. I have a local copy of the xml and "unit" folder for development purposes and I have simply been adding my new units to the existing folder in the actual game. I see the original author of this game did have these two units in the folder. If I move them out.. the problem is solved! Thanks. Also, I agree it would be better to look at production frontier, but minor problem. Thanks for the help. I think my new version is ready to release to the public.
@LaFayette Yeah, that's why DNAI needs to be figured out and documented (and fixed to work with no capitals without crashing, possibly), as it is now going one way in the moment you can use it for attacking with its own phases and another way in the moment it substantially skips the collect phase, plus the strange behaviour of a first purchase then nevermore, that it is a complete surprise to everyone. Substantially, Veqryn made this AI probably based on something he was planning, but that never happened and, as far as I know, nothing was documented about all this more or less artificial and likely sigle-game tailored construct, that has been since available to all users and map makers.
I would personally prefer it being just 100% like assigning the player to somebody that just keeps skipping everything it can skip and clicks randomly on anything it must do (but this would require fixing the placement phase itself as being a must do, preferably with a property to allow having the current free-not-to-place behaviour for custom maps).
@Hepps Yeah thats what it looks like and what I initially thought but I double-triple checked and didnt find anything.
But you did just give me the idea of searching for "" in the file and I found a unit placed with no territory.
I probably wouldnt have thought of searching for that if I didnt read your comment tho, so thank you alot.
@gabegolfer said in Can a Unit do 2 damage on one hit? (Make enemy select 2 casualties):
How would I assign the number of dice rolls per round?
<option name="attackRolls" value="*"/>
<option name="defenseRolls" value="*"/>
Would that be in the “unitAttachment” section?
Is more than one dice roll per round even possible?
Yes, since Classic.
@Michael-Hoover as @Cernel stated "-reset-" is used to clear multiple values. You can use a "playerProperty" to change a "switch" value.
<attachment name="conditionAttachment_WaxOn" attachTo="Player1" javaClass="RulesAttachment" type="player">
<option name="switch" value="true"/>
Then you would need to create a condition for when to turn the switch to false:
<attachment name="conditionAttachment_TurnWaxOff" attachTo="Player1" javaClass="RulesAttachment" type="player">
<!-- Create the condition here -->
Then by checking the state of "conditionAttachment_TurnWaxOff" you could use this to then set "conditionAttachment_WaxOn" to "false":
<attachment name="conditionAttachment_WaxOff" attachTo="Player1" javaClass="TriggerAttachment" type="player">
<option name="conditions" value="conditionAttachment_TurnWaxOff"/>
<option name="players" value="Player1"/>
<option name="playerAttachmentName" value="RulesAttachment" count="conditionAttachment_WaxOn"/>
<option name="playerProperty" value="switch" count="false"/>
To change "conditionAttachment_WaxOn" to false.
Hope this helps.