[Guide] How to rationalize the Dynamic Campaign engine
-
Deejay,
Science progressed thanks to experiments and taken risks.
Maybe BMS can actually benefit from trials of the community.
I am willing to push the boundaries a bit further on an online server to check how stable it is…Cheers
PS: there are pieces of c code for FF that actually explain the flags and help on the understanding…
This is why I tend to believe that it is a good thing that Mystic thrown it on the public forum. But I stey prudent. It could also have some very bad consequences if everyone are messing their install as soon as 34 is out. Same story about TvT events … we can’t monitor anything and any bug reports/investigations will be void.
But of course I will consider it … once I will have a bit less to do on my current todo list.
Lets see what happens.
PS: there are pieces of c code for FF that actually explain the flags and help on the understanding…
^This. Some of them may have been been “hijacked” on current BMS code to serve a different purpose or no longer works the same. I wouldn’t trust FF code.
-
One of the most interesting posts I’ve seen in a while. Frankly, I’m a little surprised that this is one area that the BMS devs have apparently not tweaked yet.
Dee-Jay makes an excellent point and suggestion– Like Ellie’s dad said in the movie ‘Contact’-- “Small steps…”. Based on what Mystic said, I would make smaller changes than he suggested and take my time with studying the results.
I’ll be following this thread closely for feedback on different values.
-
yeah interesting finding!
on a side note… for historical vietnam campaigns, we need lots suicidal flights generated…or we cannot reproduce historical scenes.;)
-
yeah interesting finding!
on a side note… for historical vietnam campaigns, we need lots suicidal flights generated…or we cannot reproduce historical scenes.;)
Do you put Fortunate Son in the background too ?
-
One of the most interesting posts I’ve seen in a while. Frankly, I’m a little surprised that this is one area that the BMS devs have apparently not tweaked yet.
Dee-Jay makes an excellent point and suggestion– Like Ellie’s dad said in the movie ‘Contact’-- “Small steps…”. Based on what Mystic said, I would make smaller changes than he suggested and take my time with studying the results.
I’ll be following this thread closely for feedback on different values.
Hi SoBad
While I don’t disagree, In my limited experience making small changes while trying to evaluate the effects of edits to settings can be counter productive. Larger changes can lead to a quicker understanding of what influences what.After understanding is established, with some documentation, then it becomes time to fine tune.
This type of editing is only for those with the experience needed and determination to put in the amount of testing needed, and is always better as a team or squad endevour.
Get used to starting a fresh campaign every week or even sooner.
-
I’m a little surprised that this is one area that the BMS devs have apparently not tweaked yet.
We did (on various areas) But in some/many cases we have reverted to previous values because benefits were not balanced. For instance, there is no point in increasing the max ditance of a SAM missile to make it “closer to rl) as long as objectives do not remains deagged until missile reaches its tgt. Same applies to many other things. It is all about compromises.
-
point of view of a developper (amongst others) that has spent a significant amount of time (read years) to fix bugs or mistakes that have been done between falcon 1.05 and BMS 4.32
Please let’s not repeat the mistake of the past:
-we glorified some people in the past SPteam , RP team, etc etc….that have done a LOT of tweaking, data and code, without perfectly understand what they were doing.
Ho yes believe me , we are still fixing many of the non sense that hose people have done (thei rproducivity was big )… In short, when there is a bug, first thing i do now is looking for comments including the names of those people because 90% of the time, this was done improperly.
My position is clear : Tweaking without understanding perfectly and i mean CODEWISE and DATAWISE , what is behind is
- no productive
- Extremly risky
- very frustrating
My advice is to liaise with a Code developper that is willing to participate to the adventure, to be more clear, i doubt a third party can make anything good in that area.
If someone is really interested in it, please apply for BMS recruitment, but be advised this will ask time, dedication and frustration.
My 2 cents
PS: sorry if i heart some feelings about those people from the past, i recognize they didnt have at all the same tools or CPU power that we have today, so their perspective was very different than ours (for instance, i compile and run an exe change in 30 seconds , i can even debug in Release & Continue in game, but in the past, it was certainly hours to compile a change !!! )
-
As we all know, the Dynamic Campaign (DC) in BMS is one of the core aspects of this sim. Also, we are all familiar with the fact that in DC, the ATO generates lots of suicidal missions, which do not make sense. Other times, it generates missions which are not rational. The good news is that this can be changed. The bad news is that this cumbersome situation was never properly addressed in years. Finally, I managed to alter this situation during the campaigns I made for EMF theater. Below, I will describe the necessary steps campaign creators should follow to force the ATO to generate rational missions according to modern air force doctrines.
Two crucial files that affect directly the way DC operates are: a)falcon4.aii and b)mission.dat. Both are located in the campaign folder. In the former file, there are lots of variables which affect the DC engine. During the various BMS updates, some variables were tweaked and others were added or deleted. It is, beyond the scope of this thread to discuss the proper values for all those variables. What is important is that none of those updates addressed the following crucial values:
MaxFlymissionThreat=85
MaxFlymissionHighThreat=100
MaxFlymissionNoThreat=10
MinSeadescortThreat=20
MinAvoidThreat=40For some reason, all BMS updates and even SP, FF or OF versions left those aforementioned variables in their default values. By googling around these variables, all the results regarding their meaning are rather vague. By playing around with these values and making correct changes in mission.dat, we can erase once and for all the DC suicidal missions.
So, what these values mean? These are thresholds, which represent the risk level of missions. In other words, it is a measurement of the GBAD (SAM) threat in an area. The higher the value, the higher the risk level of mission and vice versa. How the threat level is measured? It is measured by the air and low air hit chance of SAM missiles. For example the MaxFlymissionNoThreat=10 means that the ATO will generate low risk missions. In other words, missions will be generated if and only if the SAM threat is minimal or absent. Now, the main problem is that the MaxFlymissionThreat=85 and MaxFlymissionHighThreat=100 are way too high. These values alone are responsible for the suicidal missions ATO generates all the time. In plain English, the values of 85 and 100 mean that the ATO will generate missions regardless of the SAM type in an area. So, you will find an OCA Strike or a SWEEP mission generated in the MEZ of a SA-10 or Patriot battery. Clearly, insane. Bottom line, is that if you increase these values, the ATO will generate more missions, simply because it doesn’t care about the threats, as if they don’t exist. Why these values were left too high? I assume that in the days of MicroProse the goal was to flood the skies with as many a/c as possible, regardless of the realism factor. Afterwards, who knows? Maybe they didn’t get the proper attention.
Having this in mind, we now move forward to the mission.dat file to check out which missions fall under which threat category. In order to find out this valuable info, we need a tool named missiondatutil (http://www.mediafire.com/file/rcdcd7dmeak8473/MissionDatUtil.rar/file). The tool is accompanied with a word, which explains all the mission.dat variables. It is beyond the scope of this threat to address all those values. For now, we care only to find out the Risk Level we have to assign to each mission type.
Follow the steps and convert your mission.dat file to mission.csv one. Open the latter file and scroll to the flags column for each mission. Each mission type will have one of the following variables: a)AMIS_Nothreat, or b)AMIS_Highthreat or c) none variable regarding threat. To save you time, this is the result below.http://i64.tinypic.com/iml6qw.jpg
You can see that in the AMIS_Nothreat category fall missions which make sense to be generated in areas where SAM presence is either minimal or absent. It makes sense that HVA like AWACS and Tankers orbit in safe areas, far away from A2/AD bubbles.
You can also see that in the AMIS_Highthreat category fall missions which, rationally, do not belong there. You can’t generate and OCA Strike in area covered in full with A2/AD SAMs like SA-10. First, these SAM must be targeted with dedicated DEAD/SEAD missions. Once the area is clear of high threat GBADs, other strike packages can follow.
All the other missions which do not have any type of threat variable in the flags column, fall under the MaxFlymissionThreat=85 category, which is a risk level between the Nothreat and HighThreat values. Let’s say missions of medium risk.
So, what should we do to eliminate the suicidal missions and force the ATO to generate rational missions? We should do the following steps:
-
Leave the variable AMIS_HighThreat only in two missions. These are SEAD Strike and STSTRIKE (Stealth Strike). Perhaps, leave it in dedicated ECM missions too. But it is obligatory to include it in SEADSTRIKE & STSTRIKE. Remove the AMIS_HighThreat variable from all other missions, which have it by default. This way we tell the DC engine that only dedicated DEAD/SEAD packages will enter areas covered by A2/AD GBADs (high threat areas). Also, only stealth a/c will penetrate these areas for purposes other than DEAD. This rationale is on par with modern air force doctrines as well. You will observe that once SAMs are eliminated by DEAD / SEAD, packages, then the ATO will generate missions which fall under the MaxFlymissionThreat category. Once you done that, save your mission.csv file and by using the missiondatutil tool, convert your .csv back to mission.dat
-
Go to falcon4.aii, and use the following values:
MaxFlymissionThreat=20
MaxFlymissionHighThreat=85
MaxFlymissionNoThreat=10
MinSeadescortThreat=15
MinAvoidThreat=12By having a MaxFlymissionThreat=20, all the missions in mission.dat which fall under this category (i.e. SWEEP missions) will have a low to medium ALR (Acceptable Risk Level). Thus, no more SWEEP flights in the MEZ of SAMs. It doesn’t make sense.
By changing the variable MinAvoidThreat from the default value of 40 to 12, the AI a/c will try to avoid more SAMs. Previously, they pretty much didn’t avoid any threat at all. By how far away the AI a/c will try to avoid the SAM, depends on the value Airpathmax. Currently, I am playing around with this variable to check if there is any tangible effect.
All the aforementioned values work perfectly in my EMF campaigns, given the EMF database. Play around with these values, but bare in mind that they should be close to the ones I provided.
Nice.
Does it have real effect on red side too? As I see you said “yes”.
So far in all F4 versions from my aspect red side was simply a suicidal dumb player. Attack targets without SEAD and targets are mostly unimportant regardless campaign has some kind of supply system.
IMHO these changes for Korean campaigns are too few.In my Korea '80s MOD I made different but much more powerful changes which has very strong impact on performance of red side even it use mostly outdated equipment. Role scores for sq. and even in campaign squadron settings should be changed strongly to get a way more intelligent OPFOR.
For ex. in my '80s MOD red side uses large strike packages against airbases with H-5, J-5 J-6 but some of them attack HAWK batteries which means in case they are successful both in 2D and 3D can have REAL effect on AD capabilities of BLUEFOR.
Maybe I still have the list of my changes somewhere because I documented some of them. -
-
Hi SoBad
While I don’t disagree, In my limited experience making small changes while trying to evaluate the effects of edits to settings can be counter productive. Larger changes can lead to a quicker understanding of what influences what.After understanding is established, with some documentation, then it becomes time to fine tune.
This type of editing is only for those with the experience needed and determination to put in the amount of testing needed, and is always better as a team or squad endevour.
Get used to starting a fresh campaign every week or even sooner.
Larger changes will be easier to spot-check for effect. The only thing is to change one configuration option at a time as changing several will make it impossible to determine what actually had an effect and what the effect was.
-
Does it have real effect on red side too? As I see you said “yes”.
This is one of the major issue. It applies to all camps in all scenarios of a given Theater.
-
Question for Devs:
I believe it is in the interest of the devs, as well as of the community, that new exciting campaigns are created, isn´t it?
Why the devs don´t make a short document (or perhaps a chapter in the 4.34 manual) describing what all those variables are doing inthe .aii file? I beleive that could save a lot of time and trouble for many of us.
Anyway, just a suggestion.
-
Gold Post!
-
Question for Devs:
I believe it is in the interest of the devs, as well as of the community, that new exciting campaigns are created, isn´t it?
Why the devs don´t make a short document (or perhaps a chapter in the 4.34 manual) describing what all those variables are doing inthe .aii file? I beleive that could save a lot of time and trouble for many of us.
Anyway, just a suggestion.
doing such document will require hundreds of hours of code reading / testing / analysis…
i think you guys just dont realize the spaghetti plate !!!
IMO, It can be rated as a development project as a whole since it touches some of the inner principles …a single change could have unexpected consequences etc etc…
And, as usual, the more we will dig, the more shit we will find, and the more code we will need to erase / redo …
that is the curse of Falcon4 development.
i put a bet that more than 50% of the variables in that .aii file are not working as they should
-
This is one of the major issue. It applies to all camps in all scenarios of a given Theater.
Should be made for separated file for each theatres and each campaigns?
-
Should be made for separated file for each theatres and each campaigns?
let the game begin
that would mean filter EVERYTHING by teams impacted by those variables, and we can talk about hundreds / thousands of places …. and you can add on top of that the dozens we’ will forget and the dozens we couldnt know beeing impacted etc etc…
Welcome in the 3 to 4 weeks dev time world guys
-
let the game begin
that would mean filter EVERYTHING by teams impacted by those variables, and we can talk about hundreds / thousands of places …. and you can add on top of that the dozens we’ will forget and the dozens we couldnt know beeing impacted etc etc…
Welcome in the 3 to 4 weeks dev time world guys
I’m not exactly sure we have an issue for not. In case any campaign both sides has SEAD capable jet as I understand well these changes has positive changes on both sides.
Of course from my POV at first step it would be great to have better loadout and role scores for all jets. -
guys it’s just simple.
The dev tells it’s a mess.
understanding DC when reading it on docs it’s a head banging.To measure actual impact if not on debug mode u need at least a tool to visualize all the values and kinda crosscheck the behavior and actions, which will also be very difficult I presume, both to create such as a dev, and to monitor as a user.
what would be best is to break down current implementation, exclude non working parameters and variables, create a new clean implementation where u can enrich with new additions and parameters.
-
This is one of the major issue. It applies to all camps in all scenarios of a given Theater.
Or you can create an f4patch and select the campaign you want along with savexx.cam, savexx.tri, falcon4.aii,mission.dat. Works fine
-
Should be made for separated file for each theatres and each campaigns?
Since few years we are in the plan to make a separated mission.dat for each scenarios. So … I let you imagine that we didn’t waited that post to start digging all of this.
But during the process, we have found many other things must be changed before … so it takes time.To measure actual impact if not on debug mode u need at least a tool to visualize all the values and kinda crosscheck the behavior and actions, which will also be very difficult I presume, both to create such as a dev, and to monitor as a user.
There are what you can see … and what you won’t see. Fixing/enhancing => gooood. Breaking stuff without realizing it => less good.
Or you can create an f4patch and select the campaign you want along with savexx.cam, savexx.tri, falcon4.aii,mission.dat. Works fine
Cheap.
You could also copy/past …
That’s not good…
-
When I say break down, I mean break down analysis and not break it down like destroy it.
Στάλθηκε από το MI 5 μου χρησιμοποιώντας Tapatalk