Can the border mod tool be used for standard dice maps?

should work.  Please let me know if you have any problems.

Would it be possible to use a variable that connects the regex in the from and the regex in the to. For example (using modify border) if the from were '.A' and the to were '\1B' then it would create borders from 1A to 1B and 2A to 2B, etc but not from 1A to 2B. This is similar to how Word does search and replace: https://support.office.com/en-us/article/Find-and-replace-text-by-using-regular-expressions-Advanced-eeaa03b0-e9f3-4921-b1e8-85b0ad1c427f

Word calls the variables placeholders.

Let me see how well the python regex library I am using supports this.

I added a simple addBorders function.  It doesn't have a gui form, so (for now) you have to enter the command by hand. I did put it into the documentation and link that on the main WGAME page.

What should I work on next?  Korrun, do you still want a way to connect two regexs in modify borders ?

Connecting the two regexs would make an easy way to self reference (not just for modify borders). Say you want a vision territory to be auto captured for every territory on the map. Use a ".*" for the from and use "\1 Vision" for the to so a factory will be created for every territory that auto captures the territory with the same name and "Vision" afterword.

Okay I guess there might need to be some refinement there, since then "A Vision" would try to autocaptue "A Vision Vision", but you get the idea.

Things I would use more immediately:

Collector's bonus for triples, etc.

Moving every territory on the map a certain number of pixels (to accommodate a border or title being added to the image later).

Moving every territory on the map a certain number of pixels (to accommodate a border or title being added to the image later).

You can already do this directly in the map editor, though it's a bit slow. If you are in territories -> edit, and you select the "all" button, then every territory will be selected. You can use the arrow keys on your keyboard to move them, as a group, one pixel at a time in any direction. That said, it's a bit touchy to move a large and precise number of pixels, but you can check to make sure you got it right be turning on the X,Y coordinates.

Kjeld wrote:

Moving every territory on the map a certain number of pixels (to accommodate a border or title being added to the image later).

You can already do this directly in the map editor, though it's a bit slow. If you are in territories -> edit, and you select the "all" button, then every territory will be selected. You can use the arrow keys on your keyboard to move them, as a group, one pixel at a time in any direction. That said, it's a bit touchy to move a large and precise number of pixels, but you can check to make sure you got it right be turning on the X,Y coordinates.

What would be good though is to be able to move a chunk of territories like those used as off board factories.  Every territory with "- obf" at the end can be shifted south at a whim, or, back up again, at a whim, if you need to work on those factories again.  Sometimes if off screen factories are too close to the board the numbers are visible on high pixel displays.

One could really put any addition into the territory names so that they can move any group with WGAME.  So, it could be -all - obf for some and -all for the others and then you could move all or just the obf's.

@Ozyman

Finally got my hands on Python. Installed Python 3.6.0 and PyCharm 4.0.5 IDE.

At first I couldn't run the interpreter. After a lot of research, turned out I was missing the Visual Studio C++ 2015 Redistributable package.

Took a look at your General.py, but I'm a bit rusty with programming atm, so skipped the class part and set to do what I wanted to, from scratch. Gotta say Python is very similar to Java, which I only worked with for a semester some years ago.

Read a bit of a tutorial and started pounding my head at DOM... finally managed to do what I wanted, which was to move the position of all territories by a fixed amount, since in one of my scenarios the board is bigger.

This is what I came up with:

__author__ = 'redshift'

from xml.dom.minidom import parse, parseString

dom1 = parse("xml_test1.xml")

shift_pos = 62

for land in dom1.getElementsByTagName('territories'):
    land.toxml()

for num in range(0, len(land.childNodes), 2):
    xpos = land.childNodes[num].getAttribute('xpos')
    xpos = int(xpos) + shift_pos
    xpos = str(xpos)
    land.childNodes[num].setAttribute('xpos', xpos)
    ypos = land.childNodes[num].getAttribute('ypos')
    ypos = int(ypos) + shift_pos
    ypos = str(ypos)
    land.childNodes[num].setAttribute('ypos', ypos)

file_handle = open("xml_test1_out.xml", "w+")
land.writexml(file_handle)
file_handle.close()

For some reason, I had to go in steps of 2 in the last 'for' loop, which I didn't understand why, but from the tests I made, I figured it had to be this way.

I noticed that the order of the attributes in a given line do not matter, the designer ate it well. The DOM tree orders the attributes alphabetically. Example:

<territory boardid="7113" id="2133881" max_units="0" name="S74" scenario_seat="0" scenario_type="Neutral Capital" scenario_units="3" tid="73" unit_placement="Enabled" xpos="312" ypos="517"/>

looks good redshift.   not sure why you have to step by 2 in your loop.  I think it has to do with the way the XML comes out of the DOM.

FYI, I have a moveTerritories() function in the WGLib.  Using my library your code would be:

inXML = 'xml_test1.xml'
 
wgmap = WGMap()
wgmap.loadMapFromFile(inXML)

shift_pos = 62

wgmap.moveTerritories( (shift_pos, shift_pos) )

wgmap.saveMapToFile('xml_test1_out.xml')