SQ, that's some great insight - thanks!
I want to explore data science in some more depth, and applying it to wargaming sounds like a compelling approach for me. However, I'm much stronger in python (and pandas) than Lua.
Would you say the pro-data portion of the professional wargaming community is as committed to Lua for analysis as it is for in-game scripting?
BVR Engagement Logic & Boost-Coast missiles
Moderator: MOD_Command
Re: BVR Engagement Logic & Boost-Coast missiles
An argument for data-driven decisions, in terms of wargaming and planning, is the ability to sandbox an event. Create a repeatable scenario where you can test out dozens, or hundreds, or thousands, of different approaches, to see which outcome suits your needs best. A challenge with Command is using in-game functions, and writing LUA, to accurately model an adversary. An output of this process could be intelligence for commanders - like, "if you send Growlers with this strike package, you increase your chance of success by 38%" Now the nerds may like to know that you ran 5000 simulations with various strike packages, but the extrovert strike commander may only want the bottom line up front.
I think nearly every pre-Tiny scenario needs to be rewritten, which isn't a bad thing - we need to use this tool to inform decisions (either real decisions or hobbyist "what if"), and as the game changes, we need to update the AI that we write for the adversary.
I imagine some future where a strike planner nerd on a Carrier is using something like CMO to model an upcoming strike package, which then informs the commander on how to plan the strike. Or, maybe, some AI system does this for "us", and uses a "CommandGPT" to tell the drones how to configure themselves for the upcoming battle.
I think nearly every pre-Tiny scenario needs to be rewritten, which isn't a bad thing - we need to use this tool to inform decisions (either real decisions or hobbyist "what if"), and as the game changes, we need to update the AI that we write for the adversary.
I imagine some future where a strike planner nerd on a Carrier is using something like CMO to model an upcoming strike package, which then informs the commander on how to plan the strike. Or, maybe, some AI system does this for "us", and uses a "CommandGPT" to tell the drones how to configure themselves for the upcoming battle.
Re: BVR Engagement Logic & Boost-Coast missiles
I have never heard of anyone using LUA for producing an analysis product. There's way better tools out there for that.Fido81 wrote: Thu Jan 05, 2023 4:47 am Would you say the pro-data portion of the professional wargaming community is as committed to Lua for analysis as it is for in-game scripting?
Re: BVR Engagement Logic & Boost-Coast missiles
That's not the purpose of wargames. That's the purpose of an M&S study. It's a mistake to conflate the two, and it's easy to do that when you're doing a computer wargame. Everyone wants to think you can run a wargame event and get an M&S study for free. It doesn't work that way on a practical level.Craigkn wrote: Fri Jan 06, 2023 5:18 am An output of this process could be intelligence for commanders - like, "if you send Growlers with this strike package, you increase your chance of success by 38%" Now the nerds may like to know that you ran 5000 simulations with various strike packages, but the extrovert strike commander may only want the bottom line up front.
You don't measure effectiveness in a wargame. Instead, you build or eliminate courses of action, and justify the logic behind that course of action. At the tactical level, wargames tend to be very down in the weeds and technical. They're really about mission planning. In the case of Growler employment, we all know you'll probably do better with jamming support. A wargame would focus on things like where do you put their marshall areas? How do those correspond to the tanker orbits? How are you going to protect those tanker orbits from fighters? If those aircraft are under attack, where are you going to retrograde to? If you add aircraft to defend the marshall areas and tankers, that might take away from the number of fighters you have available as escorts? What are some factors you consider when balancing between the two? Once the Growlers begin ingressing into hostile territory where will they set up their CAPs? Why there? Will there be more CAPs to protect them? Where will they be? How many aircraft will fill them? How long can you stay there? How does the time on station for the electronic warfare aircraft impact the time on target for your incoming strikes? These aren't really quantitative questions, or if they are, they're probably questions with a deterministic answer. It often helps to figure this stuff out by experimentation because there's lots of variables and more than one answer.
The data collection part is less about measuring effectiveness and more about illustrating what happened. It's a story telling tool, more than a method of developing measures of effectiveness and performance. I think one of the challenges in wargaming when there's a computer involved is moving people away from that mentality, actually. Sometimes you can make statistical statements (we shot 200 of missile X in this scenario, with an effectiveness rate of...) but it's hard to develop top level measures of effectiveness from a wargame (e.g. mission success rate). I would be hesitant to say something like "course of action A is 25% more effective than course of action B." I would be comfortable saying something like, "In course of action A we were forced to retrograde the Growlers and suffer diminished jamming support because we didn't have enough fighters protecting them to achieve a favorable force ratio in the engagements that followed."
It's a different type of learning. In an M&S study, you fix the course of action and do it over and over again. In a wargame you do it once, but change your course of action.
Naw... they're fine. Besides compatibility issues, there's no reason to mess with them. Most commercial scenarios are not really suitable for analysis. I would not be willing to draw any conclusions from them.I think nearly every pre-Tiny scenario needs to be rewritten, which isn't a bad thing - we need to use this tool to inform decisions (either real decisions or hobbyist "what if"), and as the game changes, we need to update the AI that we write for the adversary.
I think that vision definitely exists elsewhere. I think we're a long way from achieving that, but we're a lot further along than we once were thanks to CPE. I think there's lots of room for growth in the area.I imagine some future where a strike planner nerd on a Carrier is using something like CMO to model an upcoming strike package, which then informs the commander on how to plan the strike. Or, maybe, some AI system does this for "us", and uses a "CommandGPT" to tell the drones how to configure themselves for the upcoming battle.
Re: BVR Engagement Logic & Boost-Coast missiles
Question, how is missile burn time in determined in the DB? Is it a formula derived from nominal max range and missile velocity, or is it based on an open source dataset somewhere.
Ex, the AIM-7M in game has a motor burn time of 4 seconds,

