Grimes

Trees are not accessible to the scripting engine unfortunately. Its one of those highly desirable features requests.

This is the script used in the attached mission. local foundUnits = {} local deleteThis = {['GREENHOUSE1'] = true, ['GREENHOUSE2'] = true,} local sphere = trigger.misc.getZone('zone') local volS = { id = world.VolumeType.SPHERE, params = { point = sphere.point, radius = sphere.radius } } local ifFound = function(foundItem, val) local tName = foundItem:getTypeName() if deleteThis[tName] then if not foundUnits[tName] then foundUnits[tName] = 0 end foundUnits[tName] = foundUnits[tName] + 1 foundItem:destroy() end end world.searchObjects(Object.Category.SCENERY, volS, ifFound) local msg = {'Removed: \n'} for tName, val in pairs(foundUnits) do env.info(tName .. ' : ' .. val) msg[#msg+1] = tName .. ' : ' .. val .. '\n' end trigger.action.outText(table.concat(msg), 20) remove_hippy_farmers.miz

Use :destroy() within the search function. if obj:getTypeName() == 'GREENHOUSE2' then obj:destroy() end

Yes it is compatible. Slmod in some ways was a precursor to mist and for access to the scripting engine in general, so it does have some scripting functions available in the mission environment. Most if not all of those functions are now part of mist.

That was entirely my mistake. I pushed a change that had a few syntax errors in it. Realized it the next day, fixed those errors, recommitted the changes, but forgot to push those changes to github. So they were just sitting fixed locally with me thinking the problem was resolved. Redownload it on the github page and use that version, should fix it for you.

Considering the requests are nearly 5 years old at this point, yeah you would think it would have been added by now. There is no scripting function for it, its been requested for both script and triggers and with outSound, outText, and radio menus.

Nope not missing anything, it doesn't exist. There has been a request to add it for a while now, but no dice as of yet.

Some of that can be accomplished, but not precisely as you desire. For example to cover an area you can combine multiple search and engage tasks to accomplish a more complex shape. Use searchAndEngage, set max distance, and the AI will use their route as the shape. Multiple searchAndEngageInZone's can be used to get some shape, while it'll have some curves to it, the shape can be close enough to what you want. Randomly moving can be commanded via switch waypoint, or possibly a better solution would be to just use the scripting engine to randomly generate those points or change the order of them.

Would have to investigate, but I know there have been problems with this in the past.

More precisely it is "allowed to engage any valid targets detected in zone while task active". A critical component is that it is an "Enroute Task" which isn't a command to do a specific action, but rather what it is allowed to do if that task comes up. See this wiki page for more information: https://wiki.hoggitworld.com/view/DCS_editor_AITasking#Perform_Task_vs_Enroute_Task This is why that group RTBs immediately, because they don't detect the target and they have reached the end of their route, thus the task has very little time to detect the target and be allowed to attack it.

Its been like that since coalition.addGroup was added to the game. The debrief code simply hasn't been updated to reflect any information about dynamically spawned units.

A good test for this would be to jump into any aircraft and see if the radar is emitting. If its not then that means the F-16 is unable to detect it with its RWR or fire AGM-88s at the target. Could try adding the other parts of the sam site to see it will turn its radars on and allow the F-16 to attack it. Could also try giving the F-16 a missile like the maverick.

Make those modifications to the SlmodMissionScripting.lua found in Scripts/net/slmodv7_6 folder.

The barrier for entry is a bit different. On one hand you need access to the aircraft, weapon system, and hope all the avionics play nice. On the other you can go to amazon, buy NVGs, and jump into any aircraft from the Wright Flyer to SpaceShipTwo and have roughly the same experience. Push comes to shove you can delete the keybinds to activate the goggles and bask in the glory of self simulation superiority.

Doubt it occurs more than once after mission start. Its caused due to an event occurring before slmod creates the oldClientsByName table. The only thing that is likely to occur in that time frame are birth events and the stats code doesn't do any with the birth events anyway, so I'd characterize this as a minor bug and nothing to worry about. That is as long as its only occurring and only at mission start. If you see it with anything that isn't a birth event then there would be a real big problem.

When does it happen? How often does it happen? Is there any line above it that has the following? SLMOD INFO: checking X SLMOD INFO: {event table here} If unsure, send me a log file with the error. Preferably DCS.log.

P-51B has been there for several years now. Possibly was added around the time of the original P-51.

Historical mode.

Fixed the issue with that error message occurring with 4.5.95. -Added support for static objects in makeUnitTable function. It still returns a list of all objects in a single table, so be careful and know that it WILL return static objects. -Added optional value to mist.makeUnitTable to exclude categories of objects. Can be used to filter out statics or any other type. Input is a string or a table of strings. -Added/fixed getUnitsInZones, getUnitsInPolygon, getUnitsInMovingZones, and getUnitsLOS to support static objects. Change was made due to farp objects returning via Unit.getByName() and not checking for object category.

Or master. Depends on what you are comfortable using. The update from 7_5 to 7_6 was quite substantial and had a few growing pains, but it appears to be stable lately. Not sure when I'll merge the develop branch into master.

I leave most of that to github since its less of a pain to maintain there. I try to at least mention changes made with each commit. Just gotta know which branch you are on and check the dates of when it was last updated. Only reason I knew you hadn't updated recently was because the line number for the error didn't match the file.

Update slmod. Had fixed something related to that 3 weeks ago. Make sure you are on build 140.

Well its not by design on my part thats for sure. Respawn and clone appear to be ok, but teleport isn't. Guessing there is something different about the WW2 units preventing it from working because if I switch to modern units it'll execute as expected. Its a game bug then, will report.

world.searchObjects Search for scenery, use getTypeName() on the object, if its the right string, then use destroy() on the object. Easy way to do it is to make a reference table and list all the object types you want to remove. You might need to first output a list of the object names or make mark panels over an object just so you can get an idea what is what. if searchInclude[obj:getTypeName()] then obj:destroy() end Note. It might not be synced correctly in MP.

There are two issues. The first is that for some reason the invisible farp is registered as a unit and not a static object. The second issue is that the unitsInZones function doesn't handle static objects correctly. This is mostly due to it not knowing the category of different objects and an extra check I had done to prevent late activated units from being checked. I'll fix it soon.