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 .

So it's not entirely impossible that a compressor stall would result in such behavior, the recirculating air nested within the stalled compressor stage (the air is in such a state because of the stall) can contaminate perfectly good incoming air causing the phenomenon to self sustain. Now it's in theory and frankly I'm curious as to why it's not flushed out almost immediatly or at least why it's so hard to get moving after going into the right parameters which would be to unload the compressors by going to idle and playing with the aircraft's speed (accelerating if my memory is correct). Bleeding this polluted airflow is done on some air intake designs I believe. This does work in the Mirage F1 currently, you'll get a compressor stall when pulling extreme maneuvers and it seems impossible to get out of it but diving and getting sufficient airspeed does get rid of the problem after some time in those parameters with the throttle at idle.

I am well aware, I am pointing out that if this MOOSE feature works in SP but not in MP, then it points to a synchronisation problem (an ED problem). This is a very recurrent issue. There are no fundamental differences in scripting for a single player mission and multiplayer for this case. I am however happy to be proven wrong. Unfortunately I lack the time to create such a mission on top of not knowing exactly what the OP is doing. I hope the OP can help out here and I'll see if I can make something later on.

Simplest way to verify is to run the mission in singleplayer and see if the callsigns change as intended. That would be what the server sees and would indicate a synchronisation issue.

Hello, The "HQ7_LN_EO" unit otherwise known as the Electro-Optic version of the HQ7 launcher does not have the "vehicle" property like every other ground unit that is a vehicle in DCS, please add it for consistency and as to not cause issues with scripts. Thanks !

Any update on this ?

Bumping this

I'm fairly sure dogfighting modes do not reset elevation difference/tilt/whatever they actually do as it's extremely poorly worded in the manual thanks to google translate. In my testing, locks were impossible if the elevation control was not near or at +00. Something is seriously wrong.

Indeed it is very annoying, it doesn't even seem like the disperse under fire option works too well, which could sort of help. It's a crappy solution to a problem that could easily be solved via ME options and scripting functions (please sync them in MP btw)

So I'll speak for our mission but this does seem like a related issue, we spawn AFACs on demand via markers. They're all clones from a group in the ME and this clone has a specific callsign (take "Dodge 1-1" as an example) which we change in the group data before spawning the clone. This poses sync issues in MP, all the clients connected prior to the AFAC spawning will see in the JTAC menu the cloned AFAC with the original callsign ("Dodge 1-1"), not the modified one. Using setCallsign however seemed to fix this issue, you shouldn't have to but it does sync up other players in our case. Players logged in after the AFAC spawn, regardless of a setCallsign call or not, do not have this issue. It does not occur in SP/server side either with or without the setCallsign call.

Hello, When spawning a ground unit, static, boat etc. on a multiplayer server via the game's scripting engine, the "HiddenOnMFD" setting (or in this case table value since this is in scripting and not the ME) for the spawned group will not work for the clients of a server. They will see the SAM, static, etc. on their MFDs regardless of this setting set in the code. This issue is very much similar to the one where invisible FARPs spawned dynamically used to not be synchronised for clients but would appear just fine for the server. Tracks for the server side and the client side are attached, although since you'll be running these in "single player" it is unlikely they'll show anything abnormal. The mission (with the scripts built in) is attached and will allow you to run tests in MP, I recommend the hot Hornet slots on Gudauta (Maykop being the closest point to monitor) : Mission : https://drive.google.com/file/d/1ryZsdG7pdASz5yuzu3D8sAPnzsGJJH16/view?usp=sharing Server side track : https://drive.google.com/file/d/1n2cuTugesY4oUSW-GYSJOKkAYY1K4WMM/view?usp=sharing Client side track : https://drive.google.com/file/d/1LQNSyfUJue3eLVY9jflJnLaCzT5Ipw4Q/view?usp=sharing In this mission, SAM sites protecting airfields are spawned through scripting at t=1 second (we have very specific reasons for not doing it through the editor directly and regardless we tried it with dynamically spawned units and the behavior was strictly identical). These SAMs are supposed to not be visible on MFD and that is the behavior observed for the server side, however clients see all of them. This is an important issue for multiple reasons, when the mission designer/scripter wants realism it's particularily annoying to have defended convoys etc. show up perfectly on MFDs, reducing most search efforts to 0 for the large majority of aircrafts flown in modern era missions. Even defences showing up on the Apache's TSD is annoying since you don't really risk flying by mistake over any threats if you're careless. Lastly, with the upcoming dynamic campaign I can't imagine this could be left untouched if any sort of difficulty levels are implemented as I imagine turning off MFD visibility for SAMs would be a no brainer to make things harder/force people to do recon in the multiplayer campaign. Anyways, hopefully this is an easy fix. Thanks in advance, Rex PS : the option also seems to do nothing for aircrafts, through the ME or scripting for both clients and server.