cfrag

Yes. Since you say that the direction that the aircraft moving in is normalized, it means that the magnitude of the direction is one. If you multiply that vector by the speed (itself a scalar value in m/s) you have the velocity vector for that aircraft. It is moving in that direction by that amount every second. So, to see where that plane will be in 7 seconds, multiply the velocity vector by 7, and add the resulting vector to the starting point. The result is the point where (no changes in speed or direction assumed) the plane will be in 7 seconds.
 

Have you de-sanitized your DCS installation? By default, the modules lfs, io and os are 'sanitized', i.e. set to nil. That may be where you get the nil error from. It would of course help if you posted the error message and location where the error happened.

change your script to 
["x"] = 77192, -- use dcs local coords ["y"] = 244632, -- use dcs local coords when spawning, you must use DCS local coords for your objects. And "y is z"
unit_location.miz

If by 'or something' you include DML, then yes, near trivially. Please see below demo mission. 
To use in your own mission, simply place the Trigger zone "Endless Respawn every 600 seconds" over the sam group that you want to regularly respawn. Note the trigger zone attributes that control the respawn details. It may look silly, but that's how DML works: no fiddling with Lua code, simply add trigger zones and some attributes that control how the stuff works inside the zone. The trigger zone below has a cloner and a pulser (timer) attached.

The cloner in Kutaisi is set up to clone all the units inside the trigger zone every 600 seconds (= 10 minutes, see 'time' attribute). 
Since you may want to change that set-up should the player manager to destroy the entire sam site before the timer (pulse! in DML) runs out and then no longer respawn all, I've added a slight variation on this (very common) design pattern that stops the timer (pulser) when all units from the last spawn have been destroyed. You'll find it near Kobuleti
DML trigger zones can copy/pasted and will not get in each others way. Note the START trigger that loads the required DML modules (dcsCommon, cfxZones, cfxMX, cloneZones, pulseFlag). That loads DML and no more scripting is required to configure anything after that - it's all done with trigger zone attributes.
 
Hope this helps,
-ch
 
 
autorespawn sams.miz

You are happily invoking "destroy()" on something that you did not make sure that it exists, inviting an error. If you don't get an error dialog and for some reason some lines in your code aren't executed, make sure that you have enabled the error box, else debugging becomes impossible without checking the logs.
Try below simplified code of yours (untested, sorry, on a train). I suspect that some of your units that should be named "Static1" through "Static10" do not exist.
... which brings me to the next point: You call them "Static", but try access them with Unit.getByName(). If whatever you are trying to remove are units, that is fine, just ensure that their name matches. If they are static objects (i.e. NOT units), you need to access them vie StaticObject.getByName()
for i=1, 10 do if math.random(1,100) > 50 then local strObjeto = "Static" .. i local o = Unit.getByName(strObjeto) if o then Unit.destroy(o) trigger.action.outText("Erased ".. strObjeto,5) else trigger.action.outText("unit <" .. strObjeto .. "> does not exist", 30) end end end  

With map objects, it’s very different. Right-click on the map object, and choose the ‘assign as’ pop-up. It’ll place a trigger zone over the map object. Use that trigger zone‘s name to access the zone, then get its (the zone’s) position. That’s the easiest way to access map object locations from Lua.

I agree that it would be prudent to apply some sanity checks at the very beginning of your event processor:
function unitReport:onEvent(event) if not event then return end -- wtf? bad call if not event.initiator then return end -- no initiator, no interest ... (some more test before you dereference them) ... if not event.target then return end end That way, your code won't scream at you when it receives something unexpected (for example, when at a event.dead invocation, a formerly unit object got sneakily converted to a static object and now crashes on getCoalition() and similar fun. Yeah, that can now happen when the unit 'cooks off'. Fun with events.)
 
-ch

The error screen (in a roundabout way) tells you that you need to de-sanitize your DCS install. I recommend you do not do that unless you know what you are doing.
The change that you made to the script may be indicative of the fact that you do not yet know enough scripting to attempts these kind of changes. That's not something bad at all, it merely means that currently, some things will take a lot more effort on your side before you can feel comfortable enough to do them. Unless it is really, really important to you to see the replay, just let it rest. 

A couple of possible causes:
You have set the time filter option to on (the chono/watch icon at the bottom) and the year is WWII. Recovery: turn off the filter. You have moved all combined task forces to neutral in the coalitions panel. Recovery: use the coalitions tool to move them back, and turn on "ALL" coalitions from "COMBAT". Hope this helps,
-ch
 

