I see what you mean and I think we don't have a big dissent here at least regarding the consequences. I am not very happy with that FAQ-aspect that introduced the rule "You may only purchase as many units as you will have the ability to mobilize after making repairs to any damaged industrial complexes. The rules for returning excess units are intended only for inadvertent over-purchasing."
While the first sentence is a clear "law" the second sentence opens room for discussing the "human factor". Representing the latter in the TripleA engine appears to be pointless, IMHO.
@prastle Makes sense. I think anyone can go into a bot and take it over if someone is camping in it and not responding to texts because they are in another game or not present. I might suggest we post an add on message to the lobby that says if you can host please do and leave the bots for those that cant.
Hosting bots is not as difficult as it sounds. If I can do it, then I’m sure most people here can too. If you can Host a game on the Lobby, then you are almost there. Just needs a few tweaks to your router, a .bat file, a bit of patience and possible some help from a friendly Mod!
First you need to update your router settings and open more ports. You should already have port 3300 open. I opened 6 in all, 3300 to 3305 (one for your own Hosting and 5 for the Bots). There is a freeware program you can use: Simple Port Forwarding (see here http://www.simpleportforwarding.com/download ), which can help with the task. Follow the program instructions and open the required ports.
Once you’ve opened the ports, you need to download the latest Beta(Pre-Release) version of TripleA. This is located here https://github.com/triplea-game/triplea/releases/ . This can be installed in a different folder from your stable TripleA. It's is recommended that you keep the stable version for testing purposes between the two versions of TripleA. I used the 220.127.116.11.10245 version. It is in this new folder that the .bat files must be inserted.
Next is to create a .bat file. Using the attached .txt file as an example, edit the following asterisked sections:
SET PORT= **** (the number of the port)
SET BOT_NUMBER= *** (the number to identify the bot on the lobby, your choice)
.name=Bot%BOT_NUMBER%_ ***** (letters and/or numbers to identify the bot on the lobby, your choice. Mine is DKMart1)
.hostedBy= Bot%BOT_NUMBER%_***** (letters and/or numbers to identify the bot on the lobby, your choice. Mine is DKMart1)
.supportEmail=************** (your email so Mods know where to find you… )
Once you’ve finished editing, save the file with the .bat extension. You can call the file anything you wish (in my case DKMart1_bot_1.bat).
Repeat for the number of bots you wish to create.
Remember, SET PORT= must be different for each .bat file and correspond to the ports you have opened on your router!
Place the .bat files in the 18.104.22.168.10245 TripleA folder. If all goes to plan, when you click on the .bat file a command prompt window will open and attempt to load the bot to the server lobby. Open TripleA as usual (not the 22.214.171.124.10245 version), go to the lobby and marvel at the wonder of your work.
Any problems contact a Mod (@prastle). He’ll sort you out! LOL
Also looking at your specific problem (the first image) it could very well be that your anti-virus software is interfering at some point, trying to sniff on your email connection, but if temporarily disabling it entirely doesn't work there could be another unknown reason as well.
Gmail requires TLS at some point so disabling it likely won't work, so the second error can probably be ignored.
@bayder said in AA-fire/casualty selection issues in Revised (and other versions):
There is still zero reason for the rules to indicate that AA fire should occur in the Combat Move phase. The rules could easily state that AA fire occurs in Conduct Combat and Noncombat Move phases only. If this had been done, then there would be no questions regarding this rule.
What I understand is that here you believe that Revised OOB and LHTR work the same way, for flyovers during the Combat Move phase, as there would be no difference between saying that they are resolved at the end of the Combat Move phase or saying that they are resolved during the Conduct Combat phase, but the second formulation being clearer.
What I understand, instead, is that, by moving the AA fly over resolution from Combat Move to Conduct Combat, LHTR makes a practically relevant behaviour change, as in Revised OOB you would know the results of all Combat Move fly-overs before resolving any battles, as they already happened in a previous phase, while in Revised LHTR you know then only for the units involved in the current battle, and all the already resolved ones.
I have a fighter that flies over an AA gun in a territory "A", then flies over an AA gun in a territory "B", then end movement in a territory "C" (to take part in a battle in there).
I also have another fighter that flies over an AA gun in a territory "A" (the same territory that the other fighter is flying over too), then flies over an AA gun in a territory "D", then end movement in a territory "E" (to take part in a battle in there).
In Revised OOB, you would resolve the fly overs for:
The first fighter in "A"
The first fighter in "B"
The second fighter in "A"
The second fighter in "D"
In only one of the following only two possible orders, at your discretion:
1A, 1B, 2A, 2D
2A, 2D, 1A, 1B
Then, after resolving all fly overs, you would resolve the battles (with all other units involved in the same battle), comprising, at this point, any battle AA fire, if an AA gun is present in the embattled territory, for:
The first fighter in "C", if surviving the fly overs
The second fighter in "E", if surviving the fly overs
Assuming both fly overs miss, then, during Conduct Combat, either first resolving the "C" battle or first the "E" one, then the other one, at your discretion, no matter if you previously resolved the fly overs for the first fighter (that is now in "C") or the second one (that is now in "E") (of course, if the a fighter is shot down during fly over and was the only attacking unit, then there is no battle, instead).
Consequently, in case all fly overs miss, considering Combat Move and Conduct Combat together, you would have all and only the following possible resolution sequences, across the two phases:
1A, 1B, 2A, 2D, C, E
2A, 2D, 1A, 1B, C, E
1A, 1B, 2A, 2D, E, C
2A, 2D, 1A, 1B, E, C
(where, for example, "1A, 1B, 2A, 2D, C, E" literally means "at the end of combat move, resolving the flyover in A for the first fighter, then resolving the fly over in B for the first fighter, then resolving the fly over in A for the second fighter, then resolving the fly over in D for the second fighter, then, during Conduct Combat, resolving the battle in C, then resolving the battle in E")
In Revised LHTR, instead, during the Conduct Combat phase, fly-overs are all integrated as part of the specific battles where the flying over units are heading to, so you only decide whether first to make the battle in "C" or first to make the battle in "E", and, in this case, you cannot even decide in what order to resolve the fly overs, for each battle, since having only 1 fighter involved in any, for each one, thus being restricted to resolving all fly overs, by their zones movement sequence for the same unit, before resolving the battle that unit may be part of (if surviving all fly overs).
Meaning you can only resolve all fly overs and all battles as "1 then 2" or "2 then 1", where 1 and 2 are the following sequences:
1- Making the battle in "C", you first resolve the fly over for the first fighter in "A", then (if surviving) resolve the fly over for the first fighter in "B", then resolve the rest of the battle in "C", with the first fighter participating, and possibly being hit by an AA gun in the embattled territory, if surviving both fly overs.
2- Making the battle in "E", you first resolve the fly over for the second fighter in "A", then (if surviving) resolve the fly over for the second fighter in "D", then resolve the rest of the battle in "E", with the first fighter participating, and possibly being hit by an AA gun in the embattled territory, if surviving both fly overs.
Meaning that you have only the option of resolving them in any one of only the following two sequences:
1A, 1B, C, 2A, 2D, E
2A, 2D, E, 1A, 1B, C
(where, for example, "1A, 1B, C, 2A, 2D, E" literally means "resolving the flyover in A for the first fighter, then resolving the fly over in B for the first fighter, then resolving the battle in C, then resolving the fly over in A for the second fighter, then resolving the fly over in D for the second fighter, then resolving the battle in E")
The substantial difference being that, as said, in Revised OOB you know all fly over results, for Combat Movement, before resolving any battles, but you never know battle outcomes before resolving any fly overs, while in Revised LHTR, you cannot know all fly over results before resolving any battles (unless only one battle has any fly overs and you resolve that battle first, but, even in this case, the flyovers are technically part of the battle itself, not happening before it), but you may have or decide to resolve battles before fly overs, which is going to be actually inevitable if you have more than one battle with fly overs or if the battle with the fly overs is also an amphibious assault from an hostile sea zone, meaning, in the example, that, if you decide first to resolve the battle in "C", you have to do so without knowing the fly over results for the second fighter, until after that battle is over, while, if you decide first to resolve the battle in "E", you have to do so without knowing the fly over results for the first fighter, until after that battle is over.
However, I have to say I'm not sure of what I'm saying, so please @Panther check this all out, and let me know if my understanding is fully correct.
Of course, other than what above, if all correct, the only other difference for Revised OOB, over Revised LHTR, is that, in Revised OOB, you practically have the exactly same fly over resolutions for Non Combat Move, as well, to be resolved the exactly same way as the ones happening during Combat Move, except only that you must resolve those of air units coming back from battles before plotting any other, or rather actual, non combat movements, thus any other fly overs, this being factually realized by having the fly overs for air units that participated in battles happening during the Conduct Combat phase (but, in practice, they are all non combat movements too, merely anticipated during the Conduct Combat phase), but only after all battles have been resolved. In practice, the whole system is exactly like having two Non Combat Move phases, after Conduct Combat, that work under exactly the same rules except only that, in the first one, you can only move air units that took part in battles (and must move them, if having any possible landing spots, possibly plotting carrier movements happening in the next phase), while, in the second one, you can move anything else, and having the fly overs resolved at the end of each of these two Non Combat Move phases, under the same dynamics as when resolving them at the end of the Combat Move phase.