TEMPEST.114

Thanks to @Chump You have to *ALWAYS* ADD 180 to this figure - it's in degrees. /facepalm. Totally obvious. /smh

Specifically: function onShowRadioMenu(a_h) end function onShowMessage(a_text, a_duration) end function onTriggerMessage(message, duration, clearView) end function onRadioMessage(message, duration) end function onRadioCommand(command_message) end And to that end - clearly show/link/explain what 'a_h' is and how that can relate to a specific PLAYER/UNIT. There is ZERO reason why these should not be available inside the mission environment - esp as it would allow mission designers to have greater interaction between the mission/story and individual players.

@funkyfranky Can we please get confirmation bird strikes only affect FC3 aircraft! This is kind of important!

'False Expectation'? How about it's because of crummy naming conventions? If it's groundspeed it should be 'getGroundspeed()' !!!!! I don't know about the rest of the people struggling with this unsupported API, but I'm not a mind reader. If we can't rely on the name to describe what it does in lieu of proper and up-to-date documentation, the ED need to be better at naming things so they describe themselves properly. As it stands, I'd already worked out if I vector subtract the wind from it I get an approximate value. But come on...

@SUNTSAG I believe the rendering of this is backwards. The ILS 'fan' arrow and the freq/Course for the localiser should be visible IN-GAME on the F-10 map. It's not. But for some crazy and unusable (from a pilots pov) it's visible ONLY in the mission editor. Please, as a matter for urgency, can you flip this around so it's correct? Thanks.

Anderson AFB. In game 4 freqs are provided for radios for the field. In code, there is only one.

When you're flying you have no way to see or find the radial for an ILS for a field and the Aerodrome Data doesn't show it either.

So I'm looking at beacons.lua for each terrain. In there is a table like this: { display_name = ('Batumi'); beaconId = 'airfield22_1'; type = BEACON_TYPE_ILS_GLIDESLOPE; callsign = 'ILU'; frequency = 110300000.000000; position = { -355396.812500, 10.044037, 616600.500000 }; direction = -54.415131; positionGeo = { latitude = 41.613985, longitude = 41.591406 }; sceneObjects = {'t:318309567'}; chartOffsetX = 120.000000; }; If you make the normally correct assumption that directions in the backend are in radians, then converting '-54.415131' to degrees gives: -3117.75734796 So, that's clearly wrong, but if we do 'degrees %360' that gives: 122.24265204 Which is wrong based on the included plates and the Mission Editor map - and the variation is somewhere around 6 or 7 so even then that doesn't resolve the issue:

I have it all working now - thanks to you.

e.g. if I double click over a single word, it will also select characters AFTER the word. This seems minor but it's a real pita.

Thanks for that. It's a huge help.

According to Suntsag et al, that's what 'RANDOM' condition is now. The ACTION will DEFINIETLY HAPPEN, it's just DELAYED by the size of the RANDOM number provided. /facepalm.

that option is the most retarded addition i've ever seen. What's the point of a mission designer crafting an experience if the players can just disable everything?! Dumbing down DCS is always a mistake and a poor business decision. REALLY?! Where is that stated? Can we get confirmation @NineLine?

Trying to figure out where the mouse pointer is in relation to the tiny dialog by waving it about until you by chance get it to move over the on-screen sub window is stupid and horribly slow and inefficient. Also allow multi-crew YES/NO options to be bindable.

I'm having this in OB. It is working perfectly at the start of my mission / play session, at some point (regardless of aircraft I'm flying) THE RADIO MENU stops responding to ANYTHING other than the physical keyboard. If I bring up the SETTINGS / CONTROLS then the HOTAS is still triggering the event and the buttons are being detected by DCS, but DCS will not show or transmit on those button presses. This ***IS*** DCS.

What is the point of having a community when you don’t listen to it? Saying this is ‘no bug’ is just wrong.

For the life of me I can't understand the obfuscation and 'logic' in these two designs. In the airbase.getDesc() we have: ['life'] = 3600, ['attributes'] = { ['Airfields'] = true }, ['_origin'] = '', ['category'] = 0, ['typeName'] = 'Anapa-Vityazevo', ['displayName'] = 'Anapa-Vityazevo' Yet in Radio.lua we have: { radioId = 'airfield12_0'; role = {"ground", "tower", "approach"}; callsign = {{["common"] = {_("Anapa"), "Anapa"}}}; frequency = {[HF] = {MODULATIONTYPE_AM, 3750000.000000}, [UHF] = {MODULATIONTYPE_AM, 250000000.000000}, [VHF_HI] = {MODULATIONTYPE_AM, 121000000.000000}, [VHF_LOW] = {MODULATIONTYPE_AM, 38400000.000000}}; sceneObjects = {'t:136022192'}; }; The name is different, there is no common 'id' between them... no idea what 't:136022192' is... so how does one marry the two up without having to manually type a table of key / value pairs linking them?! Is there some missing 'bridge' file and why is this 'architecture' so overly complicated?

Are you going to tag this thread as 'reported' then?

If this is GROUNDSPEED (which is wrong), then where is the figure on the AWACS display coming from? Because THAT'S what getVelocity() should be reporting. BTW is would be REALLY NICE to actually have a GROUNDSPEED we can pull from the scripting engine.

Then it's a bug - because Velocity is NOT groundspeed.

UPDATE: Same units, same script, same everything else EXCEPT A DIFFERENT MAP (Caucasus) and this time it works perfectly... WTH is going on? What am I missing? getVelocityBug_Caucasus.miz

Here is a copy of the embedded script: function ShowTankerVelocity() local function Show() local velocityVec3 = Group.getByName("KC135MPRS"):getUnit(1):getVelocity() local velocity = ( velocityVec3.x ^ 2 + velocityVec3.y ^ 2 + velocityVec3.z ^ 2 ) ^ 0.5 local knots = velocity * 1.943844 local text = string.format("%dkts", knots) trigger.action.outTextForCoalition(2, text, 1, true) return timer.getTime() + 1 end timer.scheduleFunction(Show, nil, timer.getTime() + 0.1) end ShowTankerVelocity() This is called after 10 seconds by a trigger in the ME. The tanker reports on the F10 map on the grey/blue box that it's stable at 350 knots ( @SUNTSAG note the label error - MPH is incorrect, but also giving the same as KNOTS - and the rounding errors.) However, the speed reported by 'getVelocity()' changes every frame. Such that it's bouncing between 295 and 415. Attached is the miz, the script and a link to a YT video showing the error. https://www.youtube.com/watch?v=1PwQ8FngCHs This should be returning a stable 350 - it's not. getVelocityBug.miz getVelocityScript.lua

HOW IS THE DAMN FOOTWELL SO OVERSATURATED AS THE SIDE OF THE COCKPIT?! If you're going to gaslight about shadows and sun, then don't try and fob someone off by saying something that should still be in somewhat dark - being just as over-blown white as the sidewall much higher up. Maybe if Stevie Wonder stops saying everything is fine and someone who can actually see takes a look...

Not remotely helpful.

forced to use the keyboard, despite the hotas correctly triggering the binding in 'settings / controls'. Doesn't matter on aircraft (happens on everything). Never fixes without a reboot.