"slmod" beta 3 - multiplayer mod providing more functionality to mission creators

SLMOD BETA 4:

Guide:

http://forums.eagle.ru/attachment.php?attachmentid=55923&d=1314597424

Quick overview:

THIS IS A SERVER-SIDE MOD. ONLY THE SERVER NEEDS TO HAVE THIS MOD INSTALLED TO MAKE A MISSION USING THIS MOD WORK.

There, did I say that clearly enough? :music_whistling:

Functions provided include

chatIOlib "legacy" support:

chatmsg - output a chat message

chatmsg_repeat - repeat a chat message

chatmsg_groupMGRS - output MGRS of a set of units

command_check - set flag if someone has said a certain phrase in chat

command_check_start_loop - set a flag if someone says a certain phrase in chat

New functionality

mapobj_destroyed - set a flag if a specific map object (such as a bridge, runway, building in a town, etc) is destroyed

msg_out - output a message as chat, "message to all"-type trigger text, or combinations of both (several options)

msg_MGRS - use msg_out to output average location of a set of units in MGRS

msg_LL - use msg_out to output average location of a set of units in Lat/Long

msg_leading - use msg_out to output the average location of a set of units that are most to the north, south, east, or west.

Parallel tasking system

add_task - add a task to the task list, can pick from several different kinds

remove_task - remove a task off of the task list

show_task - manually trigger the showing of a task

show_task_list - manually trigger the showing of the task list

See the .pdf guide for more detailed instructions.

Youtube videos giving instruction are planned for the near future.

If you want to host a mission that makes use of this mod, you need to install it. Clients need not install it. (Oops I said it again!)

slmod beta 4 installation files and instructions here:

http://forums.eagle.ru/showpost.php?p=1281834&postcount=21

 

I know I've released like a new version of this mod a week, but I think the next version won't come out for at least another two weeks, maybe more, unless there needs to be some kind of bug fix or whatnot, as the next things I'd like to add are features perhaps less demanded or more time-consuming to make.