after which it coasts with no thrust. However, the documentation for the Sparrow M states that the Hercules mk58 motor is dual pulse boost-sustain with 4.5s boost and 11.5s sustain.
Most 80's missiles should be boost-sustain, however in game they are mostly boost-coast, resulting in significantly shorter effective ranges than they should have.
Ex, the AIM-7M in game has a motor burn time of 4 seconds,

after which it coasts with no thrust. However, the documentation for the Sparrow M states that the Hercules mk58 motor is dual pulse boost-sustain with 4.5s boost and 11.5s sustain.

Most 80's missiles should be boost-sustain, however in game they are mostly boost-coast, resulting in significantly shorter effective ranges than they should have.
Re: BVR Engagement Logic & Boost-Coast missiles
Any chance for a No-Escape-Zone+10% WRA setting? Might help for those targets that don't turn tail and run until they actually detect the missile.
-
- Posts: 457
- Joined: Mon May 11, 2020 5:16 pm
Re: BVR Engagement Logic & Boost-Coast missiles
You might want to open a DB update request and provide the source above.codextero wrote: Tue Jan 10, 2023 5:26 pm Question, how is missile burn time in determined in the DB? Is it a formula derived from nominal max range and missile velocity, or is it based on an open source dataset somewhere.
Ex, the AIM-7M in game has a motor burn time of 4 seconds,
after which it coasts with no thrust. However, the documentation for the Sparrow M states that the Hercules mk58 motor is dual pulse boost-sustain with 4.5s boost and 11.5s sustain.
Most 80's missiles should be boost-sustain, however in game they are mostly boost-coast, resulting in significantly shorter effective ranges than they should have.
Re: BVR Engagement Logic & Boost-Coast missiles
The burn/boost times are dynamically calculated in-sim the first time that a given weapon is about to be used.codextero wrote: Tue Jan 10, 2023 5:26 pm Question, how is missile burn time in determined in the DB? Is it a formula derived from nominal max range and missile velocity, or is it based on an open source dataset somewhere.
Ex, the AIM-7M in game has a motor burn time of 4 seconds,
after which it coasts with no thrust. However, the documentation for the Sparrow M states that the Hercules mk58 motor is dual pulse boost-sustain with 4.5s boost and 11.5s sustain.
Most 80's missiles should be boost-sustain, however in game they are mostly boost-coast, resulting in significantly shorter effective ranges than they should have.
What happens is effectively a recursive inverse-DLZ calculation: "If this weapon is launched under nominal conditions, and with a nominal target, how long does the boost duration need to be in order to successfully intercept the target, with the target's starting position at X distance?" This is run repeatedly until a burn duration satisfying the nominal range is found.
Now, part of this trajectory calculation are some factors which, by necessity, are abstracted or hardcoded. For example:
* The drag coefficient is assumed to be the same for all AAW missiles, which IRL is most definitely not the case (the R-77's lattice fins are supposed to be _real_ draggy, for instance). We use this coefficient values in combination with the known dimensions of the weapon to arrive at the actual drag value at any given time (taking also into account at-altitude pressure, angle of attack etc).
UPDATE: The drag coefficient is now dynamically calculated per-weapon, based on the weapon's dimensions.
* Another example is the "post-burnout weight fraction", ie. the missile's post-burnout weight divided by the missile's pre-launch weight. IRL this is different for each individual weapon; here we assume a 30% figure for all of them.
UPDATE: It is now possible to pre-define this value per-weapon.
* Some propulsion systems use boost+sustain combinations with different impulse characteristics for each, or restartable engines or multi-staged engines (e.g. SA-2, SA-3, SA-5, SM-1ER/SM-2ER, SM-3, SM-6, Aster-15/30 etc.). We do not have separate dedicated propulsion models for each of those configurations, so instead we assume a constant-burn boost and as described above we calculate their necessary duration. _That said_, we take extra care to model the "average speed/time to target" differences between the various propulsion options; for example, ramjet weapons like Meteor, Sea Dart or SA-6 have significantly higher average speed than simpler rocket-propelled weapons like pre-D AMRAAM, and this is clearly reflected in the burn times.
UPDATE: We have added explicit support for multi-staged AAW weapons.
As a result of these and some other abstractions, you are likely to observe burn times that are usually close, but not exactly match known public figures. The overall concept is to "shape" the burn figures to match known nominal ranges. The "litmus test", if you will, is: Does this missile reach out to X nominal range?
(Nominal conditions are, for air launch, a M1.5 launch speed at 36K feet. Surface launch assumes a static launch platform at surface level. In both cases the nominal target is a head-on incoming transonic aircraft at either 36K feet OR the weapon's ceiling if it is lower than that.)
-
- Posts: 23
- Joined: Thu Nov 24, 2022 11:18 pm
Re: BVR Engagement Logic & Boost-Coast missiles
Does launch speed and altitude factor into missile range calculation?
If I launch from max speed and height do I get an advantage?
BSW
If I launch from max speed and height do I get an advantage?
BSW
Re: BVR Engagement Logic & Boost-Coast missiles
I think this thread might answer your question. Searched "launch speed" and this showed up. Might help the devs not repeat themselves.
https://www.matrixgames.com/forums/view ... d#p5063327
https://www.matrixgames.com/forums/view ... d#p5063327