Slmod- multiplayer server mod for new mission logic functionality

[daribouca]

Ok, just installed this (modman and manual no servman version) and using the my own attempt which is basically a copy from the quick ref guide and the example missions nothing happens. I've attached my mission so you can see if that's a problem.

 

I changed the script line to

 

slmod.chat_cmd('-Axeman hold',1,1, 'blue')

 

and it works. Don't know if it came from the extra space after "chat_cmd" or from the "-1", I'm no guru ^^

[Jona33]

Still not working for me. Is there a way to double check that slmod is installed?

[daribouca]

Still not working for me. Is there a way to double check that slmod is installed?

 

None that I know of ... your mission is fine since it worked with me not changing anything except for the scriptline. I would double-check the 3 files that comes with slmod, and their correct location in your A10 folder.

[Jona33]

Working on Speed's now. Need to check my one.

[mwd2]

slmod.chat_cmd('-Axeman hold',1,-1, 'blue')

 

Look at the FLAG number, first FLAG is for the trigger and the 2nd. is the stop FLAG.

I have also have to change TRIGGERS to Switched Condition

 

than it works for me

[Jona33]

Got it working. Weird problem with saving meant I was always trying the wrong thing for a while. Sorted now. Thanks very much.

[daribouca]

Got it working. Weird problem with saving meant I was always trying the wrong thing for a while. Sorted now. Thanks very much.

 

Aw... Always quite the thrill when you realize what you were fighting against all along ^^ Hail computers! Anyway, glad for you you nailed it, now you can enjoy the pure awesomeness of this little gem :beer:

[Speed]

Hi (and merry christmas :) ),

 

I need a clarification: in your test video you say that the script must be contained in a isolated and "out of fire units". I thinked that if the units/group die, than you won't be able to use the script anymore.

 

Using this assumption and after have checked that I can have a lot of "scriptman" units, I made a test adding an "activate", "move" and "hold" run script commands directly to the subject group instead of Scriptman group. All of the script are adding POS options (this solution is better for me cause of a lot of reason: just understand that I need that the options won't be added anymore when the group is dead...).

 

But when I tried to run the scenery, and kill one of the triggerable group before running the add-option script (all the group), this script worked however.

 

So, scripting work also if the "scriptman" group die? I understand the opposite.

 

Sorry for my long absence, I've been visiting my folks in Alabama for Christmas.

 

Interesting! So the script still ran AFTER the group had died? I am pretty sure that it worked the opposite way back in beta when I first starting using scriptmen. I'll have to test it myself when I get the chance.

[chromium]

And I'll retest also!

[chromium]

restest say that I was wrong: when a scripting unit/group die, script won't work anymore. Sorry.

[Moa]

For me this mod is most useful for the game events it writes out, which allows me to build pilot statistics for DCS (in the same way that is done for Flaming Cliffs 2 at http://stallturn.com/104th/)

 

Have tested this mod on stallturn running A-10C v1.1.1.1 with 6-10 players for around 10 hours per mission and it has no noticeable impact on the mission's performance. Excellent work Speed.

 

Have also written a little Java program that runs in the background and stitches the 5 second interval files into a single file for the mission (essentially re-creating the a log file in real-time that A-10C used to produce). Besides storing the original log content I also convert the log entries into another XML file (which is much easier to parse in languages other than LUA, since there are a lot of XML parsing libraries out there). Am still testing this program but will release when testing finished.

 

There are some log entries that were present in FC2/early A-10C that are not written in the new logs. I'm going to try and modify the logging produced by this mod so that some of this extra information is logged - and will submit my modified scripts back for examination (in case you'd like to integrate my version with the main 'trunk' version).

[chromium]

@Speed, I sent you a pm :)

[Jona33]

I'm having a problem with the LOS function. It worked fine in a test mission but in this one it isn't working. Missions attached. The way it should work is a random car just south of the town called 'LOS car' when it gets LOS to the Ka-50 '451' flag 100 should be set to true and a message involving lot's of shouting happens. (Not literally)

Mp mission fsf.miz

Edited January 2, 2012 by Jona33

[chromium]

Regarding group status (AI OFF / AI ON /DEAD) scripting:

 

I made further tests, and I verified that:

 

