Slmod- multiplayer server mod for new mission logic functionality

Slmod Debugger now working:

I've noticed that lots of people get lost in the dcs.log, where Lua errors are normally reported, and where I recommend people go to check if they have Lua errors. As it exists right now, the Slmod debugger accesses the mission environment, and attempts to compile (but not run!) all "Run Script" triggered actions. If a script failed to compile, it's due to a syntax error (such as missing a parathesis or a quote or something like that). So a message will be output to the screen, and a text file will be written so you have a record of this.

Note: the debugger cannot catch runtime Lua errors, but, at least for people using premade function libraries (such as Slmod), the vast majority of Lua errors will be syntax errors.

Note #2: the debugger feature, like the coordinate conversion utility, will have the ability to be easily toggled on or off in Slmodv6's SlmodConfig.lua file.

Additionally, I think I've just about completed the new way to call functions (feeding them a single table of variables rather than a list of variables). It will be optional, of course, and the old way will still work. So, let's say, you want to use units_firing (a particularly complex function with lots of optional variables) and you want to have units_firing output a message, but you don't want to have to specify the optional variables "display_units" or "weapons" or "stopflag". Using the new function calling method, you can call units_firing this way then:

Slmod.units_firing({ init_units = {'buff11'}, flag = 50, msg = 'Buff 1-1, bombs away!', display_mode = 'text', coa = 'blue', display_time = 20})

Note that choice of variable order within that table is completely arbitrary, and furthermore, it's very clear exactly what each variable does. Compare to the old way to do this:

units_firing_net({'buff11'}, 50,  -1, {}, 'Buff 1-1, bombs away!', '', 20, 'text', 'blue')

