Released: AA group for the entire Western Front map!

[Flashy]

Hi all, 

This is something I have been working on for about 2 months now, and I am happy to release the full western front AA group today! 😁

This is a group for the Mission Editor that creates AA fire along the front line for the WW1 map with very little passive performance hit, as far as I can tell. Whenever you fly low over the enemy front line, a group of machine gunners and a flak gun will be spawned below you. The AA will only be activated if you fly lower than about 1300m, otherwise you are safe.

 

How to use:

1. Download the group(s) which correspond to the area your mission takes place in (see below), and extract them to the "\IL-2 Sturmovik Great Battles\data\Template" folder.
2. Open the single player mission in the mission editor
3. Import the group(s) you extracted in step one (i.e AAFrontLineArras, AAFrontLineVerdun or even AAFrontLineGroupComplete if you want all the groups combined) by clicking "File | Import From File:
   
4. wait for it to import then save the mission
5. Play!

 

Thats it! the logic is not dependent on the player aircraft or location, so there is no need to connect it to the player aircraft or anything else. Its Plug and Play  

 

IMPORTANT! DO NOT move the groups once imported, it will mess up the placement of everything! If you need to cover a bigger area than a group allows,  just import the next group as well (i.e if you need to cover an area slightly beyond the Arras group, just import the Amiens group as well, do not try to move the Arras group down!)

 

Whats with the names of the different groups?

 

I have divided the front line up into groups of +-50km, starting from the top of the map and going down. Each group is independent and doesnt require any of the others present to work.  I have named these groups loosely based on which towns they are near. Therefore, the first group is called AAFrontLineArras because it is around Arras (i.e it runs from Ypres-Arras-Bapaume), the AAFrontLineAmiens is the next group because it is the 50km of front line around Amiens, etc.  This is roughly the area the groups occupy (not exactly to scale):

 

Its recommended you only import the groups you need for your mission area, but the performance cost on the mission is so low for groups which arent active (i.e if there are no aircraft in the vicinity) that you can actually import the whole front line without fear of it slowing anything down.

 

Other questions:

 

Will this kill me as soon as I get low over the lines?

 

Spoiler

The amount of ground fire is currently set to be not too deadly.. you will take a few machine guns hits and get a few close flak bursts, but its unlikely to be lethal. This can obviously be changed but I am trying to strike a balance between giving the player enough time to get out of there alive, while also being a deterrent to flying low over the line. If you fly low along the line for a while, you will obviously start to take more serious damage, as you would expect.. Here's a vid showing the level of fire: its still light, but hopefully enough to entice you to get out of there!
 

 

 

(you can hear the bullets whizzing by, and the guns exploding near you, even though they dont often hit..much)

How does it work?
 

Spoiler

To begin with, there are a few large (50km² ) checkzones which initially detect if there are any planes in the group's area. If a plane is detected, the front line loop is activated until there are no more planes in the area. The actual front line logic works as follows:

Using a modified version of F/JG300_Gruber's Area Detection group, the front line consists of a series of deactivated checkzones extending along about 50km of the front line (the area inside the big 50km² checkzone) . The mission logic loops through each "Plane IN" checkzone in each Area Detection group, activates and "pings" it for a very short amount of time (200ms), before disabling it again and moving on to the next one. In this way, the performance cost is kept very low because only 1 checkzone is ever active on each side of the line at a time while the logic is running (so you can have as many of them as you want because they are inactive 90% of the time).

 

If a checkzone is triggered by an enemy plane when it is pinged, the Plane-IN checkzone is deactivated, AA objects are spawned (5 machine-gunners and a flak cannon) and a "Plane-OUT" checkzone loop is started. This loop works in a similar way, except it only pings the plane out checkzone once every 10 seconds (again for 200ms - keeping performance hit as low as possible).The main loop then checks this OUT checkzone next time it comes round, ensuring that only 1 checkzone from each little AA group is active at a time. When the plane out checkzone is triggered (enemy plane has either left or is dead), the AA objects are deleted and the whole group is reset, waiting for the main loop to come round and check it again.

The logic in each AA group checkzone

 

