UPDATING OLDER MAPS FOR 2.1

Hepps

@ebbe Always supportive of fresh/new ideas and concepts. Feel free to use what you need to get your game going.

If I can be of any help, I am always happy to help whomever needs it. Just bear in mind I have very little personal time ATM and may not be 'Johnny on the spot' with responses or fulfilling requests.

RogerCooper

@ebbe I have updated most maps. What map are you looking for. Here are the changes I make

"IPCs" "PUs"
"ttatch" "ttach"
"<option name="victoryCity" value="true"/>" "<option name="victoryCity" value="1"/>"
"isImpassible" "isImpassable"
"occupiedTerrOf" "originalOwner"
"turns" "rounds"
"turns" "rounds"
"<option name="costPU" value="0" "costResources" value="PUs" count=""
"Impassible" "Impassable"

Cernel

@ebbe said in UPDATING OLDER MAPS FOR 2.1:

PLUS a lot of work aligning all units in the PLACE file to keep the map in order

You have definitely improved on placement over the original skin, but I suggest looking out for cases like the fighter in East Poland. It always annoys me a lot when a map has units that you are not quite sure whether they are in one or another one territory. However, if the map is not big enough, it's fine to have units going a little out of their zones, to have more placement spots.

Of course, this is my opinion. Others may feel it is clear enough the fighter in question is in East Poland and not in West Poland.

Conversely, I feel Germany has enough space not to have that overflow line.

ebbe

@RogerCooper THNXS, I am
happy to see tripleA community is very active and alive ; )

ebbe

@Cernel Still work in progressive... thnxs for advice... I realize this "straight order"alignment of units takes away the Boardgame-roots feeling.. but it gives me personally so much better overview in gameplay.... Right now doing a painstaking job on Units placement in sea zones ... created a soviet naval invasion to check .. place Fleet.png

Hepps

@ebbe Quite the Russian navy!!

ebbe

@RogerCooper Okej, I realize: my programming skils are limited and still I try to solve issues , asking for trouble... haha... ( forgive me the disturbance ) I managed to adapt the 1.8 files to be theoretically running in 2.1 : stilll I got this error... blocking my progress. and no clue what it could be ... anyone an idea?

wc_sumpton

@ebbe "attatchTo" needs to be changed to "attachTo".

ebbe

@wc_sumpton OFCOURSE... ! I fixed only the attachment not attachTo's thnxs

wc_sumpton

@ebbe Sorry to ask this but did you start with the latest download for "World War II Global 1940 2nd Edition", because I just re-downloaded it and the map seem to run fine. I am of the opinion that the map was already updated for 1.9 and runs fine on 2.1.

If I looking at the wrong map please forgive this inquiry and let me know what base map you are working with.

Cheers...

ebbe

@wc_sumpton Indeed, but I started from the original 1.8 workfiles I had... so if I get completely stuck a transfer all adaptions to the latest WWIIG '40 2nd ed.

wc_sumpton

@ebbe ok, no problem. That is where my confusion was coming from.

Cheers...

ebbe

Up and running in 2.1.... GREAT !!!! so I come back in some weeks with progress... if anyone knows how to reach Veqruin except for triplAdev forum.. I still have to ask him permission to use his work for an alternative version if I want to share it here... thnxs everybody... for the next weeks I'll be alligning Soviet fleet and armies on all Territories ... aaaaahh.....

Cernel

@ebbe Just a warning: The fact that a map is "running" in 2.1 without errors doesn't necessarily mean that it is correctly coded for or updated to it, because there are items that are not validated or that are deprecated (or both) (and I believe the program is not giving any warning for deprecated elements).

LaFayette

If using an XML element that has been removed, chances are really good schema validation will fail, or if not, map parsing would fail.

If the element is 'deprecated' but the map still loads, then the engine is doing some backward compatibility magic to translate the 'deprecated' elements to non-deprecated variant.

Cernel

@LaFayette said in UPDATING OLDER MAPS FOR 2.1:

If using an XML element that has been removed, chances are really good schema validation will fail, or if not, map parsing would fail.

Yes, since most is validated. I was just saying that you cannot be sure. For example, inexistent properties are simply ignored.

LaFayette

I'm not aware of any ignored properties. Either a property is going to "do the right thing" and translate itself into modern code, or the XML schema validation will throw a fit because the property is not recognized.

I'm interested in any counter-examples that you may run across @Cernel . Those are worth addressing in one manner or another.

Cernel

@LaFayette said in UPDATING OLDER MAPS FOR 2.1:

I'm not aware of any ignored properties. Either a property is going to "do the right thing" and translate itself into modern code, or the XML schema validation will throw a fit because the property is not recognized.

I'm interested in any counter-examples that you may run across @Cernel . Those are worth addressing in one manner or another.

@LaFayette As I said, properties are never validated, as far as I know and as far as a non-developer can be sure about it. Having a wrong property simply equals not having it (which, in turn, equals having it false and non-editable). You can test it by mangling the name of a property of whatever game. The result of this should be the same as having deleted the property from the game file (xml).

LaFayette

There is a DTD, doc type definition that does enforce which XML entities and properties are allowed.

I was thinking you meant an XML property as opposed to a TripleA <property> tag. In XML, a property is typically a value after a tag, eg: <tag property=123>

When parsing in an enforcing mode the DTD defines which properties are valid and which are not.

Though you are right about property name values. An unrecognized one would go unused. EG: <property name='not-recognized'>