@gregorek Do rule changes disturb order in the purchase menu? (ie. remove then add to end, which changes location.) - Yes, remove a purchase shuffles the purchases after the remove and an adds to the end. You would have to rewrite the whole of the production list every time you did an upgrade to keep the locations constant. . Currently there is no function to test a resource. . Personally I would remove the TIMER and see if the game plays well enough without it. Good, Bad, Ugly? I would let the players decide. I will be one of them . As @wc_sumpton suggested create a Jurassic - Official Thread under 'Maps & Mods, ask your questions under it and show case your progress. Keep the first post to advertise the mod.

@GREGOREK In my copy of Jurassic, I noticed that there are no technologies. By adding an empty technology section: <technology> </technology> The Technologies Tab/Window can be removed. Cheers...

@rogercooper said in Problem with foreach: The variable system was well coded.. yea redrum did that. He was working on TWW and realized he needed about 1500 triggers so said F it and wrote the code. But you probably already knew that

Just tried 2.7.15426 it works, its been fixed. all good. Below is the log for 2.7.15393 - fails 611 15:17:53.465 [main] INFO o.t.game.client.HeadedGameRunner - Launching game, version: 2.7.15393 1024 15:17:53.878 [Thread-2] DEBUG g.s.e.data.gameparser.GameParser - Parsing game XML: C:\Users\RYZEN\triplea\downloadedMaps\the_grand_war\map\games\the_grand_war.xml 7699 15:18:00.553 [Thread-5] ERROR g.s.e.f.s.launcher.LocalLauncher - Failed to start game java.nio.file.InvalidPathException: Illegal char <<> at index 5: misc/<!-- arjerg.png at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:204) at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:175) at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92) at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:231) at java.base/java.nio.file.Path.of(Path.java:148) at games.strategy.triplea.ResourceLoader.createPathToImageString(ResourceLoader.java:164) at games.strategy.triplea.ResourceLoader.loadBufferedImage(ResourceLoader.java:182) at games.strategy.triplea.ResourceLoader.loadImage(ResourceLoader.java:158) at games.strategy.triplea.ui.mapdata.MapData.lambda$loadDecorations$2(MapData.java:261) at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197) at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133) at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1939) at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509) at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499) at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921) at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:682) at games.strategy.triplea.ui.mapdata.MapData.loadDecorations(MapData.java:263) at games.strategy.triplea.ui.mapdata.MapData.<init>(MapData.java:179) at games.strategy.triplea.ui.UiContext.<init>(UiContext.java:139) at games.strategy.triplea.ui.TripleAFrame.create(TripleAFrame.java:488) at games.strategy.engine.framework.startup.mc.HeadedLaunchAction.startGame(HeadedLaunchAction.java:87) at games.strategy.triplea.TripleA.startGame(TripleA.java:62) at games.strategy.engine.framework.startup.launcher.LocalLauncher.loadGame(LocalLauncher.java:78) at games.strategy.engine.framework.startup.launcher.LocalLauncher.launch(LocalLauncher.java:59) at games.strategy.engine.framework.startup.ui.panels.main.MainPanelBuilder.lambda$launch$3(MainPanelBuilder.java:65) at java.base/java.lang.Thread.run(Thread.java:1583) 7896 15:18:00.750 [Thread-7] DEBUG g.s.e.data.gameparser.GameParser - Parsing game XML: C:\Users\RYZEN\triplea\downloadedMaps\the_grand_war\map\games\the_grand_war.xml

@RogerCooper The second method is to take control of another players units. [image: 1772835340458-screenshot-2026-03-06-153311.png] To let Germany take control of the 4 units in Bulgaria and the one unit in Varna. In the unitAttachment for infantry add <option name="canBeCapturedOnEnteringBy" value="Germans"/>. In the territoryAttachment for Bulgaria and Varna add <option name="captureUnitOnEnteringBy" value="Germans"/>. In the playerAttachment for Neutral_Player add <option name="captureUnitOnEnteringBy" value="Germans"/>. And set <property name="Capture Units On Entering Territory" value="true"/>. Then this <option name="changeOwnership" value="Bulgaria:any:Germans:true"/> in a trigger, the 'when' can be any step. After Germany's noncombat move. [image: 1772836589538-screenshot-2026-03-06-171112.png] The 4 units changed, but not factory or the Territory and because Germany moved into Varna during noncombat the unit and territory does not change. Adding <option name="canTakeOverOwnedTerritory" value="true"/> to the relationshipTypeAttachment between Germany and Neutral_Player to get this. [image: 1772837664547-screenshot-2026-03-06-154000.png] Control of the units happens on the 'true' setting of 'changeOwnership' and changes at the 'when'. Cheers...

