Grimes

Did some testing on this recently and assuming they are in range if the units needed to change their orientation to shoot then they would. Only exceptions would be stationary ones like the mortar and WW2 howitzers.

Order shouldn't matter as long as the task executes. And yeah the task that is listed right below the country value is more of a "role" and about all it does is limit the available tasks actually available to that group based on the role.

I think it is something that I had changed and inadvertently causes a long running bug/behavior with DCS scripting because you are giving it an order immediately after it spawns. I have not pinpointed the exact cause within mist, but I have a pretty good guess. The solution would be kind of an ugly fix because it would work only in specific circumstances. In the meantime the AI accept the move order as long as you don't call the groupToRandomPoint function at the same time that you call teleportToPoint. Set it to on a trigger that occurs a second after they spawn or schedule it to occur later. Ideally you could do some of the legwork and pass the new route directly to teleportToPoint, which works flawlessly. local v = {groupName = 'RED transporter-1', point = mist.getRandomPointInZone('test'), action = 'respawn', disperse = true, maxDisp = 60, radius = 30, innerRadius = 20} v.route = {} v.route[#v.route + 1] = mist.ground.buildWP(v.point, "Cone", 4) v.route[#v.route + 1] = mist.ground.buildWP(mist.getRandomPointInZone('AO-' .. mist.random(2)), "Cone", 4) mist.teleportToPoint(v)

Just did a quick test and missiles set to go for the snow drift tracked the snow drift and the missiles tracking the launchers went for the launchers. Couldn't say for sure which launcher I targeted, but with enough time between shots it seemed to be possible for the missiles to switch to other launchers. If you have a track it would be appreciated.

Easiest would be to add a command task to the route over the point where you want the AI to "drop" the unit at. dropList = {} function dropCargo(gp) local gName = gp:getName() if dropList[gName] then local point = gp:getUnit(1):getPoint() -- do whatever you need to do to spawn the contents of dropList[gName] at or near that location. end end --The task format needs to be rougly like this within a route. task = {["id"] = "ComboTask", ["params"] = {tasks = {{["params"] = {["action"] = { ["id"] = "Script", ["params"] = {["command"] = "local gp = ... dropCargo(gp)"}}}}}}} -- DO NOT CHANGE the ( ... ) that is literally a lua command. Gist is you make a table of cargo groups and their contents, then use a task that the AI do on passing a waypoint to execute a function that checks that table to see if it can drop anything. If there is then you can spawn the group as needed. Conversely you can just periodically check the location of that unit and get the distance from the drop point. If its within a certain range of that point then drop it. The command is "better" in the sense that the AI actually have to reach the destination and it executes automatically assuming its setup correctly.

The different events occur in a given order and sometimes the object wouldn't exist the exact moment an event is called. With ejection there are two possibilities. 1. Target is the ejection seat. 2. Target is the ejected pilot. Simply put if the aircraft has an ejection seat then it'll be possibility 1. Then the additional event of discard chair after ejection will occur after a few seconds once below a certain altitude. That is when the ejected pilot object actually begins to exist. So with the altitude bit, if you eject above that altitude then the pilot will stay in the chair for a while to lose altitude before the parachute deploys. If the aircraft is without an ejection seat the pilot will bail out and deploy the chute immediately. With enough wind this can drift them quite a distance away. The further caveat is that if the ejected pilot lands in water then the landing after ejection event simply doesn't fire. Nor does a dead event. It simply ceases to exist.

The function that gets called by world.searchObjects needs to be defined above it in the code. So your function pObj needs to be placed somewhere above: function EventHandl:onEvent(EventData). It basically doesn't know what pObj is at that point when the script is compiled. Also ParatroopSphereSrc = { params = { point = ejSeatPos, }, } That code just redefines the entire table as that and you aren't just updating the point coordinate. To do that: ParatroopSphereSrc.params.point = ejSeatPos I'm a little confused what you are trying to accomplish because it looks like you are trying to get the id of the ejected pilot seat by searching the area around it during the event. Which would likely return the aircraft they are in when the pilot ejected and possibly the ejected seat, but I don't think you'd actually get the seat because it isn't really a unit, static object, weapon, or scenery object. The more confusing part about all that is you already have the ejection seat by virtue of having access to the ejection seat in the form of EventData.target. You should be able to build that list via: EventData.target:getID() But also because https://wiki.hoggitworld.com/view/DCS_event_discard_chair_after_ejection will occur sooner or later and the pilot in a parachute will detach from the chair. (Unless its a WW2 aircraft because the ejection event is all that occurs for them)

You can't specify which units are invisible to others. The option is on/off and applies to all AI. However invisible units can still broadcast their own datalink to a network. Tanker set to invisible: AI AWACS can't "see" the tanker, thus it isn't on datalink. * AWACS set to invisible, has EPLRS (datalink) task: AWACs broadcasting its position to datalink network. AWACS set to invisible, EPLRS (datalink) task disabled: AWACS not visible on datalink. * * Being the caveat that player controlled aircraft should still share their datalink radar contacts. So in the example of the tanker if a player had their radar on and detected it then other players on the datalink network should see it as long as the player sharing it still detects it.

