Short Attachment Names

RoiEX

Just a note for the map makers among you, as of Version 1.9.0.0.9142 the engine no longer requires the package name in front of the attachment class name.
This means instead of writing for example

<attachment name="unitAttachment" attachTo="army" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">

You can now write

<attachment name="unitAttachment" attachTo="army" javaClass="UnitAttachment" type="unitType">

Note however that this change is not backwards compatible, so in case you are planning to change your map xmls keep in mind that players with any previous version will no longer be able to play it.

I'm planning to do a similar change for the delegate names as well, however allowing the exact same will cause problems because there are duplicate delegate names in the games.strategy.twoIfBySea.delegate package for EndTurnDelegate, InitDelegate and PlaceDelegate, that are only used by a handful of maps.
If someone could tell me the difference of those delegates (compared to the normal ones in games.strategy.triplea.delegate), or even modify the xmls to no longer use them, I'd be happy to try and remove this requirement for delegates as well.

redrum

@roiex It would probably be good to update POS2 XML to use this new standard once a new stable is released. At a minimum if we don't update the whole XML then adding a note similar to your post in the comments would be necessary.

Hepps

You really have to edit the entire XML.

Since it is used extensively as a resources for both seasoned as well as noobile map makers.... there can be no ambiguity in the information presented there.

Cernel

@roiex said in Short Attachment Names:

I'm planning to do a similar change for the delegate names as well, however allowing the exact same will cause problems because there are duplicate delegate names in the games.strategy.twoIfBySea.delegate package for EndTurnDelegate, InitDelegate and PlaceDelegate, that are only used by a handful of maps.
If someone could tell me the difference of those delegates (compared to the normal ones in games.strategy.triplea.delegate), or even modify the xmls to no longer use them, I'd be happy to try and remove this requirement for delegates as well.

I noticed this only now.
So, those are hugely old things that I believe are not anymore supported by more than 5 years, but just for compatibility, letting them doing just what the standard ones do, and were formerly meant to implement this rule: "Each factory can produce 5 units, but there can be multiple factories per territory", which is not currently supported.
However, I'm mostly guessing, and I've bug reported this Veqryn in the past, but he has not been very clear, so I don't even know if he actually knows the full story himself.
I just suggest you delve into the code and find out by yourself; the chance of someone knowing what is what, giving you info, is virtually zero.
Neuschwabenland is bugged the same way, as their factories work normally, not as per what the notes say they work (just read them). That is a map with some following (the FFA only), and people play it as it works (just Revised style production and placement), not as the notes say it should.
Again, I'm really not sure of any of the above, and I'm not a player of those maps, either; so all I said may be just all wrong.
I'm a bit reticent at modifying those maps, as I dislike them all (it feels strange when a map is modified by someone that never played and has no intention to play it, and one should always playtest what he modifies). As far as I'm concerned, you could just remove all those maps from download list, keeping them in the repository until someone fixes them, but at least the Neuschwabenland FFA is liked by not that few people, and it is a bit of a classy, so they would be seriously upset, if they cannot play it anymore (pretty sure nobody who plays those maps would fix them).
If it is feasible for your, I'm almost sure you can go ahead mass changing all those occurrences with the standard alternative, maybe after checking that they are already factually just doing that, already (as I said, I'm not sure; so I guess you can only by sure by delving into the code).

Cernel

@cernel Here it is my old bug report. I just made it for the record, as I've never played the map myself, and not interested in it (I was watching a game played by others, and I noticed that the map is not working as per its notes):
https://sourceforge.net/p/triplea/bugs/1102/

Cernel

@roiex Anyways, this looks like a really nice clean-up, so I guess I'm disposable doing the needed changes where you linked, if nobody else, but I warn you I'm not going to really playtest any of those maps (I dislike them all). Is there an expert player of Neuschwabenland here that would volunteer to playtest the map working the same after the changes being made, in case?

Cernel

