MIssion Scripting Tools (Mist)- enhancing mission scripting Lua

[chromium]

Sometimes is better to have a feature with limitation, instead that don't even have any feature. In this sim we need countinously to look for workaround due to bug or engine limitations, so having a function that work for weapon "a" but not for weapon "b" isn't an issue for me, as far I have a list of "a".

 

 

But...

 

it's only my personal opinion.

[Speed]

Maybe is on work... I miss the POS & PTS... they're almost necessary to me :)

 

Mist only has access to a portion of the game's Lua API that Slmod has access to. Mist is limited to only ONE DCS Lua environment; Slmod uses FOUR. Unfortunately, mission scripting has no info on the multiplayer client environment.

 

Even if we had all the info on who were the clients, what they said in chat, what mission slots they were in, etc, we'd still need some kind of callback that was equivalent to server.on_chat, and also, we'd need an equivalent to net.send_chat (so that you could communicate privately to Combined Arms players and spectators).

 

Basically, it is impossible to replicate SlmodMenu objects (POS, PTS, AdminMenu, Coordinate converter, ...) in mission scripting Lua, and it's unlikely that the necessary changes to the game's code to do so will be made in the near future (if ever).

[chromium]

than the other question is: do you think that could exist a workaround to have something similar (es. a multiplayer working radio menù)?

 

in the meantime... nothing will move me by SLmod also, I will use both if necessary :)

[Speed]

Hi folks, maybe someone can help me.

 

I'm trying for weeks to get this to work: I just want to do a message to a specific group via trigger.action.outTextForGroup but all I get is an error that the GroupID is nil. Maybe I'm too dumb to get this ID by using this one Group.getByName(string):getID()

 

Regards

trigger.action.outTextForGroup- and all the outTextFor functions- got broken during the process of building one of the patches (I think it was 1.2.1). Group.getByName(string groupName):getID() is indeed the correct way to get a group's ID for this function (though- you wouldn't want to use EXACTLY that code for an ACTUAL mission- you'd generate a Lua error if that group was not alive. So first, you'd want to make sure that Group.getByName actually returned a group before you tried using getID).

 

Anyway, they should be fixed in a future DCS version. :)

[Speed]

than the other question is: do you think that could exist a workaround to have something similar (es. a multiplayer working radio menù)?

 

in the meantime... nothing will move me by SLmod also, I will use both if necessary :)

 

Yes, the best work-around is to use a server-side mod to replicate similar functionality to the F10 "other" menu by using multiplayer chat :smilewink:

 

As I understand it- this could be wrong though- the "create other radio menu/menu item" commands only occur once, if you're not around to "see" it, you won't get it. So this command would have to be stored somewhere/somehow. This info is also not communicated over the network to clients.

 

And finally, there's a design decision- how exactly should these menus work for clients- should clients be allowed unrestricted access to these? If that were to happen, it would actually break a feature I'm sure SOMEONE out there is using- right now, the host has his own private set of menus to control mission trigger logic, that clients cannot interfere with. So, do we need to be able to specify WHO can use these menu items?

 

So anyway, it's definitely a non-trivial design/programming challenge. No, it's probably not difficult, just time consuming.

Edited December 5, 2012 by Speed

[Quax456]

trigger.action.outTextForGroup- and all the outTextFor functions- got broken during the process of building one of the patches (I think it was 1.2.1). Group.getByName(string groupName):getID() is indeed the correct way to get a group's ID for this function (though- you wouldn't want to use EXACTLY that code for an ACTUAL mission- you'd generate a Lua error if that group was not alive. So first, you'd want to make sure that Group.getByName actually returned a group before you tried using getID).

 

Anyway, they should be fixed in a future DCS version. :)

 