Because of the fact that the checkzones are not active all the time, and have to wait to be pinged by the main loop, there is a bit of a delay from when a plane flies into the zone area and when the AA are spawned. In my testing so far, it takes the logic about 7-10 seconds to check the whole 50km front line, so the worst case scenario (if you fly into the area just as the loop has passed by), you will wait 10 seconds before AA spawns. But, realistically speaking it will be much shorter and closer to 3-5 seconds on average. Since this has been designed for WW1 planes, that delay is not an issue due to the lower speeds of the aircraft. 

 

Can you extend the number of checkzones/length of the front?
 

Spoiler

The entire front of the western front map (+-400kms I think) has been divided into different groups (Arras,Amiens,Reims, etc), so if you want to extend the front, just import whichever groups you need. There is also a AAFrontLineComplete group which covers the whole front line. 

 

The length of the checkzone line can be extended easily with little to no performance penalty, however the longer the chain of checkzones which the logic has to loop through, the longer the potential delay between when you enter the area and when the AA will spawn. I have chosen a line +-50km long because a lot of WW1 single player missions use an area of 50 square km's as their mission area, and I consider the delay in the AA spawns to be acceptable for this length of front.

 

It is also possible to use more than one of these groups because each one only has a passive cost of 1 active checkzone per side (1 for German frontline, 1 for British/French/American etc frontline) (so you can extend it to 100,150,200kms etc), but I don't think this is necessary in most cases - you wont be flying that far out of the mission area.

Why did you create this?
 

Spoiler

Since the RoF days, there has been virtually no consequence to flying low over the frontline on the WW1 map. In reality, WW1 pilots would have to climb to a decent altitude before going over the line, because it was too dangerous to cross it flying low.

 

This group is my first real attempt to re-create a more realistic front line which "forces" higher flying altitudes over the lines. I haven't seen anyone do this satisfactorily yet, due to the performance cost of having lots of active checkzones and units, but when I saw F/JG300_Gruber's Area Detection group logic (i.e. keeping the checkzones inactive for 90% of the time), it suddenly occurred to me that this could be used to build something which used hundreds of checkzones, without the performance penalty of having them actually running all the time - the perfect thing for machine gunners and AA over the lines.. Its my hope that others can take this group and run with it to create something even better!

Can this cause performance problems?

Spoiler

Absolutely! While the passive cost of the loop running is very low (1 checkzone per side of the front per area), the logic is literally looking along the whole front line for enemy planes, and spawning AA units when they are there. If there are lots of planes flying low over the front in many different places, then 5 AI units will be spawned for each zone in which there are planes, and there is currently no limit on how many of the groups can be spawned at a time. This could definitely cause performance issues in extreme cases. However, the logic is designed to aggressively delete objects when they are no longer needed, and the performance overhead from the checkzones themselves is minimal, so it should be fine for the vast majority of missions. I have been copying this group into career and PWCG missions and I haven't noticed any performance problems which weren't there in the original mission. I have also stress tested this by having the entire western front AA logic running, and 25 planes flying low in various positions along the front to trigger the AA (which is pretty much the worst case scenario IMO), there was still no detectable time dilation, so I am quite confident it will be fine for pretty much any realistic mission. 

What are the downsides?

Spoiler

In addition to the small spawn delay mentioned above, the AI for ground units is also slow to respond to enemy aircraft entering their range - they seem to take around 5-10 seconds before they actually start firing. I have tried all the tricks I know to reduce this delay (using a force complete LOW command on spawn, and placing them facing the direction where the plane is most likely to come from) but they are still slow. To offset this, I have increased each Plane-IN checkzone to 1250m diameter, which seems to give them enough time to get their act together and actually fire a bit before the plane leaves the area and they are deleted.

Anything else?

Spoiler

Obviously, I don't know 100% what performance impact lots of inactive checkzones and lots of running timers will have on a mission, but all the information I have seems to suggest its not much. My tests seem to confirm this because this group doesn't seem to create any lag or time-warping in the missions I have used it in. This group was also built on a slow PC (1st gen i7 920 and GTX 1060) which can barely run the game as it is, and I still didn't see any performance hit on that machine from it, but it would be great if others could test it and give feedback on the performance hit.

 

 

UPDATE:

 

 

2025/11/06 Full Western Front AA group released

 