I will likely have to renege on this, due to my belated discovery of where the Mission Scripting environment is set up (this post: http://forums.eagle.ru/showpost.php?p=1277963&postcount=109). I can probably put all the slmod data sending functions in MissionScripting.lua and then class them into a "slmod" class and have it get passed into the Mission Scripting environment. Then we will be able to go back to using scripts under a unit's triggered actions again. Wish I had looked earlier, I still can't understand how I was so blind :doh:

Of course, backwards compatibility will be maintained. Any missions made using slmod beta 3 will work with whatever the hell I decide to call the next version.

Im assuming youll be pushing this stuff out in the next few weeks... I was just reading the SLM pdf this morning going oh crap.... I think I'll wait to throw it my MP campaign. I desperately want to get rid of the radio triggers...

I really enjoyed reading about the parallel tasking system, and your ideas/theory/testing on those other things you had thrown in, first contact CAS and tailored artillery.. Wow. This is one to watch in the future to come.

I would think that the "beta 4" version can be released this weekend. We had a very successful test tonight. In slmodbeta4, scripts are now running from unit's triggered actions again, like in A-10C versions 1.1.0.8 and before, but this time without the massive security vulnerabilities that the scripting feature opened up in 1.1.0.8 and before.

What this means is that in addition to modifying the mission file itself to run slmod scripts, a better way is now available. Just create a "Triggered Action" of type "Run Script", enter your function call, then call the script with a trigger. Just like in 1.1.0.8.

I finally got around to messing around with the "export" environment. The export environment has some very nice data getting functions... they can be used for things like a "weapons impacting in zone" trigger/function (set a flag based off of specific weapons impacting in a zone). So some time in the near future we may actually be to trigger events solely on whether munitions are impacting in a location.

Would have gotten a lot more work done on the mod tonight, but the forums were down for hours, making the Luasocket programming example I needed to download unavailable :(

Yeah it was down for a while. Good news to get it back to triggered actions, that is the preferred method. And heck I already know how to use all the commands so it'll be easy for me.

If anyone ever figures out to limit mission loadouts we could use the bomb impact thing to verify a certain bomb has been dropped and remove it from the available inventory. I like the idea of limiting cbu's cause it means you have to add a bunch more vehicles to the mission and they go and kill em all with one bomb... kind of takes away from MP. For now you just gotta spread everything out.

I tried reading the developers notes for using lua on the dcs website... I got overwhelmed in like 20 minutes.. Good luck with that... lol.

So some time in the near future we may actually be to trigger events solely on whether munitions are impacting in a location.

Nice work. I am running the Servman mod and will give this a try in that environment as well.

Any input from others running Servman on how this is working?

woah that sounds great!

I am attempting to fix my other missions now. I finally installed .09 update. Now I just need to clean my monitor after reading your pdf file while drinking a soda. Page 8 turned my monitor into a sticky mess LOL.

Oh this method is not working for me. I think its because it wont let me rezip the mission. I had this problem before.

After I edited the mission to try to see if I could get this to work, it wouldn't let me open it in editor. I think I did the script part right. I just think its when I zipped it back up. Can you take a look at it?

http://www.mediafire.com/file/91upwq861hlvv35/Operation%20Lawn%20Dart%281%29.miz

I was just testing the "START" command to see if I got my message. If so, I knew I did it right.

Mia, just hang in there hell get the new one out soon and you wont have to screw with all that.

Oh this method is not working for me. I think its because it wont let me rezip the mission. I had this problem before.

 

After I edited the mission to try to see if I could get this to work, it wouldn't let me open it in editor. I think I did the script part right. I just think its when I zipped it back up. Can you take a look at it?

 

http://www.mediafire.com/file/91upwq861hlvv35/Operation%20Lawn%20Dart%281%29.miz

 

I was just testing the "START" command to see if I got my message. If so, I knew I did it right.

You did everything right except one thing: you tried to use double quotes (" "). I recommend strongly against using them in the directions, but I didn't really state why. So, for this mission-insertion method, please use single quotes (' '), unless you want to create extra work for yourself. See, this is what your attempted command looked like because you used double quotes:

[1] = "command_check_start_loop( \\\"START\\\", 99, 3); mission.trig.func[1]=nil;",

I'm not even sure what that means in Lua, honestly. The first escape (\) is going to escape the double quotes. The second escape is going to escape the escape? And the third escape is going to escape the escape of the escape? Yea. I'm not well enough versed in strings to understand exactly how this will be interpreted. I'm pretty sure THIS will work though:

[1] = "command_check_start_loop( \"START\", 99, 3); mission.trig.func[1]=nil;",

But instead of this horrible confusion, you should use single quotes/apostrophes (' '). Just be advised, you need to write your scripts in a non-retarded word processor, like Notepad++, otherwise it may try to use "smart quotes" and #@$% everything up.

Anyway, with single quotes, your line will look like this:

[1] = "command_check_start_loop( 'START', 99, 3); mission.trig.func[1]=nil;",

I uploaded the fixed mission that uses single quotes.

BTW, it was last Monday, the day after I released that .pdf guide for slmodbeta3, when I finally figured out the way to use slmod directly from unit scripted actions, just like we did it in patches 1.1.0.8 and before. It has worked flawlessly so far in my tests. So expect a new version in just the next couple days (30% chance that this may even be as early as very late tonight, or very early Saturday morning), and with the new slmod version, you can forget about having to edit mission files directly ever again, unless ED accidentally screws us over again next patch (which is very unlikely). Even if that did happen, I'm reasonably sure I could find a way to fix it.

Oh, and the new, old method would let you use double quotes :)

I just wish they would directly let us use Lua for trigger conditions and actions.

Lawn_Dart_Fixed.miz

Just a note about the \\\" syntax ... you've just added one extra layer of s*t ;) A simple way to tell what happens is through this two pass evaluation:

[TABLE]pass #1 | \\\" | expands into | \" | one \ escaping each special character

pass #2 | \" | expands into | " | the remaining \ escaping the "[/TABLE]

Thanks for explaining Speed. I copied all the scripts from original mission and didn't even think about the double quotes. I thought the ( \\\"START\\\", 99, 3) looked funny.

I think I will just wait until your done with your next version.

Thanks for the fantastic work Speed. This is a great tool. I haven't looked at the gizzards of the script yet so I'll be lazy and ask the question, does it have the event export useful for stats? It is great to hear it works with Servman, as would be nice to have stats and Servman play together.

Thanks for the fantastic work Speed. This is a great tool. I haven't looked at the gizzards of the script yet so I'll be lazy and ask the question, does it have the event export useful for stats? It is great to hear it works with Servman, as would be nice to have stats and Servman play together.

Well, let's set up a time to another time to meet and try to figure out exactly what you need. I don't know exactly where you needed it exported to, or how.

As far as Luasocket goes, correct me if I'm wrong, but my experiments suggest that, similar to the dcs.log data passing, I will need an external service/daemon that receives data on one port, and continuously tries to send data to another, in order to pass data between Lua environments with Luasocket. It looks like data sent to a port is not buffered and held until received. You need to have an active connection there to receive that data when it arrives, or it disappears. So it's not possible to pass data between different parts of a single-threaded application with Luasocket without having an external application that serves as a buffer/repeater.

And no, Lua coroutines cannot be used to fix this. Coroutines are not parallel-processed.

Or maybe, I just haven't figured out how to send data correctly.

No matter what, any single threaded application cannot read what it writes without some buffer facility provided by another thread. Simple case is a fifo where the OS itself provides this service through one of it's IO layers.

Sockets are application responsibility, meaning they depend on how the OS gives a chance to the reader to do its job every time the writer has pushed something into its output channel.

As you say, a single threaded TCP socket application would be stuck at waiting for its output to be read by its input function that would never get a chance to be called. As for the unconnected UDP kind, data would just be wasted ;)