Ugh. What does each variable do? And I have to specify -1 for stopflag, an empty table for weapons, and an empty string for display_units :( (but with the new fix, you can now actually specify nil for a variable you don't want to use).

Anyway, the real benefit (for me) for this functionality is that it allows me to add lots of new optional variables to further specify how you want functions to act.

Ok, there's a feature I'd like to implement, but I'm worried about breaking compatibility, and/or causing behaviors that someone who is not familiar with what's going on would find very odd. Anyway, I'd like to see if any of you guys have any feedback about it.

What I'd like to do is allow you to insert a "tag" into your Lua scripts that allows them to be run in the "mission" environment, instead of where they currently run, the "mission scripting" environment. It looks highly likely that I will be able to implement such a feature, I've tested almost all or almost all the requisite concepts, and everything checks out. The "tag" would probably simply be a comment like this:

--#RUN IN MISSION#

Slmod would look for that comment in a triggered action, and if it saw it, then, when the triggered action went off, the script would run in the same Lua environment where the "mission" table, functions like "a_out_text_delay", "c_time_more", "c_flag_is_true" (and many others), and the database of groups/units/etc, "db" reside.

But that's not the primary reason I'd like to do this, and not the reason I'm asking this question. I'd like to do this because I could, by default, make all calls to Slmod functions operate in the mission environment. This would make the daemon mostly unnecessary, and Slmod would no longer be depending primarily on the print function to transfer in function calls, which is a messy method, though it's proven reliable enough (100% reliable, in my tests, in fact). But I still don't like it, as it adds a significant time lag between calling a function and that function taking effect.

The problem is, no data passage occurs between the "mission scripting" and "mission" environments. So, if you do something like this in one script:

enemy_armor = {'tanks1', 'tanks2', 'tanks3', 'tanks4', 'tanks5'}

And in another script, you do something like this:

slmod.units_firing(enemy_armor, 45)

Which is currently, quite valid (as long as you call the first script first, which creates the global table variable named "enemy_armor")-- this change will BREAK something like this, as the Lua script that declares the global table variable "enemy_armor" will be declared in the "mission scripting" environment, while Slmod will run the function call "slmod.units_firing(enemy_armor, 45)" in the "mission" environment, where this global table of "enemy_armor" doesn't exist. I don't think many people do stuff like this, but still- I'm weary of implementing this change. Of course, you could easily fix your mission in the new system I'm thinking about by doing this:

--#RUN IN MISSION#
enemy_armor = {'tanks1', 'tanks2', 'tanks3', 'tanks4', 'tanks5'}

so that the global table variable "enemy_armor" becomes defined in the "mission" environment instead of the "mission scripting" environment, but that would go against how I've been keeping full backwards compatibility since day 1.

Anyway, I don't think many folks do things like this anyway, but does anyone out there have an opinion on this? Should I do this? By making Slmod functions default into the "mission" environment instead of the mission scripting, I can quite easily decrease the time lag that exists between calling an Slmod function and the function being implemented, from its current 0-2.5 seconds to 0-1 seconds. Maybe even cut it down to 0-0.5 seconds! Then the primary lag would simply become the once-per-second trigger evaluation lag.

Anyway, I've been too busy to do much work on Slmod lately, but I hope to get back into it in about a week. I think (and this is with much greater certainty that before) that I can have Slmodv6 complete sometime between late March and mid-April. But that all depends, really. There's also an extra uncertainty not included in that calculation that could potentially delay version six for an extra month- but it would have a lot more features after that extra month of delay.

EDIT 3/14:

I think I can ask that this request for opinions be disregarded, unless you just want to offer one anyway. These variables inside function calls might be considered "upvalues" (though I think the term "upvalue" usually applies to local variables, these variables are global variables (and local to their namespace/environment), so in effect, they are upvalues to Slmod, which goes between environments). I think what I will do is write some code to detect upvalues inside Slmod function calls. If the function call has an upvalue in it, then the script will run in the "mission scripting" environment, unless the comment tag --#RUN IN MISSION# is included in the script. If the Slmod function call has no upvalues in it, then the script will be run in the "mission" environment, unless explicitly told otherwise with a --#RUN IN SCRIPTING# comment tag. So now, full backwards compatibility will be maintained, and furthermore, the 99% of Slmod function calls out there in real missions, which don't use upvalues, will now occur inside the "mission" environment, run a good 1 second faster, and not utilize the daemon at all. Poor little neglected daemon :)

ALSO, while I am not able to work on Slmod actively for a little while, it hasn't meant I have stopped brainstorming... I just today made a major breakthrough with the events system that will allow me to almost certainly include a "weapons impacting in zone(s)" function with the Slmodv6. A huge amount of the computational time requirements were reduced too, with this breakthrough.

And if you're wondering why I keep posting stuff in here, where people might not care, well... sorta consider it a development blog, I guess. Also, and more importantly, this often serves as something I can reference later for ideas.

I find interesting to read you ideas :).

But obviously I'm here to ask something:

Is there a way to make the units_hitting function to work whitout declare the table_unit that is firing? What I need the function to activate a flag every time my "target" table_unit is hit by something or someone.

(the idea is: when something hit the group, this will activate a flag that trigger a message and a "defensive" task is added to the PTS.

And if you're wondering why I keep posting stuff in here, where people might not care, well... sorta consider it a development blog, I guess. Also, and more importantly, this often serves as something I can reference later for ideas.

Keep posting :thumbup:

I find interesting to read you ideas :).

 

But obviously I'm here to ask something:

 

Is there a way to make the units_hitting function to work whitout declare the table_unit that is firing? What I need the function to activate a flag every time my "target" table_unit is hit by something or someone.

 

(the idea is: when something hit the group, this will activate a flag that trigger a message and a "defensive" task is added to the PTS.

No, not at this time, sorry. For now, you'll have to add every single unit that could hit them to the table. Next version, things will be much more simple, you'll just be able to specify something like '[red]' and it will add all red units to the table automatically. But for now, only the hard way works.

Then I will find a smarter way to solve this issue waiting till next version :)

Ok I'm preparing an excel file that auto-build a LOS script with two table units.. in one of the table units will be the 1 to 9 units of a single group. In the other table... ALL the units of the other coalition (>300).

It will work, for sure, but I'm asking you if I have to worry about something (example: every seconds my computer will have to check for 60 LOS scripts that everyone check itself for los relations between 9 vs 300 units (range 10 km)

thanks in advance :)

Ok I'm preparing an excel file that auto-build a LOS script with two table units.. in one of the table units will be the 1 to 9 units of a single group. In the other table... ALL the units of the other coalition (>300).

 