-Finished building and testing groups which span the entire front line for the FC Western front map. These are named based on which town they are close to (Arras, Amiens, Reims, Verdun and Nancy). There is also a combined group for the whole front!

-Minor bug fixes

 

2025/11/03 Version 2 released

 

-Cleaned up the Plane-OUT logic to make it more efficient. Initially it ran on its own 10 second timer once it had been activated, but that could mean the OUT checkzone was triggered at the same time as one of the other IN checkzones in the main loop. Now the OUT checkzone is also checked by the main loop, ensuring that only 1 checkzone on each side of the line will ever be active at a time. 

 

-Added a 50km² checkzone to determine when the main loop is activated. This runs once a minute for 500ms. If any aircraft are detected in the area, the AAFrontLine is started. If no aircraft are present, the loop will be deactivated, meaning it uses basically zero resources (a timer and a checkzone for 500ms every minute) when nobody is around. 

 

 

 

 

 

 

AAFrontLineAmiens.rar AAFrontLineArras.rar AAFrontLineReims.rar ADGFrontLineComplete.rar ADGFrontLineNancy.rar ADGFrontLineVerdun.rar

 

 

 

Edited 3 hours ago by Flashy
new version

[IckyATLAS]

I am not sure all this effort is really worth, but I must admit maybe I did not understand well. On a modern gaming rig you can very well have all of them active and it won't much tax the cpu/gpu resources too much. The spacing is about 1 AA gun post for every 1500 meters of each side of the line. Depending on the AA chosen they will act accordingly and will not fire much higher than your altitude. They will also naturally move to track you and fire. In total this is about 30 AA gun posts.

What you can do is have the line not firing using Force Complete, and then you can alert them when a plane enters the line with another Force Complete. With three or four checkzones you can detect that your plane is overflying a region of the line, and wake up the gunners in that region. To make it simple you can define a control object (Fake Vehicle) to which all gun posts of a region are connected. Giving a command to it would send the command to all the connected gun posts. This allows to separate the AA artillery infrastructure from the control logic, so that you can change and test modify the control part with just one entry point to the gun posts regional group. If you want to spare some resources then just activate or deactivate the gunposts group if the plane is in or out a given region of the line. This is very easy as you will just use the Activate or Deactivate MCU to the control Fake Vehicle. This will make disappear the gun-posts or make them reappear. I prefer this to spawn and delete because otherwise you loose the links with the control Fake Vehicle. Activate and deactivate keeps everything properly connected.

 

[Flashy]

Hi @IckyATLAS , thanks for responding! My goal here is to create something which can be imported into an existing mission like those generated from the career mode or PWCG. These missions are already very well populated with other checkzones, complex triggers etc, so I want something which puts as little additional strain on the mission as possible. My current checkzone array uses something like 50 checkzones per side of the line in each "area" of 50km². If I am understanding you correctly, that would mean suddenly activating 100 checkzones (50 on each side of the line), or 50 "groups" of AA (300! objects at once). I'm pretty sure this would create a big performance hit in an already busy mission. With my current loop logic, only 1 checkzone on each side of the line would ever be "active". 

 

I am not really familiar with the Fake Vehicle idea, can you please elaborate on that a bit more? Do you mean you TL the other objects to the fake vehicle and then when you disable the fake vehicle, it automatically disables any entity which is TL'd to it? I.e you dont need to deactivate/activate each object individually? 

[JG4_Deciman]

The difference between 'spawn / delete' and 'activate / deactivate' for objects is:

- with spawn / delete the object will loose any connections to further triggers... after it has despawned.

- with enable / disable all these connections will stay in place and come back to live after 'enable'

 

For mission creation you just have to set the object as 'enabled' by default (and then disable it after mission start)

So it is present with all connections and then deactivated (like deleted after having spawned)

and 'enable' does the same as 'spawn' later, but all the logic behind is still working

 

Deci

[Flashy]

Version 2 released. See UPDATE on original post. 

[IckyATLAS]

12 hours ago, Flashy said:

I am not really familiar with the Fake Vehicle idea, can you please elaborate on that a bit more? Do you mean you TL the other objects to the fake vehicle and then when you disable the fake vehicle, it automatically disables any entity which is TL'd to it? I.e you dont need to deactivate/activate each object individually? 