Gotta convert it from LO to LL and then from LL to MGRS. Really those 4 functions can be used to convert to the 3 main types used. Different LL values is simply string formatting. https://wiki.hoggitworld.com/view/DCS_func_LOtoLL https://wiki.hoggitworld.com/view/DCS_func_LLtoMGRS

Reported.

That is a known and reported bug.

The mist error is simply because the mist scheduler is used to call the GCICAP code. As you correctly figured out the error is with GCICAP. You could try adding some debug code to GCICAP to figure out what the problem might be. For instance above any line that calls airbase:getPoint() add something like the following to see if it gives a name for the airbase that it is erroring on: env.info(airbase:getName()) Best guess it isn't populating the airbase list correctly.

Reported. Worth noting that setMarkupText seems to not display a message when updating the markup shape. Not the best workaround, but it exists.

At that point you are just better off randomizing it with your own code. Which is the point I was probably making with the partial code snippet you had copied in. local gp = mist.getGroupData('wahtever', true) gp.clone = true if gp.route and gp.route.points then for i = 1, #gp.route.points do local ref = gp.route.points[i] if ref.type ~= "Takeoff" and ref.type ~= "Landing" then local newWP = mist.getRandPointInCircle({x = ref.x, y = ref.y}, 30000) ref.x = newWP.x ref.y = newWP.y end ref.alt = math.random(3000, 8000) end end mist.dynAdd(gp) That just purely randomizes each WP to within 30km of where that waypoint was placed in the editor and does a rather inconsistent altitude change throughout the route. It doesn't check if that point would be underground due to terrain changes though. Point is you take something simple like that and then gradually add on what you need it to do.

https://wiki.hoggitworld.com/view/DCS_event_hit The hit event works with object collisions as long as damage is done. It isn't the most reliable with aircraft to aircraft collisions and determining who was the initiator.

https://github.com/mrSkortch/MissionScriptingTools/releases/tag/4.5.106 Finally pushing 4.5 to master build. I don't really have any major overhauls planned so any additions and fixes should be merged quicker into it from development. Most of this is documented on the hoggit wiki. However I still need to add a few pages to it. Cumulative list of additions since 4.4.90: +added: mist.getPathLength() +added: mist.getPathInSegments() +added: mist.getPointAtDistanceOnPath() +added: mist.projectPoint() +added: mist.utils.getHeadingPoints() +added: mist.vec.normalize() +added: mist.getGroupTable() Returns the verbatim table for a group as defined in the mission editor. +added: mist.debug.writeGroup() This function is used to write a group table directly to a file of the groups name.lua. The point of this is to easily get the contents into a separate file. +added: mist.debug.writeTypes() This function iterates through units placed in the mission file and writes to a file containing a list of object typeNames, CLSIDs, and liveries +added: mist.shape.insideShape() Returns if the first shape is inside the second shape. +added: mist.shape.circleInCircle() +added: mist.shape.circleInPoly() +added: mist.shape.polyInPoly() +added: mist.shape.polyInCircle() +added: mist.shape.getPointOnSegment() +added: mist.shape.segmentInsersect() +added: mist.mapValue() +added: mist.utils.hexToRGB() +added: mist.getWindBearingAndVel() +added: mist.getUnitsByAttribute() +added: mist.getGroupsByAttribute() +added: mist.stringCondense() +added: mist.debug.changeSetting() +added: mist.debug.mark() +added: mist.marker.add() +added: mist.marker.getNextId() +added: mist.marker.remove() +added: mist.marker.get() +added: mist.marker.drawZone() +added: mist.marker.drawShape() +added mist.groupIsDead() +added better error handling messages in a number of functions +added mist.DBs.drawingByName and mist.DBs.drawingIndexed. Note: the above tables contains the values associated with the new drawings in the mission editor. Can be used with mist.marker.drawShape to activate a drawing shape created. There are limitations to this due to the scripting engine lacking a number of the draw features. For example rotating text, line thickness, icons, and outline types. Note 2: The shapes created in the editor are allowed to share a name. As a result entries sharing names in mist.DBs.drawingsByName will be overwritten with whichever value was used last. All are added to mist.DBs.drawingIndexed. -modified: properties table to zone entries in database -modified: mist.dynAdd will now check tasks assigned in route for any beacons and will update the groupId or unitId as needed. -modified: mist.getGroupData now has optional route boolean. If present it will also return the route. This allows the user to skip a function call. -modified: mist.debug.dump_G now accepts a boolean value that deletes entries that I commonly delete when dumping _G. -modified: mist.teleportToPoint -modified: mist.respawnInZone -modified: mist.cloneInZone -modified: mist.teleportInZone All four above functions now support additional parameters that can be used to alter specific behavior. -newGroupName : forces the create group to use this name - anyTerrain : If present no terrain check is performed to verify the new position is valid - validTerrain : Customize valid terrain types for the group to spawn on - initTasks : Keep initial tasking - offsetWP1 : Offsets the initial WP the group spawns at. Will go to next WP as defined in the editor. - offsetRoute : Offsets the entire route by the new location the group spawned at. - Modified: the following functions to support static objects: getUnitsInZones, getUnitsInPolygon, getUnitsInMovingZones, and getUnitsLOS, makeUnitTable - Modified: makeUnitTable to exlude units by category. - Modified: groupRandomDistSelf and groupToRandomZone to accept optional disableRoads parameter - Fixed: DB entry for country names to use the values stored in the country table instead of the localized name within the miz. This fixes a missmatch when spawning units for the third reich - Modified: getRandPointInCircle to use a default radius of 1000m if none provided. - Optimized: any instance of trigger.misc.getZone to reference mist.DBs.zonesByName instead = Modified mist.DBs.const.callsigns to include the new callsigns - Modified mist messages to update the display only if a change has been made. This will reduce spam in new DCS Message Log feature. It is still dependent on how often messages are updated, if you update a message for a stop watch timer then expect spam. -fixed: typo in mist.dynAdd -fixed: typo is mist.teleportToPoint -fixed: bug with mist.getLeadingPos where the position appeared to be reversed from what it was expecting -Fixed: verifyDB to check for empty string from static objects because it apparently can happen. -Fixed: checkSpawnedEventsNew to better handle errors from dbUpdate -Fixed: getUnitsInPolygon was erroneously checking for category 14 instead of 1 -Fixed: getUNitsInZones had an incorrectly named variable that defined an entry as nil.

