@squid_daddy Please take the liberty to update the docs to get them more up to date, fill in any missing details, and generally make them more useful for someone getting started

@cernel said in General 2.6 Discussion:

downloadedMaps/the_pact_of_steel

In this example, the map.yml file goes right under the map folder, downloadedMaps/the_pact_of_steel/map.yml. That is true no matter which current or legacy folder structure that is used.

About the version number, it should never be called as just version (to avoid confusion with the game version, which (you want it or not) will remain something defined by at least some map-makers, no matter if you remove it, because every time you change a map's game without changing the game's name you have a new version of the same-named game, and this is a fact no matter if the program misses to inform the users about any difference before starting the game) and should be at least a two digit one: the first digit for non-backward compatible changes (meaning that your saved games may be not anymore playable if you update the map) and the second digit for backward compatible changes (meaning you should be safe to update the map with no fear of being then unable to continue your saved games).

This is nothing new at all with 2.6. Be what it may:

I don't know if the game engine ever used the version value found in map XML for anything beyond a label. Each map maker having their own versioning system is not sustainable for maintaining maps. If they all need to be updated, nobody is capable of divining all the different version number strategies It's not important to define a version number'ing strategy and teaching everyone it when it is not enforced by the engine Maps should never be made non-compatible. TripleA has NEVER supported this, (it is a major design flaw present since day 1) - it is a very bad move for a map maker to do this. Whenever we have made incompatible changes, it's always been incredibly painful. Instead a person needs to create an entirely new map copy and note that it is an updated version in the map title.

@hepps I would love for the ratings to be sorted out and refined. There is an open need for Map Admins to go through and do curation of maps, volunteers needed: https://forums.triplea-game.org/topic/2707/map-curation-rating-maps-categories/1

@lafayette well i think having some kind of directional arrows behind the lock or maybe a map grid under the lock 3d style would have the same effect. 🙂

@cernel said in Allow user to specifically choose amphibious offloaded units in battle chooser:

I want to add that, as far as I know, the only current case (beside multiple hitpoints) in which you are prompted to select different same-named units is when the two or more same-named transports (surely sea and maybe air too) have different units assigned. In this case, the transports will display the units on board beside the transport's image (or nothing if none). So this should be done in a way similar to that and also taking into account that in the future more additional images might be added for other cases in which it is not irrelevant chosing any one amongst two or more same-named units.

There are other cases as well. When putting a unit on a transport, if transports have different amount of movement left, it will separate them. When putting a unit on an air transport, if the units have different transport cost, it will separate them.

I'm still unsure about resurrecting the previous and next buttons. If a person really wants to cycle through all units before toggling them as moved, assuming sleep remains removed, why not cycle through all units once and then use alert-all to go back through them?

Can I get some more feedback on how exactly the previous button is useful as well. The ordering is not very deterministic, if you can see a unit on the same screen, then it seems that cycling is not super useful. On the other hand, if a unit is on the other side of the map, then previous also does not seem useful as well.

Please pay attention to exactly how you use this feature. IN which circumstances does everyone use the following?

previous sleep wake-all

Really would appreciate as much feedback as possible here from those that have been using the unit scroller.

FWIW, the places that would need a fix are largely in code that will be deleted pretty imminently. That is why the fixes are in queue.

@LaFayette i do think we are currently diluting our branding the way it is now.

when you say "cut off drop-shadow" are you referring to the outer glow he has around everything?

@LaFayette The alternative skin for 270BC is an example of changing also the units. There may be others.

Here you can find a map-skin for RSoC that is actually about making the map bigger:
https://github.com/Cernelius/red_sun_over_china-big_skin

The current map-skin feature allows changing everything in the skin, and that is good. What is not very good is that it obliges you changing everything, so forcing duplication if you don't actually want to change everything. It is true that most map-skins are only about changing the map details, but I think this is beside the point (Of course, some things are more used or useful than others.).

@LaFayette said in TripleA Rules Sets:

What would be ideal is to have a table describing different behaviors by rule set.

We are actually on our way there. We have example maps that follow each rule set, all we need to do is to start teasing apart the behaviors that are different and then answer for each map, "does this follow that behavior, yes or no?"

If we find that some rule sets are only very slightly different, simpler is better. The 'v3' moniker will be difficult to drop, if we can keep it simple and say "old edition", "revised edition" and "new edition", it could be easier to adopt. At this point though, without knowing what the rule sets actually are, it seems to be a first priority to know which rules are in each rule set before we do much of anything else.

@Cernel As we unzip a file, we will be doing a lot of checks (are all the required folders there? is there a centers.txt, etc.?) and as part of that process, we could enforce a casing convention.

I have a tool that fixes capitalization. When I got image assets from @GenerationKILL sometimes the casing was a bit off, so I would just run this tool and it would conform every unit to a convention like this: Unit-Name.png regardless of the OS and regardless of the original naming.

We could implement a similar normalization process at the map parsing level (though it might be hard to get map makers on the same page about which casing convention should be used).

https://github.com/jdimeo/triplea-map-tools/blob/master/src/main/java/jdimeo/triplea/util/FixFileNames.java

So, would you be ok with removing some locks if it can be shown that the data is actually read only?

I'm currently looking at ResourceList which is what GameData#getResourceList returns. The class has only one setter and it is only called during the game parse process and a test method. The data that ResourceList stores is a map of Strings and Resources. And Resource is a value object.

ResourceList doesn't appear to need any sort of read lock since I don't see any way for it to change. If I see locks around GameData#getResourceList, can I just remove them? Would you like me to tag Resource and ResourceList somehow (such as @Value) to indicate that they are read-only objects?

@LaFayette Dont forget to add triplea.log to the list of files to uninstall.

That said, is there a particular reason (other than a chunk of code not really necessary to functionality) that save game files don't work that way?

Java serialization was once popular, it was an initial design decision to use it, it was somewhat easy. We would actually like for save games to work more like you have described. It's a very large project, that is all, and we have a large backlog of small and large projects that we are working on and collectively there is not that much development labor available.

Re: performance requirements

These are the wrong things to focus on. First focus on functionality, what are you going to built? What value will it provide, how will it be used? You need a good product for anything else to matter. Then I'd encourage to stop worrying about specs. Simple and well done architectures are fast and perform well. Simple code is usually fast code. Once you have a reasonable design in place and functioning, then you can start analyzing where the performance bottlenecks are and where to go to optimize. It's a ways to get to that point, and once you are there the process is to measure, change, repeat. Humans have generally very bad intuitions for where performance problems will arise. It's also easy to try and fix all performance problems as optimization problems when they are really design problems. One can look at a block of code and wonder "how can I make this faster", and sometimes the right answer is, "how can I avoid needing to execute this in the first place?" That is why keeping things simple and working is very important, it lets you reason about what your code is doing. For example TripleA does a lot of calculations twice, why? Because there are 15 layers of call indirection separating the two which creates several thousands of lines of code in between the duplication.

Bottom line

OUr time is short in just about every way imaginable. I'm pretty sure and somewhat regrettfully going to say, if you want something that interoperates with TripleA, it's potentially one of and likely all of: untractable and/or a truly huge project

We have wanted to for example to allow TripleA to run on web browsers, or phones. That project is probably 3-8 years away from being completed if it were started today.

This might be even better of a starting point: https://github.com/triplea-game/triplea/tree/master/docs/development#developer-setup-guide

Installing intellij is pretty easy. Once you've done that, you clone the code (you'll need to install a git client), and then in IntelliJ you select "open" > "project" and then select the build.gradle file and it should auto-configure everything. From there, there is a 'launcher' that you can use to compile and run the game.

Its a good idea, I like it.