Mixed Questions

Stohrm

The spelling needs to be the same as the map name at the top of the xml (not the bottom of xml )except you need to use underscores "_" instead of "spaces".

So this "World War II v3 1941" is written like this in objectives.properties "World_War_II_v3_1941".

@beelee I just wanted to say "thank you"; as this just helped me resolve an issue I didn't even realize that I had. Since the Objectives tab wasn't even showing up, I failed to notice that they were missing.
So, besides the "objectives.properties" file, are there any other places where the map name(s) need to match? I gather the "README.md" file needs to match the map name at the bottom part of xml; or is it even necessary if the files are just local to my computer and not being uploaded to GitHub?

beelee

@Stohrm said in Mixed Questions:

@beelee said in Mixed Questions:

The spelling needs to be the same as the map name at the top of the xml (not the bottom of xml )except you need to use underscores "_" instead of "spaces".

Since the Objectives tab wasn't even showing up, I failed to notice that they were missing.

Heh heh. I did the same thing. Must've worked on a mod for weeks before realized there was no objectives. :grinning_face:
yea idk, being local might be ok. When uploading to Git you gotta be on it. @Frostion has a nice guide for adding stuff to Git.
Well sadly, I can't seem to find it right now. I thought it was under map making but w/e...:) I'll try and find it again when I have a few more brain cells functioning

Here it is:

https://docs.google.com/document/d/1FfF7N0srp9QG0_if5D-c1d1Aa1QTttdhxgm1GBh3pI4/edit

Edit
Yea you gotta make sure the name is right or it won't show up in "Select Map" when you have triplea fired up. Gotta use the bottom one for that. I think

LaFayette

FWIW, the folder structure that is uploaded to github matches what you would have locally. You can work on files locally, make sure it works, and upload changes incrementally to github. It's not required for maps to be working to be in a repository (github), but they should be working when added to map index file: https://github.com/triplea-game/triplea/blob/master/triplea_maps.yaml

Publishing to github often allows you to recover previous versions in case you make a mistake, and you can use 'git' locally to do the same. The upload also allows others do DL the work in progress map by downloading the repository.

While none of the above is terribly complicated, there is a learning curve to it. Hence there is a long term project to make this even easier yet and allow uploads from in-game.

Cernel

@RoiEX Anyways, I also want to add that, if it is true that escaping spaces in calling info name from properties folders is currently somehow disabled (I know, for having tried it, that generally escaping spaces in properties folders, instead, works, at least in other cases), I don't know if it would be that good to enable it, as then you would end up with two different methods for doing the same thing supported at the same time. If going that way, I'm just strongly suggesting making clear which one of the two methods is the correct one, deprecating the other, and updating the_pact_of_steel.

RoiEX

escaping spaces in calling info name from properties folders is currently somehow disabled

This isn't true. The code uses the default java way to parse .properties files, which supports escaping spaces.

The "real" problem is that before actually comparing the map name with the key is that the game name is being substituted for a weird underscore solution as already mentioned by you.
Found the place in the code:
https://github.com/triplea-game/triplea/blob/4a22b54ee153168091a4d537db1f5725cc011a8b/game-core/src/main/java/games/strategy/triplea/ui/ObjectivePanel.java#L129-L132

The following characters are replaced by underscores:

