dorianR666

C++ with a bit of Lua

Still broken on latest OB. Is this bug being worked on? Its been half year now.

its an unknown game engine bug that happens semi-randomly. its difficult to reproduce and may be influenced by hw specifics. it appears to be related to spawning smoke during mission initialization. some investigation here: https://github.com/dcs-liberation/dcs_liberation/issues/103

jfc... this means dcs lost multiplayer support as far as im concerned.

+1

game crashes can NEVER be user errors.

The old behaviour was correct. Hopefully ED will revert the change.

Interesting, didnt know about that. Yeah the wingman was like 20 miles away from me when i gave the order, anchored over a waypoint.

i have seen this just now. told wingman to go home and somehow radio started speaking and case 2/3 menu appeared. it also sometimes assigns your wingman's "identity" to your radio menu, and whenever you speak with the carrier, youre reporting the wingmans number instead of your own. even if you abort and start over. not sure if its part of this or a separate bug.

thats an older bug. one of the changelogs long time ago said it was fixed - it wasnt.

the apache trailer showed improved flir (trees werent hot). maybe its the new flir tech that was supposed to come with hornet's atflir originally.

what do you mean? as far as i know, there are no missing buttons in either cockpit.

Correct, it is not finished. As razo+r posted above, this module is still in development.

its fixed since 2.7

+1 this is a pretty big bug

DCS's missile behaviour "template" provided by ED.

they are interconnected actually IIRC. when you rotate the plane in azimuth, rwr contacts rotate too according to whats fed to it by ins. the rwr refresh delay is too long and youd notice them not rotating smoothly otherwise (as it is currently, incorrectly, in dcs hornet). but what you say definitely sounds like a bug. jf-17 had the same exact bug actually, the rwr code was using the drifted ins own position instead of real in-game own position to compute azimuth to emitter. which results in azimuths being more off with more drift.

trackfiles work exactly like that if theyre recorded server side. so just run your mission through a dedicated server running on the same PC. that track will be 100% reliable but you wont be able to enter cockpit (and you wont see wing vapors).

VS: maximum range of detection, but cant tell you how far the targets are. RWS: can determine range of targets and can have full volume (azimuth range * bar count) TWS: like RWS but builds trackfiles (so you see where each target is flying), but has limited volume (so time between reflections from a target is small enough to maintain the trackfile). you can guide missiles against 2 targets simultanously in TWS. usecases should be obvious from description above: if you need to detect very far away targets, you use VS. if you are just scanning the airspace around (CAP mission), you use RWS to see maximum volume. if you know about a group of targets close to each other, you use TWS so you can attack 2.

yes actually. there can be only one shadow-casting light source in dcs, either moon or sun.

this is another bug btw. changing this variable should have no impact in this scenario.

whats interesting is that in DCS F-16 this works correctly (boresight moves with HMD even when blanked over HUD). the Hornet implementation is annoying in comparison.

ancient dcs core bug. gets reported every year. you must never fully stop on soil or youll get glued to it. static friction of soil is somehow set to some absurd amount by ed or something.

+1 the datapanel is unreadable at night

its an old issue