- GROUP NOT ACTIVE * -> Script work;

- GROUP ACTIVE / AI OFF -> Script work;

- GROUP ACTIVE / AI ON -> Script work;

- GROUP DEAD -> Script do not work;

 

*regardless visible/not visible

[Speed]

I'm having a problem with the LOS function. It worked fine in a test mission but in this one it isn't working. Missions attached. The way it should work is a random car just south of the town called 'LOS car' when it gets LOS to the Ka-50 '451' flag 100 should be set to true and a message involving lot's of shouting happens. (Not literally)

 

There's a few issues, first of all, your script contains a Lua error:

 

slmod.units_LOS({'LOS car'},2,{'451},921,10,-1,6,1000,1000)

 

There is a missing single quote/apostrophe that is needed to make '451'. Since I can't remember exactly what all the function input variables all are, here is the line copied from the scripting guide:

slmod.units_LOS( table unitset1, number altoffset1, table unitset2, number altoffset2,

number flag, number stopflag, number interval, number checks, number radius )

 

So it looks like you have another two problems here: First of all, you specify a very high alt offset for the second unit named "451", 921 meters. This means that line of sight will be calculated 921 meters ABOVE the unit 451's position. Keep in mind that the altoffset variable determines from what altitude offset from the units position (x, y, and z) you want line of sight calculated from. So, for a Ka-50, since the Shkval is located near the bottom of the chopper, set altoffset for 1 meter. Another example, for an M1 abrams, you would want to set the altoffset variable to be about the height above the tracks that the sighting devices are- so maybe 2.5 meters, give or take. Perhaps 3 meters if you want to simulate a guy popping his head out of the turret and scanning with binos.

 

 

The second potential issue is that you specify a radius of 1000 meters. So even if the units are calculated to be line of sight to each other, then flag 10 will not be set true unless they are line of sight AND within 1000 meters of each other. That is the function of the radius input variable- it allows you to set a max radius out to which line of sight checking will no longer occur. Very useful for simulating detection by search radars or IR sensors or the such.

 

However, as I said, that's a potential issue- you may in fact WANT your line of sight to only work within 1 km. I donno exactly what you're trying to do in this mission.

 

So my suggested improvement would be:

 

slmod.units_LOS({'LOS car'}, 1, {'451'}, 1, 10, -1, 6, 1000, 10000)

 

I set the radius variable to 10km in this case. If you omit the radius variable, it is considered infinite, and there is no max radius out to which LOS will not be calculated.

 

You can also reduce the checks variable if you need to do a lot of LOS checking for several different units. Somewhere in the neighborhood of 50000 checks per second, give or take half of an order of 10, and you will start to notice micropauses as the game freezes while calculating LOS. 1000 checks is thorough, but usually a bit more than you need unless the range is very long. Note that you can spread out the checks per second by utilizing the interval variable effectively, and triggering LOS functions to start running at different times for different sets of units.

 

I actually didn't open your mission (I am unable to right now), I only extracted the mission to inspect your function call, so there could be issues with unit naming or triggering, but most likely, the problems were the ones I mentioned above.

Edited January 3, 2012 by Speed

[Jona33]

First issue, my bad. I thought alt offset was height above the ground (roughly) and the Ka-50 a was supposed to be at 2400m MSL (921AGL). Second problem was a fail. I missed a 0 when typing. That's pretty stupid. Thanks for the help. Will LOS still work if there's a building in the way (scenery rather than one I placed)?

 

EDIT:Another typing issue is the flag that gets set. Should be 100 not 10.

Edited January 3, 2012 by Jona33

[Speed]

For me this mod is most useful for the game events it writes out, which allows me to build pilot statistics for DCS (in the same way that is done for Flaming Cliffs 2 at http://stallturn.com/104th/)

 

Have tested this mod on stallturn running A-10C v1.1.1.1 with 6-10 players for around 10 hours per mission and it has no noticeable impact on the mission's performance. Excellent work Speed.

 

Have also written a little Java program that runs in the background and stitches the 5 second interval files into a single file for the mission (essentially re-creating the a log file in real-time that A-10C used to produce). Besides storing the original log content I also convert the log entries into another XML file (which is much easier to parse in languages other than LUA, since there are a lot of XML parsing libraries out there). Am still testing this program but will release when testing finished.

 

There are some log entries that were present in FC2/early A-10C that are not written in the new logs. I'm going to try and modify the logging produced by this mod so that some of this extra information is logged - and will submit my modified scripts back for examination (in case you'd like to integrate my version with the main 'trunk' version).

 

Yes, I will gladly take any improvements to the Slmod events system. I'm curious what entries are now omitted from the events system- I can think of one I think, I believe events used to give weapon runtime ID, it is very unfortunate that it this is now missing in DCS. I know how to access a "killers" table listing what units have killed what other units if you are in need of such information.

 

I'm back now for good, so if you ever want to set up a meeting time to discuss or ask about something on TS, just send me a PM.

Edited January 3, 2012 by Speed

[Speed]

Did I get all the current questions answered? I looked over the thread and I think I did... anyway, if I still haven't answered your question, and you're still having an issue, please reply, and either tell me what the issue you're having, or point me to the appropriate post.

[Jona33]

Bloody hell, how many mistakes can I make with this. I named the group the car was in LOS car rather than the unit. It's working.

Edited January 3, 2012 by Jona33

[Speed]

Whislist for (very far) future updates:

 

- Timestamp function: as for coordinates, the ability to have a "timestamp" option in the task message could be helpful when a task is added. Example: an AI recce heli spot enemy, add a task with coordinates. Than AI recce goes away... the task is there, with the coordinates of the enemy units: could be helpful if the coordinates are updated since the heli has LOS on the target, than is "fixed" to the last state when our AI recce doesn't have anymore the LOS with the target... in that case, having the time of the last spot plotted will be useful for sit.awareness;

 

- report history: the ability to list the task created, removed and executed (units of the table units destroyed?);

 

- Option to report the composition of the alive units in the table units in the msg function (add SA a lot, cause now you have to manually enter a description of the target units... and if for example the Air defence part of a table units is destroyed could be helpful to know that you doesn't have to worry about it in a following attack). Another less accurate option could be reporting the % of alive units of the table/unit group;

 

 

Some good suggestions. Unfortunately, there are two things that I am limited by:

1) The current way that Slmod functions are called sucks for very complex functions like add_task. You have a few required variables, and a bazillion optional variables, all of which have to be in the right order. If you have an option variable whose setting you don't care about, like a stopflag, and a later optional variable that you do care about, you still have to list a value for the stopflag variable. The current way of calling Slmod functions also limits how complex I can make these functions.

 

2) The necessity of supporting older missions. I can't add new variables easily to functions because of the need to support missions that used the older versions of the functions.

 

So what I really need to do is eventually switch to a totally new way of calling functions. The old method will stick around, to support older missions, and I may even be able to continue to actively supporting and adding to the old method by just adding new variable additions as optional variables. In the new and improved function calling system, this is how an add_task function call might look:

 

local task = { 
		coa = 'blue', 
		task_type = 'msg_MGRS', 
		description = 'Kill tanks', 
		msg = 'Enemy tanks were spotted at %s.  Group composition is %s. Kill them!', 
		group = { 'M1_1', 'M1_2', 'M1_3', 'M1_4' },
		numdigits = 6,
		timestamp = true,
		show_units = true,
		update_coords = true,
		remove_when_dead = true
		}
slmod.add_task(task)

 

Now it would be very easy to add new functionality to old functions, and you would no longer be forced to specify variables like stopflag when you don't want a stopflag in the first place.

 

So those suggestions are great, but would require considerable effort for me to create- I'd really need to switch to a new system.

 

- Verify friend function: ability to write coordinates in chat to ask if a units in that coordinates area (ratius 100 mt?) is frendly of enemy;

Excellent idea! I like this suggestion too. I am definitely adding this to the to-do list. How about an additional, realism enhancing option to it: what if I made it not 100% reliable? Perhaps 1% of the time you might erroneously be told the friendly is an enemy, the enemy is a friendly. Perhaps 5% of the time, you might be told "unknown"? Could add to realism quite a bit.

 

- (this is very useful): Actual situation: I'm going to add some script function directly to the units that command it, this for some reason but the most important are first that if the group die I won't have those function available anymore (see last post: seems that functions are added and work anyway...) and ladder because if I use CTRL-C and CTRL-V to add a unit to the same mission or to another mission it will copy automatically the scripts. Whis option: If the function is optionally automatically activated to the group whitout passing by the flag condition: I add a group script, than I will activate all the groups related script by an unique commond SLmod command: When called that command, all the units with AI ON present in the scenery activate their script (LOS functions, POS options, Task Adding options..). This will really help adding SLmod throu mission to other missions and speed up a lot the editing.

Well, you can already do this easily with triggers- Slmod functions can be called individually, or en-mass, and at any time in the mission other than the very first second or two. They are can be called based off of the results of any kind of trigger conditions and types other than Mission Start. Simply put, you use triggers to call them whenever mission logic demands it. You'd just like a more streamlined approach? I've personally never seen the need, but that could just be because the kind of missions I have made and am slowly in the process of making are different than yours.

Edited January 5, 2012 by Speed

[Jona33]

Speed a while back you mentioned that you were trying to get an SAR helo to fly to last known co ordinates. Could you instead get one to fly to co ordinates typed into chat eg -Request SAR 37T GG436436 rather than trying to find the ones at point of ejection.

[Speed]

Speed a while back you mentioned that you were trying to get an SAR helo to fly to last known co ordinates. Could you instead get one to fly to co ordinates typed into chat eg -Request SAR 37T GG436436 rather than trying to find the ones at point of ejection.

 

Possible, yes...

 

Anyway, I am definitely going to have to push back the release for Slmod version 6 for quite a while longer- a number of factors combined to make December a very unproductive month for me, as far as Lua modding is concerned. Hopefully this month is better, but work and school are about to get very demanding.

 

To do SAR right, what I'd really like is to be able to query the location of client ejected pilots, and right now, ejected multiplayer client pilots are local to the client. I'd also like to be able to deactivate multiplayer clients, but after investigating multiple methods, I've found no way to do so other than to kick them from the server. The idea would be to implement a hardcore mode where if you ejected and survived, you had to wait for rescue, and possibly even evade enemy forces.

 

I could probably implement an escape and evasion plug-in mod that does the necessary operations (client deactivation and sending of client pilot coordinates, as well as boosting ejected pilot running speed) that interfaces with Slmod, but it would need to be installed on clients.

[Grimes]

Been getting this error after the server crashes

 

[Ells228]

Always amazes me what you can do Speed, great job.

[Speed]

Been getting this error after the server crashes

 

That's the daemon crashing. If it is after the server crashes, I wouldn't worry. It's only an issue if it crashes while the server is running. I could look into it anyway and see if I can make this error not appear.

 

I'm still looking at ways to try to eliminate the daemon, but I haven't found one yet. I do have a promising lead or two, but if those don't pan out, then there probably isn't one without ED's help- most likely, we need ED to make a certain one of the changes to Lua I requested before I could eliminate the daemon. Specifically, we need ED to allow net.dostring_in to access the mission scripting environment. It can access every other Lua environment, including the mission-specific "mission" environment, so why not? (In fact, ED has never said they wouldn't do this, they just haven't said they would do it either. It's probably something they wouldn't mind adding, but is just too low on their long list of priorities to warrant their attention at this time. But that's just my best guess.)

 

For anyone Lua-minded, what I am actually thinking of attempting, as a last resort to eliminate the daemon, is to simply run any mission scripting script that contains "slmod." in the "mission" environment, rather than the "mission scripting" environment. I have been avoiding this for a couple reasons:

1) Because there would still be no memory link between mission scripting and the mission environments, you'd have to declare all your variables you want to use with Slmod in one of the scripts that calls a Slmod function. Normally, this would not cause an issue- people rarely use variables declared in other scripts with Slmod functions anyway, but a more advanced Lua programmer might. Anyone who starts embedding Slmod functions into more complex scripts than just a single function call is going to get awfully confused.

2) This won't be that easy to program, and I'm not even sure it will work. It's going to require Slmod to modify the loaded contents of a mission at run time. Slmod will have to go into the table of trigger functions, and change them. I think this will work... but I'm not 100%

3) Even after this, there are things that I still want to keep the daemon running for anyway.

 

Really, what is needed is a link through memory.

Edited January 18, 2012 by Speed