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

[mia389]

Nice job Speed. When I get some time I can update my missions now. Big thanks!

[Speed]

Nice job Speed. When I get some time I can update my missions now. Big thanks!

 

It shouldn't be difficult at all, in fact, I'll do it if you want, but it could be some good experience for you to do it, especially now that it's so easy (looked like you nearly had the harder method figured out, too). Delete all the Lua in the initialization scripts for chatIOlibv1 and v2, but leave the triggered actions themselves- rename them to "blank". This way, you can avoid having the the whole list of triggered actions shift upwards, messing up which trigger calls which script, which is what happens when you outright delete a triggered action. So yea, just empty out all the initialization and installation scripts. Now, just change every chatmsg_MGRS(...) or chatmsg_repeat(...) or command_check_start_loop(...) with slmod.chatmsg_MGRS(...), slmod.chatmsg_repeat(...), or slmod.command_check_start_loop(...), respectively, and that should do it.

[mia389]

Sounds easy :thumbup:

[WildFire]

Hmm.. tonight was the first time I punched up a server since installing the late-sunday version you put out, servman was broken... I'll have to look into it. Cant imagine your scripts would have changed anything, probably corrupted a copy of something somewhere.

 

Already implemented your object-destroyed trigger in one of my "semi-dynamic" campaign missions Im building. I hope that works as that is one of the things I really wish ED would have built into the game.

[Speed]

Hmm.. tonight was the first time I punched up a server since installing the late-sunday version you put out, servman was broken... I'll have to look into it. Cant imagine your scripts would have changed anything, probably corrupted a copy of something somewhere.

 

Already implemented your object-destroyed trigger in one of my "semi-dynamic" campaign missions Im building. I hope that works as that is one of the things I really wish ED would have built into the game.

 

Well, my scripts very well could be at fault, having never tested the Servman version myself. Sounds like I'll have to bite the bullet and install it myself. Last time I had it installed, I couldn't test anything on it because it would just auto pause with only me in the server, and I didn't take the time to figure out how to turn off auto pause... let me know if you make the Servman version work yourself, but meanwhile, I'll probably just have to install it and figure it out myself. If you get the chance, you could upload a copy of dcs.log next time you test the Servman version. If there's a problem, it will usually tell you exactly what the problem is in dcs.log.

 

Those campaign missions you are building- they're multiplayer, right? Just making sure. I don't think much, if any, slmod functions work in single player ATM, as slmod is dependent on the on_process function in Scripts/net/server.lua. on_process is not called when you are a client, and I don't believe that it's called when you are in single player, either. I could be completely wrong about that though. At the very least, I can tell you that single player functionality is completely untested. I would certainly like to expand slmod functionality to single player eventually, however... not sure how difficult or easy that will be. Hell, maybe it already works...

 

Anyway, work continues... I've been spending the last 1-2 weeks primarily building the foundation I will need for unit line of sight, units firing weapons, units killed by units, units killed/damaged by units, etc functions, and I think that this foundation is nearly complete; yesterday I was able to create a units line of sight to units function that works on multiplayer clients. Just taking a guess here, but the next slmod version may be out in 2-3 weeks, and I may call it a "release" version rather than a beta version this time. One of the huge challenges I have been facing is how to make all this stuff work without significantly slowing down the multiplayer host's frame rate or causing pauses. This is mainly due to the high computational overhead of the loadstring function (it's only possible to directly pass strings between the environments, so in order to pass a data table, one must, at some point, use loadstring)... anyway, I've found some tricks and I'm getting what I believe to be acceptable performance- no slow downs or pauses, at least on my machine, and I have a low-end PC. I've gotta get some performance tests on other hardware, though.

[WildFire]

Yeah they are MP. Ive been so busy building and testing I havent had a chance to look at the code involved with slm/servman. Maybe this week. So far most of your stuff seems to be working without error. The only thing I havent tested is the map_object, I have a task using it I just havent checked to see if it switched the flag. I'll get to it.

 

I really enjoy the parallel tasking, perhaps a way to assign aircraft and have it come up in the task list would be neat, but as it is now, it works and is great so who really cares.

 

A couple of questions, do your scripts use local or global? Are you able to pass variables from one environment to the next or do you have to define them beforehand? Are they created and named as you pass them?

[Druid_]

One of the huge challenges I have been facing is how to make all this stuff work without significantly slowing down the multiplayer host's frame rate or causing pauses. This is mainly due to the high computational overhead of the loadstring function ...

You have to pass the whole table using loadstring! is there no C++ pointer type system in Lua, I'll have to have a scan through my lua book later.

[Speed]

You have to pass the whole table using loadstring! is there no C++ pointer type system in Lua, I'll have to have a scan through my lua book later.

 

Lua does not have pointers, though it has something called "userdata". I don't believe I can use this purely from Lua, however, I think you have to edit the C source code as well. But yea, there is a glaring lack of pointer implementation within Lua itself. Even if you can do useful stuff purely in Lua using userdata, it's hard for me to find any information on how to do it. The most likely explanation is that it is impossible to do stuff with userdata solely from within Lua, as Lua is ment to be a scripting language, not a programming language.

 

Certainly, you cannot tell Lua variables to take on the value contained at a certain memory address, and you cannot tell Lua variables to take on the value of the memory address of a certain variable- the C/C++/C#? implementation that I am familiar with.

 

Sadly, you can in fact get the memory address of a Lua table- just run the print function on that table and it will say something like: "table: 000a7c932f15". The hex number is the memory address. But you cannot do anything with that- though it has come in useful to me before, as I can use it determine when two tables are in fact the exact same table.

 

It sucks, but to pass a table to a different Lua environment, you have to first:

1) Convert the table to a string that can be safely run with loadstring. string.format('%q', s) comes in useful here.

 