It will work, for sure, but I'm asking you if I have to worry about something (example: every seconds my computer will have to check for 60 LOS scripts that everyone check itself for los relations between 9 vs 300 units (range 10 km)

 

thanks in advance :)

Yea, that sounds like you could quickly get into the realm where you start noticing micro-pauses when the scripts run. This is where you want to utilize the "interval" and "checks" variables properly. For one thing, say you want to do LOS checking between 60 vs. 300 units (so the size of "unitset1" is 60, and the nominal size of unitset2 is 300). You can split this up, divide this task, so instead of making like a 150ms stutter, you get a very slightly lower frame rate. Here's how:

1) Divide the LOS task into fifteen separate calls. Each call does 60 vs 20 (20 out of the total of 300)

2) For each units_LOS function call, set the interval to 15 seconds.

3) Now stagger the calling of each of these units_LOS function calls, like this:

Once->Time More (1) -> AI TASK (Run Script(units LOS for unitset1 and 1-20 out of 300 of unitset2))

Once->Time More (2) -> AI TASK (Run Script(units LOS for unitset1 and 21-40 out of 300 of unitset2))

Once->Time More (3) -> AI TASK (Run Script(units LOS for unitset1 and 41-60 out of 300 of unitset2))

... ...

Once->Time More (15) -> AI TASK (Run Script(units LOS for unitset1 and 281-300 out of 300 of unitset2))

So now, instead of one big 150ms pause every 15 seconds, you divide the computations into fifteen parts and get fifteen undetectable 10ms pauses, with one "pause" occurring every second. :thumbup:

Also, for just 10km max range, you can probably use a checks variable value of 50. That's, at worse, one terrain height check every 200 meters. That will usually be sufficient.

Anyway, the next version of Slmod will make significant performance improvements to many functions, and units_LOS will benefit more than most functions from these performance improvements, in fact.

EDIT: stupid questions.

Also, you can see some time-staggered units_LOS calls in the LOS-based tasking example mission,

http://forums.eagle.ru/attachment.php?attachmentid=60051&d=1323598989

I will explain why I need to check a 9 vs 400 group:

I have 50 groups of 8 units each for each side (tot. 400), They randomly activate themself and move on the territory. When one group come in sight of ANY other, I want to add a task for each side (obviously as the "red" group come in sight of the "blue" group, they will activate a different flag for each one, allowing me to create two task for each coalition: a defensive one and an offensive one. This will allow planning for CAS operations for each side).

Also, you can see some time-staggered units_LOS calls in the LOS-based tasking example mission,

 

http://forums.eagle.ru/attachment.php?attachmentid=60051&d=1323598989

I already use them for a training purposes mission, that have some flag related issues and I was afraid that they could be LOS - spacing related, cause I have a range of 4 km and a time spacing of 60 seconds .... but it is not (likely) :)

I will explain why I need to check a 9 vs 400 group:

 

I have 50 groups of 8 units each for each side (tot. 400), They randomly activate themself and move on the territory. When one group come in sight of ANY other, I want to add a task for each side (obviously as the "red" group come in sight of the "blue" group, they will activate a different flag for each one, allowing me to create two task for each coalition: a defensive one and an offensive one. This will allow planning for CAS operations for each side).

Looks like you need to create 100 units_LOS calls then, each with #unitset1 = 8 and #unitset2 = 400 ("#" is the table size operator). Set the interval variable to 50, and the checks variable to 50 or 75.

Create a flag loop:

Once-> Time More (1) -> Set flag (101)

Switched->Time Since Flag (101, 51 sec) ->Clear Flag (101), Set Flag(101)

Now, when you randomly activate each group, also set a flag, such as this:

(Random Activation Conditions True) -> Activate Group (Blue 17), Set Flag (17)

To run each units_LOS function, do something like this:

Once-> Flag is true (17), Time Since Flag (101, 17 sec) -> AI TASK (Run Script(Blue 17 units_LOS))

Also, set a stopflag for each group. For example, make the stopflag for Blue 17's units_LOS function be flag 217. Now, when the group Blue 17 is dead, set the stopflag, to make sure that the units_LOS function for Blue 17 is still not wastefully looping:

Once->Group Dead("Blue 17")->Set Flag (217)

