TEMPEST.114

This is frustrating... local velocityInMPS = GetVectorMagnitude(magnitude) local knots = MpsToKnots(velocityInMPS) where function MpsToKnots(mps) return mps * 1.94384449 end function GetVectorMagnitude(vec) return (vec.x^2 + vec.y^2 + vec.z^2)^0.5 end For this: Google says: But the function returns 363kts What's going on?!

I was just trying to work out why my velocity isn't working correctly - that I thought was in metres per second, but when looked at via F10 with Combined Arms is reporting as MILES PER HOUR and then in the aircraft's ADVANCED WAYPOINT ACTIONS it's IN KNOTS - but the same numerical number!?!? Can't we just pick one and stick with it?! This is crazy. This is the same aircraft, with each screen grab taken within seconds of each other, with the aircraft at a stable altitude and speed (allegedly) What the heck is going on here?

I'm trying to change the speed by 20kts Here's the maths of what's happening in the script 2023-02-09 16:54:31.579 INFO (Main): magnitdue 208.744693 2023-02-09 16:54:31.579 INFO (Main): knots 405.767222 2023-02-09 16:54:31.579 INFO (Main): newSpeed 425.767222 deltaSpeed 20.000000 2023-02-09 16:54:31.579 INFO (Main): newSpeedInMPS 219.033582 (magnitude is the MPS of the aircraft before any changes) i.e. getVelocity() I convert to knots, make the delta change and reconvert back to MPS before I issue the setSpeed command. These numbers were used on an F18 at 18000ft at 350kts. After the change, it's speed went to 425kts. What the hell is going on? Is this a bug? Here's the code: local velocityInMPS = selectedAircraft.unit:getVelocity() local magnitude = GetVectorMagnitude(velocityInMPS) local knots = MpsToKnots(magnitude) local newSpeed = knots + deltaSpeed local newSpeedInMPS = KnotsToMPS(newSpeed) selectedAircraft.group:getController():setSpeed(newSpeedInMPS, true)

Look how there is little subtlety in the lower right sidewall, how blown out the deck is, and under the stby compass. This is on a monitor where other games and images look fine.

Sigh... it's OBVIOUSLY a VR headset, not a monitor... And I can lower the gamma in the main settings to 1. and the F16 side panels are still glowing white. This CHANGED with 2.8. It's not right.

Sigh... it's OBVIOUSLY a VR headset, not a monitor... And I can lower the gamma in the main settings to 1. and the F16 side panels are still glowing white. This CHANGED with 2.8. It's not right.

As usual... crickets...

When you have a lot of nested commands, making a user go back to the root after picking a choice that will then impact further sub menu displays is a horrible handicap to give players in a combat game. If it's just a single command with no dependencies, that what you have works, but if you're e.g. giving players the choice to move another unit x distance from their current pos, and then in y direction, you either have to duplicate x times the y commands to cover each one (stupid and time wasting in script) or you just allow them to pick up from where they left off in the menu system with an optional Boolean on the command in the script.

This should have been a radial menu head tracked like the Jester UI for the last 5 years. ED's too slow on this. The crippling limitations of the F10 menu is handicapping mission designers.

@some1 Thank you! That's really helpful.

Thank you for your help, but then my point still stands. We shouldn't have to do that to get access to this data.

as title says; as an irl pilot, I've never come across that type of beacon.

Wait, doesn't that mean I have to de-sanitise DCS to get access to dofile?

We can't get access to this data from the scripting engine because it's outside in other files. Yet the game 'does' know about it all. It just needs exposing to the lua scripting engine. Thanks

Fading to grey happens when the hmd loses positional data. You can stop with in the windows mixed reality settings - there is a toggle to stop that. also ensure your area is well lit.

It's free to include and would mean we can change the voice and make units talk dynamically to what players are doing.

Picture doesn't work and I don't believe for one second that the entire oval sheet of glass is almost an opaque green.

This is related to AI Pathing. ED knows it's broken. It's on the back burner awaiting to be fixed. Has been for years. There are countless bugs posted about this. There is no way around it right now. AI Pathing Land/Sea/Infantry and Air are borked.

Then fly War Thunder.

As it stands you have to pre-populate your submenus, but if you want to populate them with 'live' information, you need to know when that sub menu has been selected to update your sub menu commands. As this doesn't allow for an OPTIONAL function call, it would be very useful if it did. PLUS work on UNITS rather than GROUPS.

WTF?! Really?!?!

Ko-Fi is good and doesn't charge you fees.

Everything is too too bright now, and totally washed out. MFD's on the Apache in daylight are so washed out, it's easier to read them on night setting. The HUD doesn't stand out against the sky anymore clearly. The over-zealousness of the glass reflections are already 'bugged' but reflections of the sun glare come through the aircraft / apache when they should have been stopped by the actual airframe, and render the dividing glass or canopy so glaring and opaque you can't see anything. Everything is too washed out and too bright. This didn't happen before the new lighting came in. Can we get confirmation this is still WIP and will be addressed? Because it's awful right now. The reflections on the gauges are so opaque that you can't read the gauges! Look at the AI, DG and others. It's insane the amount of opacity and reflections in them. Look at how washed out the sky and ground are.

So this is definitely wrong then? (from original link) constants: coalition.side enumerator values 0 = Neutral 1 = Red 2 = Blue

Has anyone worked out how to do this? I don't want to include it in my project, but I wanted to tell Visual Studio Code to use it to filter out the autocomplete / intellisense suggestions.