2) Send this string. However you are going to send it.

 

3) run do something like loadstring('passed_data = ' .. s)() on the string.

Now passed_data is a global variable that is a table that contains your original data.

 

But yea, you can't just pass a pointer to a table. Programatically, a multi-enviroment approach in Lua is ugly, but ED gives me no other choice at this moment. All the useful stuff is spread out among the net, server/main, export, and mission environments, and in order to run scripts on a triggered actions, you gotta go into a fifth environment as well, the "mission scripting" environment. I think this is why c0ff said this:

Uhh, this multi-env approach start to look ugly.

Since this scripting thing is actually getting used, I'll think about a better way.

Edited September 7, 2011 by Speed

[Druid_]

Ok I took a look at it last night and it appears that the only solution is to write a C Function that is accessable from the different lua environments using as you said "userdata" or possibly "lightuserdata". Pushing & pulling the data off a reserved stack.

 

One question, does each environment produce its own _G table?

 

I really do hope c0ff gets a chance to streamline this multi-environment approach into something a little easier & less costly to use.

[ivanwfr]

Yea, the _G table is the very means to isolate access controled threads in LUA with setfenv(0, nerfed_G) ...

 

It looks more and more like you' re digging a tunnel between your bed and your bathroom

 

As long as ED wont give back the door handle, all this looks like a waste of hard work. If I say that, it's because I could not go on with what I planned to do with TARGET on my side ... so

[Speed]

Yea, the _G table is the very means to isolate access controled threads in LUA with setfenv(0, nerfed_G) ...

 

It looks more and more like you' re digging a tunnel between your bed and your bathroom

Yea, well, ED locked the bathroom door and threw away the key. The only way to get in there is to dig a tunnel ;)

 

As long as ED wont give back the door handle, all this looks like a waste of hard work. If I say that, it's because I could not go on with what I planned to do with TARGET on my side ... so

 

A waste? Not quite. I'm learning a huge amount about Lua, and what I am making does in fact work... it's just greatly complicated by having to span multiple environments in a programming language that lacks pointers. I also wouldn't blame ED over this, I don't think they ever really anticipated Lua being used so extensively across environments. They have the export environment for modding, but the fact is that export is not good for the kinds of mods that I want to do:

 

If you need to set a flag, then you need to access the server/main or mission environments. If you need to display a message, then you need to access the net or mission environments. If you need to get the position of a unit, then you need to access the server/main or export environments. If you need to convert x,y,z to MGRS or LL, then you need to access the server/main environment. If you need to assign a dynamically created fire at point to artillery, or bombing task to aircraft, then you need to access the server/main environment. If you need to get a list of all the units currently in the game then you need to access the export environment. If you need a function that is called every simulation frame then you need to access the net or export environment. If you need to get all the units in the mission, then you need to access the mission environment. If you need to get received chat messages then you need to access the net environment. If you need to to tell aircraft to orbit somewhere, then you need to access the server/main environment. If you need to get the events, then you need to access the server/main environment. If you need to figure out which aircraft are multiplayer clients, and what their original, mission editor name is, then you need to access the mission, export, AND server/main environments (though perhaps the net environment could be used instead of server/main). And the only environment that is capable of tying these all these disparate environments together with acceptable efficiency is the net environment- due to net.dostring_in. Everything useful is all spread out.

 