Correct. You can Target link objects like say AAA guns, or ground artillery to a Fake Vehicle that would act as a Command Unit. You must have it as a linked entity and will set its parameters to Non Engageable and Non Vulnerable. You can target link tens of objects does not matter.

 

It is a similar logic that you have with a flight leader and wingmen. Give orders to the flight leader and these orders will also go to the wingmen.

 

Every action you will make on this Command Unit will immediately be transmitted to all the objects that are linked.

 

 

[IckyATLAS]

12 hours ago, Flashy said:

My current checkzone array uses something like 50 checkzones per side of the line in each "area" of 50km². If I am understanding you correctly, that would mean suddenly activating 100 checkzones (50 on each side of the line), or 50 "groups" of AA (300! objects at once). I'm pretty sure this would create a big performance hit in an already busy mission.

Agreed, but you can simplify. 100 active checkzones per se have really no major impact, I tested it yes true on a very powerful PC, nevertheless I could see no impact. Having 300 AAA units firing at the same time that is a little different story, because AAA  and artillery rounds ballistics will consume resources. This is why I was mentioning to make groups. The size of the groups have to be made so that it makes sense to activate and deactivate them in fact based on the visibility you may have from the plane. What is annoying is when you look from your plane and you have stuff that appears or disappears on your map. You may cut the thing into 5 groups covering each 10 km or ten groups covering 5 kilometers. And with the Fake Vehicle logic you can manage the group. A group would cover both sides of the line. It depends how wide the line is. If it is 10 km wide then better indeed split in groups for each side. The thing is to find the right balance. Let's say do not bother checkzone, what is more important is the number of active guns. I do not know how loaded the mission is already, and how powerful your rig is, so izt is up to you. 

 

[Flashy]

12 hours ago, JG4_Deciman said:

The difference between 'spawn / delete' and 'activate / deactivate' for objects is:

- with spawn / delete the object will loose any connections to further triggers... after it has despawned.

- with enable / disable all these connections will stay in place and come back to live after 'enable'

 

For mission creation you just have to set the object as 'enabled' by default (and then disable it after mission start)

So it is present with all connections and then deactivated (like deleted after having spawned)

and 'enable' does the same as 'spawn' later, but all the logic behind is still working

 

Deci

 

10 hours ago, IckyATLAS said:

Correct. You can Target link objects like say AAA guns, or ground artillery to a Fake Vehicle that would act as a Command Unit. You must have it as a linked entity and will set its parameters to Non Engageable and Non Vulnerable. You can target link tens of objects does not matter.

 

It is a similar logic that you have with a flight leader and wingmen. Give orders to the flight leader and these orders will also go to the wingmen.

 

Every action you will make on this Command Unit will immediately be transmitted to all the objects that are linked.

 

 

Thanks guys, I understand now what you mean. Unfortunately this wont work in this case because I am spawning objects (not activating them), but that is a useful trick for future missions. I hadnt realised that giving commands to only the lead ground unit would propagate the command to all the linked units, like it does for planes - I thought that was something unique to aircraft. But it actually makes perfect sense since we do that with vehicles when telling them to follow the leader on a road etc. 

Edited Tuesday at 07:29 AM by Flashy

[IckyATLAS]

14 hours ago, Flashy said:

because I am spawning objects (not activating them)

Frankly even with hundred of objects spawning and deleting does not make you gain a lot. A deactivated object will spare the resources. I tested and did not see much difference.

If you deactivate and reactivate then the object will restart once active from where he was when deactivated. This can be interesting in some scenarios where you want vehicles or even planes, trains whatever that they restart from where they where and continue. This means that you deactivate a moving object it will be in suspended animation in the cyberspace and when you reactivate it will be there and start again from where you have deactivated it. When you spawn and delete it will be at a predefined position when editing the mission and you loose the links. 

[JG4_Deciman]

11 hours ago, IckyATLAS said:

 

If you deactivate and reactivate then the object will restart once active from where he was when deactivated. This can be interesting in some scenarios where you want vehicles or even planes, trains whatever that they restart from where they where and continue. This means that you deactivate a moving object it will be in suspended animation in the cyberspace and when you reactivate it will be there and start again from where you have deactivated it. When you spawn and delete it will be at a predefined position when editing the mission and you loose the links. 

 