@roiex So, what I'm saying is that I guess I can do that (even tho not a fan of those maps), but, since I'm not going to test them but superficially and partially (definitely not playing them), and I've not played them before, I need to know if you are fine to take responsibility yourself for any mess-ups I might do (end eventually revert everything, if people complain), or if there are any expert players disposable to testify the maps working the same before and after I make the changes (I know, unlikely).

General_Zod

@cernel I've played those maps in the past. I suggest just changing game notes, rather than changing the known game rules. Since no one was ever upset about it.

Cernel

@general_zod Since that keeps track of the way the maps were supposed to be played, and I'm not a player of those, I'm oriented leaving game notes alone, even tho I agree (and I said it) that it is bad having game notes and engine behaviour conflicting, but I tend to think that would be up to a player of those maps to take ownership of them, and update them.
While I believe I've always seen those maps played by engine behaviour, not by games notes (otherwise people would be editing all the time), and this really sucks, as I would hate that (I think it is obvious that game notes are more important than the engine behaviour, otherwise wtf?), we cannot esclude them being balanced and meant to be properly played by game notes (like when World At War had canal rules not enforced by the engine: it would have been really bad to change Game Notes to follow the engine behaviour!).

Side note, all those maps but the classic mod are Sieg's.

Out of curiosity only, does anybody know or guess what this means (written in Neuch notes):

Grey Terretories belong to Start Country

?

For the matter at hand, let's leave rules and notes alone, and just limit ourselves making the code only changes that @RoiEX requires, if any (and if he still wants to take the risk).

Cernel

@general_zod (or any players of these) But if @RoiEX still want to do the code changes, if you would be disposable at playing the popular ones of those and confirming they are still working the same way as they used to, after I (or someone else) do the required changes, that would be much safer. The only concern is if anybody gets angry because we mess up how their Neuch works from current (even tho it is already messed up).

The only alternative I can see is that a developer code all those maps to work as the game notes tell they should, for the understeandable part of those game notes, but probably unlikely or not worth it (plus, people may not like a behaviour change from current, like when some people were against @redrum changing the behaviour of WAW canals to work as per its notes, preferring to old behaviour, no matter if faulty).

Cernel

@roiex For example, I just pulled the update I believe you required for "four_if_by_sea.xml" only.
https://github.com/triplea-maps/classic_variations/pull/3

