[Teaser] Working radar guidance

[kraut1]

On 3/18/2025 at 12:22 PM, AEthelraedUnraed said:

1. Using the Win+2 and Win+3 key combinations, the user selects a desired frequency.
2. If either the user closes the widget using Win+1 or the user hasn't changed the frequency for 1s, the FREQ_SELECTED timer at the top is triggered. This disables all beacons. Note that this automatically functions as an "off" switch if an "empty" frequency is selected.
3. After a delay of 250ms, the timer corresponding to the selected frequency is triggered. In case of the mentioned frequencies, this in turn activates the corresponding beacon.

Attached are the required widgets, as well as an example mission. I also updated the KeyListener widget because of a bug that made it fail when used together with some other widgets.
SwitchableBeacons.zip

Hi @AEthelraedUnraed

For me it is okay, but for your information:

-if you end the mission with external view and the FuG10 is visible IL-2GB crashs (vanishes)

-if the FuG10 is active / working but hidden ending the mission with external view is possible.

-if the plane flys, has landed, if the engines are running or not seems not have any influence.

As already mentioned for me it's acceptable.

Again thanks very much for the radio!

[AEthelraedUnraed]

10 hours ago, Stonehouse said:

Not sure what epl or efx file equates to the light you are using but for what it is worth, in data\LuaScripts\WorldObjects\mapemitters and data\LuaScripts\WorldObjects\emitters there are text files which are used to control some of the effects that you can place with the editor. Within these you can specify image attributes as you can see below. This is an example from the Dynamic effects plus units mod. IA_ALWAYSVISIBLE does what you would expect although what you see is based on the LOD set up for the object. IE if you are further away than the object would normally render you see the most distant LOD version (as I understand things based on limited experience). 

 

FYI there was an old system used as well and basically the image attr was a number which you arrived at by adding the numbers shown after the attributes shown below. So if you wanted IA_NOMINZ and IA_ALWAYSVISIBLE the image attr was 136 (128+8). I believe this has been almost completely replaced by the new system of just using a list of attributes required as shown in the example below. Which makes a lot of sense as it is vastly easier for people in the dev team to maintain and understand at a glance.

 

I use my own .epl and .txt files; modified versions of I believe the hangarpointlight effect. They do have IA_ALWAYSVISIBLE set, and I've played around with some of the other attributes but so far I haven't been able to get it to work.

 

To illustrate the problem, this is how it's supposed to look, and how it does look if less than 32 lights are shown:

 

But if I slightly move the camera so that there's one additional light in view:

 

1 hour ago, kraut1 said:

Hi @AEthelraedUnraed

For me it is okay, but for your information:

-if you end the mission with external view and the FuG10 is visible IL-2GB crashs (vanishes)

-if the FuG10 is active / working but hidden ending the mission with external view is possible.

-if the plane flys, has landed, if the engines are running or not seems not have any influence.

As already mentioned for me it's acceptable.

Again thanks very much for the radio!

Thanks for the report! I've confirmed the issue; I'll investigate.

Edited March 25 by AEthelraedUnraed

[Regingrave-]

14 часов назад, AEthelraedUnraed сказал:

Is there anybody (perhaps @Regingrave knows at least some pointers?) who knows if:

- Is there a way to increase the permitted amount of effects in e.g. startup.cfg?

- Is there anything I can set in the .epl file or .txt file to keep the effect always visible?

- If not, is there anything I can do to at least keep at least the most important lights fully visible? I.e. have some lights disappear before the other ones.

No, map effect system just isn't designed and supposed to be used that way.
In Korea separate and more optimized system is designed to be used for cities and airfield lights.

[AEthelraedUnraed]

3 hours ago, Regingrave said:

No, map effect system just isn't designed and supposed to be used that way.

Well, there's a difference between "supposed to be used" and "possible to be used"

 

Anyhow, thanks for the reply. I was hoping that there was some kind of graphics setting that'd regulate this, but if that's not the case I'll have to come up with an alternative.

 

For now I'll stick with this:

Only the lights at the start and end of the runway are the "proper" ones; the ones in the center only have the ground lit up and don't have the glare graphics. That makes them harder to spot from a distance, as can already be seen in this screenshot (the lights between the doubled white light and the red lights in the distance). Still, I think it's an acceptable compromise.

 

From a distance, with "Visual Lorenz" visible in the foreground:

 

Edited March 25 by AEthelraedUnraed

[AEthelraedUnraed]

Alright, given that I'm stuck with a max amount of 32 "real" lights, I've come up with one other light placement algorithm and I'd like your input. Please tell me which you like best, or let me know if you can think of another option. For both options, I show a general close-up-ish view as you might see during approach, and a distant view from the side.

 

First the historical view (photoshopped):

 

Option 1:

Pros:

- Bright lights along the entire runway.

Cons:

- Lights might be up to 2.5 times as far apart as historically correct (worst case; more typical is around 1.75 times the distance).

- Dim perimeter lights (the red triangles).

 

Option 2:

Pros:

- Historical distance between lights (~50m).

- Bright perimeter lights (the red triangles).

Cons:

- Dim lights along the middle section of the runway; only the start and end are visible from a distance.

 

Let me know which of the two you prefer. For lack of a better system, vote 😄 (Haha) if you prefer option 1 or 😕 (Confused) if you prefer option 2.

Edited March 26 by AEthelraedUnraed

[Stonehouse]

Based on your pics and purely considering what is needed to land, I think you could probably get by with an alternative option1 with larger spacing between lights if that allows the perimeter lights to be brighter. Particularly the ones marking the end of the runway.

[kraut1]

Option 1 is from my point of view better.

[AEthelraedUnraed]

