Jump to content

Elphaba

Members
  • Posts

    1333
  • Joined

  • Last visited

  • Days Won

    1

3 Followers

About Elphaba

  • Birthday May 6

Personal Information

  • Flight Simulators
    A10C, Huey, F15, Elite Dangerous (Beta)
  • Location
    UK - for my sins.
  • Interests
    Sleeping, eating dim sum, reading fanfic.
  • Occupation
    Airline Pilot (Captain) for UK regional airline.

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. MOOSE is bloatware and overly architected and overly complicated to use and expand. And the fact that the MOOSE team haven't spotted this bug or flagged it either, gives cause to think it's not as good as it claims to be. and I've already got a working ATIS - it's just the thickness is wrong.
  2. 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.
  3. 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.
  4. 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?
  5. 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.
  6. 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?
  7. as the title says. The position keeping of units in a naval group is... let's just say awful, esp when the lead makes changes. However a helo set to follow a naval unit does much better staying in position through the changes in heading. Therefore it would be ideal if FOLLOW was added for all units (ground/naval/air/infantry) so that the group structure can be more accurately maintained. Re: Labels Distance - is the fore/aft or lateral? Interval - that doesn't even make sense with regards to follow - its obviously the opposite of distance but it's not clear from its nomenclature. Now, trial and error will tell you that Distance is lateral and Interval is fore/aft in relation to the thing being followed, but it's just three labels that need changing and maybe a tooltip for each explaining them for users.
  8. But why does the new birth happen before the previous aircraft's leave? That makes no sense. And surely the event leave - as it does contain data to a unit that in the sim no longer exists - that unit shouldn't have been removed from the backend before all the necessary events have completed, right? Otherwise - like now, it's utterly useless and asking for trouble if the things it's referencing are already gone. Shouldn't these events be firing for the scripting engine at a point where all the referenced objects still exist - the the scripter / mission designer and do what they need to first, and then the back end removes them as it completes its actions? There seems to be a rather larger issue at hand if this is the way it's been architected...
  9. /facepalm. Which is why I'm raising it here - they look here, they review the posts... /smh
  10. Here's the entry in: \DCS World\Mods\terrains\PersianGult\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?!
  11. I have a player manager that records when players join and leave. The join events are either birth or on enter unit. The leave events are either dead pilot or leave unit On trying to handle the onEvent for the leaving events, the event specifies that the initiator is a Unit. The problem is, that I have to filter out players from AI units. So the way to do that is getPlayerName() on the Unit. But when I try and cast the event.initiator : Unit.getByName(event.initiator:getName()) then I get an error because the unit has already been destroyed in the game engine! What's worse is that in the event the player changes slot or even changes coalition, the BIRTH event for the new aircraft happens BEFORE the LEAVE_UNIT event for the previous aircraft!?! @Exorcet Surely there's something screwy going on here?
  12. I meant it's way out of date - most entries are from 2022 so it's not exactly reliable.
×
×
  • Create New...