Grimes

Partly haven't documented the gameGUI environment fully because there is decent documentation for it in your install/API folder in the DCS_ControlAPI.html file. Also just need to dedicate the time to it and probably explain the differences between it and the simulator scripting engine. However the difference between onPlayerChangeSlot and onPlayerTryChangeSlot is that the try callback occurs when the user clicks the slot. This gives you an opportunity to deny the request and thus prevent the user from joining that specific slot. Its useful for slot block. It is also the same mechanism used by multicrew aircraft where the pilot has a choice to deny a user access. The onPlayerChangeSlot just contains the playerId and lets you know that they successfully changed slots.

1. There aren't a ton of changes for the scripting engine from patch to patch. 2. If I know of a change I'll update or create a relevant page. 3. Updating the version number on the landing page is often forgotten about and kind of pointless. Most of the scripting pages have a version number that it was added with and in the notes a comment about how it was updated/changed with a given patch will usually be present. I could add some categories that automatically groups data, but it'll take a while to go through every single page to add the relevant info.

Just remove any text you have there.

You have the string "AP" in the initialization script line for some reason. Its on the triggers menu nearish the bottom. This line is meant to run lua code while the mission is loading. Since it isn't a valid lua statement it generates an error.

I did update for 2.7. However from some testing its just gonna generate errors whenever those events occur and it should be able to recover. https://github.com/mrSkortch/DCS-SLmod/commit/07717cf9fea57c30b8bc812743cb4aa5893aed47

Thats slmod not mist. The only event handlers mist has is for checking for dead objects and birth events.

Fairly certain the griefer doing that wasn't purely due to them having access of the Scripts/Database folder. The overall size of the community is a firewall of sorts to heavy amounts of griefing compared to other games out there. The integrity check isn't perfect, but it serves the role of blocking the easy hacks, but allowing people to mod if they want, while the people who can hack around it are probably not impacted by this change at all. That mod works because its changing stuff in Coremods which is where all of the 3rd party and a lot of the new stuff by ED gets placed into instead of the old Scripts/Database folder. Thus some database files are more equal than others.

Harpoon received a damage buff in 2.7. But nothing was really changed in terms of the ships themselves and the aimpoint for the harpoon, it always hits center of the object. I would have to double check to see if any other ship HP values changed, just know of the Molinya.

In the actions for that trigger you can set a flag to on. Then where-ever you have the other trigger setup to say the drone is dead add the condition "flag X is false" . So basically if the JTAC is killed before the target is destroyed it will display the KIA message because the group was killed and that flag is false. But if you destroy the target then it sets the flag to true and the condition of (drone is dead and flag is false) won't occur and the message won't display.

Group deactivate is more or less the same as killing the group. What you can do is when you deactivate the group also set flag X to true and then on the message trigger you have for saying the drone was KIA add an extra condition that flag X is false.

There is one solution, you gotta make sure the AI spawn at a parking spot that will use the catapults you want them to. It simply doesn't matter what you or any other player does on the carrier. It is 100% governed by where the AI spawn at.

It would be in a format like this: https://wiki.hoggitworld.com/view/DCS_task_mission and/or this https://wiki.hoggitworld.com/view/DCS_func_addGroup You are basically using moose to build the table for you and it then passes that table to the game to execute. With that table I could completely delete all references to moose and still get the same outcome. More importantly it would be much easier to test different aspects of it and conditions to see if something changes. Plus it is more helpful to whichever dev will look at it if its all in a format that the game uses and not something they gotta spend time trying to figure out.

It is entirely based on where an aircraft spawns at. You have to block different spawn points with static objects so that the aircraft is forced to spawn at a point that will use the catapult you want. https://wiki.hoggitworld.com/view/DCS_editor_carrier_spawns

function unitinzone1() mist.flagFunc.units_in_moving_zones({ units = {'Aerial-1'}, zone_units = {'Ground-1'}, flag = "1", radius = 3000, toggle = true, }) if trigger.misc.getUserFlag("1") > 0 then trigger.action.outText('unit is in the moving zone', 5) end end unitinzone1() You have the creation and evaluation of the flag in the same block. When you run it once it will create the flag function in mist, which it will check every second, but since you are only evaluating whether flag 1 is true that one time it'll never return true. Code like the following would be one way to change it. Generally speaking though the idea of the flagFuncs are to set a flag value. So just creating a do script with the flagFunc definition and another trigger where it is checking the value for that flag to do a given action is more in line with the design usage. Though you can certainly just check the flag value via code as exampled below. function unitinzone1() if trigger.misc.getUserFlag("1") > 0 then trigger.action.outText('unit is in the moving zone', 5) end timer.scheduleFunction(unitinzone1, {}, timer.getTime() + 1) -- reschedule the check end mist.flagFunc.units_in_moving_zones({ -- create flag func units = {'Aerial-1'}, zone_units = {'Ground-1'}, flag = "1", radius = 3000, toggle = true, }) unitinzone1() -- run the check The attached screenshot is a quick test of a simple outText statement added into the mist code that displays the time that flagFunc is run and what happens if you constantly keep calling the function. Since the functions automatically reschedule themselves until told to stop each time you manually call it again it is adding more and more checks. As you can see it runs once, then twice, then 3 times, 4, 5, 6, etc. Yeah kinda. Its keeping track of which units have been winched and where they are in a sense. So perhaps if you had command to unload those units then it could check to see who sent the command, use the name to get the unit's properties, modify the point values, and the respawn the group where it was dropped off. Honestly it is a little backwards because for something like that it might be better to index it by the helicopter rather than what is winched.