/, the normal slash
\b, the backspace character (which probably isn't ever going to land in the name, but hey for completeness)
\n, the newline char
\r, the carriage return char
\t the Tab character
\0, the null character which is probably not going to land in any file either
\f, the new page character that I didn't know until now (probably never used either)
`, the backtick for some reason
? and some other common symbols:
*
\
<
>
|
"
'
:
.
,
^
[
]
=
+
;
and finally the space character

The code basically re-uses the "filtering mechanism" for filenames, replacing illegal characters there, which is why the weird characters end up in this list.

I mean we could optionally "allow" the real map name to be used, but if you ask me this logic should really be part of the XML instead.

Cernel

@RoiEX As I said, in my opinion the best solution would have been forbidding using all those characters and the space character in the info name of the game file (xml), then, when the info name is displayed to the user anywhere, display all underscores as spaces. Of course, this may not be feasible, for compatibility, as there are a lot of info name entries with spaces in them already.

Cernel

@Cernel said in Mixed Questions:

@RoiEX As I said, in my opinion the best solution would have been forbidding using all those characters and the space character in the info name of the game file (xml), then, when the info name is displayed to the user anywhere, display all underscores as spaces. Of course, this may not be feasible, for compatibility, as there are a lot of info name entries with spaces in them already.

And I would apply the exact same restriction to the "mapName" property (that is the one that is searching for the name of the map file), so that you cannot have spaces in map names. Maybe in this one also adding that all characters must be lower case, since this is the current practice.

Schulz

Can one tech token's cost be 2.5?

Cernel

@Schulz You can sort this out by setting it at that value, see what happens, faster than waiting for someone to give you an answer on that. I'm almost sure it will not be accepted and the game will fail to parse.

Stohrm

@Schulz said in Mixed Questions:

Can one tech token's cost be 2.5?

I don't think it likes decimals much; but you can sell 2 tokens for 5 PU's (if that's your ultimate goal). At least I think you can. Myself, I'm going to try adding them to the Purchase phase of the game - similar to the way Suicide tokens are bought by the Japanese in World War II Global 1940...

I found this in PoS-2 (and modified it) :

<!-- You can use a production frontier to buy resources using other resources.
	<productionRule name="buyTechTokens">
		<cost resource="PUs" quantity="5" />
		<result resourceOrUnit="techTokens" quantity="2"/>
	</productionRule>-->

Cernel

@RoiEX said in Mixed Questions:

escaping spaces in calling info name from properties folders is currently somehow disabled

This isn't true. The code uses the default java way to parse .properties files, which supports escaping spaces.

The "real" problem is that before actually comparing the map name with the key is that the game name is being substituted for a weird underscore solution as already mentioned by you.
Found the place in the code:
https://github.com/triplea-game/triplea/blob/4a22b54ee153168091a4d537db1f5725cc011a8b/game-core/src/main/java/games/strategy/triplea/ui/ObjectivePanel.java#L129-L132

The following characters are replaced by underscores:

/, the normal slash

\b, the backspace character (which probably isn't ever going to land in the name, but hey for completeness)

\n, the newline char

\r, the carriage return char

\t the Tab character

\0, the null character which is probably not going to land in any file either

\f, the new page character that I didn't know until now (probably never used either)

`, the backtick for some reason

? and some other common symbols:

*

\

<

>

|

"

'

:

.

,

^

[

]

=

+

;

and finally the space character

The code basically re-uses the "filtering mechanism" for filenames, replacing illegal characters there, which is why the weird characters end up in this list.

I mean we could optionally "allow" the real map name to be used, but if you ask me this logic should really be part of the XML instead.

By the way, this is not the only case of underscores to spaces. For example, you have underscores in the image files of territory names with spaces in the xml. I personally think that this underscores to spaces thing would have been better made via having only underscores, not spaces, both in the games' files (xml) entries (the game name, the name of zones, etc.) and in the skin elements referring to them, then always displaying underscores as spaces, to the user (the reason why, in the game's file (xml), you want to call a territory as "New York" instead of "New_York" is only the fact that you don't want to use a purely technical character, the underscore, that is not part of the common normal usage). I think the best way to realize this consistently would have been to completely forbid having spaces in any names inside the games' files (xml), making the game crash otherwise. Of course, now such a thing would imply breaking compatibility with all existent games, or almost so.

So, if you add or change to a backspace method (I've never seen a single map using it so far, did you?), in this case only, then you still have other instances of underscores-to-space methods, that you are leaving or not changing. So I'm not sure if this would be an improvement, generally speaking, as I personally would prefer everything following the same method, or similar methods, if possible.

Cernel

@RoiEX Also, on this matter (territory names), a name that has spaces in the game's file (xml) is referenced with underscores, instead of spaces, in the called territoryNames image files (as I said), but it is still going with spaces in the name_place names, so here you have a double criss-crossed instance of underscores-to-spaces method, and actually, differently from our case, one in which a name with underscores inside the name_place file will fail to be assigned to an image file name within territoryNames that is being called for display (as an additional side note, this is actually a mapmaking issue, as when you make those territories with the mapmaking utilities (using the Run the Map Creator/Step 2: Map Utilities/Run the Decoration Placer) those underscores you get from the image files names are not changes to spaces, by this utility generating the text file having the coordinates for them, so the "name_place" file you get will just not work for all territories with spaces in the game's file (xml) and underscores in the territoryNames image file names, nothing telling you that, either, if veqryn or something is not sitting next to you), and I assume at least the image files names part is advisable, as you don't want to have spaces in any of them (I recall you changed all spaces to underscores in the maps' folders names, for example, beside also having them full lower case). So, I'm just saying the example I made is not only for games names, but also for what written inside the name_place txt file, that in this case is not a properties one (so, of course, you are not escaping those spaces).