With all these tricks, you ought to get acceptable performance even in the current version of Slmod. You are only running units_LOS for groups that are actually active, and when those groups die, the stopflag for the corresponding units_LOS function is being set true, and stopping that units_LOS loop from looping any more.

Every unit already has a dedicated set of flag (I use excel to auto-build functions and table units), What I may need to understand is why you say to create a flag loop to AI task activation.. to syncronize all the LOS calculation in the same second?

thanks in advance for the clarification.

Every unit already has a dedicated set of flag (I use excel to auto-build functions and table units), What I may need to understand is why you say to create a flag loop to AI task activation.. to syncronize all the LOS calculation in the same second?

 

thanks in advance for the clarification.

The reason for the flag loop is to make sure that the units_LOS functions are always called at the correct time, such as in the example:

Once-> Flag is true (17), Time Since Flag (101, 17 sec) -> AI TASK (Run Script(Blue 17 units_LOS))

Actually, it's not all that important- what is most important is that you make sure that the units_LOS calculations are spread out over time. Using a flag loop is one way to help ensure that. But if you activate all the random groups you are going to use at mission start, it's unnecessary. For example, if you activate all your groups at mission start, then you only need to spread out your units_LOS calls with the TIME MORE condition. Here's a complete example:

Blue random variables for group activation:

MISSION START(random variable for blue 1)->RANDOM (15)->SET FLAG (301), ACTIVATE GROUP('blue 1')

MISSION START(random variable for blue 2)->RANDOM(15)->SET FLAG (302), ACTIVATE GROUP('blue 2')

… … …

MISSION START(random variable for blue 50)->RANDOM(15)->SET FLAG(350), ACTIVATE GROUP('blue 50')

Red random variables for group activation:

MISSION START(random variable for red 1)->RANDOM(15)->SET FLAG (401), ACTIVATE GROUP('red 1')

MISSION START(random variable for red 2)->RANDOM(15)->SET FLAG (402), ACTIVATE GROUP('red 2')

… … …

MISSION START(random variable for red 50)->RANDOM(15)->SET FLAG(450), ACTIVATE GROUP('red 50')

Start LOS scripts for blue

ONCE->TIME MORE(1) AND FLAG IS TRUE(301)->AI TASK(Run Script(blue 1 units_LOS function call))

ONCE->TIME MORE(2) AND FLAG IS TRUE(302)->AI TASK(Run Script(blue 2 units_LOS function call))

… … …

ONCE->TIME MORE(50) AND FLAG IS TRUE(350)->AI TASK(Run Script(blue 50 units_LOS function call))

Start LOS scripts for red

ONCE->TIME MORE(1) AND FLAG IS TRUE(401)->AI TASK(Run Script(red 1 units_LOS function call))

ONCE->TIME MORE(2) AND FLAG IS TRUE(402)->AI TASK(Run Script(red 2 units_LOS function call))

… … …

ONCE->TIME MORE(50) AND FLAG IS TRUE(450)->AI TASK(Run Script(red 50 units_LOS function call))

This would do the trick too, if you’re activating all your groups that will EVER be activated at mission start. The flag loop was only there to help ensure that the units_LOS calls were spread out over time, and it’s only useful if you’re activating groups randomly, at different times. Even then, if your activation times are random enough, it won’t matter much, as the probability of getting like five or six “overlapping” units_LOS calls is pretty unlikely. I'm just kinda obsessive-compulsive about covering all possibilities and leaving no possible logical holes/problems. Code I write probably tends to be more reliable, but slower to execute, due to all of the checking and double-checking I do.

clear :)

One question: if the LOS function is run IN the group that contain all the units of the "table unit", and not by a dedicated "scriptman"-like unit, It will stop calculating if the group die?

One question: if the LOS function is run IN the group that contain all the units of the "table unit", and not by a dedicated "scriptman"-like unit, It will stop calculating if the group die?

Nope. And it would be a very bad idea to make it work that way, too- what if you were running units_LOS (or any other similar function like units_firing) on a humanable unit that might spawn or despawn at any random time in the mission? No, these functions only stop looping themselves if you set the stopflag to true.

right!

I'm adding a wish-item:

