TEMPEST.114

Is this related to certain events not firing in MP environments? If so, is this ever going to be addressed? Or is this a newly found issue?

All the other airfields in radio.lua have frequencies listed and AFAIK they work correctly. @Exorcet Said that those hard baked into the M.E. are wrong. So how come you're now saying that the radio.lua is unreliable?! What is this insanity of an architecture doing? If the whole point of radio.lua and beacon.lua are to hold the data about the radio freqs and beacon data on the map, then why the heck is the game engine creating stuff on the fly?! And if it's creating stuff on the fly, how do you get at it from the scripting engine?! Then as Exorcet said, there are *incorrect* freqs hard baked into the M.E. That's THREE places and none are fully accurate or complete. I know the engine is decades old, but surely there are engineering and tech leads to un-spaghettify this mess? How are we, scripters and mission designers, supposed to get the accurate and correct data for every airfield/farp/base/carrier if none of the 3 systems are complete and correct?!

@Exorcet THANK YOU. New bug raised in there.

Here's the entry in: \DCS World\Mods\terrains\PersianGulf\radio.lua { radioId = 'airfield21_0'; role = {"ground", "tower", "approach"}; callsign = {{["common"] = {_("Jask"), "Jask"}}}; frequency = {}; sceneObjects = {'t:82673668'}; }; However in the M.E. window you see this: Where is that data coming from if not from the radio.lua for the terrain pack?!

In that case which are the ones that are correct? The ones in radios.lua or the hardcoded ones in the ME? And in this particular case, wasn't it ED that made the map? So how do I raise the bug that the terrain is missing the comms freqs? Is there a specific channel or person to flag it to?

Okay, I'll watch this space but at least I know it's a 'feature' not a bug lol

Why is that even required or useful? The zoom level you're looking at the map or where you are looking at the map isn't anything to do with the mission. None of the mission objects have changed. This shouldn't cause a change and it shouldn't change the mission name from under you.

@Exorcet Hi. Do you know the answer to this please?

I have the following events handled (amongst all the others) S_EVENT_PLAYER_ENTER_UNIT S_EVENT_PLAYER_LEAVE_UNIT When I enter the F14, I see a S_EVENT_BIRTH followed by a S_EVENT_PLAYER_ENTER_UNIT. Then I ask my RIO to join in, I get the on-screen allow someone to join dialog (would be nice if this could have a keybinding as finding the mouse pointer esp in VR is a pita) and then I click allow... After a few seconds I get the blue banner saying my RIO has joined, and he confirms he's in the back. Yet NO events fire. Nothing. But when he jumps out, I get the expected S_EVENT_PLAYER_LEAVE_UNIT to fire. Obviously I can't give you a track or anything because you need two people and a multi-crew aircraft to do this, but it's a simple test. Without the S_EVENT_PLAYER_ENTER_UNIT event firing then it's impossible for my Player Manager to work out that they are a backseater and set things up accordingly.

I **believe** it might be caused by having your mission open in the mission editor, zooming in or out or scrolling around to look at something BUT NEVER CHANGING ANYTHING. Then clicking the green circle with the arrow to go fly, you get a warning dialog about saving changes - BUT YOU HAVEN'T MADE ANY CHANGES - so you click NO, go into the mission. do you stuff, hit esp to bring up the pause menu, select quit, select MISSION EDITOR on the after game report screen and when you return to the mission editor the mission name has changed to "tempMission.miz". I think the M.E. has a flag that something changed that's getting set when nothing changes and when running a mission without saving, it then insists on changing it's name...

Daily.

So, the best way I've been able to come up with is to keep a table of all players, by unitID's. On the PLAYER_ENTER event, check if a unitID with a player already exists in that table, and if so, then you must be a RIO/WSO. However I haven't checked this; it might not work because hoggitworld says: Occurs when any player assumes direct control of a unit. Initiator : The unit that is being taken control of. And that would imply it only fires for the pilot, not the backseater. On top of that, there's no way to know which player (client) was the one who triggered this because it's not included in the event. So maybe I need to also keep track of births and cross-check? Anothery source of failure I can see is for the Apache, where you can MP as a CPG and then have a human jump in as pilot. So somewhere there is a way to know which slot you're filling, but I'm not sure it's exposed to the scripting side (sigh). Unless someone can think of better?

Assuming that nothing in the Mission Editor has been setup i.e. naming the Pilot something with 'RIO' in their playerName etc. Is it even possible from when they just into the back seat to know that they aren't the pilot from an onBirth or onEnterUnit event - obviously this is in MP or even dedicated server environment.

I am writing my own library, I won't use MOOSE. I'm not just doing it for aircraft carriers, but for any ship that can take a helo. I've worked it out too thank, both sanitised and de-sanitised. (Sanitised has a 2 degree error but I think that's and ED engine issue.

At the moment, we need to create a load of custom waypoints for a unit or group to force it onto a specific heading (mag or true), we're reproducing what the engine already does probably much more efficiently that we can. So why can't we just pass a heading(either true or mag if the bool is true) to a Unit or Group (air/sea/land) and just let the engine plot it out for us? Thanks

Hi That's totally fair, but perhaps, someone could just stop the requirement to desanitise DCS to be able to 'require "magvar"' and just put the magvar stuff into the core libraries where it should really be. I can see no reason why that most basic of piloting information (mag variation) is walled off behind sanitisation... Thanks