What they really need, if at all possible, is a integrated Lua environment that has direct access to all the export, net, server/main, mission (and perhaps config) environment functions and data, and perhaps indirect access to information in the mission scripting environment (as in, a dostring_in that works in mission scripting, and returns a string result).

Edited September 8, 2011 by Speed

[WildFire]

If you need to set a flag, then you need to access the server/main or mission environments. If you need to display a message, then you need to access the net or mission environments. If you need to get the position of a unit, then you need to access the server/main or export environments. If you need to convert x,y,z to MGRS or LL, then you need to access the server/main environment. If you need to assign a dynamically created fire at point to artillery, or bombing task to aircraft, then you need to access the server/main environment. If you need to get a list of all the units currently in the game then you need to access the export environment. If you need a function that is called every simulation frame then you need to access the net or export environment. If you need to get all the units in the mission, then you need to access the mission environment. If you need to get received chat messages then you need to access the net environment. If you need to to tell aircraft to orbit somewhere, then you need to access the server/main environment. If you need to get the events, then you need to access the server/main environment. If you need to figure out which aircraft are multiplayer clients, and what their original, mission editor name is, then you need to access the mission, export, AND server/main environments (though perhaps the net environment could be used instead of server/main). And the only environment that is capable of tying these all these disparate environments together with acceptable efficiency is the net environment- due to net.dostring_in. Everything useful is all spread out.

 

INSANITY.:surrender:

[ivanwfr]

As I understand it (with a rather limited ranged experience) the use of dostring in any recurrent function is the best way to create :doh: unoptimized piece of code in lua where any other scripting language would put some bytecode to replace it at first pass.

 

What I'm trying to underscore here is how far ED decision has damaged this kind of work for the time being. I hope this is just a temporary situation but I can't be optimistic as long as I see that Developer's journal - Lua exporting in DCS page sitting there with large portions of it being so obsolete for years! Even worse, nobody cares to delete it :huh:

 

But I'm sure you learn a lot, just like I used to, from all those not so technical parts around computers. Silicon based are easier to deal with than carbon based after all, everybody knows that!

[Druid_]

They could always keep their environments, just give us easier access to them by incorporating a C functions specifically into the DCS code that register enhanced lua functions capable of the tasks we want. If they really wanted to be smart they could run a specific exe in another thread to do this & it wouldn't hurt frame rates one bit.

 

ivanwfr, c0ff has already said that he will look at a better way of doing it. So I believe it will be temporary, we will just have to be patient & it helps to be a little optimistic now and again.

Edited September 9, 2011 by Druid_

[ivanwfr]

I agree with the positive way to look at things in general, and it would easily apply here as far as we have to deal with smart people, no need to repeat that again and again. But even smart people can have their moments or priorities in need of some comments that may help looking for balance. I know that because I'm smart, just like everyone here ;) and I DO mistakes. I'm even sure I do more mistakes than others. Those that do not do much of anything, just to keep on the safe side.

 

In fact, I'm just trying to help here, isn't that obvious ?

[Speed]

Since there was a request, here is a parallel tasking example mission. Look for scriptman in the northwest corner of the map. He's there and unhidden, you just have to zoom out far enough.

slmod_parallel_tasking_example_mission.miz

Edited October 7, 2011 by Speed

[Scorpi]

very nice, now works

[Speed]

Anyway, I was excited about the progress I made and I have to vent it somewhere. I should release a new version within a 1-2 weeks. Barring unforeseen complications, the following new functions will be included (plus a few others perhaps):

 

mapobj_destroyed_in_zone()- just like it's named, it detects if a map object has been destroyed within a zone. The zone will be placed just like any other using the mission editor. Once the function is called with a unit's triggered action, then if the requisite number of map objects are destroyed within that zone (default is 1, but the user will able to optionally specify a number higher than this), then a flag is set.

 

Anyway, the older, mapobj_destroyed function that requires an id will persist, as I've made the promise to keep supporting all old functions going back to chatIOlibv1, but I expect that except in a few rare cases, the mapobj_destroyed_in_zone function will be preferable.

 

 

units_LOS: Sets a flag based on whether or not a unit or set of units is line of sight to another unit or set of units. Great for "surprise" missions when you want to simulate radar detection by early warning radars.

 