As you know for sure the only way to get rearmed or refueled for helicopters at FARPs is to have the "helipad" 3D object... do you thing it is possible to command a refuel or a rearm function simply by calling a script? (even if, for example, is "default" fuel and weapons loadout).

This way a designer could be able to re-create working FARP whitout the helipad structure (whitout radios... but triggered messages could do the work).

I'm adding a wish-item:

 

As you know for sure the only way to get rearmed or refueled for helicopters at FARPs is to have the "helipad" 3D object... do you thing it is possible to command a refuel or a rearm function simply by calling a script? (even if, for example, is "default" fuel and weapons loadout).

 

This way a designer could be able to re-create working FARP whitout the helipad structure (whitout radios... but triggered messages could do the work).

Personally, I'd love it if I could simply make a rearming/refueling/ATC ZONE, but I really haven't studied the Lua involved with FARPs and airbases in depth enough to know for sure that it is possible. Odds are it is NOT possible. Furthermore, is something, that, even if it is possible to do in Lua, almost certainly every person joining the mission would have to have the mod installed.

understood: too much off-topic :).

I downloaded this tool and have it installed. I am running into a problem that when I download your .miz folder example I have all the a/c there as well as the ground forces. The issue is your "placeholder" for the triggered actions that is way up northwest has nothing in the script its just a mortarman named slmodman or there abouts. What am I doing wrong? Thanks for the help.

Also I am trying to have two task at once, I can see the first task under the -stl and -st# I can only see one task in the list. I have a issue also that once the task 1 is complete it doesnt remove itself from the -stl, I am at a loss as to how to have two tasks at once as well as removing the task once its dead or destroyed.

Hi Speed,

Thanks for keeping your scripts updated. I just came back after a long break and its nice to see this has evolved so much!

I for the love god can not figure out why my ATIS is not working in this mission. I created a test mission as well and it works in that one but the one I have posted here, it does not work. Everything as far as triggers and script wise is the same. Something is breaking down on me. Could you take a look Speed?

Operation Raindrop.miz

I downloaded this tool and have it installed. I am running into a problem that when I download your .miz folder example I have all the a/c there as well as the ground forces. The issue is your "placeholder" for the triggered actions that is way up northwest has nothing in the script its just a mortarman named slmodman or there abouts. What am I doing wrong? Thanks for the help.

The reason you saw no scripts in the scripting group's actions was probably because you were looking in the waypoint actions. Don't look there. Look in the triggered actions tab:

Triggered actions only run when they are told to by a mission editor trigger, thus making them vastly more flexible; they can also be run as many times as you want. Waypoint actions are only useful when you want something to occur when a group hits a waypoint. Look in the triggers list and you will see when and under what conditions various Lua scripts are run, via the AI ACTION trigger action (the AI ACTION trigger action is the trigger action that runs a triggered action).

Also I am trying to have two task at once, I can see the first task under the -stl and -st# I can only see one task in the list. I have a issue also that once the task 1 is complete it doesnt remove itself from the -stl, I am at a loss as to how to have two tasks at once as well as removing the task once its dead or destroyed.

Tasks do not automatically delete themselves- you have to do it with the remove_task function. I suppose it might be possible to some day have an option to make certain kinds of tasks (the group-based tasks) automatically remove themselves when the units are dead, but as of right now, you need to do it manually.

Remember that each task has a unique ID number. That's how you identify tasks with the add_task and remove_task functions. To have more than one task, you need to use more than one unique ID- otherwise, you will just over-write the previous task.

For example:

slmod.add_task(101, 'msg_out', 'Destroy enemy HQ', 'Destroy enemy HQ at 38T KM 074 221')
slmod.add_task(102, 'msg_MGRS', 'Destroy enemy armor', 'We have spotted enemy tanks at: ', {'tank1_1', 'tank1_2', 'tank1_3', 'tank1_4', 'tank1_5'}, 6)

This code will add two tasks, because the unique ID, the first variable, is different for each task.

So basically, if you wanted the 'Destroy enemy armor' task, task 102, (where 102 refers again, to its unique identifier number) to go away, you will need to run the following code:

slmod.remove_task(102)

which will delete task 102 from both the red coalition and the blue coalition's task lists.