Grimes

Its fairly common throughout the scripting engine that values are defined within table entries and you can use one or the other. If you dump _G then you can see a list of the events like below, which is how the event types table is saved. A lot of the time the value is an "enumerator" which most of the time just means its a number value that might not have a frame of reference. What I mean is if you check event.id == 8 then you *have* to know what is at id 8, if for whatever reason ED decided to insert an event into the list, then every id after that would be shifted. Whereas if you used world.event.S_EVENT_DEAD then the only way that would break is if that event was deleted. ["world"]["event"] = table: 000001E8157FC630 { ["world"]["event"]["S_EVENT_MISSION_END"] = 12, ["world"]["event"]["S_EVENT_DAYNIGHT"] = 39, ["world"]["event"]["S_EVENT_AI_ABORT_MISSION"] = 38, ["world"]["event"]["S_EVENT_KILL"] = 28, ["world"]["event"]["S_EVENT_UNIT_CREATE_TASK"] = 44, ["world"]["event"]["S_EVENT_SHOOTING_END"] = 24, ["world"]["event"]["S_EVENT_BASE_CAPTURED"] = 10, ["world"]["event"]["S_EVENT_DEAD"] = 8, ["world"]["event"]["S_EVENT_TRIGGER_ZONE"] = 35, ["world"]["event"]["S_EVENT_EJECTION"] = 6, ["world"]["event"]["S_EVENT_WEAPON_ADD"] = 34, ["world"]["event"]["S_EVENT_SHOOTING_START"] = 23, ["world"]["event"]["S_EVENT_UNIT_LOST"] = 30, ["world"]["event"]["S_EVENT_INVALID"] = 0, ["world"]["event"]["S_EVENT_PLAYER_ENTER_UNIT"] = 20, ["world"]["event"]["S_EVENT_EMERGENCY_LANDING"] = 43, ["world"]["event"]["S_EVENT_CRASH"] = 5, ["world"]["event"]["S_EVENT_MAX"] = 46, ["world"]["event"]["S_EVENT_LANDING_AFTER_EJECTION"] = 31, ["world"]["event"]["S_EVENT_PLAYER_LEAVE_UNIT"] = 21, ["world"]["event"]["S_EVENT_HUMAN_FAILURE"] = 16, ["world"]["event"]["S_EVENT_ENGINE_SHUTDOWN"] = 19, ["world"]["event"]["S_EVENT_PILOT_DEAD"] = 9, ["world"]["event"]["S_EVENT_REFUELING_STOP"] = 14, ["world"]["event"]["S_EVENT_LANDING_QUALITY_MARK"] = 36, ["world"]["event"]["S_EVENT_BDA"] = 37, ["world"]["event"]["S_EVENT_HIT"] = 2, ["world"]["event"]["S_EVENT_MARK_ADDED"] = 25, ["world"]["event"]["S_EVENT_ENGINE_STARTUP"] = 18, ["world"]["event"]["S_EVENT_LAND"] = 4, ["world"]["event"]["S_EVENT_FLIGHT_TIME"] = 40, ["world"]["event"]["S_EVENT_DISCARD_CHAIR_AFTER_EJECTION"] = 33, ["world"]["event"]["S_EVENT_TAKEOFF"] = 3, ["world"]["event"]["S_EVENT_TOOK_CONTROL"] = 13, ["world"]["event"]["S_EVENT_PLAYER_CAPTURE_AIRFIELD"] = 42, ["world"]["event"]["S_EVENT_PLAYER_COMMENT"] = 22, ["world"]["event"]["S_EVENT_PLAYER_SELF_KILL_PILOT"] = 41, ["world"]["event"]["S_EVENT_SCORE"] = 29, ["world"]["event"]["S_EVENT_REFUELING"] = 7, ["world"]["event"]["S_EVENT_PARATROOPER_LENDING"] = 32, ["world"]["event"]["S_EVENT_BIRTH"] = 15, ["world"]["event"]["S_EVENT_SHOT"] = 1, ["world"]["event"]["S_EVENT_MARK_REMOVED"] = 27, ["world"]["event"]["S_EVENT_MARK_CHANGE"] = 26, ["world"]["event"]["S_EVENT_DETAILED_FAILURE"] = 17, ["world"]["event"]["S_EVENT_MISSION_START"] = 11, ["world"]["event"]["S_EVENT_UNIT_DELETE_TASK"] = 45, },

Then upload a mission with just that and the event occurring because I can't reproduce it.

Yeah I wish there was a "load mission anyway" button because most of what it does is it just changes the missing unit to something that does exist or deletes the unit. I've had to do it a number of times because people often post missions using mods in bug reports and I don't have the desire to find and install mods on my own. Two methods. Modify the mission and modify the mission editor. 1. Modifying the mission. The mission file is basically a zip file. Do not have the mission open anywhere. Use a program like 7zip to explore it, the open mission within a text editor like notepad++. Find the requiredModules table and remove the table entries. Once done, save the mission file somewhere. CRITICAL, do not save it as a file type and do not append any extension for it. In NP++ save as "all types". Once saved, drag the file into the miz archive open in 7zip to replace it. 2. I *think* you can comment out these lines in me_mission.lua starting at line 1713 in the 2.7.18 patch by just adding a -- on each line. This will be on a different line number on most patches. It will entirely get rid of the warning dialog. if veryfyUnitsPlugins(env.mission) == false then zipFile:unzClose() if base.isInitTerrain() == true then create_new_mission() end return false end