According to the problems I had a long time ago

when I tried to create a logic for trains

and I used spawn/despawn

 

And according to take into account what I have leared in the meantime

the only clue to 'solve' my former problems is: get rid of spawn/despawn and use activate/deactivate.

 

Those days my logic was working for a time, and then suddenly the trains reached a waypoint, turned 180 degrees and moved back to where they came from.

And with the knowledge I have now, there is only one reason... Despawning and Spawning them made them loose the formerly made connections and orders

 

Deci

[Flashy]

18 minutes ago, JG4_Deciman said:

Those days my logic was working for a time, and then suddenly the trains reached a waypoint, turned 180 degrees and moved back to where they came from.

And with the knowledge I have now, there is only one reason... Despawning and Spawning them made them loose the formerly made connections and orders

 

Deci

I had this issue recently, and I dont think it has to do with despawing and spawning, because I wasnt doing any of that. I think its just that trains have a limit to how far they can go or how many waypoints you can have in the chain. I had a mission where the train was meant to go from the top of the Normandy map to Dover, stopping at each station along the way. The logic was simple, and the waypoints were placed correctly, but after running for about 50km or so (I think when it reached Maidstone or Canterbury), the train would suddenly do a 180 and head off randomly in the other direction. I couldnt fix it by changing the waypoints, so I concluded that the train logic can only handle so many waypoints or distance before it gets confused...  either that or there is some bug in the rail network in those cities which means the train cant route through them, so tries to go round some other way... 

Edited Wednesday at 09:08 AM by Flashy

[IckyATLAS]

Regarding trains on the Kuban map I loved making them go through tunnels. You can have them entering the tunnel full speed, and you see the smoke of the locomotive entering the tunnel, but then you can have a train restart on the other side at the exit, but unfortunately it will start moving from still position. Like if he came out stopped and that starts again. Not too realistic, but you have no choice. To do this trick you must have two identical strains one on one side and the other on the other side of the tunnel.

Each has its own set of waypoints. And with a good waypoint positioning, speed and control and choreography it is very acceptable. In this case Deleting when entering and Spawning when coming out is necessary. Train once entered must be deleted, deactivation is no use here. On the other side you must spawn. In this way every time a train enters it continues. An you can have different type of trains entering and coming out. 

This editor allow many many complex behaviors, but you have to devote a tremendous amount of time to polish all the glitches until all works perfectly. 

It can only be though pet projects and a hobby.

 

Now things must be visible only when you can see them. If not then to spare processing power and avoid time dilation you must deactivate or delete according to the case. For fixed objects check-zone (entering and leaving). But for mobile  objects like tanks and vehicles, trains, planes you must use the proximity MCU. This one will react when you and the moving objects are within a certain distance. All of this will allow to make extremely complex and animated maps still keeping an acceptable load.

 

In the case of effects, on the Kuban map, factories with Chimneys do have smoke, white, black, grey it all depends. Chimneys are fixed objects. I have created a complete logic that covers all the places on the map about a dozen cities or places, that when you fly let's say under a certain distance these chimneys are active and smoke. When you are farther than a set distance they will not smoke anymore to spare resources.

 

This means that the whole map is covered of "actions, objects, events" that will depend on the Player plane. The player plane is the one thing that will make "events" happen as he flies on the map. The drawback is that he has a very very large number of object links that connect him to these events. Each event being activated through Triggers like  CheckZones, Proximity, Complex, Date Time,  and various other conditions.  However depending on the mission concept and design some events will not depend form the player as they need to evolve during the mission time in parallel to the Player.  By properly coding and structuring all this sky is the limit.

 

I remember the first time I designed a very complex mission where you had to carry out a mission in an environment of a war that was just happening independently of you. This means everything animated was active all the time. Example: you had ships battling, tanks battling, trains, planes bombing certain regions of the map, taking ofs here and there, landing, fighters here and there. It was a kind of animated Kuban map with things happening everywhere and you were a pilot in the middle of this with a mission. The result was a time dilation factor of 30%. Planes would fly at reduce speeds, trains run slow etc. etc. This was many many years ago. Maybe now the same thing would run acceptable on most powerful CPU's and GPU's. Anyway that time dilation factor has since become a parameter to check with every new mission.

 

