@benabbott1 Also check your settings for "Notifications & Sounds" in your Forum Profile Settings. Sometimes email-notification is set there.

I got it to work thanks

@beelee Thank you! That information was exactly what I was looking for.

@Hepps the sad thing is dont even have a cat i can blame it on!

Thanks for the suggestions!

@Panther got it. Thanks. Was just confused cause the tutorial allowed the combo, didn't realize a difference in rules was at play. Thank you for response.

@SilverBullet That's correct. Sean Bridges is the original creator.

@LaFayette Thank you list view it was. You saved me a lot of time. Thanks again Guys

FWIW @Michael-Hoover , this is the script we use to download all maps: https://github.com/triplea-game/triplea/blob/master/infrastructure/ansible/roles/bot/templates/download-all-maps.j2 The stuff in {{ }} are template variables, you'll want to remove/update those as necessary.

FWIW, an HTML version of the rule-book is now available on the user-guides page: https://triplea-game.org/user-guide/ https://triplea-game.org/user-guide/rule-book The formatting is probably quite rough, but at least the content is there in HTML.

Thanks, RoiEX. I'll whitelist "githubusercontent.com" and it should work.

@RogerCooper said in Can't Get the Debug Console to Display: @LaFayette Toggling did not help I confirm this problem. Debug/Show_Console does nothing, and this isn't fixing it (I suppose you or somebody should move this to GitHub, then, if not posting there in the first place).

@SilverBullet said in new players entering with multiple ghosts: @beelee well i am sure it isnt on purpose, it does appear to happen upon entering the lobby, not as much as entering a room. Yea i doubt it is. I think when I did it (had 3 beelees) lol was when I kept joining the game to be a different player because i didn't know how to do it. it was 10 years ago or so. I can't really remember

@RoiEX I'm using Windows 10, latest version, which is working perfectly. However, your comment about the font made me remember that I altered the default Windows font with Winaero tweaker some time ago. So I tried to reset to the original font, and voilá, the game launches without any problems and with the correct/legible font. Thank you very much both for your help!

@SilverBullet said in Is there a ledger mod?: @Cernel ... MP (military police), them guys are tough ... P.S. if talking about a Moderator, a cap "m" means a Moderator a small m is a mod for a game. Yea Jack Reacher types

@Hepps wow that almost sounded psycho lol. Anyways dude what thread are you trying to troll me on please because if you read the forum it was a belee troll post in the "Guide lines and feature requests" thread ... where only a few people can post because he's a modded troll (duh why??) and so Cernel then pwnt belee and moved my belee pwning post to "Taking your suggestions for a new UI" thread where we can now ez mock the troll so then we discovered there that we can't edit posts in that thread so thats where the actual topic of "being allowed to edit posts in a thread" was raised and so then Rolex shows up and called the "Guide lines and feature requests" thread as an Announcement thread and a special thread where he's now raising the issue of what things should be allowed in threads like non admin/mod posting allowed or being able to edit posts etc. with all of this resulting in people reading this forum's thread are like lolool look at these anal nerd trolls that think we want to be reading this dolt anal spam but anyways I totally gave some nice answer to Rolex about how he explained not allowing editting posts nicely and even gave him a Like and then he gets defensive roofl making people kind of figure that these constant mad nerds haveto abuse commands and threads and not allow editting only because they keep getting pwnt so ez on their other troll aliases and its really sad but funny to me Hepps its called retention and ya I make aliaser trolls mad ez just read the thread wow care more hehe SO EZ nub aliaser trolls. I tell yous they call me a meme on Star Wars my handle is YKO<!>AW5UM my clan is young knights of old -.-

@RoiEX That might be.

@Frostion

@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. For example: 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.