Oh it certainly helps. I use something like your #3 idea for a bubble script, but its a little more complicated. Basically any group that I want to spawn in like that has their probability set to 0 in the mission editor. This means it doesn't exist at anypoint while the mission runs. The script constantly checks the distance between any unit that can spawn a bubble, depending on the mission that would be aircraft and certain weapons spawning bubbles of enemy units and maybe friendly client aircraft spawning friendly bubbles for ambience. The mission maker can place trigger zones to define groupings and to simplify the checks. Say if you had an SA-5 site with groups of SA-15 or AAA emplacements to defend it you don't need or want those short range groups to spawn in until they'd actually be useful. On top of that the script creates virtual bubbles of averaging the spawn range of bubbles within to further simplify the check. https://imgur.com/tQ7u92A The downsides are that you are consistently checking where each unit is at that can spawn something and the actual act of spawning has its own processing woes. For example on the Grayflag server this script causes MIST to update its own databases anytime groups spawn in, slmod also does the same for its own stats handling, and tacview thinks they are new groups entirely so you might end up with units listed 20 times when its just a Patriot battery that never gets attacked. Likewise the number of groups being spawned in at a given moment can be substantial. Its one of those things where an optimization leads to the mission maker adding more units to counteract said optimization. The missions run "fine" with 16000 units placed in the editor, but only so many are alive at a given moment, yet if more players go more places then the number of units alive expands substantially.

This is the only reference to it in the editor that I can find. for k,v in pairs(group.units) do v.heading = heading v.psi = -heading end No idea what it is for.

I think some have it, but it might be limited to the ones that are also static objects that can be placed. So only objects from the Caucuses map. Also box doesn't represent a hitbox at all. Its just two points representing opposite corners of the area the object takes up.

Yes and no. getCategory for objects like weapons and airbases are supposed to have their own copy of sorts of the function that returns the relative category value. IIRC depending on what you wanted there was a difference from running Airbase.getCategory(base) and base:getCategory(). The former would have returned the airbase category while the latter probably would have been the object. The getCategory bug always returning the object category cropped up in 2017 and hasn't been fixed.

Gotta use point in polygon checks. Something like the code in the mist function https://github.com/mrSkortch/MissionScriptingTools/blob/master/mist.lua#L3138

It has been asked about over 2 years ago with no answer. Other functions were asked about at the same time and did receive answers. Most likely it is dormant and waiting for something in the future. Best to do it the way everyone else does it. 1. Brute force usage of ((zone.x - unitPoint.x)^2 + (zone.z - unitPoint.z)^2)^0.5 < zone.radius to see if a point is within a circle. Maybe limiting the total units that are checked and how often it checks to be slightly more efficient with it. If the precise time a unit enters a zone is critical then its easily doable to schedule checks for certain units at different rates and do those closer to the zone more frequently. 2. world.searchObjects for units to give an exact listing of the units within the zone on each check.

It doesn't list the reciprocal heading of a runway, it just lists it the one time. The runway name and course given is likely the default runway value given no wind. The example on the wiki has two runways. I should probably figure out which airbase I grabbed that data from. Yeah the course is still bugged. Example below is drawn with red using the raw course value with grey being multiplied by -1. Also note that the game doesn't consider the other runway to be a runway. Which is more of a map setup issue than anything else. They removed multiple runway functionality on Caucasus a long time ago.

Yeah setSpeed and setAlttitude both work. Am using both on the Grayflag server to do precisely that for players to request speed and altitude changes for the tanker so that we don't have to have a special one for the A-10 or whatever. You can also just generate a new task via https://wiki.hoggitworld.com/view/DCS_task_mission and set randomized altitude values there.

Ehhh it depends. Anything placed on the ground like ground units, statics, or aircraft spawns will be at the coordinates where-ever they are. So yeah vehicles might be in the middle of a runway all a sudden. Again, fixable in the editor ~= "incompatible". Aircraft with ramp spawns have an id associated with a given parking spot, if said coordinates of that parking spot move then the aircraft will likewise be moved with it. It appears that if a parkingId is not present then the editor will assign one automatically. Fairly certain the same rules apply if you just load into the mission without re-saving. It is a relatively unique situation though since major layout changes to an airport don't occur that often on DCS maps. Usually its minor taxiway changes if anything. The only one I can think of off the top of my head was when Caucasus updated from BS1 to WH release. Batumi and Sukhumi were changed a bit, but what I don't remember is precisely when the change occurred and if the old versions were ever present in A-10C beta releases. Since the miz format from BS1 to now is technically compatible as you can see it might as well be random chance if units happen to block the changed base.