To do that you program a small code that will activate a Timer at a given moment in your mission (choose a CPU/GPU intensive moments of your mission). Let the Timer run for one minute at least to have an acceptable average. You will flash for one second a text on the screen that says Start and after a minute or the time span you have decided and then flash Stop. When you see Start you start a stopwatch. When you see Stop you stop the stopwatch.

Compare the internal mission time against your real time. If you see that your mission time is longer say by 5 seconds or ten seconds then you have an important time dilation. 

If you do not see some real difference than you are perfect. A 1-2% time dilation is perfectly acceptable.

 

 

 

[Flashy]

11 minutes ago, IckyATLAS said:

This means that the whole map is covered of "actions, objects, events" that will depend on the Player plane. The player plane is the one thing that will make "events" happen as he flies on the map. The drawback is that he has a very very large number of object links that connect him to these events. Each event being activated through Triggers like  CheckZones, Proximity, Complex, Date Time,  and various other conditions.  However depending on the mission concept and design some events will not depend form the player as they need to evolve during the mission time in parallel to the Player.  By properly coding and structuring all this sky is the limit.

Yeah, this is the thing I really want to avoid with the stuff I design though. The mission logic I like to create should be as "player agnostic" as possible, and should be able to be imported into a mission without requiring you to link it to anything if you dont want to. It should just work, regardless of what side the player is flying for, what plane they are flying, where they take off from etc..  There is definitely a place for the more player-oriented logic, and sometimes you have to use it when there is no other way, but I enjoy the challenge of designing stuff that is much more general purpose (i.e works for SP and MP, doesnt care about or depend on player name, aircraft type, side, time of day etc). 

19 minutes ago, IckyATLAS said:

To do that you program a small code that will activate a Timer at a given moment in your mission (choose a CPU/GPU intensive moments of your mission). Let the Timer run for one minute at least to have an acceptable average. You will flash for one second a text on the screen that says Start and after a minute or the time span you have decided and then flash Stop. When you see Start you start a stopwatch. When you see Stop you stop the stopwatch.

Compare the internal mission time against your real time. If you see that your mission time is longer say by 5 seconds or ten seconds then you have an important time dilation. 

If you do not see some real difference than you are perfect. A 1-2% time dilation is perfectly acceptable.

This is a good idea, thanks! I suppose there is some human error (time it takes to react to the message and click the stopwatch), but its accurate enough to spot big time dialation problems. I will try this with this AA front line group and see if I am getting any human-detectable issues! 

[Flashy]

 

20 hours ago, IckyATLAS said:

To do that you program a small code that will activate a Timer at a given moment in your mission (choose a CPU/GPU intensive moments of your mission). Let the Timer run for one minute at least to have an acceptable average. You will flash for one second a text on the screen that says Start and after a minute or the time span you have decided and then flash Stop. When you see Start you start a stopwatch. When you see Stop you stop the stopwatch.

Compare the internal mission time against your real time. If you see that your mission time is longer say by 5 seconds or ten seconds then you have an important time dilation. 

If you do not see some real difference than you are perfect. A 1-2% time dilation is perfectly acceptable.

So, I tested this last night. Even with the entire western front (I think +-400 km of frontline!) AA logic running, and 25 planes flying low in various positions along the front to trigger the AA (which is pretty much the worst case scenario IMO), there was still no detectable time dilation! Woohoo! 🥳🎉 I am super happy that this logic actually seems to work well, and does so without any major performance penalty. 

 

I will clean everything up and release the rest of the groups this evening!

Edited yesterday at 07:21 AM by Flashy

[Flashy]

Groups for the entire front now released! See UPDATE on original post.  If you have a plane with enough fuel (and you enable invulnerability!) you can now literally fly low along the whole front from Ypres to past Nancy (which will take a while!), and you will take ground fire and AA for the entire distance! 

 

I will now work on adding improved versions of the groups which include fixed AA batteries which engage the player at any height in certain (random) locations on the front, and I want to add some logic for what happens at night along the front..