Rex854Warrior

Hello, I've been messing around with the trailer attach/detach tasks available for tractor vehicles. I was doing this since the new S-300 search radar needs one to move around as currently implemented. I'm not sure how long these features have been in the works but anyways I thought I'd make some bug reports to hopefully push it a bit since this would genuinely be nice to have. Trailer Attach : -So the trailer attach task is currently not usable without editing the mission file inside of the miz since there are no trailers available in the drop down (probably because no unit is reported as a trailer I guess, as otherwise I can hitch anything onto it). -It also does not seem to work if not done on mission start (an option of the task), the AI does not seem to know how to attach a trailer if asked to do so after spawning. -The trailer seems to rotate around a "hitch point" as a trailer should but is floating. Trailer Detach : -The trailer detach task works correctly it seems, but the trailer takes an odd orientation after being released and is floating. -There is no way to request a final heading for the tractor when unhitching (QoL feature but can be necessary in some scenarios). Here are two videos displaying these few issues + the .miz files used : 2023-12-10 15-21-21.mp4 2023-12-10 15-30-46.mp4 Here is also a screenshot of the line I added to the mission file of the .miz to make the feature "work" : Alright that's it, good luck ! Sincerely, Rex TestTrailerS300SR.miz TestTrailerS300TRmast.miz

Using quad views foveated renderring (Pimax Crystal, Pimax 8KX with a Droolon Pi 1 eye tracker, Varjo Aero etc.) , the spotting dots do not appear within the region that is "high resolution". They do however appear in the peripheral region so basically you look away, see the dots, then look towards them, they disappear. This is the layer (developped by @mbucchia) that is required for headsets others then the Varjo Aero which supports it within Varjo Base, it also has documentation regarding how this technique works : https://github.com/mbucchia/Quad-Views-Foveated https://github.com/mbucchia/Quad-Views-Foveated/wiki/What-is-Quad-Views-rendering%3F

Hello, Fairly straight forward, when using ALAS above 25k ft, the laser still fires and allows bombs to track. Attached is two tracks where I release 6 GBU-54 LJDAMs and one GBU-12 from above 25k ft (and stay there). The first track is using MLAS and as expected, the LJDAMs all reach their target and the GBU-12 misses. The second track is using ALAS where a majority of LJDAMs and the GBU-12 all land on the TPOD designated point (the LJDAMs that did not make it I suspect lost the laser or never got it, in any case, the GBU-12 tracked which is not supposed to work). MLAS_above25k.trkALAS_above25k.trk PS : I know this is not related, but it merits to be written, the JDAMs released in an extremely poor state (selection bugs, bombs disappearing from the SMART WPNS page, bombs going astray, no synchronisation in MC) and really is a stain in the track record for RAZBAM that has been improving for a while now. Anyhow, happy bug hunting. Sincerely, Rex

My findings for this were that designating enough times allows for synchronisation. Eventually, if you are close enough to the target, you can switch to point track which is very reliable. Then and only then you may switch to CDES since CDES seems to make things worse when moving the camera manually. However, any kind of TPOD movement from the WSO while designating + relative movement between the target and the aircraft, throws off the TPOD, sometimes to a point where the WSO can't compensate. Which is why CDES seems to not work well. This very much seems related to the way motion compensation is done between WSO and pilot. Considering that the TPOD drifts on it's own I can't imagine this being easy to do. This remains extremely unreliable and makes multicrew a lot less interesting since the pilot has to be ready to step in to get on target when closing in if it's not already the case. And has to confirm that we're on target anyways.

Thank you for your courtesy, and taking the time to be unhelpful. I did not look in the whole forum and this is a pretty weird place for this report. This is also not wasted e-ink as the original thread is lacking elements to reproduce the bug easily. Anyways, thank you Flappie and thank you Bignewy, sorry for the bother.