It looks weird having to go through an external application only to be able to send data from one function layer to another of the same application.

Global or package name space would be the smart way to do that. If not possible, then shared memory or a FIFO would still be better than some extra daemon socket application.

[edit]

If external socket buffer application it is, one port would be enough, you can write from one end then read from the other ... both ways ... at the "same time" ;) (full duplex comm)

No matter what, any single threaded application cannot read what it writes without some buffer facility provided by another thread. Simple case is a fifo where the OS itself provides this service through one of it's IO layers.

 

Sockets are application responsibility, meaning they depend on how the OS gives a chance to the reader to do its job every time the writer has pushed something into its output channel.

 

As you say, a single threaded TCP socket application would be stuck at waiting for its output to be read by its input function that would never get a chance to be called. As for the unconnected UDP kind, data would just be wasted ;)

 

It looks weird having to go through an external application only to be able to send data from one function layer to another of the same application.

 

Global or package name space would be the smart way to do that. If not possible, then shared memory or a FIFO would still be better than some extra daemon socket application.

 

[edit]

If external socket buffer application it is, one port would be enough, you can write from one end then read from the other ... both ways ... at the "same time" ;) (full duplex comm)

Ok thanks for confirming that. I'll just continue to use the dcs.log VBscript daemon and net.dostring_in. I'll think about making a C++ based daemon though... would be much better than a VBscript daemon, but it will require the inclusion of a fourth file in the mod.

You can try using netcat. In any case, for passing data, avoiding using the disk if at all possible should be a good thing, so luasocket is still valuable.

Just as a little preview for what will be coming eventually... spent several hours on bringing all the components together for a proof of concept test:

Yes, I know, this all needs a lot of work. The mission and Lua functionality shown in the video was just a proof of concept, but I thought it looked pretty cool so I decided to share it. The AFAC function set definitely won't be ready this weekend. Maybe in 1-2 weeks :)

Good news is Lat/Long will be supported, and the Ka-50 should be capable of calling in strikes to an accuracy of 5-10 meters using it as well (using the Abris's ability to measure coordinates to an accuracy of 0.01 minutes of latitude/longitude). I can't wait to get up in the air with my KA-50 and just play God of FAC all day :)

Edit: ModMan packs up.

Anyway, with slmod beta 4, I didn't get to add too many major functionality improvments other than increasing the functionality of the mapobj_destroyed function (see .pdf guide). Mostly, the major change with this version is that you can now run scripts directly from a unit's triggered actions. The dcs.log daemon has been reactivated in this version to allow this to happen, so as the game is first loading up the multiplayer gui, you may notice your A-10C splash screen quickly minimize and then re-maximize when the daemon is "summoned" with the "os.execute" ritual :)

I am also including a "hello world" mission example.

Just remember that slmod functions called from triggered actions must have "slmod." inserted in front of them, i.e., slmod.msg_out('hello world', 20)

----------------------------------------------------------------------------------------------------

NON-Servman:

Manual installation:

1) Download these three files:

http://forums.eagle.ru/attachment.php?attachmentid=55924&d=1314597628

http://forums.eagle.ru/attachment.php?attachmentid=55925&d=1314597628

http://forums.eagle.ru/attachment.php?attachmentid=55926&d=1314597628

2) In C:\Program Files\Eagle Dynamics\DCS A-10C\Scripts, rename "MissionScripting.lua" to "MissionScripting_original.lua". Next, drop the "MissionScripting.lua" file you downloaded here into that same directory.

