Speed

Personally, I just avoid bridges and road travel as much as possible. You need good, open battlefields without a lot of obstructions for the best ground AI behavior and CA experience. We're working on getting the bugs reported, but there are a lot of them still.

:mad: Entertainment, duh!

Dumb question... this almost certainly won't help... but have you tried disabling your virus scanner? It's just that several times, I've seen weird problems like this trace back to virus scanners and/or firewall programs that interfere with the operation of your computer in the name of "security", and really just end up causing more headaches than they solve.

Yea, it's not a problem on your end, several users have now reported the same problem. I was in teamspeak earlier today with one of them, and we even tried deactivating and reactivating his FC3. He said that allowed him to log in to the master server, but as soon as he restarted DCS, the problem returned.

OK, look very closely at the spelling of the first argument in TestFct TestFct = function(goupName,unitName) mist.groupToPoint(groupName,"TZ1",nil,270,14,0) local fakeZone = {} local pos = Unit.getByName(unitName):getPosition().p fakeZone.point = { x = pos.x, y = pos.y, z = pos.z} trigger.action.explosion(fakeZone, 100) end See it yet? This is why Lua does not make a good language to program anything extremely complex in... Heck, Lua even officially admits this, I came across a statement the other day, when trying to figure out if it was possible to make private data fields for Lua objects that could only be accessed from getter or setter methods of the object itself. The statement basically said, in a more verbose fashion, "sorry, Lua is supposed to be used for simple stuff". Of course, that doesn't mean you CAN'T write complex stuff in Lua, but you'll spend more time trouble-shooting than you would in some other languages... and if you are slightly dyslexic... you might spend A LOT more time trouble-shooting :D Secondly, you are not using trigger.action.explosion correctly. It expects a Vec3 argument as its first variable. It does not expect anything like a "zone". Vec3 is {x = number, y = number, z = number}. Here is a corrected version of your TestFnc TestFct = function(groupName,unitName) mist.groupToPoint(groupName,"TZ1",nil,270,14,0) trigger.action.explosion(Unit.getByName(unitName):getPosition().p, 100) end

Lua is kinda ridiculous like that- things default global if you don't put local in front of them. It's because it's a scripting language intended for simple things, usually. But it runs fast enough that you CAN create fairly complicated scripts with it. You can change the default behavior of Lua, however, by modifying the __newindex metamethod of _G. I haven't tested this particular code, but this ought to make it impossible to declare global variables except with rawset or the function "makeGlobal": function makeGlobal(key, val) assert(type(key) == 'string', "Why would you want to create a global variable with a key type of " .. type(key) .. "?!?!") rawset(_G, key, val) end do local function _GNewIndex(G, key, val) -- G in this case is _G. assert(false, "Attempt to create new global variable at key \"" .. tostring(key) .. "\". Please use rawset(_G, <key>, <val>) or makeGlobal(<key>, <val>) to make a global variable.") end setmetatable(_G, {__newindex = _GNewIndex}) end Though, if you don't get into the habit of using "local", you'll keep making mistakes. I'll check out your mission. In the future though, please elaborate further than "strange error", Lua usually tells you very clearly what went wrong.

I don't have DCS in front of me right now, and I don't have a lot of time, but I'll try to help. Well, I'm no expert on the groupToPoint function, I didn't write it. But you do clearly have an issue with your EXPLODETEST function- EXPLODETEST = function(goupname,unitname) mist.groupToPoint(groupname,"TZ1",nil,270,14,0) local fakeZone = {} pos = Unit.getByName(unitName):getPosition().p fakeZone.point = {x = pos.x,y = pos.y, z = pos.z} trigger.action.explosion(fakeZone, 100) return end Two issues, actually, one that will cause it not to work, and the second that is usually bad programming practice. The most severe issue is that you are passing in a variable named "unitname", but you use a variable named "unitName" in your function. unitName will be nil, unless you have it globally defined somewhere. Secondly, because you do not write "local" in front of the first declaration of "pos", then "pos" is a global variable that every single other thing in Lua can now see. Global variables need to be restricted to only those things that absolutely have to be global variables. There are two reasons- 1) It's good programming practice; you don't want a mess of global variables filling your global namespace and causing problems with unrelated parts of your code. 2) Secondly, due to the way that Lua retrieves the values of variables, using global variables is less efficient than using local variables. In sections of code where, for example, you use a global function like table.remove hundreds or thousands of times in a loop, I usually make a local reference to the function to improve the efficiency and speed of my code. Oh and finally, you only need to use "return" if you need to break out of a function before it would naturally return, or you need to return a value. You don't need to put "return" at the very end of a function, when it would just return anyways. Rarely though, I do put a "return nil" in my code, usually in my object destructor functions, but that's just to remind myself that I should use it like obj = obj:destroy().

