The Grand War
-
@redrum Thanks. And regarding version numbers, is there any reason why I should or should not use integers (version1, version2, etc.) as opposed to decimals (version1.1, version1.0.1, etc.)?
@frostion Hm, yeah I can see the appeal in that, it does look nicer... would take a while to change every single one, though, so I may take a while to update everything.
-
@elreigh For the yaml we always just use integers as the number doesn't really mean anything and that's just simpler/consistent. For the XML, its really up to each map maker how they'd like to version the XML. Most I'd say use either 2 or 3 numbers (x.x or x.x.x) but some use just 1 and some even have 4 (x.x.x.x). I'm sure @Frostion and @Hepps have opinions on the matter.
-
@Elreigh If you use Photoshop, that program has a “batch” feature. With that you can “record” what you do with one picture and give the same treatment to a batch of pictures. It takes some time to learn, but it is very useful. I have actually forgotten the details, so don’t expect me to explain the process, but we can probably find a guide on youtube or somewhere.
EDIT: I have the feature at: File --> Automate --> Batch...
@redrum I have not been consistent with how I do version numbers, but I think I have finally settled with a three digit system, like v1.0.1 updates to v1.0.2 and v1.0.9 updates to v1.1.0.
This is partly because going from v1.9 to v1.10 results in TripleA displaying v1.10 as v1.1. TripleA does not want to display the 0.
-
-
-
Alright, I did edit all of the territory names to half opacity, but I do not like the way most of them look on the map. Arcadia and India look great, but only because they are bold fonts. Grands is barely legible because of how thin it is, and it does need that extra opacity to be readable. I may wind up changing some of these fonts to make it look better, since I have always thought the Grands font was especially difficult to make out.
-
@elreigh Maybe only make the Arcadia and India be half opacity then and leave the rest?
-
Version 3 Update is out now, changing relief tiles to make territory names stand out less. I've also reduced fighter defense from 4 to 3, after some consideration on balance concerns.
-
@elreigh All bot servers will require a restart to accept your new version. (which I don't mind slowly doing as they empty) Are you planning any more revisions soon?
-
@prastle No I'm not planning on any more revisions at the moment; I'm pretty happy with the way things look at the moment, and I'd like to work on some other projects for the time being.
Is there a common courtesy standard for releasing versions so they don't mess with all bot servers? When I need to make updates in the future I could stall them out to bundle many into a single version. I would've done so with these changes if I knew it was a hassle for others.
-
@elreigh No hassle we needed an update anyways. I just was mentioning so i could time it with your new stuff as well as frosti's
-
Regarding version numbers, for some reason changing the xml version to "3.0" disables the map in the "Select Map" screen, so until that mystery is solved I'm going to leave the xml version as "1.0"
EDIT: Scratch that, I was changing the wrong version number in the xml. I've got it working now.
-
@prastle FYI ... I have no planned updates to any maps right now or in the near future. If I got some time, it will probably be spent on some new map project. All those new maps being developed by other mapmakers inspire me to also make something new
-
@frostion kk
-
@elreigh Changes look good. Just forgot a small update to the notes: https://github.com/triplea-maps/the_grand_war/pull/1
The unmentioned new naval unit images are definitely an improvement as well
closed Update fighter defense notes #1
-
@redrum Ah, yeah I forgot to mention that, and I didn't know the pull request had to have the details of my updates in them. I'll be more specific in the future.
-
@elreigh Oh I meant your post above. You can take a look at merging my pull request if you agree with the notes update
-
@redrum Ah, I thought the "notes" you mentioned was "patch notes." My bad! Yeah, I've confirmed your request. Nice catch, thanks!
-
-
@redrum said in The Grand War:
@elreigh The version in the XML is the 'real' map version that players would reference and such to version changes you make. The yaml version is just a way so the engine knows for players that already have the map that there is a new version that it should allow them to download.
You are the owner of the project, so you can set the definitions for it, but this definition alone is simply not possible, based on what I understand the definition of "map" is. Since a map is the entire "map" folder (so, the skin plus the games), you can have multiple games for a same map, each one with a different version, obviously. Hence, the XML/game version simply can't version the map, as being potentially not unique.
As now, there is no way to version a map, while it would be advisable there is, not only for maps offering multiple games, but also because if a mapmaker just changes something in the skin (like you change a player colour and nothing else, or just make new images for the "Carrier", or whatever), it doesn't make sense (to me) reversioning an untouched XML. I'm really not going to upgrade an xml version if the xml is the same, and I just changed something minor in the skin, and (to avoid having different maps without versioning differentiation, which I like to avoid) my "solution" currently is just holding off on any skin changes until some xml changes are made, but this is a lame solution that kind of works only for single game maps.
For example, if we just take the New World Order map and make new "Carrier" images, because somebody thinks they look too similar to the battleships, it would be bad to increase the version of the game, as that would be telling that we have made changes to New World Order, while we have not. It would be actually good leaving New World Order, as a game, having the exactly same version, and referencing somewhere else skin-only changes. Or we could also simply swap one of its mapskins to be the current original one; also this should not cause and upgrading of the game's version, in my opinion.
In absence of an actual map versioning, it is unsurprising mapmakers will think about the download version as being the map version, as that is actually the closest thing to a map versioning you currently have. Also, that is an endless source of confusion for users, because they see a version number when they download and another version number when they look at the game, and don't understand why is that (had a few cases of users asking me if they downloaded correctly).
My suggestion would be having a map version, in "map.properties", additionally to the game (or games) version (or versions) in the xml inside the "games" folder. Then (still just my suggestions), the mapmakers should be instructed to always upgrade the version in map.properties each time any changes inside the "map" folder are made (also if only the xml are), while, on the other hand, upgrade the games versions only in case of changes for the respective xml only. Then, to make all clear to the users, in the "Select a Game" windows they would be told, for each game, its version and what map that game is using and the current version of that map. Once this is done, then I would advise the download version actually equalling the map version. I believe this would cut confusion, and cover all needs. Just a suggestion, since I believe this issue has been ever present in TripleA (also in the old depot there was this dualism between download versions and games versions, and mapmakers tended to just have the download versions being the same as their games' versions, at least for single game maps, but I don't believe this was deliberate, or at least I've never seen it documented anywhere (not sure, we would need asking Veqryn)).
