I figured it out! You have to designate Japan as the initial territoryowner for each of the Kamikaze sea zones! YAAAAAAAAAH

thanks man.

Right on! Thanks for the info

I figured it out thanks to Hepp's help in private chat. Here was the solution: changeOwnership only seems to work if the players changing ownership are at WAR with each other. So the trigger now has 3 steps. First it changes relationship to WAR. then another trigger does the change in ownership. And then a third trigger changes the relationship back to Allied.

@Cernel Here is the panel [image: 1590528965253-844c0c9d-d5a3-4dcb-b165-45d2ad417fa2-image.png] The trick is that A&B start at war and the real players randomly ally with A or B. A & B are nominal players with no territories or units.

Yah. that was it. And another typo. thanks man

@Hepps Thanks for your help, but I just researched it and found out how to remove the background.

@Cernel well damn. now its working. that so weird. cuz all the other Objectives.Properties files i've checked 'appear" to have linebreaks there. But hey, it worked, so i'm happy. THanks man. When u gonna be back on to continue our game

@danelyoung The scenario is still not working in pre-release, but works in the stable version.

A StackOverflowError is simply signals that there is no more memory available. It is to the stack what an OutOfMemoryError is to the heap: it simply signals that there is no more memory available. JVM has a given memory allocated for each stack of each thread, and if an attempt to call a method happens to fill this memory, JVM throws an error. Just like it would do if you were trying to write at index N of an array of length N. No memory corruption can happen. The stack can not write into the heap. The common cause for a stackoverflow is a bad recursive call. Typically, this is caused when your recursive functions doesn't have the correct termination condition, so it ends up calling itself forever. Or when the termination condition is fine, it can be caused by requiring too many recursive calls before fulfilling it. Here's an example: public class Overflow { public static final void main(String[] args) { main(args); } } That function calls itself repeatedly with no termination condition. Consequently, the stack fills up because each call has to push a return address on the stack, but the return addresses are never popped off the stack because the function never returns, it just keeps calling itself. If the stack is full you can't push, if you do you'll get stack overflow error. StackOverflowError is avoidable if recursive calls are bounded to prevent the aggregate total of incomplete in-memory calls (in bytes) from exceeding the stack size (in bytes).

@Frostion I am actually close to getting something working. <attachment name="conditionAttachmentJapaneseEnemyUnitPresent" attachTo="Japanese" javaClass="games.strategy.triplea.attachments.RulesAttachment" type="player"> <option name="enemyPresenceTerritories" value="all" count="each"/> </attachment> <attachment name="triggerAttachmentJapaneseEnemyUnitCount" attachTo="Japanese" javaClass="games.strategy.triplea.attachments.TriggerAttachment" type="player"> <option name="conditions" value="conditionAttachmentJapaneseEnemyUnitPresent"/> <option name="resource" value="PUs"/> <option name="resourceCount" value="1"/> <option name="when" value="after:BBidplace"/> </attachment> The trigger is not firing, but I am getting close to having a way of counting all enemy units and all friendly units. I can then use the difference for some rough handicapping. In many scenarios, there is no obvious historical (or hypothetical) conflict. This way I can just assign random sides and balance them, rather than having a free-for-all, which I find makes for uninteresting play.

Ok thanks, that worked!

thanks guys!

@Frostion Yes it does, thank you for the additional information.

Hey Cernel, thanks for your guidance here. I figured out the problem. Did not have a relationshipinitialize section Did not have any true neutral territories on the board so it interfered with stuff. It works now! Thanks for all your help.

@Joe-G FIgured this out. A list of playerattachments at the end was missing from my XML.

@Joe-G No problem. TripleA is fairly evenly split between British and American English. It can be easily confusing. I would personally prefer if TripleA would follow British English fully.

@Frostion thanks. you guys rock. I got it working

@Cernel @stalinpasha I just use drag and drop when I want to upload an image to forum.

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