Cernel

@Cernel Actually, now that I think about it, I vaguely maybe remember that years ago this thing caused, for some time, images for territory names, with underscores in the images files names and spaces in the entries in the game file (xml), to fail to display, but I'm not sure I recall correctly, and it was eventually fixed.

RoiEX

@Cernel The problem with an 'underscore to space method' is that eventually someone would like to get some special char into the title, so that john_smiths_map turns into John Smith's Map and the apostrophe in the 'technical name' will be forbidden, this really leads down a rabbit hole of visual preferences.
It would be far better if there were 2 keys, one with the display name that is being used everywhere for displaying and another key that is purely being used by other references without any special chars.

Cernel

@RoiEX I wonder if the apostrophe is ok to have in file names (I suppose not)? For example, "New York" in the xml has to be "New_York" in the file name of the image (right?). Can, instead, "Bishop's Stortford" remain as "Bishop's_Stortford" in the image file name?

Anyways, I see your point: there may be more undesirable characters than just the space, that you may have in names inside the game file (xml), and, differently from the underscore, that is clearly representing a space, they may be not so obvious to convert for visualization.

Though, I think TripleA could be fine simply disallowing all of them in names. I think the space is the only one you don't want to pass, even though, of course, you could still write "New York" as "NewYork" (not a fan).

By the way, are you aware that this system of disallowing spaces in names entirely is already partially in place? For example, you cannot have units (and other things) with spaces in them.

So, @RoiEX or any developers, can you explain me why, as a potential mapmaker, I am allowed to have a territory called "New York" in the name, calling its image file name as "New_York", while I'm forbidden having a unit called "AA Gun", and I, instead, have to call it "AAGun" or "AA_Gun", or whatever, and exactly the same as its image file name, instead?

TripleA has already a few different methods. Substantially, what I would prefer is that it goes with only one of them in all cases, preferably one that allows a better look to the final user (I think we can all agree that "New York" and "Horse Artillery" look better than "New_York" and "Horse_Artillery" or "NewYork" and "HorseArtillery", right?). Wouldn't this be at least better? But I know I'm talking mostly theorically, as I realize there would be huge compatibility issues.

Schulz

I get this error message though map still works.

line: 3097, column: 26, error: The content of element type "attachmentList" must match "(attachment)+".

Line 3097 is just </attachmentList> as usual

Hepps

@Schulz If you post a copy of the lines around line 3097. It should be pretty easy to identify the issue.

redrum

@Schulz you most likely either have no attachments defined in the attachment list or you have something invalid defined in there.

Schulz

Cernel

@Hepps Actually, the problem can be anywhere from the start to the end of the "attachmentlist".