Well, I know that the "start" action is not working for uncontrolled planes. :( That breaks a lot of missions.

Correct, that means "all blue planes + all blue helicopters".

I'm not exactly sure what your problem is- what do you mean by "The only time it works as designed is the latter." Define "works". Also, define not working. Anyway, the reason I don't understand what you're trying to do is because you're not using the unit table shortcuts correctly, see below. So I don't know what you're expecting to happen, so I don't know what "works" means. But secondly, [blue][plane][helicopter] is not a valid category. So it recognizes [blue], but it doesn't recognize what [plane][helicopter] means. What are you trying to detect, when a V-22 Osprey comes into zone?! :D Anyway, unless Grimes has changed it, from what I can tell, since it doesn't recognize "[plane][helicopter]", then it should just default to everything blue. Edit- this is a list of all the Unit table shortcuts- --[[ Prefixes: "[-u]<unit name>" - subtract this unit if its in the table "[g]<group name>" - add this group to the table "[-g]<group name>" - subtract this group from the table "[c]<country name>" - add this country's units "[-c]<country name>" - subtract this country's units if any are in the table Stand-alone identifiers "[all]" - add all units "[-all]" - subtract all units (not very useful by itself) "[blue]" - add all blue units "[-blue]" - subtract all blue units "[red]" - add all red coalition units "[-red]" - subtract all red units Compound Identifiers: "[c][helicopter]<country name>" - add all of this country's helicopters "[-c][helicopter]<country name>" - subtract all of this country's helicopters "[c][plane]<country name>" - add all of this country's planes "[-c][plane]<country name>" - subtract all of this country's planes "[c][ship]<country name>" - add all of this country's ships "[-c][ship]<country name>" - subtract all of this country's ships "[c][vehicle]<country name>" - add all of this country's vehicles "[-c][vehicle]<country name>" - subtract all of this country's vehicles "[all][helicopter]" - add all helicopters "[-all][helicopter]" - subtract all helicopters "[all][plane]" - add all planes "[-all][plane]" - subtract all planes "[all][ship]" - add all ships "[-all][ship]" - subtract all ships "[all][vehicle]" - add all vehicles "[-all][vehicle]" - subtract all vehicles "[blue][helicopter]" - add all blue coalition helicopters "[-blue][helicopter]" - subtract all blue coalition helicopters "[blue][plane]" - add all blue coalition planes "[-blue][plane]" - subtract all blue coalition planes "[blue][ship]" - add all blue coalition ships "[-blue][ship]" - subtract all blue coalition ships "[blue][vehicle]" - add all blue coalition vehicles "[-blue][vehicle]" - subtract all blue coalition vehicles "[red][helicopter]" - add all red coalition helicopters "[-red][helicopter]" - subtract all red coalition helicopters "[red][plane]" - add all red coalition planes "[-red][plane]" - subtract all red coalition planes "[red][ship]" - add all red coalition ships "[-red][ship]" - subtract all red coalition ships "[red][vehicle]" - add all red coalition vehicles "[-red][vehicle]" - subtract all red coalition vehicles Country names to be used in [c] and [-c] short-cuts: "Turkey" "Norway" "The Netherlands" "Spain" "UK" "Denmark" "USA" "Georgia" "Germany" "Belgium" "Canada" "France" "Israel" "Ukraine" "Russia" "South Osetia" "Abkhazia" "Italy" ]]

No. However, if the player picks the wrong aircraft, you could deactivate them and pop up a message telling them which aircraft they should be flying.

No. You can always check for yourself by reading a dump of _G. _G stores all global variables, so if you iterate through it (recursively, so that you also iterate through all the tables it contains), and output the results to a file (what I call a "_G dump"), you will see everything there is to see. In some cases, however, you will find functions that are not officially supported by ED, so if you find them, use them at your own risk.

Yea, I was looking for this the other day. It turns out that we forgot to request it, and/or Saint forgot to add it. Can't remember which. All hope is not lost. You can still get skill, you just have to work for it more- you do have env.mission. And if you're dynamically adding any groups, you know what their skill is. So to get a unit's skill, you need to look in env.mission. env.mission holds the mission table. So you'll have to step through that, and throw all the units into a big database (my favorite is to make them into a DB by unit name), and then you can quite easily just get the skill by indexing that particular unit's .skill. Mist does this for you automatically, in the mist.DBs.unitsByName table. You don't need all of mist for this, just get the parts that are relevant to DB building from env.mission. So now, to get the skill of a unit named <unit name>, you would just use local skill = mist.DBs.unitsByName[<unit name>].skill

Unlikely, though some units (like tanks) may be able to do it. ALARM STATE can be thought of forcing a unit into various detection states. "Alarm state red" basically forces them into the "enemy units detected! posture." It's the state right before they fire a weapon. So units that can't move and shoot simultaneously should most certainly stop when given alarm state red. Anyway, try experimenting around with different group combinations (like, try all T-55s, or better yet, single-unit groups), and see if some units will move while red, and if so, which.

At the current rate things are going, there will be no 7th gen jet fighters, as no will be able to afford them. Yea, that's the other thing I was thinking- put 4*pi steradians of IRST on it, and just add some gimballed, high-power solid state lasers. Dogfights will be gunz and lazorz only. :D

(Yes, I'm back but currently at a low level of activity; I am slowly ramping up my activities as time allows between work and other projects.) If you want to save data from the mission to the hard drive, you must modify MissionScripting.lua. Put a do - end closure before lfs and io are sanitized, and make local references to io and lfs inside that do - end closure. Now, you can write some global functions inside that do-end which will be able to "see" the lfs and io as upvalues, even though io and lfs will still be sanitized from the global environment. You might want to sanitize debug.getupvalue, however, as otherwise it can be used by a malicious mission creator to break into your do-end closure and get references to io and lfs. Unfortunately, however, sometime during like 1.2.4, Saint (accidentally or not, I donno) made Lua debugging dependent on the debug lib, so you might not get proper Lua error reporting if you sanitize away debug.getupvalue. That can be fixed however, if you start handling error reporting yourself using pcall, but that's a different can of worms, as you pretty much have to do debug reporting on a per-function basis. All that said, I'm not sure if debug.getupvalue is used at all for the internal bug reporting; all I know is that if you completely sanitize away debug, then you'll get a lot of "error in error reporting" messages.

Ok, I am back from vacation now. I'll be getting to work on Slmod and Mist and testing and other things. I suspect that the reason that many of the Slmod events-based things are no longer working is that the internal event code that Slmod was exploiting has changed. Slmod has been using two closely related simulator events systems/formats, partly for backwards compatibility and partly because it USED to be necessary. It may no longer be. I may have to finally re-write all the internal Slmod events code to use just one events system. The downside is that weapons names in functions like units_firing may change, but maybe I could make a names/aliases database.

Ummm... is that pseudocode you posted? Anyway, without pcall, the Lua calling the untrusted code will crash. I donno why you would ever want to do that. It's better if you just test whether or not the first value returned by pcall was true or false. pcall returns true (plus any values returned by the function) if the function it calls executes without error. If there is an error, pcall returns false, plus an error message string that tells what the error was.

If you need to dostring on untrusted code, you make a sandboxed environment for that code, and run it in there. do local untrustedLua = <some string data from where ever, that you don't necessarily trust> local env = {} --[[ now, either add to env all the functions you think are safe, or copy everything from _G into env except those functions/libs you think are unsafe. It is probably better to manually add references to safe functions/libs to env rather than copy over _G and then remove unsafe refereneces. That way, you are not dependent on what else _G might or might not contain. ]] --[[in this example, I copy a few SAFE funcitons/libraries from _G into env that are safe. Do not consider this a complete set of safe functions! Google "Lua Sandboxing" for a more complete list!]] env.print = print env.string = string env.table = table env.math = math env.loadstring = loadstring -- etc. local f = loadstring(untrustedLua) --now, compile the untrusted code if f then -- the untrusted Lua compiled successfully. setfenv(f, env) -- Switches the environment the compiled, untrusted code will run in from _G to our new, safe environment. pcall(f) -- now, run the unsafe code in our safe environment, where it cannot do any damage. -- Also note the use of pcall. pcall prevents runtime errors in the untrusted Lua code from causing a -- Lua error. end end

I've seen the "error in error handling" message myself. I didn't associate the change with Slmod though... I thought it was a peculiar error in the scripting system. I think I got it when running a scheduled function. Are you positive Slmod is associated with this, and it's not some bug with 1.2.4? I will certainly grant it's possible Slmod is causing it, or at least triggering it, as it modifies MissionScripting.lua, but I don't see how or where a problem like this could creep in. Anyway, thanks for the report, I'll check it out and let you know what I find.

Get the weapon from a shot event event handler that adds the weapon to a table of "tracked weapons". Using a very rapidly-rescheduled function, track the alive/dead status of tracked weapons and their position with Object.isExist and Object.getPosition. When Object.isExist fails on a tracked weapon, then it has exploded in game. Set a trigger.action.explosion off at the last recorded position of the weapon. Be warned though... there are bugs with weapon shot events and multiplayer clients for some types of shot weapons. Be sure to test any such code thoroughly in multiplayer.

No, it's just a virtual object in the game, represented only in code, not with an actual 3D object. It owes its existence to a rapidly re-scheduled (using mist.scheduleFunction) function call that receives arguments from the previous scheduled function call. For fun, I make the virtual object's path be traced through the 3D world with occasional explosions and flares. That way, you can see it coming and dodge out of the way :D

There is an option that (mostly) disables SlmodStats (unless a server admin turns it back on). To go to this mostly-off mode, you, set enable_slmod_stats = false in the config.lua file. I think another config.lua option that disables the stats menu as well might be good. No need for it if you never track any stats. The problem with making a "no-SlmodStats" mode was it put so many roots into other components that I had a hard time thinking of a good way to make Slmod run without at least some SlmodStats code running. It wouldn't be easy to entirely remove it, but it could be done. As xcom mentions though, you can always build a restart timer into the mission trigger logic itself. Once -> Time More (<some number>) -> Load Mission (mission)

Well, here is one really easy option you could also try: on line 457 of SlmodCallbacks.lua, you should see: if slmod.clients[id] and (not slmod.clients[id].motdTime or net.get_real_time() - slmod.clients[id].motdTime > 5) then Change this to: if slmod.clients[id] and (not slmod.clients[id].motdTime or net.get_real_time() - slmod.clients[id].motdTime > 1800) then And this will prevent the MOTD from being delivered any more often than once every 1800 seconds (30 mins). But yes, you can rotate missions solely using trigger logic. A think a definite improvement to the MOTD would be to increase this time to be a lot less often. It was at 10 minutes, but I changed it to (I thought 10 seconds- but it looks like 5 seconds) when I added the "default keystroke for chat in your module is <>" line. I think an optimal solution would be this: 1) Change the time back to like, 30 minutes or something. 2) Remove the "the default keystroke for chat in your module is <>" message from the MOTD and make it part of a different message entirely. Maybe make the chat keystroke message appear every time you are physically inside a new aircraft that has a different keystroke for chat than the one you were in before. Part 2) will take a fair amount of extra logic, but is doable.

Yes, you can edit the base Lua code in SlmodMOTD.lua, but is it wise to do so? Probably not. Maybe it's time to "protect" Slmod in Lua byte code? :D But no, just kidding... if you want to remove the Slmod info, I'll just shake my head and sigh. For the most part, I've tried to be completely open to modifying stuff in accordance with user feedback, but on the MOTD providing information on how to use Slmod... I think that's the first time I'll have to say "that's the way it's gonna be, and if you don't like it, then go in and change it yourself." However, you can change my mind, if you can give me a valid reason why it should be changed. I guess also if there is a strong enough negative response, that could change my mind too- in which case, I would still think you're wrong, but I wouldn't have much of a choice in the matter. I do agree that I should shorten it as much as possible, but even at maximum shortness it will probably still be 3 or 4 lines. As far as mission rotation goes- I assume you've got Servman working? Did you have to modify anything in servman_server.lua or was it just main.lua modifications? Do you think it would be worth the time to make one last Slmod/Servman version?