@rogercooper said in Polygon Grabber Missing: 2.7.15204 It was really helpful knowing a known good version too! This and the screenshot and the terse statement of the problem were kinda perfect

@simon-hibbs Don't feel bad, me and @beelee have talked at great lengths about our 'Duh' moments. I feel like I haven't learned something if I haven't slapped my head a couple of times. In a pinch a solid wall will also suffice. Cheers...

this post is deleted

@beelee Thanks. I've been rereading through "Pact of Steel 2" and continue to learn what I can. I'm almost 70 now, so learning is taking longer than it did when I was younger. It does say in "2" that conditions should precede "any" triggers. It also says that meta-conditions need come after the conditions within (as I figured). The trick is to only move the conditions and not the triggers, at this point. It'll be a long boring process, but I'll have a better understanding of what everything does. The code I'm revamping is that of the "Path to Victory" game (that I modified) and not actually the "Oztea" game code. I was just using "Oztea" to know which territories were owned by whom in 1939. A few of the names didn't match and the sea zones were different, but I did get that part done. It was working on the Politics that are leading me to adjust the conditions. I'm also re-formatting the code as I move it, which I had started doing before but never finished. Last, but not least, I'm also adding more comments (mostly for my own benefit) so that I have a better idea of what each condition is actually checking. It also looks like a lot of the conditions can be recoded into for-next loops and I will eventually get around to doing that as well. This is especially true with many of the French conditions as there a plethora of them. So, thank you again.

@thedog yes thank you. I had it for my one time player. So I tried it. I just didn't think it'd be that easy

@rogercooper said in Triggered Victory on Specific Turn: We should update Pact of Steel 2 to reflect that notifications.properties is mandatory. <!-- Support Attachments --> number values: how many units to be supportedhow much support can be given. All support can be given to a single unit, or spread too multiple units depending on bonusType. There are many other mistakes in the PoS2. Cheers...

Hi @shazbot182 DL "Domination" and it will be included in there.

@rogercooper [image: 1750819638912-rightarm.png]

@lafayette said in Relationship Problems: If you can upload a zip of the map somewhere; I can run it through with a debugger. I will keep that in mind. For now, I removed the code and will see if I can work without it.

@rogercooper said in Problem with foreach: I was copying existing code. If I understand correctly, "attachTo" is arbitrary and "players" is required to be sure that the correct player is involved. If "players" is used, then "attachTo" is ignored. I only use "players" when the trigger affects more than one player. But to each his own. @rogercooper said in Problem with foreach: @rogercooper SOLVED IT. I forgot the variableList tags. Would have never guessed this! Happy you have figured it out. Cheers...

@wc_sumpton said in Making a unit attack alone: The problem is with "isSuicideOnAttack". The fusion_bomb will be removed after its attack roll so there will be no bonuses given to enemy units because the fusion_bomb will not be there. Thanks for the help. The first support attachment should be good enough. The AA attack reflects an EMP attack effect from the "East & West" game.

@thedog various reasons; Create an interesting visual difference between the land and sea areas. Provide more complex land territories for more interesting and granular borders and front lines. Make choke points on land more important because it's easier to go around enemy armies. Provide some incentive to split up land armies, rather than keep them all concentrated in a single territory. Make it easier for ships to defend a coastline. Cut down on how many sea territories need to be calculated or programmed.

@rogercooper said in Handling Customized Techs: The tech system in TripleA suffers from hard-coding, but it would be difficult to fix the program without breaking the existing mods This would incur what one would think "fixing" would need to be done. Maybe "expanding" the present system would be better. Either way someone would still need to define how the system is "broken". Still, I didn't understand what was meant by this statement. Sorry. Cheers...

@beelee said in Scenario Design on Wiki: @rogercooper I wonder if the "Axis and Allies" and "TripleA" is problematic. When I started the wiki, TripleA was still in its early years and the content was less focused on TripleA. I have never received a complaint from Hasbro, Renegade Studios or anybody else.

@wc_sumpton said in What "canMoveAirUnitsOverOwnedLand" does and oughts to do: @cernel I'm sorry what I meant was the default setting for archType Neutral "canMoveAirUnitsOverOwnedLand" is governed by the option "Neutral Flyover Allowed". If "Neutral Flyover Allowed" is false then "canMoveAirUnitsOverOwnedLand" is default false, if true then default is true. Wow! Sounds like that means that is supposed actually to be about flying over (and not just entering with air units). So is the description of this option in PoS2 wrong? I need to test this.