excellent. that worked perfectly (once i corrected the slight typo at the end (that final '/')). thank you kindly. : ) <attachment name="conditionAttachmentAlwaysTrue" attachTo="Germany" javaClass="RulesAttachment" type="player"> <option name="switch" value="true"/> </attachment> <attachment name="triggerAttachmentScienceForGermany" attachTo="Germany" javaClass="TriggerAttachment" type="player"> <option name="conditions" value="conditionAttachmentAlwaysTrue"/> <option name="tech" value="Science"/> <option name="uses" value="1"/> <option name="when" value="before:GermanyTech"/> </attachment>

I actually found a very, very, very dirty trick. But my map is already so heavily modded that it could do the job. Sharing just in case I use the repairPlayers step option, which allows a player to repair for another player. The feature seems to be working ONLY if the main player has anything to repair for himself (which isn't very logic or intuitive). To say it another way, if you want Germans to be able to repare italian factories, you need to have at least one german damaged facility as well, otherwise the phase is skipped. So I created two extra (hidden) players, " Axis" and "Allies". Only those two have the repair frontier. In order to have the repairPlayers feature working (see above), both have a (hidden) fake damaged unit on the map (in Sahara and Himalaya, respectively) that cannot be repaired (no repair frontier). This way, the repair screen doesn't pop-up before regular players purchase phase (as they don't have the frontier). Instead, just after the Place phase of each players, there is a separate "repair" phase, actually lead by the "Axis" and "Allies" players, and using pooled resources. This all just to make sure factories cannot be repaired before placing units...

@black_elk You are a triplea treasure Elkstar

Found this too late to be of much use, but yeah I had the same issues a few times when trying to create a place.txt for a couple maps. What happened in my case was that I had accidentally blanked a place, which is fairly easy to do since it's a lot of click/shift click to add or remove entries, but then without any assigned coordinates for a tile it would throw off that error. Another sorta similar error I think can happen if you have a duplicate entry in the text files. like say for a tile that was renamed. The utility also sometimes asks if you want to use the centers or polys, which can reintroduce an old label depending on which order you make the change. I think it happened to me there in a similar situation, like where I had an impassible tile listed twice, Sahara vs Sahara Desert or the like. That was easier to hunt down than the non existent/blanked place since at least I was able to search the txt file. Sucks the you had to go through that to manually delete the text blocks, hopefully you didn't lose too much work. After a couple snafus I started getting in the habit of maybe an extra copy of all the txt files each time I went in to edit them. Just in case something goofed, I'd have an earlier copy to reference. I had almost hosed like a whole weekends worth of placements for the big map, but somehow theDog was able to figure out which lines were different and saved my bacon. Anyhow, glad you figured it out. The map making tools can be really finicky, cause it you have to save it to launch and confirm changes, but usually the way I tend to do stuff, it'll be more than a few entries at a go.

@azimuth what exactly are you trying todo with SBR ? There may be a way around it, although probably doubtful I've tried tweaking them before without much success

@cameron said in Universal Objectives: Thanks for the replies. Think i might just make special factory type units that spawn the special units. I tried: <attachment name="territoryAttachment" attachTo="Themyscira" javaClass="games.strategy.triplea.attachments.TerritoryAttachment" type="territory"> <option name="production" value="1"/> <option name="unitProduction" value="1"/> <option name='createsUnitsList' value='1:amazons'/> </attachment> but i guess those options only work with units? Or did i just miss something. I seem to be constantly missing things... In the line, you are using primes, whereas you should use seconds (also known as double primes) (as TripleA wrongly uses seconds as if they are either primary American English quotation marks or secondary British English quotation marks, also know as double quotes). Yes, that is only for units: just have an "infrastructure" unit creating whatever you need wherever you need it in the starting setup. Is there a list of list of territory attachments like this helpful list? The official reference for game-making is https://github.com/triplea-maps/the_pact_of_steel/blob/master/map/games/pact_of_steel_2.xml

@azimuth Try using "Movement By Territory Restricted" to prohibit movement anywhere.

@tannenbernie It is good that you tried to a test map first. Many would-be modders try something overly ambitious and then give up when the run into problems. I wish you luck on your new mod.

Yeah I think so. It's not the simplest thing to test, but I can take whatever existing map and extend the canvas horizontally or vertically. I think if the map is wider than 4:3 you'll get the horizontal pan, which to me feels pretty natural, like the map sorta behaving as I'd expect for the drag around survey view. If the map is narrower than 4:3 you'll get the vertical pan at max zoom out instead, and to me this feels sorta awkward and I can't quickly zoom out to scan and pan, but have to drag the cursor to see the bottom. The mouse wheel up/down scales the height. I'm not sure if there is a way to define the mapview window or the marquee rectangle on the mini as something other than 4:3 or whatever it's using for the actual field of view? I think if there is, it's within tripleA or if tripleA is carrying that over from windows, like the game engine rather than in the map.properties of whatever specific map? The Tutorial map is an interesting case, cause it shows the Bung World War II Europe 1940 map which has almost not pan at max zoom out. Like it is only just the tiniest bit wider than 4:3 so there is no play in the grab and drag unless you first zoom in. The minimap for the tutorial is a swatch at 2:1 currently. So the image shown in the mini is stretched. The map view holds at 4:3 but the dimensions of the minimap will change the shape of that rectangle as it's it's displayed on the mini. If the baseline and mini don't match, you will see a slightly different shaped rectangle on the mini, but really it's the 4:3 image being stretched. Here's a screen showing the current default for the map called "Tutorial" [image: 1712136747813-screenshot-2024-04-03-022752.png] Here's how it looks when I replace the 2:1 smallMap image in the map folder with one that matches the aspect ratio of the Tutorial baseline. You can see the minimap rectangle is now displaying as normal and the main map has the vertical up/down drag. The field of view orients top right so the bottom of the board is cropped off at max zoom out. [image: 1712137045605-screenshot-2024-04-03-023557.png] I think the reason the mini is at 2:1 in the default is so that the map can zoom all the way out, even though it heavily distorts the mini to achieve that. The zoom for the field of view on the main map seems like it can be at least partial controlled by the smallMap that the minimap is using? I've been saying 4:3 but it's kinda hard to tell honestly, my screen is at 16:10 so it could just be that is the display area and it's just the mini that's stretching, same as in the above. I guess someone could maybe confirm if your screen is at 16:9 and the rectangle on the mini matches that with a slightly wider view then I guess we'd know it's keying off the resolution screen size in windows for that? But anyway, the idea would just be to make sure the baseline map is wider if you want a horizontal pan at max zoom out, like to fit the map by Height as opposed to Width. Otherwise you'll get a crop like in the Tutorial map, with the up/down drag. I think most players will play at some intermediate zoom, but then mouse wheel to max zoom out for the quick scan. That's what I do at any rate. There aren't a whole lot of tripleA maps that have a square or vertical orientation rather than a horizontal orientation, but there are a couple. In some of the fantasy games, or simpler maps like chess or capture the flag etc those type games set in a square or taller. Maybe someone who has more experience with various maps could let us know how it feels for those. Mostly I've been playing tripleA maps that are wider than they are tall, like the World War II world maps. But I think anything too square-ish and you get a similar thing happening with the zoom.

@thedog

The game.dtd file is now located at https://github.com/triplea-game/triplea/blob/master/game-app/game-core/src/main/resources/games/strategy/engine/xml/game.dtd

Ok so I put all the stuff I had into the UHD map making folder in the lead post. With the dark ocean stuff, the Units with their flips, and some of the extra stuff for layering relief clocked in right around 200mb zipped. Here is the file again, the one that has all the relief elements and such. UHD map making stuff https://drive.google.com/file/d/1CAymUozYeQirEmsyl4wAV2Q70QunbpA6/view?usp=sharing When I removed all the extraneous stuff from the UHD World War II Global folder for a lighter footprint file that one clocked in at about 81 mb. Here is the game folder... UHD world war II global https://drive.google.com/file/d/1e1KU3n5lwPLLRWC5_3Vcdlo7NUj2mxrK/view?usp=sharing It has no relief as a single image, but that should be easy to reconstruct from the reliefTiles folder. Provided the other Customizing package lives somewhere people should be able to get at what they need from that, like to edit the relief, do different borders or different styles, retint the units or whatever. I removed the v3 48px units, since those can be grabbed from the regular global download. They're still compatible, so you can switch the units from one map to another (48px mono tints or 54px duo tints), but it trimmed down the overall filesize so hopefully the install/load is a bit faster. Let me know if that makes sense for ya Have a fun weekend!

Oh also I just remembered, so for the smallMap image you can try just making that a solid blue swatch at the desired pixels instead of using "Other: Optional Things -> Run the Image Shrinker" Just to make sure the white dots aren't coming in from that. If they only appear on the mini map it's likely from the tiny image there, where some white isn't being fully covered over by the HEX colors from the polys so they show as gaps. Unless you have tiles that are unassigned and intended to show as white on the map, the smallMap doesn't actually need any white or black, since it's just painting stuff over from the polys there. For example the smallMap in UHD global looks like this... [image: 1710372443457-smallmap-uhd-global.png] Only the arctic section at the very top was left white, since those polys weren't assigned in the game (to create the little ice sheet effect), but for everything else just needs a blue field to paint in the HEX colors on top. The white there was just me lazing out and not wanting to assign a ton of extra icy tiles, but if assigned and given a HEX they'll paint like all the other tiles and you just need the blue. ' For 4:3 at 320 px, try using this for the smallMap jpeg... If the little white dots don't display anymore then you'll know they were just coming from that tiny image instead of the actual polys. [image: 1710372476965-smallmap.jpeg] I totally forgot, but the same thing happened to me as well! lol Hope that helps! ps. oh and for the shape of the polys in the mini map display, I believe it will just stretch to match the aspect there when painting the polys into the mini if it's different than the main map. Probably not a big deal usually if the aspect is slightly off between the two rectangles when showing a squiggly world shape, although to hold a simpler overall shape like a circle, I think both need to match or the circle might get compressed and go oblong? I think you're already ahead of that one cause 4:3 is optimal for tripleA. It only sorta works at 16:9 cause the Mini and UI tab can kinda cover the unused area. I'd have done the UHD in 4:3 but the regular world war II global that bung made at 2:1 so I split the difference, but it was kinda wonky at 16:9/16:10 which I didn't manage anyway, cause ended up cropping at the margins a bit. Go figure! I'm still learning how all this stuff works myself, even after many years trying to puzzle it out haha. Best of luck dude! Let me know if you hit any snags

Short answer yes. Using isAI and say rounds 4-5, 8-9, 12-13 or another condition Have 2 or more turns give the AI a chance to assemble forces for the attack.

@ebbe FlakTower is right below your "German". Coincidence ? I say Destiny [image: 1708098670342-screenshot-from-2024-02-16-09-48-40.png]

You should at least double the size of your map, so the map will have space to deploy all the units.

@wc_sumpton said in SBRs: Use Multiple Dice: I bow to your superiority! heh heh lets not get carried away now

@eqqman So the "none" can be used as a faction that does nothing, but can have; "capital" code. step logic like notifications conditions Search map xml for to look for "DoesNothing" and then the faction to find actual use.

@rogercooper Hello- I figured it out, the map.yml file had the last required edit in it.

@joseph-prince - I'm late to the party... but for anyone searching, the problem was the capitalization (as one replier did mention, but it was never tested) lightArmour vs lightarmour