Awesome work on U3…even sitting on the ramp looks pretty now.

Thank you BMS Dev team and all those that support them!! I think having periodic updates like this goes a long way. Personally, just knowing that there are plans for another release (or two, or three…) is enough to sustain me. Thank you for all your hard work and dedication!!

While I’m all for realism, the reality is that in real world, if I make a bad call on ATC (like calling departure “approach” or “tower”, the ATC personnel will respond and give me the instructions they were going to if I had called them correctly (they’ll also use their correct callsign and if I’m paying attention I would pick up on that and correct on my response).

So for me, having filters doesn’t take away the realism. Just because I “fat finger” a menu command doesn’t mean I would really do that in real life.

Thanks for the filters!

This is a really important note (maybe even something for the manual). Defaulting to the Alt Launcher seems like a destructive choice. Defaulting to NOT use the Alt Launcher doesn’t seem have any adverse side effects might be a better choice (the “do no harm” approach). Just my two cents.

Wow, I do hope threads like this never get leaked out to a behavioral psychologist. Reading through this from the sidelines is eye-opening and a bit scary.

But thank you to everyone that kept focusing on the issue and tried to calmly restate the problem as best they could (and those that rationally tried to debug / replicate the issue as best they could).

Thank you @Falcas for wading through this and releasing updates as well.

@bms-for-msfs
I think every would love to see real world scenery at a global level in BMS - why wouldn’t you. However, and I must preface this by saying I have never seen the BMS code, I think the 4-ohase plan above is probably a little naive. Trying to put BMS into MSFS is not simply taking aircraft models and locations, there are complex system models, campaign dynamics, etc. Not to mention having to ensure some base level of common terrain so that everyone is at least seeing the same objects, making sure they are interactive (can they be destroyed or is it all just eye candy), etc.

Maybe I’m misinterpreting the approach, but I think bringing better scenery into BMS is “easier” than bringing BMS into a new scenery engine.

Nonetheless, I think the BMS Dev team knows best on how to proceed and if they feel this approach has merit, I’m sure someone will be in touch. There is no doubt in my mind that if a full globe of photorealistic scenery could happen, without compromising the fidelity of the BMS system and engine, everyone would love it.

What you are running into here is a conflict between what you “want to do” and what you “need to do”. The bottom line is you can’t fly low to evade SAM coverage if the enemy has control of the air; you either need to eliminate the air threat or eliminate the SAM threat.

SA-10s can absolutely be taken out with HARMs from long range. Our squadron has found that having 2-3 pilots fly along the edge or the threat rind (so they can build up the location to a PGM1 state) and being separated by about 10-15 degrees or arc from the SA-10 works quite well. Once all pilots have a solid PGM1 location on the 10T of the HAD, they all turn in and launch 1-2 HARMs. the combination of multiple incoming HARMs and the fact they are coming from different directions, usually allows at least one to make it through.

As for inappropriate loadouts, keep in mind that the flight generator doesn’t necessarily know what conditions exist (or at least I don’t think it does) in terms of threats. Since you are fragging it manually you should check the loadout anyway. That’s part of what it takes to plan a successful mission. You really need to understand your target, any and all threats and your weapon choices - taking all that in will allow you to plan mission that has the optimum chance for success.

@vAiCon said in Israel Theater of Operations for BMS 4.37:

Finally… It took me a while … Israel Theater of Operations v1.07.1 is here,
without further worthless words:
Download - Gdrive

Awesome - thank you! However, GDrive is only giving an error.

There are a lot of variables when it comes to AAR so let me present a possible explanation. Any additional info you can provide might help to narrow it down.

First, I personally have never tried the scenario I think you are presenting; a 4-ship flight made up of human, AI, human and human in that order (so 1, 3 and 4 are human but 2 is AI). I don’t think that will make a difference to the tanker but again, I have never tried that.

One possible explanation could be in when the tanker was initially contacted. If, for example, #1 and his AI wingman were within the 10nm bubble of the tanker but 3 & 4 were outside the bubble then only 1 and 2 would have been entered into the queue. There would be no way for you to know or recognize this until #2 finished in which case the tanker would think it was done (this appears to be what happened). If #3 would have called for the tanker at that point (using Y1) the tanker should have put him (and #4?) in the queue and possible even 1 & 2 since they would all be inside the bubble.

The only thing strange we are seeing on a consistent basis is that if you need to refuel more than once, on any AAR after the first one you will likely need to press Y2 after being cleared to precontact in order to get cleared into contact position. First AAR works fine but second, third, fourth, etc. all require this extra step.

@lorikeolmin said in Tanker question:

@alfred y-2 used to be used by some people in 4.33. Not the same function anymore. People keep recommending it as a tradition.

What I have found is that in 4.35 if you need to refuel more than once in a flight - for example in ingress and then again on egress - you HAVE to use the Y2 command or you wont get back on the boom. So the sequence of events is…

1. fly to tanker -flight lead presses Y1
2. do your first AAR and then press Y3 (if other in flight they also take fuel and press Y3 when done)
3. go strike your target and then fly back to tanker
4. flight lead presses Y1…once in pre contact press Y2 (if you don’t you will never get cleared on to boom)
5. take fuel, press Y3 when done

Not sure if that’s a function by design or a bug but it never worked that way in the past and reading the manual would seem to indicate that a Y2 should never be required in normal operations.

Having just flown a mission that required five refuelings I can assure you that pressing Y2 was required on all but the first one.

@airtex2019 - responsibility understood (and accepted). Would be happy to help test any time.

@airtex2019 - Thanks, knowing its not supported because there is risk of people not doing it correctly or accidentally running things from incorrect folders makes complete sense. I get it - not everyone has the same comfort level with PCs and many a good pilot can fly a Viper while at the same time struggle with file-level changes. I have been in the IT biz for over 4 decades so I get the need to protect people from themselves.

Just glad to know that the above practice, when followed correctly, isn’t setting me up for an unknown risk or impending disaster.

Thanks again for the feedback

@Icarus - thanks for your feedback too…I’ve scoured the registry and there isn’t anything in there that would indicate a potential problem or favor why major update vs minor update would be better or worse than the other. And based on @airtex2019 comments, it sounds like care is taken to make new entries when needed.

I read in another post recently that having multiple installs of BMS is not supported and should be done at our own risk as it potentially drives you off a cliff. This is news to me as it had been a standard practice for many years and, as far as I know, never caused any issues. Maybe it’s the way we have instructed our Wing members to do it or maybe something has changed or maybe we’ve just been lucky but I wanted to see if we could get some clarity on this and make sure the reason many do this is clear to the Dev team (and others). My hope is that we can find a safe way to test out new releases while still providing an easy way to go back if needed.

I’ll start with why I feel this is needed. Quite simply, many of us have ongoing campaigns, new pilot training or just regular routines of flying online with each other and when new releases come out we want to make sure that we can continue those routines while still learning the new features, etc. while waiting for everyone else to come up to speed. Some people barely have enough time to fly and they need to make time to do an upgrade and learn anything new specific to the release. That’s were having a separate install comes in handy.

The way I have always done this is as follows:

1. make a copy of the entire X:\Falcon BMS 4.XX folder…call it Falcon BMS 4.XX.Y where Y=0 or 1 or whatever.
2. Run the updater (recently) in the original 4.XX folder or do the old red setup.exe to upgrade after downloading the new bits

This would give me the latest version to play with. If I needed to run the previous one, say for a Wing flight with others who have not upgraded yet, I would simply rename the 4.XX folder that has the latest to 4.XX.Z and rename the 4.XX.Y back to just 4.XX. And to go back to the latest, just reverse the process.

To my knowledge, that does not change any references in the registry and BMS is none the wiser and doesn’t even know about the other versions on the disk (admittedly if new entries where made or values changed to those only supported by the latest version there could be a problem). To be clear, I would never run BMS from any folder other than its original 4.XX folder.

To the Dev team or others that REALLY KNOW what the code, libraries, registry entries, etc. all do and expect, is this a dangerous practice? And if it is, can you recommend a way for people to try out a new release of BMS while still preserving a practical option for going back and forth so that Wing operations can continue while some people test out the new release and prepare new TEs, campaigns, etc.?

You don’t need to (nor can you) boresight GPS guided weapons…they don’t need to “see” what your TGP sees.

So there are potentially several things going on here; insufficient aircraft and how to add more flights to an existing package.

Let’s stat with the first one. There are only so many a/c assigned to a squadron. If a/c are damaged/destroyed that number continues to decrease (let’s ignore resupply for the moment). Also, any flights already fragged decrease the available number and finally, there are settings (that can be adjusted) that limit the percentage of the squadron you can frag (essentially, you can hold some in reserve).

So unless you have manually taken control of the squadron and clear3ed all the pre-existing flights, you need to take all those factors into account. As missions complete, more a/cx will become available but again, you need to make sure that the squadron is under your control not HQ to ensure they don’t get assigned to other flights.

As for adding additionally flights to an existing package, as already noted, you nee dto bring up the ATO, check the box that says “show entire ATO”, then expand teh sections until you find the package your want and finally right-click on that package. In the pop-up menu that appears, click, show flight and you will get that same box you get when creating a new package. Assuming there are less than 5 flights already in the package you can then add another.

@airtex2019 - yep, thanks. And thanks to all for commenting. I would have sworn that this worked not all that long ago but having spent some time testing today on all the old releases I could get my hands on, it looks like it has been this way for much longer than I would have guessed. I would still swear that they worked at one point but I couldn’t find a version that worked. Maybe I just wasn’t that picky in the past and was simply happy to hit the runway at all!

@Buhli - I just flew a test flight in a stock KTO Iron Fortress campaign and I do not see the behavior you are describing. I had no PPTs defined and just jumped in a jet, pulled up the HAD, did a TMS up over and SA2 that it found and my STPT remained the same.

@LorikEolmin - just for clarity, these were CCIP not CCRP.
@Tumbler31 - And so that I understand, with this being marked as “solved” what does that mean? Does it mean this is the intended behavior or that this is a bug that is known and being worked on or what?

I believe this just started in U3 although I haven’t gone back to U2 to confirm. When dropping BLU-107s, they are hitting short by a consistent distance. To test this, I created a TE with zero wind and made bombing runs in opposite directions just to be sure. If the pic below, X marks where the pipper was when pressing the bomb release and I have circled the corresponding impact craters. Yellow runs were from top to bottom, blue from bottom to top. I even tested a ripple 3 (all others were single CCIP) and that at least seems to work consistent with the single (center crater aligns with where a single would have hit).

Test flown at 500 kts, 750’ AGL (yellow and 500’ AGL (blue)

As you can see, all impacts were short. Did I miss something, has the BLU behavior changed?

I also tested Mk82SEs and they appear to be spot on.

@suhkoi69 I’m not sure about that, you may be right but I do it all the time and it converts files (meaning it finds differences and adjusts).

I guess my initial reply was meant to clarify what was being said as I thought you were saying you didn’t know about the MC convert tab. But clearly you do.