Yea, indeed I did so to be shure that this group is alive, but if this function is still broken there is no need of further talk on :(

 

Thx for the help

Regards

[gunterlund21]

Speed

On these functions is it possible to do the following;

1. Use the next level down in deciding flags switch. for instance instead of saying "within 1000m of red vehicle" go down one level and say "within 1000m of red truck" or "Tank".

2. Most options turn a flag on if event occurs. Is it possible to have the flag returned to false if unit leaves the zone.

[Speed]

Speed

On these functions is it possible to do the following;

1. Use the next level down in deciding flags switch. for instance instead of saying "within 1000m of red vehicle" go down one level and say "within 1000m of red truck" or "Tank".

2. Most options turn a flag on if event occurs. Is it possible to have the flag returned to false if unit leaves the zone.

 

Yes, both are possible. Grimes was already telling me he think it would be a good idea to have further refined categories. I am planning on investigating it.

 

As far as flag off/unit outside zone/etc- they will probably be created one day, maybe a day not too far away from now.

[gunterlund21]

great thanks for the update Speed. Look forward to trying MIST. I get pushback for my missions because people dont want to hassle with slmod on the server so I hope MIST will eliminate that need and still give me the functionality I want. In particular the "in moving zone" function.

[Speed]

great thanks for the update Speed. Look forward to trying MIST. I get pushback for my missions because people dont want to hassle with slmod on the server so I hope MIST will eliminate that need and still give me the functionality I want. In particular the "in moving zone" function.

 

Mist can only eliminate the need for Slmod in some missions, unfortunately. There's a lot of things mission scripting just can't do.

[Puddlemonkey]

Any chance MIST will one day be able to do the weapons impacting in zone?

[mwd2]

use SLMOD during the waiting.....!

[Grimes]

Any chance MIST will one day be able to do the weapons impacting in zone?

 

Probably.

[Speed]

Like I said, the main problem with weapons impacting in zone is the fact that the Unit.getTypeName is not fully implemented for weapons. In fact, it was probably never even intended to be used on weapons at all, but it works... a lot of the time, at least. Anyway, since it's relavent to what I'm about to post, this is what a shot event looks like:

{ ["subPlace"] = 0, ["time"] = 43228.691, ["initiator"] = { ["id_"] = 16778752, }, ["target"] = { ["id_"] = 0, }, ["id"] = 1, ["place"] = { ["id_"] = 0, }, ["weapon"] = { ["id_"] = 33554688, }, }

See the "weapon" field? That's an Object, and while it's not a Unit, you can treat (or cast) the weapon as a Unit, and many of the Unit functions will or sometimes work. One that always works is Object.getPosition (Unit is a child class of Object, so it inherits Object.getPosition).

 

Anyway, I'm attaching a mission, "Weapons Impacting on Runway Demo.miz". Here's the script it uses.

 

 

do 

   local runwayHits = { [1] = {}, [2] = {}, [3] = {}, [4] = {}, [5] = {} }

   -- Runway segment polygon zones
   local segmentPolys = {}
   segmentPolys[1] = mist.getGroupPoints('segment1')
   segmentPolys[2] = mist.getGroupPoints('segment2')
   segmentPolys[3] = mist.getGroupPoints('segment3')
   segmentPolys[4] = mist.getGroupPoints('segment4')
   segmentPolys[5] = mist.getGroupPoints('segment5')
   
   
local tracked_wpns = {}
  
  -------------------------------------------------------------------
   -- THE EVENT HANDLER
   local shotHandler = function(event)
       if event.id == world.event.S_EVENT_SHOT then
           if event.weapon then 
               local wpn = LuaClass.createFor(Unit, event.weapon.id_)
               if wpn:isExist() then
                   local wpnName = wpn:getTypeName()
                   if wpnName and type(wpnName) == 'string' and (wpnName:find('BetAB_500')) then
                       local init = LuaClass.createFor(Unit, event.initiator.id_)
                       local init_name = ''
                       if init:isExist() then
                           init_name = init:getName()
                       end
                       tracked_wpns[event.weapon.id_] = { wpn = wpn, init = init_name, pos = wpn:getPosition().p, dir = wpn:getPosition().x }
                   end
               end
           end
       end
   end
   mist.addEventHandler(shotHandler)

---------------------------------------------------------------------
-- THE WEAPONS TRACKING FUNCTION
   local function track_wpns()
       mist.scheduleFunction(track_wpns, {}, timer.getTime() + 0.05)  -- reschedule first
       
       for wpn_id_, wpnData in pairs(tracked_wpns) do
           if wpnData.wpn:isExist() then  -- just update position and direction.
               wpnData.pos = wpnData.wpn:getPosition().p
               wpnData.dir = wpnData.wpn:getPosition().x
           else -- wpn no longer exists, must be dead.
               tracked_wpns[wpn_id_] = nil -- remove from tracked weapons first.
               local ip = land.getIP(wpnData.pos, wpnData.dir, 40)  -- terrain intersection point with weapon's nose.  Only search out 20 meters though.
               local impactPoint
               if not ip then -- use last position
                   impactPoint = wpnData.pos
               else -- use intersection point
                   impactPoint = ip
               end
               for i = 1, #segmentPolys do
                   if mist.pointInPolygon(impactPoint, segmentPolys[i]) then -- weapon impacted in runway segment!
                       runwayHits[i][#runwayHits[i] + 1] = wpnData.init
                   end
               end
           end
       end
   end
   
   track_wpns()
   
   ----------------------------------------------------------------------------------
   --  MISSION SCORING AND DEBRIEF
   function scoreMission() 
       local deathPenalty = -175
       local hitBonus = 50
       local hitBonusDecay = 0.7
       local reqPoints = 200
   
       local score = 0
       
       local loseFlag = 2001  -- for playing a sound (I could have used trigger.action.outSound, but I still would have had to attach the sound file on a trigger somewhere anyway)
       local winFlag = 2000   -- for playing a sound (I could have used trigger.action.outSound, but I still would have had to attach the sound file on a trigger somewhere anyway)
   
       local scoreMsg = 'Your mission score:\n\n'
   
       local numDeaths = 0
       for id_, object in pairs(mist.DBs.deadObjects) do
           if object.objectData and object.objectData.unitName then
               if object.objectData.unitName == '101' or object.objectData.unitName == '102' or object.objectData.unitName == '103' or object.objectData.unitName == '104' then
                   numDeaths = numDeaths + 1
               end
           end
       end
       
       score =  score + numDeaths*deathPenalty
       
       for i = 1, #runwayHits do
           local hitScore = 0
            for i = 1, #runwayHits[i] do
               hitScore = hitScore + hitBonus*hitBonusDecay^(i-1)
            end
            scoreMsg = scoreMsg .. tostring(#runwayHits[i]) .. ' hits on runway segment ' .. tostring(i) .. ': ' .. tostring(mist.utils.round(hitScore, 1)) .. ' points.\n'
            score = score + hitScore
       end
       
       scoreMsg = scoreMsg .. '\n' .. tostring(numDeaths) .. ' aircraft lost: ' .. tostring(numDeaths*deathPenalty) .. ' points.\n\n'
       
       scoreMsg = scoreMsg .. tostring(score) .. ' total points (' .. tostring(reqPoints) .. ' points needed for mission success).\n\n'
       
       if score < reqPoints then
           scoreMsg = scoreMsg .. 'MISSION FAILURE!'
           trigger.action.setUserFlag(loseFlag, true)
       else
           scoreMsg = scoreMsg .. 'MISSION SUCCESSFUL!'
           trigger.action.setUserFlag(winFlag, true)
       end
       trigger.action.outText(scoreMsg, 40)
      
   -------------------------------------------------------------------------------
       -- Debriefing second page
       local function makeMsgLine(segNum)
           local hitsBy = {0, 0, 0, 0}
           for i = 1, #runwayHits[segNum] do
               if runwayHits[segNum][i] == '101' then
                   hitsBy[1] = hitsBy[1] + 1
               elseif runwayHits[segNum][i] == '102' then
                   hitsBy[2] = hitsBy[2] + 1
               elseif runwayHits[segNum][i] == '103' then
                   hitsBy[3] = hitsBy[3] + 1
               elseif runwayHits[segNum][i] == '104' then
                   hitsBy[4] = hitsBy[4] + 1
               end
           end
       
           return 'Hits on runway segment ' .. tostring(segNum) .. ': ' .. tostring(#runwayHits[segNum]) .. ' total hits;     ' .. tostring(hitsBy[1]) .. ' hits by 101;     '  .. tostring(hitsBy[2]) .. ' hits by 102;     '  .. tostring(hitsBy[3]) .. ' hits by 103;     '  .. tostring(hitsBy[4]) .. ' hits by 104.'
       end

       local msg = 'Additional weapons delivery information:\n' .. makeMsgLine(1) .. '\n' .. makeMsgLine(2) .. '\n' .. makeMsgLine(3) .. '\n' .. makeMsgLine(4) .. '\n' .. makeMsgLine(5)

       mist.scheduleFunction(trigger.action.outText, {msg, 40}, timer.getTime() + 40)
   end
   
end

 

 

 

This script has three main parts:

 

THE EVENT HANDLER:

Using mist.addEventHandler, we create an event handler that does the following: if a "shot" type event occurs (world.event.S_EVENT_SHOT), it captures each weapon's object and stores it in a table named "tracked_weapons"- but only if Unit.getTypeName returns a string typeName for that weapon that includes "BetAB_500"! So basically, it only stores BetAB-500 type bombs. Finally, in "tracked_weapons", the event handler also stores the name of the unit that shot the weapon, the initial position of the weapon, and the initial direction the weapon's nose is pointed (Pos3.x) as well.

 

THE WEAPONS TRACKING FUNCTION:

Using mist.scheduleFunction, we create a function that runs 20 times a second. This function looks inside the "tracked_weapons" table. For each entry in the tracked_weapons table, it first determines if that weapon is still alive. If that weapon is still alive, it updates the weapon's position, and updates the direction that the weapon's nose is pointed.

 

However, if the weapon is no longer alive, then we assume that the weapon impacted somewhere (you couldn't make this assumption for missiles, however!). First, we erase this weapon from the "tracked_weapons" table. Next, using land.getIP, we get the point on the ground that the weapon was pointed at- BUT ONLY IF THAT POINT IS WITHIN 40 METERS OF THE WEAPON. If land.getIP gave us a probable impact point of the weapon with these parameters, then that's where we assume the weapon impacted. If not, then we use the last known position of the weapon.

 

Finally, we compare this probable weapon impact point to five different polygon zones representing five different runway "segments". We make this comparison using mist.pointInPolygon. The polygon zones are created by the waypoints of five different aircraft groups (that are never activated). If the point is in one of the polygon zones, we store which polygon zone the weapon impacted inside, and who dropped the bomb, in the "runwayHits" table. Later, we will use this data for mission scoring and debrief.

 

The runway "segments":

 

MISSION SCORING:

Finally, we run a scoring and debrief function that gives you positive points for hits made on the runway segments (each sequential hit on the SAME runway segment is worth 70% as much as the previous hit on that segment), subtracted by a "deathPenalty". The deathPenalty subtracts 175 points from your mission score for each aircraft lost. Dead aircraft are counted using mist.DBs.deadObjects. If your final score is above 200 points, you "win" the mission, otherwise you lose. A "two page" debrief is provided, the first page of which details your mission score, and the second page of which tells you which multiplayer clients hit which runway segments, and how many times they did so.

 

 

Anyway, to see this all in action, run the attached mission. Bomb the runway. Now, select the "Ready for Debrief" option from the F10 "Other" radio menu.

 

So to those who know Lua, we can already track weapons in zones (however, there will be some weapons types you will not be able to get the names of with Unit.getTypeName). I would indeed suggest, now that the scripting engine is incorporated officially into DCS, that it would be a good idea to start learning the Lua language if you haven't already.

 

That said, we will, OF COURSE, continue to add to the selection of Mist Lua functions that are usable by persons without detailed knowledge of the Lua language, and we hope that this one day includes specialized Mist Lua functions for detecting weapons impacting in zones. Not everyone has the time (or desire) to learn programming, and that's what Mist is about- trying to save people time, and making mission creation easier :thumbup:

Weapons Impacting On Runway Demo.miz

Edited December 6, 2012 by Speed

[Speed]

Here's a stupid but fun one: fire guns in the attached mission to launch a "nuclear missile". Just make sure no other units are within 3 km of you when you do! :D

 

 

do
local prox = 3e3
local maxRange = 75e3
local distPerTick = 75
local cooldown = 30

local function nuke(vars)

	local function explode(pos, launcher)
		local msg = ''
		for id, unitData in pairs(mist.DBs.aliveUnits) do
			local unit = Unit.getByName(unitData.unitName)
			if unit then
				local dist = mist.vec.mag(mist.vec.sub(unit:getPosition().p, pos))
				if dist < 5000 then
					if dist > 500 then
						dist = 500
					end
					msg = msg .. launcher .. '\'s nuclear missile explodes, hitting ' .. unitData.unitName ..'!\n'
					trigger.action.explosion(unit:getPosition().p, dist)
				end
			end
		end
		trigger.action.explosion(pos, 50e6)
		if msg ~= '' then
			trigger.action.outText(msg, 10)
		end
	end



	local launcherName = vars.launcherName
	local pos = vars.pos
	local dir = vars.dir
	local closestUnit = vars.closestUnit
	local prevRange = vars.prevRange
	local count = vars.count
	local start = vars.start
	
	-- first, update pos
	pos = mist.vec.add(mist.vec.scalar_mult(dir, distPerTick), pos)
	
	--now see if it's under land
	if land.getHeight(mist.utils.makeVec2(pos)) > pos.y then
		explode(pos, launcherName)
		return
	end
	
	--maxRange check
	if mist.vec.mag(mist.vec.sub(pos, start)) > maxRange then
		explode(pos, launcherName)
		return
	end
	

	if not closestUnit then
		for id, unitData in pairs(mist.DBs.aliveUnits) do
			if unitData.unitName ~= launcherName then
				local unit = Unit.getByName(unitData.unitName)
				if unit then
					local dist = mist.vec.mag(mist.vec.sub(unit:getPosition().p, pos))
					if dist < prox then
						closestUnit = unit
						prevRange = dist
					end
				end
			end
		end
	else
		if closestUnit:isExist() then
			local dist = mist.vec.mag(mist.vec.sub(closestUnit:getPosition().p, pos))
			if dist > prevRange then  -- explode
				explode(pos, launcherName)
				return
			else
				prevRange = dist
			end
		else  -- explode
			explode(pos, launcherName)
			return
		end
	end
	
	-- if here, just create a tracking explosion (if necessary) then re-schedule.
	if count%7 == 0 then  --create a tracking explosion
		trigger.action.explosion(pos, 5)
	end
	count = count + 1
	
	local newVars = {}
	newVars.launcherName = launcherName
	newVars.pos = pos
	newVars.dir = dir
	newVars.closestUnit = closestUnit
	newVars.prevRange = prevRange
	newVars.count = count
	newVars.start = start
	
	mist.scheduleFunction(nuke, {newVars}, timer.getTime() + 0.05)
	
end

local cooldowns = {}
local names = { [1] = 'F-15 #1',
				[2] = 'F-15 #2',
				[3] = 'F-15 #3',
				[4] = 'F-15 #4',
				[5] = 'Su-27 #1',
				[6] = 'Su-27 #2',
				[7] = 'Su-27 #3',
				[8] = 'Su-27 #4'
				}
				
local function launchNuke(initiator)
	local pos3 = Unit.getPosition(initiator)
	if pos3 then
		local dir = pos3.x
		local pos = mist.vec.add(mist.vec.scalar_mult(dir, 100), pos3.p)
		local vars = {}
		vars.launcherName = Unit.getName(initiator)
		vars.pos = pos
		vars.dir = dir
		vars.count = 0
		vars.start = pos
		nuke(vars)
		trigger.action.outSound('nuke.wav')
		for i, name in pairs(names) do
			if vars.launcherName == name then
				mist.scheduleFunction(trigger.action.setUserFlag, {i, true}, timer.getTime() + 30.1)
			end
		end
	end
end

local shotHandler = function(event)
	if event.id == world.event.S_EVENT_SHOT then
		if event.weapon and (not Unit.hasAttribute(event.weapon, 'Missile')) and (not Unit.hasAttribute(event.weapon, 'Bomb')) and (not Unit.hasAttribute(event.weapon, 'Rocket')) then
			if event.initiator then
				local initName = Unit.getName(event.initiator)
				if initName and initName ~= '' then
					if cooldowns[initName] then
						if cooldowns[initName] < timer.getTime() - 30 then -- out of cooldown
							cooldowns[initName] = timer.getTime()
							launchNuke(event.initiator)
						end
					else
						cooldowns[initName] = timer.getTime()
						launchNuke(event.initiator)
					end
				
				end
			end
		end
	end
end

mist.addEventHandler(shotHandler)
end

 

F-15 vs Su-27 WITH NUKES.miz

[Grimes]

Can't force system failures on client aircraft with LUA either. However blowing up units is kind of easy, although I'm not sure how big of a performance impact there will be with the following method.

 

Use mist.getUnitsinZones to populate a table of units within the zone radius. Once you have the table of units within the zone iterate through each unit and get the units position. Then generate an explosion at each position using this trigger.action.explosion(vec 3, power).

[Speed]

How to un-protect the mission scripting environment so you can write files, load modules, etc.

 

To ensure your safety, several "dangerous" Lua modules are removed, aka "sanitized", from the mission scripting Lua environment. These modules are the io library (read/write files), the os library (command prompt access), the lfs library (Lua File System- creation of folders, folder location, files in folders, etc.) and the require and loadlib functions. This prevents someone from making a mission that will install viruses/format your C: drive, etc when you run it.

 

Several patches back, "Saint" (Святой) helpfully moved this "sanitization" code from C++ into the ./Scripts/MissionScripting.lua file. This allows you to optionally un-protect the mission scripting Lua environment and have access to the FULL set of Lua libraries. So, you could for example, output mission data to a file for use in Excel, load Lua socket and send mission data over the network- whatever you desire!

 

So, to un-protect the mission scripting Lua environment, you simply need to comment out lines 33 through 39 of ./Scripts/MissionScripting.lua:

 

I would not recommend this as a permanent mod, not if you ever run missions/tracks from untrustworthy sources, but this SURE comes in useful from time to time!

Edited December 9, 2012 by Speed

[Ripcord]

This allows you to optionally un-protect the mission scripting Lua environment and have access to the FULL set of Lua libraries. So, you could for example, output mission data to a file for use in Excel, load Lua socket and send mission data over the network- whatever you desire!

 

Interesting... So a fellow could create database of flags and write that data to an excel file, and then have another mission read that same database of flags?

 

My thought is that this would enable a mission designer to do some rudimentary version of damage tracking for SAM/AAA and EW units/ groups, as well as for artillery and really any number of 'front line' combatants. So you could have a semi-dynamic moving FLOT from mission to mission.

 

Suddenly building a proper ground-war campaign gets a helluva lot more interesting.

 

EDIT: Let me understand this better -- if one were to build a mission that wrote data to a third file, as well as read data from the same file, what would that require in terms of this mod, Speed? Would it mean that that each user would need to have this same mod set up, as you have shown us here, with the lines commented out? Surely that would be heading a bit too far in the direction of a permanent mod, and ED might intervene and break this feature, should they perceive that it puts users too much at risk -- nothing prevents someone from making a mission that will install viruses/format your C: drive, etc when you run it.

 

An ideal scenario would be to work with ED a little bit here and ask for a set up whereby ANY novice mission builder would have the ability to WRITE ALL FLAG VALUES (from Flag 1 to 9999) to a file, whenever triggered in the mission editor, as well as allowing the same novice mission builder the ability to READ ALL FLAG VALUES, again from 1 to 9999, from the same said file -- and to allow us the ability to do this NOT AS A MOD that opens the door to God-knows-what, but within the framework of the ME and the sim. Essentially WRITE ALL FLAG VALUES and READ ALL FLAG VALUES should be Actions that can be selected in the trigger menu. Wags will recognize the value in this, as they allowed for this in Janes F/A-18 years ago (campaign variables) as well as allowing for damage tracking.

 

If I have derailed the thread I apologize -- but this is potentially HUGE.

Edited December 12, 2012 by Ripcord

[Grimes]

You can certainly write files. That is how we created the DB examples and I often output tables for bug testing missions. Opening files is a different issue that Speed could better answer. However as your edited posts notes, these lua environments have been sanitized by default for a very good reason.

[Ripcord]

Do you think it is a reasonable request, then, to ask that we have an 'in-game' trigger action to write/read flag values? Certainly we cannot demand it, or even expect it, but what an improvement it would be.

[Speed]

Interesting... So a fellow could create database of flags and write that data to an excel file, and then have another mission read that same database of flags?

 

My thought is that this would enable a mission designer to do some rudimentary version of damage tracking for SAM/AAA and EW units/ groups, as well as for artillery and really any number of 'front line' combatants. So you could have a semi-dynamic moving FLOT from mission to mission.

 

Suddenly building a proper ground-war campaign gets a helluva lot more interesting.

 

EDIT: Let me understand this better -- if one were to build a mission that wrote data to a third file, as well as read data from the same file, what would that require in terms of this mod, Speed? Would it mean that that each user would need to have this same mod set up, as you have shown us here, with the lines commented out? Surely that would be heading a bit too far in the direction of a permanent mod, and ED might intervene and break this feature, should they perceive that it puts users too much at risk -- nothing prevents someone from making a mission that will install viruses/format your C: drive, etc when you run it.

You're worrying too much. If I'm writing a MissionScripting.lua mod, it is quite simple to create a "sandbox" for all mission scripts so that only MY functions can access the dangerous Lua libraries (io/lfs/os), but nothing else can. If we want a function that can read/write flags, but we don't want the io/lfs/os libraries to be usable by mission scripts, we can have it.

 

An ideal scenario would be to work with ED a little bit here and ask for a set up whereby ANY novice mission builder would have the ability to WRITE ALL FLAG VALUES (from Flag 1 to 9999) to a file, whenever triggered in the mission editor, as well as allowing the same novice mission builder the ability to READ ALL FLAG VALUES, again from 1 to 9999, from the same said file -- and to allow us the ability to do this NOT AS A MOD that opens the door to God-knows-what, but within the framework of the ME and the sim. Essentially WRITE ALL FLAG VALUES and READ ALL FLAG VALUES should be Actions that can be selected in the trigger menu. Wags will recognize the value in this, as they allowed for this in Janes F/A-18 years ago (campaign variables) as well as allowing for damage tracking.

 

If I have derailed the thread I apologize -- but this is potentially HUGE.

 

Hmm... but could it be exploited to make a mission that fills up your hard drive? Maybe the risk would be worth it... after all, from 1.1.0.5 to 1.1.0.8 we had a completely unsecured and open mission scripting environment, and there were no malicious missions passed around that I know of.

Edited December 13, 2012 by Speed

[Grimes]

Not sure people knew much about the mission scripting environment at that time.

[gunterlund21]

ok so I copied and pasted Mistv1_1 into a do script trigger. Then I created another do script trigger with mist.flagFunc.mapobjs_dead_zones{ zones = {'Kurta Bridge'}, flag = 51 } in the do script. I placed the zone called Kurta Bridge over a bridge. I have another trigger that messages if flag 51 is true. Im not getting the message when the bridge is destroyed. Am I missing anything?

[Speed]

ok so I copied and pasted Mistv1_1 into a do script trigger. Then I created another do script trigger with mist.flagFunc.mapobjs_dead_zones{ zones = {'Kurta Bridge'}, flag = 51 } in the do script. I placed the zone called Kurta Bridge over a bridge. I have another trigger that messages if flag 51 is true. Im not getting the message when the bridge is destroyed. Am I missing anything?

 

Doesn't sound like there is anything wrong. Please upload the mission. I'll also double-check that the function is operating correctly. I just looked over its code, and I realized that the Mist manual is wrong about it- I believe that in the Mist manual, I state that mist.flagFunc.mapobjs_dead_zones counts up all map objects ever destroyed in that zone, but that's wrong- it only counts dead map objects that were killed AFTER the function/process began operating (so it works just like the similar Slmod function).

[Speed]

Ok, and I just doubled-checked mist.flagFuncs.mapobjs_dead_zones in 1.2.2.7286. The function still works successfully. I used a script almost identical to yours:

 

mist.flagFunc.mapobjs_dead_zones{zones = {'bridge'}, flag = 10}

 

Flag 10 is set true when the bridge map object within the zone named "bridge" dies.

 

Test mission is attached.

test of mapobjs_dead_zones.miz

Edited December 17, 2012 by Speed