This appears to be fixed on an internal build.

You would have to run a distance check for each unit you want it to be able to be moved and keep track of the winch time for each of them. However there are quite a few problems and optimizations you can make with your code. For starters the function mist.flagFunc.units_in_moving_zones creates an automated self check each time it is run. It just needs to be run once and then whenever mist sees any of those units are in a zone it'll set flag 1001 to true. Flag 1001 also never gets set to false so it is always true. You are also running Unit.getByName() multiple times when you already have that unit. local blueHelos = mist.makeUnitTable({'[blue][helicopter]'}) --get all blue helicopters. This list wont change for client units so it only needs to be created once local winchUnits = {'a', 'b'} local winchStatus = {} function checkWinch() local wPos = {} -- for storing the position of the unit. Here so that it only gets the position once for i = 1, #blueHelos do local u = Unit.getByName(blueHelos[i]) if u then local inAir = u:inAir() local uPos = u:getPoint() if u:getLife() > 0 and inAir == true then for j = 1, #winchUnits do local wName = winchUnits[j] local w = Unit.getByName(wName) if w then -- unit object only exists if returned if not wPos[wName] then wPos[wName] = w:getPoint() -- updates the position of the unit within the shared folder end if mist.utils.get2DDist(uPos, wPos[wName]) < 150 then -- within range if mist.vec.mag(u:getVelocity())*(3600/1852) < 1.5 and uPos.y - wPos[wName].y < 60 then -- hovering and within 60 meters above the unit if not winchStatus[wName] then -- creates the table winchStatus[wName] = {t = 0, heli = blueHelos[i]} -- stored as a table so you could add other information if you wanted to. -- for example adding a entry for its current status. winchStatus[wName].s = "loaded" end winchStatus[wName].t = winchStatus[wName].t + 1 -- adds to the time associated with that unit -- You can insert all of your code for displaying the status updates in this section -- You can remove the checking of flag 1003 and just use if statements on winchStatus[wName].t == whatever if winchStatus[wName].t == 40 then -- unit has been winched w:destroy() end elseif winchStatus[wName] then -- renove the entry winchStatus[wName] = nil end end end end end end end end

Would you happen to have the table that is passed to coalition.addGroup by moose so its not a massive PITA to debug?

That is still in the format of a lua table. Is it just not saving it as a .lua then? By the way, in development branch there is an option to save the stats files as json. What it does is whenever it loads the stats file it saves a copy in json. So it isn't streamed to constantly like the lua file, which is kept as the main location where new stats are written to.

Yeah that looks bugged. I have reported it.

Those mods are now kaput as the files have been hidden. I'm not happy about it either.

I think there was some miscommunication or miss-testing because I never saw it synced in MP. That aspect of it is still bugged. However the farp generating a spawn event might be fixed.

Not a clue for that one.

Yeah its an annoyance. Gotta use addCommandForGroup that is added for each group and then embed into the passed arguments an identifier so you know which group sent it. Problem therein being that it only goes to the group level so if you have multiple clients per group you don't know who sent it. That is unless you add a sub-menu for each aircraft and within that pass another identifier for that aspect of it and hope they select the correct sub-menu.

Oh I see what you mean now. I think its more a feature or a minor convenience. When you exit to the main menu it doesn't unload that map, probably because the mission editor and main menu are two sides of the same coin so to speak. A by-product of this is that if you were to go into an instant action for whatever map you opened last in the editor then it'd load quicker than if it was loading a mission from another map. Think of it as this: You get a blank mission on a map you were last on with 3-4 clicks to select a new map vs always requiring 3 clicks to open any map.

I didn't see anything obvious in your DCS.log to indicate a source of the problem. Are you running any mission editor mods? Could also try deleting the mission editor folder from your DCS install location and run a repair to see if that fixes it. If anyone else is having the issue please post.