Short answer: It was changed a few days ago. 
use Object.getCategory(event.initiator) 
 
Long answer
When you invoke event.initiator:getCategory() you should have always received the result of UNIT.getCategory, WEAPON.getCategory, STATICOBJECT.getCategory, etc's invocation - if Lua was a true OOP language, that is, because that is how inheritance is supposed to work. For years, however, this was implemented wrong, and getCategory was not inherited, always invoking the class's root method Object.getCategory
This was changed a few days ago in the second release of 2.9 beta, after years, and quite abruptly; it was mentioned in passing in the release notes. Since this was a long-standing bug, there are now many scripts that rely on the bug to not be fixed, and now break after the bug has been corrected. Many popular libraries need some tweaking because the bug was now being accepted as 'canon'.
Remedy: Since you are interested in the root class invocation of the Object tree, the solution is to explicitly invoke the root class:
Object.getCategory(event.initiator)

AFAIK, there are only a few ground vehicles in the game that have their lights modelled as light sources (not that traffic does not really have light sources, merely a light texture that is painted on the road in front of them, making it appears as light, but those "lights" aren't emissive, they don't illuminate, they do not cast shadows. 
So except for the vehicles that do have missive lights, you can't turn them on. 
Those that do, turn them on automatically when it gets dark. 
Since I've got a bird brain, I forgot which of the ground vehicles in DCS have illuminating lights; it's some kind of a truck, and the LUV Tigr.
Why so few illuminating light sources? Because they kill performance. Or used to. The new lighting that ED are working on (PG/SOH map) may make strides in lighting advancements, it's up to ED to tell us when this will trickle down to other maps. I'm still hoping for user-placable light sources. We'll see.

As I just found out (thanks to @Kanelbolle and @sirrah) you can do this by exploiting an undocumented (let's be charitable) "feature" of the "immortal" command:
If you put "immortal" as the first command  in a group's Advanced waypoints, the entire group is invulnerable to both players and other AI
if you put "immortal" as any other but first command in a group's Advanced waypoints, the entire group is invulnerable to AI, but can be killed by players.
See here: 
 

That's pretty much standard procedure that unfortunately nobody ever explains to you. You aren't really routed to the airfield, but to the known 'reporting point' where you begin your standardized approach to an airfield's active runway. That's usually a couple of miles straight from the airfield's runway, in opposite of the landing heading, so you end up a couple of miles in front of the runway, ready for a straight in or precision approach (which, since for that you'd be on a VOR/TACAN would never require you to get an Azimuth, but I digress). That would be quite convenient if DCS implemented better ATC, right now it feels somewhat annoying. So just ignore, fly to the reporting point and hope that you'd recognize the surroundings so you can turn to final by yourself. Oh, and let's keep our fingers crossed that some day we get some game ATC that's better.

Check the owner (faction) that Krymsk belongs to. If it is not aligned with your faction (i.e. it's blue while you are red) you may be not given the option to talk to them.

The API to create zones while the mission is running isn't documented, yet there are some intrepid souls who venture into the deep to use trigger.misc.addZone() (see here)
So yeah, you should be able to synthesize trigger zones from draw tool polygons, provided that you stick to 4-point polys (theoretically, DCS zones support more than 4 points, but I have never tested this) or discs. Scanning the draw tools from mission.env.drawings isn't that difficult (if annoying), so yeah, you can do that and use addZone().
My question, however, is: whatever for? Since you can't really use these dynamically generated trigger zones for crating missions (they are inaccessible from ME for the simple reason that they do not exist at the time you edit the mission), what use are they to you? I think it would then be better to simple go straight with your own stuff, rip the area from the polys, and write your own 'inside poly' method (quite easy if you keep to convex polys, unpleasant when you allow concave polys). 
What are you trying to achieve? It sounds interesting.

Currently (Oct 23) this is not possible. Maybe it becomes part of  the scripting environment later with the Dynamic Environment. One can hope.

Currently, there are multiple issue, and have been since DCS's inception that need to be overcome:
There isn't an official, formalized API to access cockpit instruments from LUA script (MSE - mission scripting environment) that can be used to pass commands to the currently running cockpit/module. All these 'perform_clickable_action()' use unofficial and undocumented, well, hacks (for lack of a better word, even if vendor-supplied) that are specific to the model that the player is currently flying (rather: the aircraft that the mission was originally designed for). They are therefore 
not multiplayer-compatible and  do not work across multiple aircraft and  aren't portable to other missions It will be a fine day indeed if and when ED release a cross-module, fully functioning cockpit API that would allow missions to script something along the lines of unit:setControl("Throttle", 1, 0.5) - which would set that unit's throttle 1 (if it exists) to 50%. Alas, today we can merely dream.
Even if you don't, I strongly recommend to stay away from trying this. You might succeed in getting some of those hacks to work, but you won't know for how long, will spend a lot of time tracking those down, usually don't know why they work at all, and each time there is an update you run the 'will it still work' fun lottery. Not to mention that it probably will not work for any other plane type, and definitely not in multiplayer (I'm a multi-plane, multiplayer guy, so I tend to eschew single-type, single-player scripts; you may not be deterred by that)
If you truly want to start your hunt for those triggers, set up a mission that uses a cockpit trigger, then analyse the "mission" file's code inside the .miz archive. Look for
["trig"] =  end make the best out of it that you can. Those are the trigger definitions, set up as a mission-wide table. I myself did not find that a particularly fun task, but maybe you are more stubborn than I 🙂
 
 
 

I'm happy it works for you, but I doubt that that was the root cause. There is no need for a 'do' after a 'then'. It's more likely that you had an extra 'end' somewhere, but that is not visible from the code that you originally posted
You may want to balance your code with some indentation to better see what level you are on. Something like this:
S = 1 local function message() timer.scheduleFunction(message, {}, timer.getTime() + 5) if trigger.misc.getUserFlag('FirstLineOut') > 0 and MS == 1 then do local msg = { id = 'TransmitMessage', params = { duration = 15, subtitle = "The first red line is accessible, \narmor 1 and 3 are proceeding to the first stop.", loop = false, file ="l10n/DEFAULT/KOH_firstline.ogg", } } Group.getByName('BLUE_ARMOR-2'):getController():setCommand(msg) end MS = 0 end end message() In above code you can delete the 'do' and the 'end' before MS = 0 

I'm not entirely sure that I understand what poses a problem for you - maybe there are some other conditions that you are thinking of and are obvious to you, but not me...
Otherwise, yes, I'd create the mission exactly as you suggest:
place trigger zones at the locations for the waypoints for each trigger zone, add a Once trigger with condition 'unit in zone' and action "increase flag value", and perhaps use a flag named 'score' - that way once the unit is inside the zone, the flag "score" in increased by one Have a 'win condition' that triggers when the flag "score" EQUALS (number of scoring waypoints)   You should be done. What am I overlooking?

Very much like in ME. You invoke trigger.action.outText() and pass true to the optional clearview parameter. That's like ticking the equivalent box in message to all.
 

That is currently and unfortunately not possible. Also not possible: spawn a unit with half or empty munitions. Hopefully we will gain that ability some time in the future.
 

I'm not sure I understand that sentence. What part of the mission scripting environment do you feel that you do not have access to?
I'm afraid that you have gotten that somewhat wrong. Missions contain the entirety of their code inside the .miz archive. If they rely on files outside of the mission file (the .miz), they will no longer be portable and cannot be freely exchanged. The entirety of the mission scripting environment is accessible from within the mission, you do not have to place other files into other folders.
This is I believe where you may have misread, or (because this subject can be better documented) have not yet come across sufficiently understandable documentation. You see, when you play a game of DCS, you can play it in different "modes" and not every mode offers all services. And those additional services are walled off in a way that nearly completely prohibits their use, so you may as well not use them at all. The two (there may be more) known modes are 'single player' and 'multiplayer'. The big difference here is that in multiplayer, there is an additional server instance running (even if you are local multiplaying on your machine): the server instance. all missions execute as clients, and synchronize with the one server. That server process, which is an entirely different process and has next to no access to the mission running, has access to some additional server-centric singletons, "DCS" among them, along with the "net" singleton.
These singletons are always available to the server, and do not require special installation into the Scripts/ directory.
Now, just like you can write Lua scripts to extend DCS functionality by writing scripts and including them into the .miz (simply by adding them to your mission), you can write additional scripts that can do similar extension to the server singletons. These scripts are indeed placed into the Scripts hierarchy (usually into Hooks/) and always run in the background when the server is active (i.e. multiplayer). There are some well-known scripts, e.g. 'Simple Slot Block' (SSB) that missions can use. Such missions then will always tell you that to enable that functionality, you must a) install those scripts on the server and b) the mission must be run in multiplayer or they won't work.
I'm afraid that there is no such thing. Writing Lua code is as low as you can get 🙂. What can be differentiated is client-side coding (i.e. the code that is run in your mission, also called 'mission context' or 'client context') and server-side code: stuff that is run on the DCS server thread, also called 'server context'. The latter is code that is placed in Scripts/ and needs to invoke some special code in order to be hooked up into the DCS event cycle to be invoked at key moments during the server/mission life cycle.
Mission-side (client) scripting should be 99.9% of what you need, and you already have access to whatever ED deem sufficient for mission scripting (now, I think that we have broad agreement that this is severely lacking, but that is a different story). Serer-side scripting is brutally inefficient to do (in addition to no IDE, there's next to no documentation, and to test a script you have to re-start DCS fully, start a multiplayer game, and then look into the log for your debugging messages) and generally not fun to do. It does not enable you to do things that you can do in missions unless you also write the client-side counterpart, and are content that you can only communicate through flags.
There are some very obscure exceptions that you can get to with net.dostring_in() which is available in the client context, but it's usually not worth writing home about.
When DCS starts. If you change a single character, to test it you must restart DCS
They are all server-only. The sockets api is available without installing anything, but cannot be accessed from the client (mission) context. It is meant for DCS export and communication with devices.
You cannot open, for example, a socket connection directly from your mission to a host of your choice. That's a good thing, for obvious security reasons.

So what is the issue with above mission? 
In cases like this, I try to stop and take a step back; usually, I've made some erroneous assumptions, try to keep holding onto some design that's wrong, or conflated some things that are actually distinct. I then write down what I want and why. Perhaps it would help if you explained why you need those zones at all, and how they figure in your decision making. What is their purpose? If you only need it to detect if a unit exists in the game, perhaps another condition like "Unit Alive" may work better for you?
It may help to write down the conditions under which a unit becomes blocked, and under which a unit becomes free to enter. These transitions in states (blocked-->unblocked, unblocked-->blocked) usually follow clearly definable events, and the events are often what you are looking for. They are the conditions to encode in triggers.

There are multiple ways to achieve what you want. You can first spawn a group, and then access their controller and add a new path to the desired location. Be careful to allow DCS a second or so before accessing a newly spawned group's controller, so use 'scheduleFunction()' for the delayed setting of the path.
OR, you can take a page from how missions spawns groups with the path added to the data that you are generating now. In this case, the route is part of the group's table, and is called, well, "route". 
Something like this:
["route"] = { ["points"] = { [1] = { ["alt"] = 13, ["type"] = "Turning Point", ["ETA"] = 0, ["alt_type"] = "BARO", ["formation_template"] = "", ["y"] = 646420.07565045, ["x"] = -281610.2890057, ["ETA_locked"] = true, ["speed"] = 0, ["action"] = "Off Road", ["task"] = { ["id"] = "ComboTask", ["params"] = { ["tasks"] = { }, -- end of ["tasks"] }, -- end of ["params"] }, -- end of ["task"] ["speed_locked"] = true, } [2] = { ["alt"] = 13, ["type"] = "Turning Point", ["ETA"] = 198.65236602235, ["alt_type"] = "BARO", ["formation_template"] = "", ["y"] = 647014.85075951, ["x"] = -281083.36702851, ["ETA_locked"] = false, ["speed"] = 4, ["action"] = "Off Road", ["task"] = { ["id"] = "ComboTask", ["params"] = { ["tasks"] = { }, -- end of ["tasks"] }, -- end of ["params"] }, -- end of ["task"] ["speed_locked"] = true, }, }, }, In your code you would then substitute for each point the  "x" and "y" for the source (group's spawn point) and destination (where they should run back to) point's coordinates.  Remember that the you must supply the "z" coordinate from those source/destination points for the route's "y" (in DCS internal data, they use x and y to represent x and z, harkening back to a simpler time) and then replace the "alt" for each point (source/dest) with that point's land.getHeight().
If you do that, you should be able to spawn your people with orders to move from source (the point they spawned) back to destination (the known location that they should run back to).
Note: I'm on the road, typed largely from memory and notes, I did not verify above, use at your own risk. 
 

Here's a simple how on demo to do that. When the drone sees targets, it reports how many, and their location in lat/lon/ele. It also puts a mark on the map that contains that information as well.
As it's using DML, your work in mission design is editing the trigger zone's attributes to control how the scripts work (you must not edit the scripts, they are self-contained and are configured with trigger zone attributes as well).
 
Droning on.miz