Volcano

Just a reminder... now two weeks out. That is, not this TGIF, but next one. 🕙 Whether we actually resume on the 26th depends on some things that have to happen from the two (new) COs that will take over (which at the moment I think will be BLUEFOR - CavGunner and OPFOR - DK). I will explain more after this TGIF...

19 MAR 2024: Future Wars-Suslik-4379b (yes, this is another train-up mission for what is coming the following TGIF...) SPECIAL CONSIDERATIONS: Draft? Yes Random CO selection? Yes Minimum # players: 8 NOTES: Remember to play within the TGIF House Rules and SB.com Community Rules.

OK great. I renamed the title of the thread for future reference.

Sounds like a good theory. Thanks for the info.

12 MAR 2024: Future Wars-Oncilla-4379 SPECIAL CONSIDERATIONS: Draft? Yes Random CO selection? Yes Minimum # players: 8 NOTES: Remember to play within the TGIF House Rules and SB.com Community Rules.

Ah yes, I missed those -- yes that would be easier to just move them there.

OK, after about 2 hours of investigating, we collectively figured out what the issue is: It seems to be that this scenario was originally created from a save-in-progress file, probably as a way to avoid re-creating everything again, which makes sense but comes with consequences. The consequence s, if an event was true once the scenario was saved-in-progress saved, then it is saved that way in the scenario's start-state. (The image shows the two events in the Mission Editor -- that they are TRUE before even starting the scenario to the Planning or Execution Phase.) Technically this is a feature (because you want save-in-progress scenarios to retain their end-state for join-in-progress sessions), but it is obviously not ideal, because there should be a way to reset those events if the scenario designer wants to. Therefore, we are investigating the possibility of making an enhancement to allow the scenario designer to uncheck the leftmost boxes in the Mission Debugger to effectively "reset" events that were saved as TRUE. If do-able, then of course this would not be available until a future version of SB, but it would mean that this would never be an issue again, since it could be controlled. But in the mean time, I have come up with a work around so that you can salvage the scenario as-is with no negative consequences. On the BLUE side, in the Mission Editor... Essentially you have to swap (re-make) Event 2 & 4 with Event 49 & 50. Event 2 & 4 are the events that we don't want to be true at the start, but are true because the scenario state was saved that way (the save in progress). Event 49 & 50 are not true at start, but they become true immediately, because they are just messages that play when mission time is > 0 (one of them is delayed another 2 seconds though). By swapping 49 & 50 with 2 & 4, then 2 & 4 are true immediately and this has no impact on the scenario, because the start message will be displayed immediately anyway, since they were going to become true at the start already. Normally we would say to move those two events (2 & 4) to new event slots to work around it, but they are all full - so this is why they would need to be swapped instead. After that, it should work fine - I tested it and it did work (those events no longer happened at start). [You may have done this already] Secondarily, it also wouldn't hurt to try to track down and fix the duplicate IDs. This is likely due to the age of the original scenario, before all that was addressed. There are a few on Blue, but seem to be quite a bit on the Civilians side.

OK so you are saying that the events occur (are TRUE) when there are no units of either party present in those regions? If so, then yes, it would seem like an error given your conditions. HOWEVER, keep in mind that -- and this may or may not be the cause here -- units on allied sides are considered to be 'friendly units' when it comes to conditions and events. I think there has been a misconception in the past by others that "friendly" refers only to that side's own units, but in reality this is not true: it refers to units on that party AND any units on allied parties. I mention it just in case you might have a unit from another party in there that is allied, that might be triggering the event instead. It can happen.

I'd say your issue is with the ">" needs to be an "<" and the "0" needs to be a "1" in both sub-condition 1, and the US Straggler's event images. You mentioned that it both "needs to be empty" of those forces, but your parameters are essentially 'greater than 0' here, which sounds like it will make it true when you don't want it to be. Or am I missing something?

For European players, the TGIF time is now back to normal 5 APR 2024: Allied Force MTC 01-smaller-4374-FMU SPECIAL CONSIDERATIONS: Draft? Yes Random CO selection? Yes Minimum # players: 8 (four sides, 2 per side)

Just FYI... The question was asked, when does "round 2" (spring) part of the campaign start? It will begin on the April 26th TGIF (four TGIF's from now). So prepare yourself. If you didn't participate last time and want to, then you can - although the teams might need to be balanced. If you participated last time and don't want to this time, that is fine too. The only rule is that if you started on one side they you must remain on that side, unless we have to re-balance the numbers on each side. More info will follow as we get closer.

It's not so much about regulation having one ammo door open at one time, its that you physically cannot have both ammo doors open at the same time. When one door opens, it slides over and covers the opening of the other side. First, you have to prepare the TC's stored ammo, which is only a manually opened door -- its not opened by hydraulic power nor electrical motor. This full process is (from memory)... a. Remove the TC's "curtain" which is a curtain behind him that is in front of that door, which has pockets and pouches, that you use to store "stuff" like maps and manuals. The curtain clips off but then has to be moved out of the way, covering up other things (like the TC's control panel) in the process. b. Then you have to un-stow a prybar-like handle that is used to manually pry open the TC's ammo door. This handle is attached to the wall, between both ammo doors. It slides and then swivels out, like some kind of crowbar that is attached to the wall. c. Then you have to pry open the door with this handle, which isn't the easiest thing to do - it can take a minute or so. d. Then you have to use your fingers to grip a detent on the door, and manually slide the TC's blast-door (which is pretty thick and heavy, maybe ~ 1" thick) over to block the ready side. e. Then you have to extract ONE round into the crew compartment from the TC's stored ammo side. f. Then you have to manually slide the TC's ammo door back shut, all the way shut, so that the ready ammo door can open. g. Then you have to hydraulically open the ready ammo door (as you normally would). h. Then you have to store the round that you currently have in the crew compartment, and let the ready door close. ...all the while you have to try to avoid chopping off anyone's fingers in the process. Then you repeat the process back at "d" above, for each and EVERY single round. (There is probably some YouTube video showing the process, maybe.) So why not just pull out more than one round at a time? No. The rounds are bulky, and it is dangerous to be handing more than one round in the turret while everyone is opening and closing doors manually, and so on. Plus, yes, regulations are in place for this part of the process, and for good reason, for the same reason that you do not "lap load". The process wasn't designed to be quick, but then again, that is the trade-off of having the ready AND stowed ammo protected in the ammo bunkers. Rest assured, if the time was wrong it would have been changed in 25 years -- it's realistic. It was timed a long time ago, to be an average crew.

Yes, at some you remapped your key for TIS alt. view, which is default to SHIFT+NUM* (I just confirmed it). Or, possibly, you may have saved a key profile and carried it over to the new version. You can press the "Defaults" button and watch the keys change back, then press Cancel if you don't want to make those changes. We feel that we don't need a TIS key for the JIM-LR, so it shares that TIS alt. view button (with a lot of other things too, like the Centauro TIS view).

Right, if you show up a little before the game time (2100 CST), then someone should be around to test your connection to a host. The scenario and map are sent to you automatically when joining the session, and are usually pretty quick.

Seems like, for European players, the time will be 1 hour sooner one last time here. 29 MAR 2024: !OBJ PV - MP-smaller_4268 SPECIAL CONSIDERATIONS: Draft? Yes Random CO selection? Yes Minimum # players: 8