That's two votes for option 1, one for option 2. Option 1 it is, for now. I also took the time to implement the "Visual Lorenz" system, based on what little information I could find on it.

 

Approaching Deelen airbase:

 

Edited March 30 by AEthelraedUnraed

[AEthelraedUnraed]

I think I get the hang of this. Testing new lighting effects for one of the major turning points in the struggle between Bomber Command and the German Nachtjäger.

Edited March 31 by AEthelraedUnraed

[kraut1]

Hi @AEthelraedUnraed,

I have released my Germany4345 EMG Settings, a Mod (with your the FuG-10 Flash Script), and my adapted Radio / Radio Navigation Group.

-For Daylight Missions.

Thank very much again for the FuG-10!

 

[Nickkyboy99]

On 2/21/2025 at 8:02 PM, AEthelraedUnraed said:

The second proof of concept is complete: a working FuG 202 board radar!

 

This time, it not only features intercom messages but also a GUI. Although for reasons beyond my control, not all inputs work when the GUI is active. Flight controls work, but the throttle doesn't and neither does mouse or keyboard input. So if you want to do something there, you have to hide the GUI first. Or not show it in the first place, since the intercom messages are good enough to track the target without using the GUI. The other restrictions mentioned in my first post also still apply.

 

Left tube shows distance, middle tube shows azimuth (target is in the direction of the larger lobe), right tube shows altitude (same).

 

The angular response of the radar is based on the actual response of the FuG 202, and the terminology used is period-correct as far as I could find out.

 

 

A small update on the progress of the earlier ground radar guidance; I was able to solve most remaining issues, with the exception of a rarely occurring CTD when exiting the mission. But this seemed to be at least partly related to wrong mission scripting.

Is the mod available for download? 

[AEthelraedUnraed]

3 hours ago, Nickkyboy99 said:

Is the mod available for download? 

Not even close

 

Actually, I've recently been working on the Himmelbett procedure code (ground controller based). I've had to rewrite the code from the bottom up because of a conceptual limitation in the old code. I'm now satisfied that my new code is:

- above all, stable,

- actually works,

- is based on historical methods.

 

However, rewriting it has taken me quite a long while. This part of the code is honestly very close to release (I "just" need to rewrite my sound system to be essentially a functional duplicate of the in-place radio system). But apart from that, it's working fine and the first few Himmelbett radar interceptions are a fact, even without actual sound

[Jeroen83]

Any news on this? Can’t wait to fly some enhanced night missions…

[AEthelraedUnraed]

On 6/29/2025 at 11:05 PM, Jeroen83 said:

Any news on this? Can’t wait to fly some enhanced night missions…

Alright, it's time for an update.

 

My code behaved somewhat unpredictably in some edge cases. I've satisfactorily solved this issue by running a Newton-based iterative solver (accurate but too slow and unreliable to use in-game) on the entire range of relative angles, distances and velocities between interceptor and target, and then did a 4th order polynomial 4D least squares fit. Through this process, I was able to obtain a continuous (and mostly-convex) function with a worst case deviation of around 10 degrees from the target course.

 

...in laymen's terms, I was able to all but eliminate faulty behaviour by a bunch of fancy math. However, during testing, another issue came up, namely which way to turn. If you're flying 50 degrees and you get an order to turn to 70 degrees, no problem. But if you're flying 50 degrees and you're told to turn to 220 degrees, do you turn left or right? The commands can follow each other pretty rapidly, so no time to do much mental arithmetic. This went wrong too often, and if it did, you'd be miles away from the target again.

 

I therefore decided it's in some cases necessary to announce the direction of the turn, e.g. "Antreten Lisa 220". Doing so would triple the amount of radio calls (left, right, none) which would result in way more audio files than I was willing to use. I therefore decided to come up with a different audio system; one that's basically modular as the in-game system is, where you construct phrases out of shorter files. This is basically done now, so I just need to test and finetune it.

 

Once that's done, I need to do some more testing with the entire system, at which point I think I'll release the first half of my campaign.

Edited July 8 by AEthelraedUnraed

[IckyATLAS]

5 hours ago, AEthelraedUnraed said:

Alright, it's time for an update.

 

My code behaved somewhat unpredictably in some edge cases. I've satisfactorily solved this issue by running a Newton-based iterative solver (accurate but too slow and unreliable to use in-game) on the entire range of relative angles, distances and velocities between interceptor and target, and then did a 4th order polynomial 4D least squares fit. Through this process, I was able to obtain a continuous (and mostly-convex) function with a worst case deviation of around 10 degrees from the target course.

 

...in laymen's terms, I was able to all but eliminate faulty behaviour by a bunch of fancy math. However, during testing, another issue came up, namely which way to turn. If you're flying 50 degrees and you get an order to turn to 70 degrees, no problem. But if you're flying 50 degrees and you're told to turn to 220 degrees, do you turn left or right? The commands can follow each other pretty rapidly, so no time to do much mental arithmetic. This went wrong too often, and if it did, you'd be miles away from the target again.

 

I therefore decided it's in some cases necessary to announce the direction of the turn, e.g. "Antreten Lisa 220". Doing so would triple the amount of radio calls (left, right, none) which would result in way more audio files than I was willing to use. I therefore decided to come up with a different audio system; one that's basically modular as the in-game system is, where you construct phrases out of shorter files. This is basically done now, so I just need to test and finetune it.

 

Once that's done, I need to do some more testing with the entire system, at which point I think I'll release the first half of my campaign.

Wow, a truly professional system. I suppose we need to buy a license for it to use it 😂

[hakman]

hello!
do you have any ETA when the mod will be avaliable to download? even as a pre alpha?
it looks really cool! good luck on further work and Im more then happy to see how the mod will develop