@ssoloff

Thinking on it some more. I suggest the confirmation checkbox should always be next to the button (done/ok) as a pre checked or not checked box, depending engine preference.

If the engine preference is activated then confirmation is required by placing a check the box.

If the engine preference is deactivate then the confirmation box is a pre checked.

This disposition might be helpful if one wants to remove the pre check from the box to be safe (if desired) , while still in normal game mode.

@redrum said in Map to Engine Compatibility Problems:

This idea would have to be flushed out a lot to see if its viable. Map makers and players still want to see versions of the same map especially when the map is newer so it would mostly have to be under the covers IMO.

There is a question of how to link such maps. We already have a database of maps, it is a yaml file. To get to the immutable suggestion, every version would be a new entry. We'd convert the version and download link to a list. In this way we have an under-cover implementation for the most part. A good chunk of the benefit is from the assumptions we can make about any given download location. If we know a map version, and they are immutable, and we know the download link for a given version, we can always download that XML. Today with updates to maps, we lose that capability with the overwrite of new data, and we lose the information for the old location. I suspect there are more simplifications once things are immutable by convention. Basically, we would be optimizing for the 'copy/paste' and update strategy for maps : )

So there is already an engine version in the map XML. Its use could be expanded so that say the downloader reads it to avoid older engines downloading new maps. But you'd also have to ensure map makers are actually specifying the min version XML field properly.

Indeed, but:

usability problem as you mention introduces a bulk update problem, we have to bulk update engine versions tracking engine versions in map XML, I think the two concepts should not be fundamentally related at all. I'd like to see the game engine depend on map parsing, not the other way round in a circular dependency. we'd have to parse every map XML to show the 'download maps' window, this is likely to be too slow. it's not known where a game XML will be, and there are multiple. We'd have to scan the entire file directory of a github repo to find the XMLs, and we'll find multiple.

It would help if games and maps were 1:1, then we would know the map XML location and maybe could parse the actual file on the fly. That would be nice as we could put other items like download description and map title all in the same file.

So if we add back in including past jar versions of TripleA then this could be useful but without those most players don't want to have multiple engine versions sitting around so any maps not upgraded are effectively dead. Also developers would most likely have to manage the max version since map makers would know what to set it to.

Good point, I've considered the same. But:

old jar was not a complete/good solution. It did not work for the 1.8 to 1.9 upgrade. We also had to do work to maintain it, it made path loading very whacky and was hard to keep working. non-upgraded maps are already effectively dead, it's something of an existing problem I suspect developers will need to manage min-version even. Max version likely would be easy, it'll match to be the next version that is not going to be compitible. WE'd have to discuss what kind, if any mapping there is to the game engine version. So I'd envision this being set to 'version 2' everywhere. When we have a new incompatible engine, we would add a bunch of maps with min version '2' and max version '3'.

Would need a lot more detail on how this would work to determine if its feasible and worthwhile.

Should be feasible, we can introduce some logic to upconvert objects. I'd personally lean on the open-close principle when designing it. 'Worthwhile' should be pretty obvious I would hope. My experience of a player for a decade plus, I've heard a number of endless tantrum's from players before, during and after upgrades. I would tend to agree from experience that destroying a save game is one of the worst things that can happen. If we can lessen the need for a non-compatible release, we get a pretty good win-win where save games are not trashed, and developers can do their work with less effort, which means more work done per unit effort 🙂

Fixing save-game compatibility I think is the best thing we can do for this project. At this point, with the code and maps out of SVN, individual owners converted to teams, I think that is probably the highest impact thing we can do now.

I wonder if "activateTrigger" and another effect within a basic trigger, fall into bad practice category. Or political actions and user actions that fire multiple effects via "activateTrigger". Actually Political action can't even use "activateTrigger".

@cernel I understand how the renaming of the Techs work, and it is a good thing. It would be nice if this type of renaming worked for other elements like:

<option name="Infantry" unit="germanInfantry"/> <option name="Infantry" unit="russianInfantry"/>