So really they are compatible it just might be buggy. Just like any mission on Caucasus from 1.5 to 2.5 where the map received a assorted updates. The mission still loaded, thus compatible. However the place where you need to land your helicopter on some specific mission is now in the middle of a forest, thus buggy. The expectation for a mission file to simply load is the main barrier of entry with any sort of inconstancies that *can be corrected* within the editor are the far lesser concern. Frankly map differences from version to version impacting missions can be expected any time a map updates paid or not.

Birth events occur whenever anything is spawned, an airbase wouldn't matter for ground units for example. However we can't create new client aircraft, so all of their starting data is embedded in the mission file. You can use this information to correlate with airbases. env.mission is the main contents of the mission file, thus you can iterate the table looking for any client skilled aircraft and build a lookup table for spawn points. You may have to also have to check for distance in instances where takeoff from ground is used because those aircraft lack an entry for the airbase. The route in the mission file follows a similar pattern as the mission task and you need to look for either airdromeId, linkUnit, or helipadId. https://wiki.hoggitworld.com/view/DCS_task_mission Below is copied from mist on a function that finds a specific groupId's route table. It is also a bit paranoid via all of the if statements to verify the expected data exists. for coa_name, coa_data in pairs(env.mission.coalition) do if type(coa_data) == 'table' then if coa_data.country then --there is a country table for cntry_id, cntry_data in pairs(coa_data.country) do for obj_cat_name, obj_cat_data in pairs(cntry_data) do if obj_cat_name == "helicopter" or obj_cat_name == "ship" or obj_cat_name == "plane" or obj_cat_name == "vehicle" then -- only these types have points if ((type(obj_cat_data) == 'table') and obj_cat_data.group and (type(obj_cat_data.group) == 'table') and (#obj_cat_data.group > 0)) then --there's a group! for group_num, group_data in pairs(obj_cat_data.group) do if group_data and group_data.groupId == gpId then -- this is the group we are looking for if group_data.route and group_data.route.points and #group_data.route.points > 0 then for point_num, point in pairs(group_data.route.points) do if point.airdromeId then -- airbases end if point.linkUnit then -- FARP and ship spawns end

At the moment quad zones have a fixed orientation based on how they are drawn. You'd have to use scripting and point in polygon checks if you want to have a quad (or more sides) shape change orientation.

The moose code looks like they are creating a reference for it in the case of someone tries to use it within moose and moose knows what to do with it whenever that event may be called. Also they seem to have their own events that they combine with the list of S_EVENTs. Moose still relies on DCS to trigger that even however it occurs. Which would be the same using world.addEventHandler. As for the other events, I usually know about them but I am not always aware of when it gets merged to public builds. If I can get the event to occur it will also get its own page with details. If not it just gets added to the list of things that exist. ED's documentation itself is slightly out of date as 2 events have been added at somepoint.

An aircraft set to the skill of "player" should be able to be spawned, but it doesn't work for client and is only functional in single player. At least that is how it has worked originally. It isn't often used so there is a chance it has changed over the last nearly a decade. Given the above conditions any script you have that is capable of spawning a new group should work. It might be best to "overwrite" an existing player aircraft though.

Anything stored within the mission is accessible. Drawings are in env.mission.drawings You can iterate the tables via to access them. if env.mission.drawings and env.mission.drawings.layers then for i = 1, #env.mission.drawings.layers do local l = env.mission.drawings.layers[i] for j = 1, #l.objects do -- some drawing end end end Note that the data format is a little different than how you might draw that same thing via the scripting engine and the features of both are different overall.

No. Outside of specific world objects on each map there is nothing in the context of a port. Across the different maps there aren't a ton of them to exist to begin with, so manually figuring it out purely from traveling from point A to point B its not to bad. Just gotta worry about navigation and sea depth.

To prevent players from joining a specific slot can only be done proactively with the hook and denying access via onPlayerTryChangeSlot. However there is a reactive method of forcing them to spectators from purely the mission env with net.force_player_slot(). It would be best to use a birth event to react to the player spawning into a given aircraft and then actively moving them. Otherwise you'd just have to constantly check all of the players to make sure they aren't in slots they shouldn't be.

In the mission editor you can right click on world objects and "assign as". This creates a trigger zone with the current id and object type name in the zone properties, however there are potential problems with both of these. The typename is formatted with string.lower, so it might not precisely match the actual typename string. The object ID is not a fixed value from patch to patch. Specifically if the map updates then the object IDs can change, either by representing an entirely other object or is simply no longer in use. So it is best to look for a certain object type at specific coordinates.

ED have a habit of adding events that aren't always immediately obvious how or what triggers them. Also a few are for WIP things. Not sure which this one is.

The mist error is simply due to the skynet code scheduling the function through mist. There error is still within skynet and apparently related to self.dcsPrepresentation being nil or no longer accessible. Would have to guess that skynet has an isExist() check on it before running that somewhere.

Gradually increase the weight as they fly away from a base if they loaded to much of a certain weapon or randomly changing the weight is also fun. To bad its all at the center of mass and can't shift the weight around.

There are no scripting functions for causing failures. The closest that exists is to exploit the function meant to mimic loading cargo by making the aircraft weigh much more than it should. https://wiki.hoggitworld.com/view/DCS_func_setUnitInternalCargo