No promises nor timelines, but as this project will get serious, cockpit and 3D model, it might push me to create some dedicated avionics for it.

Cheers!

Hi,

These effects are the result of a bug and not intentional. In fact they were there since “Forever” but noticed just now because 4.36 is the first version where terrain is lit by lights dynamically.

A fix is already in place for the next version.

If you want to fix them in the meantime, it can be done by data edit:

1. Open your Data\Terrdata\ParticleSys.ini file with notepad or any other text editor

2. Search for “gp2000-fire” and find these lines:
   light.falloff[.25]=0
   light.falloff[1]=0
   Delete both and instead write:
   light.falloff[1]=0.0001

3. Do the same as step 2 for “gp1000-fire”.

Basically the idea is that a value of 0 is illegal, in next version it’ll be removed and code will be protected against letting such value flow (Sim will crash with a specific message in the log)

Hi,

BMS doesn’t support OpenXR yet, but it’ll come with the upcoming (Hopefully not too long now) 4.37 U4.
I confirm that VDXR does work great with BMS, so it’s just a wait until U4 is released to the public.

Cheers!

@white_fang said in AV8B+ Cockpit documentation:

@Topo-0

Hope we will have working FLIR in hud, 4.38+. But that’s far from here yet.

Kinda missing it all prev versions of BMS. I even added it to a center pylon since never succeeded to implement internal one - no other plane in BMS to copy from it… , as it should be. But it worked/working still.
Maybe an old-school (old fart) but FLIR have/had it’s own glory vs NVG’s.

Cheers

FLIR isn’t working in 4.37??

Yes @Manos1981 the Aggressors only exist in the 4.38 DB, I think we never pushed all the midway-ready models (i.e with old burner) to 4.37.

@SOBO-87 said in [4.37.3] [KTO] Smoke can be seen only when distance is below 20nm:

@I-Hawk

Possibly a config file setting that people could tune to fit their own performance needs? As an idea for the future I mean.

Yes can be done, but it’ll require some work.

Performance reasons… Although I think less relevant today, maybe we can extend will see.

set g_bDetailedFrameRate 0

This will replace the FPS detailed numbers text with a minimal yellow FPS value digits, similar to how the OpenXR TK used to do it.
If necessary you can also toggle on/off while in 3D by opening a chat window and typing:

.detailedfps

Very nice work!
You can define mirrors in the cockpit files IIRC. I don’t know the exact details but it’s about defining coordinates and stencils.

You can check how it’s done for the F-15C. Open this file:
\Data\Art\CkptArt\F-15C\3dCkpit.dat. Of course the 3D model need to have the mirrors placed accordingly (Although technically you can create a mirror anywhere )

// Central mirror.
mirror_group
mirror_stencil center { forward: 1.19 left: 0.0 up: 0.431 } scale { wide: 0.105 tall: 0.0705 } rotation_deg: 0.0 shape: STENCIL_SHAPE_CIRCLE num_triangles: 10;
mirror_stencil center { forward: 1.19 left: 0.13 up: 0.423 } scale { wide: 0.12 tall: 0.0675 } rotation_deg: 4.0 shape: STENCIL_SHAPE_SQUARE;
mirror_stencil center { forward: 1.19 left: 0.25 up: 0.414 } scale { wide: 0.04 tall: 0.0675 } rotation_deg: 0.0 shape: STENCIL_SHAPE_CIRCLE num_triangles: 20;
mirror_stencil center { forward: 1.19 right: 0.13 up: 0.420 } scale { wide: 0.12 tall: 0.0675 } rotation_deg: -5.5 shape: STENCIL_SHAPE_SQUARE;
mirror_stencil center { forward: 1.19 right: 0.25 up: 0.408 } scale { wide: 0.04 tall: 0.0675 } rotation_deg: 0.0 shape: STENCIL_SHAPE_CIRCLE num_triangles: 20;
mirror_group_end op { rotate{ pitch_deg: 15 } } op { scale { wide: 1.16 tall: 1.116 } } op { translate { forward: 0.545 up: 0.047 right: 0.001 } };
// left.
mirror_group stencils_from_group: 0
mirror_group_end op { scale { wide: 1.16 tall: 1.15 } } op { rotate { roll_deg: 44.5 } } op { rotate { pitch_deg: 16.0 } } op { translate { back: -0.435 left: 1.023 down: 0.366 } }
// right.
mirror_group stencils_from_group: 0
mirror_group_end op { scale { wide: 1.26 tall: 1.23 } } op { rotate { roll_deg: -42.5 } } op { rotate { pitch_deg: 16.57 } } op { translate { back: -0.435 right: 1.10 down: 0.367} }

There is some nice code in internal Dev version that draw only simple yellow colored FPS number instead of the full render, unfortunately this isn’t part of 4.37

@Mav-jp said in AI Aricrafts Go Outside of Runway During Takeoff:

AI is keeping runway alignment until roll out…once airborne it’s drifting…

I dont understand you comment §? what do you mean a wrong path ?

AI leade (and #3 unless instructed otherwise in the take off menu ) always chose the downwind side of the runway, as per real.

As you can see in the picture above, the #2 will take off from the upwind side…this is as per coded and as per real

I look at the above picture and what I see is an Aircraft that took off too much at the side of the runway. I mean, if I saw a human doing that or if a real Aircraft would do that, it would be considered dangerous/weird, at least to my opinion. However, I’m far from being an expert in this area, if all is OK and normal here then NP.

“wrong path” - That’s what I meant, probably ba choice of words.

Asking from code POV: Would it not be possible to force the AI to keep exact (more or less, same as human would) heading when taking off, so at least until he is rolling away, his heading should be 100% aligned with the runway.

A bit from me:
The main problem here is apparently: AI is taking-off in a bit wrong path
The derived problem is that the huge dust cloud is kicking and I agree that it’s maybe look weird/huge/thick/whatever

Regarding the dust, I’ll work on that to improve with the New Terrain, I guess we can use LandCover mapping to alter the effect a bit.