Is this what you want and do you want it repeated for all the cases you listed?
Is it really fine to do so when I am not going to play any of those maps (and probably you aren't, either)?
Why not just automatically mass changing, like @LaFayette did, on several other occasions:

games.strategy.twoIfBySea.delegate
to
games.strategy.triplea.delegate

Also, @redrum @LaFayette @RoiEX @ssoloff do you think that:
https://github.com/triplea-game/triplea/wiki/Upgrade-Maps-Information
https://github.com/triplea-game/triplea/wiki/Downgrade-Maps-Information
should be updated with these or any other missing past changes (are you missing any?) or do you prefer stop tracking that, and leaving that wiki at 1.9.0.0.3266, not giving further info, in there, for upgrading to higher versions, at least from 1.8.0.9?

This is on the account that people having maps outside the repository (like @RogerCooper) would need to be informed about what at this topic, as they would need updating, as well, and in case anybody want to downgrade a map not having the "package name" back to 1.8.0.9 (this is already an item, actually, as you already did that change).

Cernelius created this issue in triplea-maps/classic_variations

closed Update four_if_by_sea.xml #3

Cernel

@roiex Also, in here:
https://github.com/triplea-maps/classic_variations/blob/05393b0c0662ce56675c6996fef3dbc8cf3071d7/map/games/four_if_by_sea.xml
when I click on the pencil icon, it tells me:
"You must be on a branch to make or propose changes to this file"
I was able to do it by going to "branch" and clicking on "master", but why the hell does it work this way? I bet some people would not figure it out.
Meaning, you cannot do the edit from the link you gave, here:
https://github.com/triplea-maps/classic_variations/blob/05393b0c0662ce56675c6996fef3dbc8cf3071d7/map/games/four_if_by_sea.xml
But, instead, you can do it from here:
https://github.com/triplea-maps/classic_variations/blob/master/map/games/four_if_by_sea.xml
Why?

General_Zod

@Cernel

Doubtful I will play those games anytime soon, if at all. I've played them to kill time in past. But these FFA are the ones that give FFA a bad wrap, imo. I've never seen anyone actually win total victory in them. Someone either bails and ruins game or it gets saved and never continued.

I guess, that's partly due to lack of a reputation or rank attached to a username, and the ability to change usernames for free. It encourages poor sportsmanship without consequences.

Cernel

@roiex said in Short Attachment Names:

games.strategy.twoIfBySea.delegate

To be clear, what I was saying is that I guess that is just the same thing as having games.strategy.triplea.delegate, kept working to just support the old maps that use it. If so, there should be no major problems in changing it over (probably the only reason to support it is not having to change it over), but:

I'm not sure, and I doubt you will get the guy who did it, or anybody who knows anything about it at all, so you need to delve into the code to verify. You may try asking Veqryn, tho.
Changing it to regular at best implies losing the info that those maps were supposed to work in a particular way (I guess not anymore supported), potentially burying "broken" maps into looking not broken anymore.
Can't you just do it as a mass change like @LaFayette did in similar cases?

RoiEX

Dear Map-Makers;
I opened a PR that also adds this feature for delegate names: https://github.com/triplea-game/triplea/pull/3367
However I made some decisions there I'd like to hear your opinion about there.

RoiEXLab created this issue in triplea-game/triplea

closed Short class names for delegates #3367

Cernel

@roiex I'm not sure about a bunch of what you are saynig there, actually; so I hope you don't mind if I ask in here, instead of writing stuff in your GitHub that is of no interest to the developers.

With this:

Allow short hand names for delegates in games.strategy.triplea.delegate, because of the name conflicts for delegates in games.strategy.twoIfbySea.delegate, those names need to be spelled out regardless of this change (because usage of those delegates is rare)

Are you saying that:
"games.strategy.triplea.delegate.InitDelegate" etc. become writable as "InitDelegate" etc..
but:
"games.strategy.twoIfbySea.delegate.InitDelegate" will still be supported too, yet you get a warning those are deprecated.

So, basically, you can write it and have it working 3 different ways:
1- "InitDelegate" etc.
2- "games.strategy.triplea.delegate.InitDelegate" etc.
3- "games.strategy.twoIfbySea.delegate.InitDelegate" etc.

With:
Number 1 being the correct way.
Number 2 being deprecated (is it?), but supported without warning.
Number 3 being deprecated, and supported giving the warning that it is deprecated.

By the way, removing those in future versions of TripleA, as opposed to removing them right now, doesn't make a lot of sense, as I'm pretty sure all those maps will still be there, as they are, 10 years from now, all the same.

p.s.: Did you verify that the the "twoIfbySea" are factually doing the same thing as the regular "triplea" ones, game wise? I'm just guessing that in the past they were working differently, and that has been discontinued.

RoiEX

@Cernel Almost, I don't know if the twoIfBySea delegates behave the same as "standard ones". However almost no maps use them at all the other one, highly indicating it might not be really useful.
In any case it's very confusing to have 2 different things being named the same with no way to tell the difference.
We as developers have to deal with name conflicts which makes the code ugly, and map makers could get confused what really is the difference.
By "will be removed in a future version" I just wanted to strongly indicate the twoIfBySea delegates shouldn't be used to enable us to either rename it in an incompatible release, or to incorporate them into the existing delegates and to remove them from the twoIfBySea package afterwards.
TL;DR
To answer your question:
games.strategy.triplea.delegate.XYZDelegate = XYZDelegate
games.strategy.twoIfBySea.XYZDelegate ≠ XYZDelegate but all of these work.

General_Zod

@roiex That seems acceptable for me.

Cernel

@roiex Ok, then I've closed my pull example in here:
https://github.com/triplea-maps/classic_variations/pull/3