In this manner the purchase window, tool tips and other displays to the player would IMOA be a little cleaner. But this is something just for looks.

Cheers...

@General_Zod I think this would be better as a bug report in github with some examples and save games. As really auto starting battles is not intended as the player should be able to choose which order they are fought in.

@crazyg yup it would require each map maker to set the default but a great idea!

@general_zod This is a very similar topic to:
https://forums.triplea-game.org/topic/293/remove-space-bar-for-casualties-confirmation
Just for reference (the issues are the same, the proposals are different (removing vs locking))

@wc_sumpton I think what @redrum wants to tackle all the resource related feature requests as a whole so there is big picture clarity.

My added suggestion only enhance what you were initially requesting. And assure no problems down the road with map compatibility.

@general_zod I kind of wonder why that's the case for attackAA. I'd be interested in someone confirming that.

@Cernel The problem with doing that is that we'd have to continue to support the existing AA fields within a unit attachment since so many maps use them unless we could script updating all maps to use the newly created AAattachment.

@beelee I think it could definitely be improved. We have a number of areas that end up on many maps having a large scroll area that is difficult to utilize. Posting some examples from various maps would help give more context.

@alkexr That would probably not be a good solution as if I open up the objectives tab to say look at the current nation objectives then scroll around to look at some things and all of a sudden its switching to a different players objectives, that would probably be a poor experience. I think something more a long the lines of making it easier to display objectives for the nation you are interested in some sort of filter at the top of the objectives tab.

Yes I agree, this is a useful request. Not all resources acquired by an individual nation will be used during purchase. Thus may not want them listed in purchase. And may or may not want them displayed at bottom bar either.

A method to differentiate would be nice. Especially once resources are actually capable of being used in conditions ( hopefully coming soon 🙂 ). If that happens resources will become much more prevalent in new maps and mods. And most likely in some very creative ways.

Btw, this also a good supporting reason to not get carried away with the sizes of images and texts in purchase and bottom bar. So we can accommodate future expansion.

@general_zod Yup, I think you see what I'm talking about. ATM my plan is to check some other possibilities, but I'm not going to make any big changes right now.

Thanks for you input.

Cheers...

@redrum said in Units Can Load In Hostile Sea Zones:

@Hepps This would actually probably be a good property for TWW as I've actually run into exactly this case in the Pacific in my game vs Wirkey which makes it so I have to keep all my troops loaded on transports which just feels wrong: https://forums.triplea-game.org/topic/533/tww-2-7-7-2-lalapalooza-redrum-allies-vs-wirkey-axis

I actually think it is not that wrong to be wanting to keep stuff loaded, but for a different reason. Really, loading/unloading takes some time, so you would not want to unload on random islands, and then reload, for no good reason, but this should be rather related to the ships using like 1 movement point for loading and/or unloading anything, on the turn. So, for example, a ship can move 3 but if it loads/unloads anything in 1 sea zone can move 2 and if it loads/unloads anything in 2 sea zones can move 1.
Probably, for easy of play, it would be advisable to charge the movement cost only on unloading, not on loading, especially since TA doesn't display loaded stuff well (what is loaded where).
Of course, this is off topic.

Final note, the original Axis&Allies 1981 (the first edition) actually had the loading cost dynamic, in that loading ships would have used 1 movement point for that.
http://axisandallies.wikia.com/wiki/Axis_%26_Allies_(Nova_Games_Edition)

I'm not opening a feature request, as I don't actually have a user case and I think there are more important feature requests around (or I could easily open hundreds of them more), but wanted to point out that the fact that normally in TA you almost never want to keep stuff on board is not necessarily that normal.

@redrum "Sustains" is the clearest wording that cannot really be misinterpreted as meaning anything else.

@general_zod Good recommendation. I've seen in for example online go timers that add a fixed amount per turn. The idea being there is that you can extend a long running game and not be forced to end the game in say round 3 or 4 because both players are low on time.

@rickard-liljeberg I believe this bug was fixed already. Can you try downloading the latest version (1.9.0.0.8304) if you don't have it already from here and retesting: http://triplea-game.org/download/