3) Rename "server.lua" to "server_original.lua" in C:\Program Files\Eagle Dynamics\DCS A-10C\Scripts\net (NOT C:\Program Files\Eagle Dynamics\DCS A-10C\Scripts!!!!). Next, drop "slmodbeta4.lua" and the new "server.lua" that you just downloaded into that same directory, C:\Program Files\Eagle Dynamics\DCS A-10C\Scripts\net.

ModMan Installation:

http://forums.eagle.ru/attachment.php?attachmentid=56070&stc=1&d=1314897034

--------------------------------------------------------------------------------------------------

Servman installation:

Manual installation

1) Download these three files:

http://forums.eagle.ru/attachment.php?attachmentid=55924&d=1314597628

http://forums.eagle.ru/attachment.php?attachmentid=55925&d=1314597628

http://forums.eagle.ru/attachment.php?attachmentid=55980&d=1314722543

2) In C:\Program Files\Eagle Dynamics\DCS A-10C\Scripts, rename "MissionScripting.lua" to "MissionScripting_original.lua". Next, drop the "MissionScripting.lua" file you downloaded here into that same directory.

3) In C:\Program Files\Eagle Dynamics\DCS A-10C\Scripts\Addons\Servman3, rename "servman_server.lua" to "servman_server_original.lua". Drop the servman_server.lua file you downloaded HERE into that directory.

4) Drop the slmodbeta4.lua file into the directory C:\Program Files\Eagle Dynamics\DCS A-10C\Scripts\net

ModMan Installation

http://forums.eagle.ru/attachment.php?attachmentid=56072&stc=1&d=1314897088

slmodbeta4.pdf

MissionScripting.lua

slmodbeta4.lua

server.lua

slmod hello world.miz

servman_server.lua

slmodbeta4_NOservman.zip

slmodbeta4_for_Servman_3_0_0.zip

Oh snap. On time as promised too.

Im taking a look at your example mission, enter stage left LMFAO. Like one very simple example. One unit, one script, one trigger. Not even a decent example of one of the longer types like groupMGRS with a good example for syntax. I gotta admit if you were looking to trim any fat off that mission Id say you were quite successful. But its alright your pdf is on point so no worries.

However, maybe a quick observation, perhaps instead of 'hello world' we could go with 'goodbye cruel world'... Just a thought, you know im just spitballin here, but it seemed like a good idea at the time. I mean he is the LAST guy on the planet, apparently.

Im taking a look at your example mission, enter stage left LMFAO. Like one very simple example. One unit, one script, one trigger. Not even a decent example of one of the longer types like groupMGRS with a good example for syntax. I gotta admit if you were looking to trim any fat off that mission Id say you were quite successful. But its alright your pdf is on point so no worries.

 

However, maybe a quick observation, perhaps instead of 'hello world' we could go with 'goodbye cruel world'... Just a thought, you know im just spitballin here, but it seemed like a good idea at the time. I mean he is the LAST guy on the planet, apparently.

Well, the idea was, at the time, to just show a very simple example of how it works. Script group/unit, triggered action, trigger. You understand that, and one should be able to use the guide to understand the rest. That said, it would certainly most likley be a good idea for me to create more example missions... in fact, I have a quite a few made already as testing missions.

Spent something like 6 hours working on slmod yesterday... I didn't manage to get any functionality added, but I did learn a lot. I'm pretty positive I can make a "weapons impacting in zone" function for missiles and bombs, but doing it for guns without noticably impacting frame rates may be a problem. I'm going to keep thinking about it, there has to be a way. Maybe I can use Luasocket and an external process to make it parallel processed.

Ok, well I got the Modman packs up today at noon. See post #21. I am pretty confident now that there will not be any updates for a while, as I am planning a re-write and cleanup of the data sending code, and working on a new events and unit library that will enable me to write some pretty cool functions, as well as support two other community modding efforts. Once I have all that finished, I hope to integrate some really cool functions, possibly including Unit(s) killed by Unit(s), weapons impacting in zone, Unit(s) firing, Unit(s) LOS to Unit(s), Units(s) killed by Unit(s), Unit(s) firing Weapon(s), Unit(s) radar locked on Units(s).... etc. Quite possibly some of those will require too much processing time to implement. Maybe I shouldn't be mentioning them because of that, but I'd like to make as many of those available and practical as possible. The benefit of trying to develop this stuff on a slow computer with a hard disk drive means it ought to work on other old and slow computers as well :)