Next release maps will need to correct "attatch" mispelling, should spell as "attach".
Game engine version: 22.214.171.124.1252 is the last one that supports the mispelling. All of the maps in github/triplea-maps have been updated accordingly and no longer have the mispelling. "attatch" should hopefully not appear anywhere any long, just the correct spelling "attach"
From a game engine perspective we have a bit more work to do, we will be changing the maps folder to allow the old maps and new maps to live side by side.
This attatch thing has really bothered me before, thanks for the fix. BTW, isImpassible is also misspelled.
Impassable - impossible to travel along or over.
Impassible - incapable of suffering or feeling pain
Correctly crazy, disingenuously German
Any others? It's a good time to fix them up
offence and defence in attachments i think, but changing them might cause property conflict. Sometimes is hard to remember to mispel them. ie.... <option name="side" value="offence"
'thats the way it is' makes it neither desireable nor inevitable
I don't know of any others. Offense/offence and defense/defence are differences between American and British English, neither is incorrect
Correctly crazy, disingenuously German
Just to be clear I understand:
Mapmakers need do nothing. Maps in repo will be auto-updated with this change. And the engine will be backwards compatible with "attatch" anyway.
But moving forward (after 126.96.36.199.1252) I should basically find-and-replace "attatch" with "attach" everywhere?
So, since we are opening the Pandora jar...
If you are going to change anything at all in the xml, first thing first, this old crap:
property name="Naval Bombard Casualties Return Fire Restricted"
Despite what this one says, it means the opposite. If true, casualties from naval bombard will get to return fire.
Having this is bad, because it shows up to the users, that will set the wrong option, as long as they can understand wtf the option is saying.
Also, if changed, it should be changed to something decent; currently you really need to concentrate to understand what "Naval Bombard Casualties Return Fire Restricted" is supposed to do; no wonder the creator ended up setting it the opposite of what it says!
Moreover, the current default is also wrong! It is currently set as the casualties from naval bombard not returning fire, while in all rulesets EXCEPT ONLY V2 they can return fire! In v1, v3, v4, v5 and all Globals they can return fire, only v2 they cannot!
Basically, in Classic, casualties from naval bombard were able to return fire, then in Revised it was changed as being unable to; this lone experiment was thankfully abandoned and, after Revised, the behaviour was always to be able to return fire, like it was also in Classic.
So, to sum it up, the property currently does the opposite of what it says (to the user too), except that the default is worded correctly, but acting incorrectly.
Basically, the property is wrongly set, doing the opposite of what it says, but the default behaviour is also set at doing the opposite of what it should do, with the consequence that it actually ends up saying the right thing, while doing the wrong one.
So, it is needed to correct 2 things:
1) Having the property doing what it says, not the opposite.
2) Changing the default as being able to return fire, as per Classic rules, for coherency with any other defaults (all properties relevant in Classic are set default at Classic rules; only this one is default Revised rules).
Since in a boolean situation one mistake cancels the other, the default is currently correct relatively to what the property says (but not to what the property does); so, it would be actually possible to correct everything by just leaving both the name and the default (false) setting as they are, and changing upside down only what the property actually does. Then, it would be needed to switch the setting (from true to false and from false to true) in all maps having this property in the xml, assuming the mapmakers knew the error and intentionally set it to do what it does, not what it says...
Still, I would suggest, instead, changing the property name, because the current version is hard to understand.
So, my actual suggestion is to change it from "Naval Bombard Casualties Return Fire Restricted" to "Naval Bombard Casualties Return Fire", leaving the behaviour as currently is, but changing the default from the current "false" to "true".
Then, we have a consolidated tradition of using the terms "turn" and "round" at random, in the xml.
property name="Battleships repair at beginning of round"
Despite what this one says, two hit units repair at the beginning of the owner turn, not at the beginning of round (this also means that Neutral never repair).
Also, despite what this one says, it applies to all surviving multiple hitpoints units that have lost hitpoints, not only to Battleships. This is a minor thing, but, still, you have to see "Battleship" referring to warelephants, in 270BC, etc..
property name="Battleships repair at end of round"
Same issues as the previous one, except that what it actually does it that it repairs at the end of whatever turns (not rounds) (so it works for Neutral too).
Finally, this condition option:
It says turns but it means rounds, instead...
And it is so explained in pos2: "values: which turns this will be checked on (example: value="1:4:6-8:11-+" means turns 1,4,6,7,8,11,and all turns after 11)"
Also the description says turns, but it is not true; and it returns true in the whole round, not only in the turn of the attached player (it is also outright wrong in case a player has multiple turns per round).
That the current behaviour, and not the current naming, is correct and intended, may be proved by the "Napoleonic_Empires" xml, where you can see:
<attatchment name="conditionAttachmentTurn2" attatchTo="France" javaClass="games.strategy.triplea.attatchments.RulesAttachment" type="player">
<option name="turns" value="2"/>
Which is used for all players, not only for "France", meaning that at least Veqryn is aware that the option works for the whole (in this case) 2nd round, not only for the 2nd France turn (and it is totally unrelated to any turns: it is purely round based).
While we are at it, on the American English vs actual English matter, I want to point out that we even have stuff like in the xml we sometimes use "defense" and sometimes use "defence", instead...
Maybe it is time to make up your minds and settle what kind of language TripleA is supposed to use.
Now, this may look trivial to English or American English speakers, but I assure you that having to remember to use incorrect English terms here and there (because they are different in American English) is tiresome, for not English people learned in actual English.
I would much like if TripleA would be corrected into something 100% using correct actual English. Not American English. I mean using the one they teach in school all over the world.
First of all, there are not really two (or more) Englishes; the true English is only the English that it is official in England (duuuh).
The so called "American English" is not English, but a variation of it (outside USA, "British English" is just simply called "English", in whatever school etc.).
So, the question is: is the TripleA language supposed to be English? Or what?
Current instances in which TripleA is American English, but not English:
"centers" is American English; "centres" is English. (centers.properties)
"Color" is American English; "Colour" is English. (map.properties)
"Defense" is American English; "Defence" is English. (xml:unitAttatchment)*
"airDefense" is American English; "airDefence" is English. (xml:unitAttatchment)
"Aluminum" is American English; "Aluminium" is English. (assets/resources)
Current instances in which TripleA is English, but not American English:
"Offense" is American English; "Offence" is English. (xml:supportAttatchment)
"Defense" is American English; "Defence" is English. (xml:supportAttatchment)*
"Armor" is American English; "Armour" is English. (assets/units)
"Harbor" is American English; "Harbour" is English. (assets/units)
*Note that TA uses "defense" for the "unitAttatchment" and "defence" for the "supportAttachment"; on the other hand, it uses "attack" and "offence", respectively. So, even if "defense" and "defence" would be standardized, this would leave the weirdness of using "defence" or "defense" for both unit and support, while using "attack" and "offence", respectively, for the same ones, on the other hand.
*Note that if both are standardized to the English "Defence" (as I would suggest), then also "airDefense" should be changed to "airDefence".
Obsolete instances in which TripleA is American English, but not English:
"Checkers" is American English; "Draughts" is English (also, a traditional English would rather say "chequers", not "checkers", but not referring to the game, while an American would say "drafts", not "draughts", but not referring to the game).
English wise, writing "Color" is as much as wrong as writing "Colur", or whatever.
If you write "Color" in a normal European school that teaches English, it will be considered an error, I believe; that the Americans say so would not be an argument.
Without internet, I would not even know that "Color" is how the Americans say it; to me it would be just a random spelling mistake of "Colour".
On the other hand, if you are supposed to write in American English, then "Colour" would be a mistake, I surmise (not sure).
As a side note, looks to me that the language commonly spoken in the TripleA lobby is not English, but American English, instead, especially when it comes to words that are existent in English and inexistent in Americans: the American version is always preferred, I think.
For example, once I said "aeroplane" and got "corrected"!
So, basically, we have 4 options:
1) English is the official language of TripleA (this is what I would definitively suggest, if we were creating TA out of nothing): then we have to correct several things.
2) American English is the official language of TripleA: then we have to correct several things.
3) English and American English are both the official supported languages of TripleA: then we have to add a lot of things (like having both "armour" and "armor" or both "Aluminium" and "Aluminum" in assets, to support both English and American English).
- Anyway, this is not a feasible solution, because then we would need to have both "centres" and "centers" as correct names for the relative property, which would be silly, confusing and just bad.
4) We leave the official language of TripleA as a random mix-up of English and American English, as it is now.
- This doesn't really make any sense, and it is confusing for not-English speakers, learned in regular English, because sometimes you have to force yourself to use the American distortions, and some other times not, and you get confused about which times what, but it is the simplest solution.
As a not-English speaker learned in English, my strong preference would be that TripleA uses actual English all the times, not American English (which to someone learned only in traditional English sounds just like a bunch of grammatical errors I must remember to use, here and there, which is annoying); and surely I dislike this confusing mix-up of English and American English.
So, I would say option 1 would be the right choice, except that, then, we have to change a bit. Anyway, option 2 would imply almost the same quantity of changes.
I would definitively be against going for option 2. I know that most developers are English Americans, but I think normally something supposed not being USA-only it is written in proper English, as first option. For example, in GIMP, English version, you have "Colours / Colourise", not "Colors / Colorize"!
I know that all American distortions have, by now, also due to internet, made into England, as well; so, you could fine a lot of English that would write "Colorize"...
Honestly, this thing of mixing up English and American English all the times makes TripleA sound Canadian. Maybe it is...
Exceptions in which I would always use American English over English:
p.s.: As an exception, if it will ever be a resource, I much prefer the American "gasoline" (not "gas"!) over the English "petrol", cause I really think something like "petrol" should not indicate something refined, because it just sounds like "petroleum" (so, in my mind, "petrol" should mean "oil", not "gasoline").
p.p.s.: I also hate how the English sometimes use the term "public", and think that always following the right American usage of public = state is preferable, instead, but I guess this would never be an issue here.
p.p.p.s.: Due to the American dominance in internet, "Color" has affirmed itself as the standard when used for color-coding; so it may make sense to stick with it, anyway.
For some good references, here there are two links to general and peculiar differences between English and American English:
All my info about the corrupted English language of the English Americans come from internet surfing, because I don't really know American English. So, this post is not to be considered very reliable, and should be double checked.
Also, again, especially with the grown of internet, a lot of the spelling differences has made into fairly common use on the other side, as well; so, the difference between American English and English is not anymore that clear, like it was in World War II times.
On the other hand, I can tell you the difference is still very clear to people having only a scholastic knowledge of traditional English.
History plays dice
For American vs British spellings - Java uses American spellings of words. So let's please try to stick to American spellings.
The overall goal of this exercise is really just to make it so you can know how things are going to be spelled without looking them up. So it does not matter too much what is decided, so long as a decision is made. For this one it is pretty easy to choose American spelling, less changes, and it jives well with the code.
@Cernel: please if you would, simply give a list of existing spellings, and the suggested corrected spellings, something like this:
offence -> offense
I don't want to propose changing "Armour" etc. to "Armor" etc..
Armour (which is how it is now) has always been the correct spelling for me.
Seems most logical to me that if you are speaking English you should speak the English spoken in England (that it is the one everyone outside of the US normally learns), not in an offspring of it.
If Java is in American English, then, yes, it would make sense to have the functional stuff (only) in American English, as well, but I see no need for the game elements.
I don't see why Java being in American English would imply that the "Armour" unit or what you see in tooltips etc. should be in American English as well.
After all, instead of "Armour" we can have "Hobbit", or whatever.
Still, the current random mix up of American and not American English doesn't make sense.
What about having everything functional or code related (center etc.) in American English and everything being game elements (name of the units etc.) or for display (default tooltips etc.) only fully in proper English, instead?
This would be consistent the most with the current trend, where there is a prevalence of the American English in the code-related things and a prevalence of the proper English in the default final stuff (assets).
So, following this direction (always American English for the code related references and, instead, proper English for the game elements and display-only writings) would also imply the least quantity of changes.
In this case, the only "assets" file name that would need to be changed from American English to proper English is "aluminum" to "aluminium", while the other changes would be code-related stuff from proper English to American English, instead.
Still, in this case, we should have always "Defense" in the xml references (instead of sometimes "Defense" and sometimes "Defence", like now), while the display in tooltips should be "Defence", for coherency with the units being "Armour" etc..
History plays dice
I think you're assumign that the game elements and functional/code stuff are actually distinct entities. They are joined at the hip, many of the XML entities are directly mapped in the game code. It would be very weird to know where that line is/would be, or that such a line would exist. Also, we do not have extra capacity for loads of work. It's far easier for us to unify to American spelling, it's simply a lot less work. So, please do provide a simple list of things that can be corrected/unified.
I lived in Hong Kong for a few years when I was a kid. As a British colony, the British version of English dominated. I even returned to America having picked up some Britishisms. But even with that history, friends now tell me that American English is what younger people in HK are choosing. Hollywood seems to be a more effective colonizer than any nation state ever was.
American English is the lingua franca of science and technology. And it seems to me to be the lingua franca of computer gaming. It is the de facto language of the official Axis & Allies, for whatever that's worth.
Whether American is worse or less correct than British is a meaningless (i.e. destinationless) conversation. And if you want to go strictly off of popularity, then I suppose we should adopt Indian English.
As for TripleA, if the code uses American, that seems an overwhelming argument to consolidate to American if consolidation is necessary. I hardly care either way, but it would be silly to allow linguistic ideology to affect what ought to be a decision governed by practicalities.
Thanks all for the responses. Again, the goal is consistency in spelling, so you know how things are spelled without looking them up. Let's not roll around in the weeds too much, if things are mispelled, that's high priority item to fix. Do @all, please just provide a list of things that can be updated, keep it simple, no need to explain why even.. If a developer disagrees, it just won't get done, and if it's obviously in need of fixing, then a developer (me) will just do it. The "attatch" was a big one since we didn't even consistently mispell it, made things just difficult. Let's start making our lives easier : )
Attatch is most important.
Then moving these British variants to American:
offence -> offense
defence -> defense
armour -> armor
harbour -> harbor
(The only things that every caused me confusion when I first started mapmaking were attatch, and defence and offence.)
And I very much agree with Cernel that the property name "Battleships repair at beginning of round" should be changed. Perhaps something like "Multiple hit point units repair at beginning of round".
To me seems very simple obvious that something called "English" should be what it is official somewhere called "England", but ok, whatever the developers prefer or it's easier for them is fine.
I was guessing that the international English, taught in school, is and will be the one of England, in most countries, as it has been in the past, but I don't actually know.
Anyway, whatever coherent is still better than a random mix up.
But I have a different proposal for changing "offence" and "defence".
Since you are so sure you want to use the American English, I want to point out again that there is that inconsistency between unitattachments and supportattachments.
If you are going to change defence to defense and offence to offense, then, you would have "defense" in both unitattachment and supportattachment, while you would have "attack" in unitattachments and "offense" in supportattachments. This doesn't really make sense (someone may wonder why they see "defense" both in unit and support attachment, while they see "attack" in unit and "offense" in support), and I would rather having them both different or both the same.
I would go for having them both different, especially since the "side" do not refer to which one get the support, but from where it is given (a "defense" support is not necessarily given to the "defense", but starting from units on "defense").
My suggestion is to change these ways, instead, the supportattachment only:
(which would also have the bonus value of being the same both in USA English and England English, not confusing people learned in the last one)
This would make more sense semantically and theorically, as "offense", not "attack", is the true opposite of "defense".
Albeit "attack" is currently mostly assumed as synonymous of "offense", its true original meaning was "making contact" or "engage" (with the aim of kicking some butts).
So, "attack" should not be understood as the synonymous of "offence", but eventually as a subset of offensive or defensive actions (when you are attacking, you are doing something either offensive or defensive; but when you are doing something offensive, you are not necessarily attacking; likewise, when you are doing something defensive, you are not necessarily attacking).
So, "offensive" and "defensive" may suit best, as they are very general eminently strategical concepts, one opposite to the other, while "attack" is a different concept that, since the XIX practice of defending your whole frontline, has become factually coincidental with the concept of going on the offensive, because, if the enemy is defensively disposed in uninterrupted trenches right on the frontline, in the exact moment in which you decide to invade the territory (which is the traditional primary form of strategical offence) you will be also attacking its defenders (as they stand right there in the frontline), but it was not usually true of the strategical game in ages past.
To let someone else clarify the matter (that "attack" is a different conceptual element, belonging no less to the "defensive" than to the "offensive"), here it is a passage from Clausewitz, in which the term "offensive", "defensive" and "attack" are properly used, and that clarifies how in ages past (before the WWI style model of defence) it was actually "easier for the defensive than for the offensive to make attacks":
First of all we must inquire into the circumstances which give the victory in a battle.
Of superiority of numbers, and bravery, discipline, or other qualities of an army, we say nothing here, because, as a rule, they depend on things which lie out of the province of the art of war in the sense in which we are now considering it; besides which they exercise the same effect in the offensive as the defensive; and, moreover also, the superiority in numbers in general cannot come under consideration here, as the number of troops is likewise a given quantity or condition, and does not depend on the will or pleasure of the general. Further, these things have no particular connection with attack and defence. But, irrespective of these things, there are other three which appear to us of decisive importance, these are: surprise, advantage of ground, and the attack from several quarters. The surprise produces an effect by opposing to the enemy a great many more troops than he expected at some particular point. The superiority in numbers in this case is very different to a general superiority of numbers; it is the most powerful agent in the art of war.—The way in which the advantage of ground contributes to the victory is intelligible enough of itself, and we have only one observation to make which is, that we do not confine our remarks to obstacles which obstruct the advance of an enemy, such as scarped grounds, high hills, marshy streams, hedges, inclosures, etc.; we also allude to the advantage which ground affords as cover, under which troops are concealed from view. Indeed we may say that even from ground which is quite unimportant a person acquainted with the locality may derive assistance. The attack from several quarters includes in itself all tactical turning movements great and small, and its effects are derived partly from the double execution obtained in this way from fire-arms, and partly from the enemy's dread of his retreat being cut off.
Now how do the offensive and defensive stand respectively in relation to these things?
Having in view the three principles of victory just described, the answer to this question is, that only a small portion of the first and last of these principles is in favour of the offensive, whilst the greater part of them, and the whole of the second principle, are at the command of the party acting defensively.
The offensive side can only have the advantage of one complete surprise of the whole mass with the whole, whilst the defensive is in a condition to surprise incessantly, throughout the whole course of the combat, by the force and form which he gives to his partial attacks.
The offensive has greater facilities than the defensive for surrounding and cutting off the whole, as the latter is in a manner in a fixed position while the former is in a state of movement having reference to that position. But the superior advantage for an enveloping movement, which the offensive possesses, as now stated, is again limited to a movement against the whole mass; for during the course of the combat, and with separate divisions of the force, it is easier for the defensive than for the offensive to make attacks from several quarters, because, as we have already said, the former is in a better situation to surprise by the force and form of his attacks.
The alternative to the above changes, would be to only change "offence" to "attack" (instead of to "offense" or "offensive") and leave everything else as it is. I advise against this solution, that has the advantages of being currently popular (the modern military has the habit of saying "attacking" with the meaning of "offending", while the more correct saying of "we are offending the enemy" is uncommon) and requiring the least changes, as well as being the standard in the Axis&Allies games (as well as about whatever wargames), but it is semantically limited (the opposite of "defense" is "offense", not "attack", albeit the dichotomy defence - attack is frequently used, instead of defence - offence, also in the English translations of Clausewitz) and problematical in reference to the Clausewitzian strategical and tactical conceptual elements of the art of war.
Especially since the traditional TA games have like more than the whole of France as 1 single territory, "offensive", for a support option called "side", makes a lot more sense than "attack".
Another alternative would be to change "offence" to "offense" in supportattachments and also change "attack" to "offense" in unitattachments. I think that would be fine, but would imply changing a lot of things, as well (also, most people prefer to use "attack", instead of "offense", as the opposite of "defense").
Usinge either "offensive" or "offense", instead of "attack", would be also consistent with the traditionally correct usage of "attack" for the AAattacks, where the term "attack" correctly defines shooting the AA in defence (attackAA) as well as in offence (offensiveAttackAA) (as you can see, for the AA only, the term "attack" is correctly used referring to the defensive and to the offensive alike (but primarily to the defensive), as it should be, in a strategical game).
Regarding the battleships thing, my suggestion is changing:
"Battleships repair at beginning of round"
"Units repair hits start turn"
"Units Repair Hits Start Turn".
My suggestion would be the lower case version, because I don't see the need of going German style on the options; but your call, since in the past the properties were tendentially lower case like:
"Battleships repair at end of round"
but then the alternate style, like:
"Naval Units May Not NonCombat Move Into Controlled Sea Zones"
Actually, this last style is split between having all upper case, like:
"Blitz Through Factories And AA Restricted"
or having only the main words (in this case not the "and") upper case, like:
"Defending Suicide and Munition Units Do Not Fire"
And now the two or three or more styles are mostly randomly mixed up, but the latest tendency is to use the upper case, and by now most properties go that way.
Similarly, I would suggest:
"Battleships repair at end of round"
to become either:
"Units repair hits end turn"
"Units Repair Hits End Turn".
Actually, this is not that right, because, with steps (steps have been a great and brilliant addition to the engine, still much under-used, in my opinion), you can have units repairing at some other points, when this property is true (normally, I suggest setting the repairing step at start of NonCombat Move (because there is no reason to keep units damaged hanging around till end turn, if they are going to repair anyway)); but I think it should be fine, as correctly defining the default behaviour (without "steps").
Still, the most important thing to adress is that battleship return fire restricted crap: it does the opposite of what it says and the default behaviour is set incoherently too (default v2, while everything else is default v1).
p.s.: I missed to tell that, if we would have gone with the English of England, than we would have had also to change "Honorable Surrender", "Axis Honorable Victory VCs", and "Allies Honorable Victory VCs" to "Honourable" (anyway, doesn't matter, since we are not).
p.p.s.: I guess we are not minding about the commented out descriptions; like I would say no point changing "behaviour" to "behavior" etc. in the descriptions of pos2 etc..
p.p.p.s.: What about using the actual English spelling in the cases they are not wrong, but just uncommon in American English; I can't help you there, cause I don't really know American English, so I don't know if stuff like "armour" or "offence" etc. are strictly wrong in American English or just uncommon, but accepted, spellings.
History plays dice
Most English taught worldwide is American English. It also the standard used in business, programming, and most other things. Converting everything to American English is a good move.
These are considered wrong in standard American English, most word processers will flag them as spelt incorrectly (including the tripleA forum). I don't think armour should be changed as part of this update, since its a unit name, but everything else ought to be standardized.
The suggestions for changes to the end of XML properties are good, many of these are worded very poorly.
Correctly crazy, disingenuously German
Some interesting discussion for sure. I will say that I'm not planning to dedicate much time to this, copy/replace. Here is the list so far:
offence -> offense
defence -> defense
armour -> armor
harbour -> harbor
To sum it up, suggest at least adding:
Naval Bombard Casualties Return Fire Restricted->Naval Bombard Casualties Return Fire*
Battleships repair at end of round->Units Repair Hits End Turn
Battleships repair at beginning of round->Units Repair Hits Start Turn
*and changing the default to "True"
**for the condition attachments only
History plays dice
As much as the attachment misspelling has annoyed me for years, it will mean that I we need to update all the maps on my website (which has a lot more maps than GitHub). This will be rather annoying as everything is in Zip files.
As for US vs UK vs Canada spelling it is worth noting that the US spellings are usually shorter and closer to the pronunciation. What purpose does the "u" in "armour" serve?
Historically the differences arose because Samuel Johnson preferred French spellings while Noah Webster preferred Latin spellings.
Then why this Noah didn't change YOUR to YOR, while he was at it? COLOR and ARMOR make me think I'm talking Spanish.
Hell, that thing of updating the wiki will be a massive pain; guess noone thought about it. What about having all maps in Git just linked in the wiki, and uploaded in the wiki only those not on Git? I'm guessing this would make sense regardless, even tho this way there is not a backup site anymore.
History plays dice
Did you take isImpassible off the list for a reason?
Sort of related, these two properties are in the PoS 2 XML
navalBase values: works according to original pacific rules: it increases the non-combat movement of naval units by +1 IF they go from friendly naval base TO friendly naval base
airBase values: works according to original pacific rules: it allows free movement between the land territory and any connecting water territories,
But it seems to me that these currently do nothing, they were planned features which were never implemented. Should these be removed from the PoS XML?
Correctly crazy, disingenuously German
|Free forum by Nabble||Edit this page|