@Exorcet @BIGNEWY Hi again. Do you think you can get this as a high priority fix please? I can't use scripting to set a ship into wind on multiple maps because the variation is so high (e.g. the South Atlantic map completely breaks this). I think it's really wrong we'd have to de-sanitise DCS on servers / player's PC's just to get the variation amount, especially as you already show it on the moving compass rose on the F10 map.

Well that's just stupid... /facepalm

Does this require MOOSE or MIST? Does this work in MP and SP? Also why do you give the qualifier (mod) ?

I am a real-life pilot (Civilian unfortunately), I've a degree in software engineering and a masters in computer games programming, I'm English and I'm a woman. I can *maybe* pull off a Southern American (Louisiana) accent. Also writing a scripting library for DCS mission / campaign designers. I'm now disabled and home a lot so plenty of time to fit in with whatever is required.

Just to help anyone else. Here are the wx from the OLD system (NONE preset) and then the new wx system (PRESET 24) --[[ OLD WX STRUCTURE ["weather"] = { ["atmosphere_type"] = 0, ["wind"] = { ["at8000"] = { ["speed"] = 20.616, ["dir"] = 90, }, -- end of ["at8000"] ["atGround"] = { ["speed"] = 6.1848, ["dir"] = 100.99998900091, }, -- end of ["atGround"] ["at2000"] = { ["speed"] = 13.4004, ["dir"] = 100, }, -- end of ["at2000"] }, -- end of ["wind"] ["enable_fog"] = false, ["groundTurbulence"] = 29.2608, ["halo"] = { ["preset"] = "off", }, -- end of ["halo"] ["visibility"] = { ["distance"] = 80000, }, -- end of ["visibility"] ["season"] = { ["temperature"] = 15, }, -- end of ["season"] ["type_weather"] = 1, ["modifiedTime"] = false, ["cyclones"] = { [1] = { ["pressure_spread"] = 1115151.3437232, ["centerZ"] = -62250.420860703, ["ellipticity"] = 9.9176892609982, ["rotation"] = -11.75631063386, ["pressure_excess"] = 1192, ["centerX"] = 159199.61333431, }, -- end of [1] }, -- end of ["cyclones"] ["name"] = "Winter, clean sky", ["fog"] = { ["thickness"] = 0, ["visibility"] = 0, }, -- end of ["fog"] ["qnh"] = 750.316, ["dust_density"] = 0, ["enable_dust"] = false, ["clouds"] = { ["thickness"] = 1830, ["density"] = 6, ["base"] = 600, ["iprecptns"] = 1, }, -- end of ["clouds"] }, -- end of ["weather"] ]] --[[ NEW WX STRUCTURE ["weather"] = { ["atmosphere_type"] = 0, ["wind"] = { ["at8000"] = { ["speed"] = 20.616, ["dir"] = 90, }, -- end of ["at8000"] ["at2000"] = { ["speed"] = 13.4004, ["dir"] = 100, }, -- end of ["at2000"] ["atGround"] = { ["speed"] = 6.1848, ["dir"] = 100.99998900091, }, -- end of ["atGround"] }, -- end of ["wind"] ["enable_fog"] = false, ["groundTurbulence"] = 29.2608, ["halo"] = { ["preset"] = "off", }, -- end of ["halo"] ["enable_dust"] = false, ["season"] = { ["temperature"] = 15, }, -- end of ["season"] ["type_weather"] = 1, ["modifiedTime"] = false, ["cyclones"] = { [1] = { ["pressure_spread"] = 1115151.3437232, ["centerZ"] = -62250.420860703, ["ellipticity"] = 9.9176892609982, ["rotation"] = -11.75631063386, ["pressure_excess"] = 1192, ["centerX"] = 159199.61333431, }, -- end of [1] }, -- end of ["cyclones"] ["name"] = "Winter, clean sky", ["fog"] = { ["thickness"] = 0, ["visibility"] = 0, }, -- end of ["fog"] ["dust_density"] = 0, ["qnh"] = 750.316, ["visibility"] = { ["distance"] = 80000, }, -- end of ["visibility"] ["clouds"] = { ["thickness"] = 200, ["density"] = 0, ["preset"] = "Preset24", ["base"] = 1700, ["iprecptns"] = 0, }, -- end of ["clouds"] }, -- end of ["weather"] ]] Note that in the OLD wx I set the cloudbase thickness to 6004 ft - which is the correct thickness of 1830m, but unless I'm going blind, the only real change to any of it is the addition of '["preset"] = "Preset24", to the structure.

I can be very patient, when I at least know it's recorded and on the list; it's when bugs are reported or questions are asked and they get no official response - that's when it gets frustrating.

Yes, thickness works in the 'old' wx system, the cloud thicknesses are reporting correctly if the Preset is none. Can we please get this logged so the new wx system can accurately show it's cloud thicknesses?

I didn't even know the 'old' wx system was still implemented; I would have thought that the new system completely replaced it. So you're saying the new wx system is only implemented if we use presets? Was this ever communicated? I'm trying with NO Preset now.. I'll report back.

Thanks for taking the time to reply. I have looked into the mission file inside the miz, and the only mention of thickness is 200m which is what the scripting is reporting - so it's getting the right number, but the number in the mission file is wrong; when you fly, it's a lot thicker (in height) that just 200m. So are you saying that it's broken since the new wx system was implemented? Is this likely to be fixed? Do you know to whom I should try and escalate this so it's at least reported and logged?