units_hitting: A really powerful function I have been having some fun with. This function will set a flag if a unit(s) hit another unit(s) with a weapon. Additionally, if additional input variables are specified, the function can even output a text, chat, or both text and chat message that includes the name of the unit doing the shooting, and/or the name of the unit getting shot (such as "KNOCK IT OFF 16th Speed!!! YOU'RE SHOOTING AT FRIENDLIES!!!). Anyway,I used this function to make a funny little target recognition mission. Friendly and enemy units are mixed together with their AI off. The mission briefing includes images of all the unit types, friendly and enemy. If you hit three friendly units, your aircraft gets blown up!!!

 

Another example might be this: say you have a helo coming in to drop off troops. If the helo starts getting hit by small arms fire coming from a group of AK-47s on a roof of some building, then you could make the helo say: "We're taking small arms fire from a group of enemy personnel on top of the large building to the east!!". Or if the helo starts taking fire from a Zu-23, then you could make it say "We're taking heavy AAA fire!!!" and then, because the function also sets a flag, you could make the helo break off its approach and return to an orbit somewhere else, make it RTB, trigger an Apache to come kill the Zu-23, etc. The possibilities are exciting!

 

Anyway, I also hope to include a units_firing() function that allows you to detect when units start shooting weapons (even specific weapon types). So you could have a trigger that plays the sound "FOX 3!" every time one of the F-15s doing CAP shoots an AMRAAM.

 

But most importantly, starting this weekend, I am going to start making the youtube video guides and all the example missions on how to use the mod. It's going to be a chore... building is a lot more fun that explaining. Additionally, I am finally going to bite the bullet and fully test the Servman version.

Edited October 14, 2011 by Speed

[WildFire]

"You must spread some rep before giving it to speed again".. lol.

[Grimes]

:

[Forza42]

excellent job, Speed ! love the unit_hit and unit_firing :p

[VFA41_Lion]

Anyway, I also hope to include a units_firing() function that allows you to detect when units start shooting weapons (even specific weapon types). So you could have a trigger that plays the sound "FOX 3!" every time one of the F-15s doing CAP shoots an AMRAAM.

 

This is sort of already implemented in the mission editor - theres that field under types of triggers that says "EVENT something" and "ON SHOT" evaluates the condition when a unit fires something.

[Grimes]

That simply executes a trigger whenever something shoots, but it doesn't exactly know what is shooting, nor are the conditions and actions tied to the unit that is shooting.

[VFA41_Lion]

Yeah, but I was thinking it would work if you put a moving zone around a Bear, and say if DCS F/A-18 comes out, you've got yourself trying to get a Bear away from the carrier group, and the last warning you give it is a tracer stream past its cockpit. That would trigger the Bear getting the heck outta there, and look really damn cool to the player.

 

:P

[Speed]

Yeah, but I was thinking it would work if you put a moving zone around a Bear, and say if DCS F/A-18 comes out, you've got yourself trying to get a Bear away from the carrier group, and the last warning you give it is a tracer stream past its cockpit. That would trigger the Bear getting the heck outta there, and look really damn cool to the player.

 

:P

 

That's a cool idea... but I suppose the trigger would also go off if you turned around and fired on your wingman, or if one of the ships fired a SM-2 or TLAM, eh? Anyway, doing it properly, detecting the passage of rounds near another object or into a certain zone is somewhat difficult, but not impossible... I plan to try it, eventually. The hard part about such a thing, a thing like a "weapons impacting in zone" function, is making it run without micro-stutters when something like a GAU opens up. If you're having to track hundreds of bullets five or ten times every second to determine their flight paths and figure out if they are passing near another object, the game very well could slow down. Maybe if I only track the first bullet of every bullet stream and every fifth or tenth bullet after that, then I can make it work without noticeably impacting frame rates. I did something similar with the events to get them into the "net" environment without causing a frame rate hit.

 

Anyway, I spent the weekend working on the video/powerpoint guides and on the mapobj_dead_in_zone function. That function now works really nicely so far in my tests. You just place a zone in the ME over where you want to detect map objects dying, and set the radius appropriately. In the lua function you run from the trigger, you just specify the zone name, the flag you want to be set to true when map object(s) die in the zone, and up to two more optional input variables- the first optional input variable is the least number of map objects that can die in the zone without the flag being set (so if you specify 2, then three map objects need to die before the flag is set), and the second optional input variable is a stop flag- the stop flag will stop the function from executing (so if you only want the function operating during a certain time frame during the mission, then just set the stop flag true when you want the function to quit looking for map objects being destroyed). The function also ignores all map objects that died in the zone before the function was called. Finally, the function ignores civilian traffic kills (it IS possible to detect civ traffic kills, but I have yet to figure out if there is a way to detect civ traffic deaths within a zone... and it's probably not worth my time, either).

Edited October 17, 2011 by Speed