Hello, It is possible to see IR beams/spots to the naked eye (no NVGs required) since the 2.9 update. The beam itself appears in a faint white color from the emitter to the target while the spot is a very visible white light on target. Attached is a mission to reproduce the issue, a very simple script (also attached) takes care of creating an lR spot between a drone (emitter) and a moving ground vehicule (target) every 5 seconds. So in the end you can retrace the entire path of the vehicule with the white dots near the ground and can see a large white plume composed of each beam descending from the drone towards the ground. NOTE : the beams are much easier to see against a dark background such as the dark blue sky above the drone. Sincerely, Rex IR_laser.lua Laser_Test.miz 2023-10-27_21-51-59.mp4

Hello, The C-RAM is always firing behind targets that have a high line of sight rate making it unreliable at dealing with those, some tuning seems required as otherwise it's perfectly capable of reaching these types of munitions. By capable I mean that it sees, tracks and has plenty of time to fire a long salvo. Attached is a track of a C-RAM vs HARMs. Some get intercepted, some go through but all are tracked and shot at in time it's just that the HARMs fired closer have more speed and so more LOS rate upon reaching the target. Hopefully this can be solved. CRAMfiringBehind.trk

Hello, Testing the C-RAM, I found that it had an extremely hard time shooting down multiple incoming munitions simply because if it fails to do so for one, it will track it all the way to the ground, then cannot turn it's turret fast enough to deal with what follows so it keeps trying to track targets that it has no way of intercepting because they are too close to the ground. Attached is a track with the specific scenario of a rocket barage coming at a C-RAM. This behavior is of course extremely problematic here since if it fails to shoot down one rocket, it will intercept none of the ones that follow. The same happens with GBU-12s dropped in close succession, if it fails to intercept one it will take a couple seconds to get on the second and shoot it down which is usually too late. Groups of C-RAMs also cooperate very badly to handle such large volume situations, they tend to all target the same thing so adding 10 C-RAMs basically changes nothing to the success rate. Hopefully this can be improved/fixed. CRAMbadtgtpriority.trk

Yep it has been fixed for a bit, sorry I didn't confirm earlier. Checked again and it's working indeed.

Rex Mirage F1EE

I believe it'll not change anything, a new aircraft has to be taken. I should test it again whenever possible but that is what used to happen. Possibly a bug.

If you start the gyro platform alignement before having ground power or AC power, it'll be broken (shows about 20° left roll) until a new aircraft is taken. I think that's what the OP was referring to.

No change with the latest update

I wouldn't be so sure, that rounded nose is awful for drag, it's an order of magnitude more draggy than a shaped ogiva in the supersonic regime. And it should count for roughly half of the overall drag generated by the missile in supersonic with a shaped ogiva so yeah... It's bad. It makes sense that they'd make it fly low supersonic, it's just impossible to go any faster without massively increasing the diameter/length and drag of the missile to house more propellant.

Thank you for your input, just to be clear I have no idea how this air intake/engine combo should behave exactly but this is ciritical terriroty for fighter aircraft, I should imagine that my collegues from way back then made sure it isn't a 50/50 chance of your engine dying when you go there. As for the behavior in DCS, well I managed to recover two-three compressor stalls in DCS doing what I said (didn't test that much further as I pretty much learned my lesson from dying to compressor stalls), otherwise I went for the relight however always using the starter but the "start" process is not the same for an in flight relight so that procedure is just wrong, I'll have to test without. It's due to the fact that adding spools allows for the associated compressor stages to run at their most efficient load which does indeed bring stalling territory closer. On single spool turbojets the turbine stages are the limiting factor but a stall is not impossible nor is it necessarily more difficult to achieve (do not forget the air intake here which plays a role in managing the incoming air, wether that is well or poorly) but in general, there should be more room for design problems/constraints and/or pilot errors. As for the F-35 I'm afraid it's mostly an air intake problem, the boundary layer deflection bump is seriously cool in terms of aerodynamics but also has it's drawbacks. And cutting the intake section to a minimum was probably a necessity to ensure stealth so it's really a match made in heaven to get engine problems. A lot of research, modelling and testing happened in the same time which brought a better understanding of the phenomenon and ways to predict/negate the effects of such an event. Take a look at the engines on the F-14A, the TF-30s, earlier two spool turbofan, not particularily stable .