@lafayette So it won't be anymore possible to keep (broken or elsewise unworthwhile) maps in the official repository yet not in download list? In particular, I've noticed that "Conquest of the World" is now offered for download (which is fine because I believe the game is at least playable).

@rainova Maybe, that link is a bit skimpy on detail. FWIW you could verify some of that yourself by running that docker container. You would need to do more to have tests run from within the container or somehow to forward to the virtual env.

Though, if you did manage to get a headless container running, there are some drawbacks:

setting up yet another docker and one more built step is just one more thing what happens if a test fails? If the UI is headless, how to tell what was incorrect? What if the results from the virtual desktop do not agree with running without docker?

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

@cernel Maybe take a look at my "270BC Wars" game. That one has 64x64 unscaled unit images
Carthage.png

Pretty unit images 🙂

Now that I give a minimum of attention to it, your screenshot clearly has enlarged (so, being raster ones, qualitatively degraded) units: those images you are displaying are certainly in excess of the 64 pixels on both axis they are supposed to be. I believe you are affected by this problem or something similar:
https://github.com/triplea-game/triplea/issues/4442

I suggest you check whether or not that issue was unwarrantedly closed. Whatever the reason, I believe what you are experiencing is a problem because a raster images based program like TripleA should be supposed never to be generally zoomed as its own default (assuming this is what's happening to you).

I agree, words are better than numbers.

@thedog
Oracle Java works fine. Your issue is that your system java install was java8. You can avoid this issue by setting the path to the java executable bundled with Triplea v2.5/2.6 on Windows, as suggested in my previous post or by modifying the classpath environment variable.

The hotkey to hide the menubar is ctrl released ALT: Press CTRL (hold), then press Alt. Releasing Alt fires the hotkey.

@cernel said in Fontsize and dpi scaling:

If it is feasible, the program should always enforce a pixel-per-pixel rendering as default (assuming vectorial graphic will never be supported).

Vector graphics require fundamentally different software tools from png and svg isn't natively supported in java swing.
Vectorizing the existing maps and artwork would be a lot of work. Then the map handling engine is based on pixel coordinates.

Vector graphics would make more sense for interface icons (ex: icons on buttons, menuitems), which TripleA makes very limited use of currently. Icon Fonts would likely be the right solution as they allow scaling and theming.

With the above said, we can certainly discuss what would be more or less equal to rope in.

@thedog said in TripleA 3.0 - Design Proposal & Discussion:

From what little I know, the coders time could be better spent coding , than unpicking the old code, working around it and patching it up, putting patching on top of patching.

That is kind of part and parcel to the task, it is somewhat intrinsic and describes what has been happening now for 15 years.

A new XML structure format might be better in a later version say 3.5.

Having new core data structures could be very important for re-arranging the code. Patching it together sounds much simpler than it will be. Removing all constraints of the existing design could prove to be very important lest the fire breaks will continue to have legacy design that has been holding us down.

New code for the file saving format

Almost all of the core data structures are tightly coupled to save game. A 'unit' and the concept of a 'unit type' cannot have any alterations because those code objects are encoded onto hard disk. We cannot change them in nearly any way without breaking save game. An overhaul of how the code is structured and data is required to enable a new save game format. Those same objects are mapped pretty directly to the XML, revisiting this from the ground up implies it all may change drastically.

There is a lot of uncertainty here, though having a green light to make radical changes is a key component to 3.0. I'd rather release a 2.7 sooner. Though, we have been trying to rearrange and fix core code design for half a decade now, it does not seem to be effective enough to really be successful.

@lafayette @TheDog agreed, upon a return review of the entire thread it is clear to me at least, that there has been some unintended obfuscation and misunderstanding on both sides.

i think we are all looking for the same ultimate goal here so if we have to burn the existing vote and start over in a more agreeable fashion i have no objection. again i thought we were under the gun so that might have been a bit rushed. 🙂

@cernel A single file for game notes could be difficult because then you have to encode the HTML in some way. You no longer could open the notes file in an web browser to get a preview of how it would render.

With 2.6, if you want to organize games into folders with generic names, AFAIK you can do that now. You could not previously to 2.6

@LaFayette
Before I was guessing what happened, but here is a little bit more detail;

where letters = Territories and numbers = units in those territories.
D2 = Territory "D" with 2 units in it.

A1, B1, C1, D2, E2, F1, G1

Say I move the 1st unit in E2, it should return to E2, but it actually goes to D2.
If I move the 2nd unit in E2, it should return to F1, but it actually goes to G1.

@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

@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. 🙂

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 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.