I added a feature to respawnInZone, teleportInZone, and cloneInZone that allows you to keep and modify the route tasking. Assuming you are on a recent build of mist 4.5 it should be there. Actually in the process of pushing the dev branch to master. https://wiki.hoggitworld.com/view/MIST_cloneInZone So with this example it would randomly spawn that group anywhere within a 100 km radius of the zone and the AI would adjust their entire route acordingly. So if it was a north south orbit they'd just orbit north south where they started. mist.cloneInZone('groupName', 'zone', nil, 100000, {offsetRoute = true, initTasks = true}) If you set offsetWP1 to true instead of offsetRoute then the AI would start randomly in the that zone and then go to the next waypoint as set in the editor.

In the first log there are a bunch of lua errors associated with loading a input profile. It isn't listing the file in question. Gonna have to get a file list from Saved Games\DCS\Config\Input and see if there are any zip, rar, or similar file types in those folders. If there is then delete that file. Could also try loading into a quickstart mission for each module you have to narrow down which one is causing the crash. Considering you can join some servers but not others seems to indicate the contents of the server matters. Aka, which units are placed in it. Last ditch effort would be to rename your saved games folder to something else then start DCS. It'll create a new saved games folder with fresh settings for everything. Anyway if you can load into a server or mission that normally crashes you then the problem was somewhere in saved games.

Launch the game as administrator. Slmod modifies install\Scripts\MissionScripting.lua and if that modification doesn't take place then that error will occur.

Can you try doing it and then post your DCS.log after you tried saving the mission file? Also could upload a mission file it occurs on to see if there is a difference in that.

Unfortunately there is no function that returns live pylon information. A feature request for such a function has been around for a while now. . getAmmo() returns a list of weapons indexed numerically. It has nothing to do with what pylon has it. Not actually sure if there is any logic to the order.

You either need to put the check in a function or set that check to run at a rate slower than two minutes otherwise you would end up with the respawn being scheduled multiple times. In other words if you have it check if a group is dead every 10 seconds, and it scheduled the group to respawn in two minutes, then the group would respawn 12 times for two minutes after the initial two minute delay. You could do something like this. Basically set a time when you want a group to respawn and have a function check to see if that time has come. If it has then it respawns the group. groups = {} function checkGroups() for gName, gData in pairs(groups) do if type(gData) == 'number' and timer.getTime() > gData then mist.respawnGroup(gName, true) groups[gName] = nil end end end mist.scheduleFunction(checkGroups, {}, timer.getTime() + 1, 30) ----- Then if you wanted to add a group to it if (Group.getByName('truck-1') and Group.getByName('truck-1'):getSize() == 0) or not Group.getByName('truck-1') then groups['truck-1'] = timer.getTime() + 120 end

Looks like the folder is not named correctly. Would also need a second copy for the other version of it.

Its there, just worded differently. Since I wrote the wiki I probably am not the best judge of which is more clear.

That isn't a bug, its what those settings allow AI to do. When its on Priority Designated the AI will only do their assigned task. Unless for self defense at close ranges. Both Weapon Free and Priority Designated allow the AI to go "off mission" to attack valid targets. From: https://wiki.hoggitworld.com/view/DCS_option_roe