Jump to content

Slmod- multiplayer server mod for new mission logic functionality


Recommended Posts

Ive done some LUA programming with FSX, basically just reading addy's that otherwise werent available or using formulas to convert Kts to MPH or liters to gallons blablabla. LUA is great and seems pretty solid. Programming can get under your skin and I know my plan-actually-fly ratio is prolly 10-to-1, if even that. The only way i was able to learn some lua ( can be a bit scary to decide to go learn a prog language ) is because of the time/resources given by those willing to share their knowledge and make it accessible for us 'noobs', Im sure effectively cutting more into their ever so dwindling free time...you're too kind Speed. Your work and willingness to teach others is a huge plus for ED marketing also...not to mention LUA can be used many other 'places'...

 

I hope with the release of the ground module your work/sharing doesnt get forgotten. You should be on the dev team IMO..it could only benefit the product.

 

Thanks for these tools and your time.


Edited by Havok
spelling...
Link to comment
Share on other sites

Havok, I appreciate the kind words, but keep in mind that Slmod has really should have been named RGLmod -Rube Goldberg Lua mod. That doesn't mean I'm not trying to make existing scripts better or that they are needlessly over-complicated, but this is still not anything like a professional product... don't get me confused with the actual professionals here. If they happened to see your post, they might not appreciate the comparison :D

 

However, we're all capable of assisting ED in reporting bugs and making feature suggestions. Because the ED team is much more accessible than most development teams, anyone who is capable of providing constructive feedback/bug reporting on the forums is, in a fairly real sense, on the ED team, much more so than most any other game you will come across. It took me a while to realize this.

 

Anyway, why would a ground commander module interfere with Slmod? It's far easier to direct air units through Lua than ground units anyway, so Slmod could potentially be a nice complement to a ground commander module by opening up AI air units to be commanded to some extent too (assuming that commanding air units isn't an unannounced feature of the battle commander module...).

 

Anyway, I did recently get the chat message coordinate analyzer working, so that was a very big brick in the foundation needed for user input. That means I'll have the chat-based coordinate conversion utilities finished whenever I get the time to actually sit down and work on them- but the time I have available for working on Slmod is less and less recently.

Intelligent discourse can only begin with the honest admission of your own fallibility.

Member of the Virtual Tactical Air Group: http://vtacticalairgroup.com/

Lua scripts and mods:

MIssion Scripting Tools (Mist): http://forums.eagle.ru/showthread.php?t=98616

Slmod version 7.0 for DCS: World: http://forums.eagle.ru/showthread.php?t=80979

Now includes remote server administration tools for kicking, banning, loading missions, etc.

Link to comment
Share on other sites

SLmod works like a charm in commmanding air units, combined with the orbit task or the switch waypoint command :).

ChromiumDis.png

Author of DSMC, mod to enable scenario persistency and save updated miz file

Stable version & site: https://dsmcfordcs.wordpress.com/

Openbeta: https://github.com/Chromium18/DSMC

 

The thing is, helicopters are different from planes. An airplane by it's nature wants to fly, and if not interfered with too strongly by unusual events or by a deliberately incompetent pilot, it will fly. A helicopter does not want to fly. It is maintained in the air by a variety of forces in opposition to each other, and if there is any disturbance in this delicate balance the helicopter stops flying; immediately and disastrously.

Link to comment
Share on other sites

Speed, I need a clarify: when I use stopflag to stop a LOS or an HIT function, Can I "reactivate" the function another time few minutes after by using another time the AI-TASK action? or using the Stopflag is a "one-shot" that stop the function for the rest of the mission?

 

thaks,

 

Lore

ChromiumDis.png

Author of DSMC, mod to enable scenario persistency and save updated miz file

Stable version & site: https://dsmcfordcs.wordpress.com/

Openbeta: https://github.com/Chromium18/DSMC

 

The thing is, helicopters are different from planes. An airplane by it's nature wants to fly, and if not interfered with too strongly by unusual events or by a deliberately incompetent pilot, it will fly. A helicopter does not want to fly. It is maintained in the air by a variety of forces in opposition to each other, and if there is any disturbance in this delicate balance the helicopter stops flying; immediately and disastrously.

Link to comment
Share on other sites

Speed, I need a clarify: when I use stopflag to stop a LOS or an HIT function, Can I "reactivate" the function another time few minutes after by using another time the AI-TASK action? or using the Stopflag is a "one-shot" that stop the function for the rest of the mission?

 

thaks,

 

Lore

 

Clear the stopflag first, then run the AI task that called the Lua function again. There's no limit to the number of times you can call an AI task, but if you leave the stop flag true, then the function will just terminate as soon as it starts.

Intelligent discourse can only begin with the honest admission of your own fallibility.

Member of the Virtual Tactical Air Group: http://vtacticalairgroup.com/

Lua scripts and mods:

MIssion Scripting Tools (Mist): http://forums.eagle.ru/showthread.php?t=98616

Slmod version 7.0 for DCS: World: http://forums.eagle.ru/showthread.php?t=80979

Now includes remote server administration tools for kicking, banning, loading missions, etc.

Link to comment
Share on other sites

Yes I had cleared it first. But in the night I understand why It was not working... it's a SW CONDITIONS trigger and I had problems due to the type of trigger.

 

But, maybe, I can report you something useful: any time (even if I use stopflag and then reactivate the function) the "units hit" function have an interesting behaviour... example:

 

I shoot rockets, hitting some units/building. They goes in flames, and the units.hit function turn on flag. Then, I reset the units.hit funtion with the stopflag and clearing the stopflag.

 

Now, if I reactivate the units.hit function before the target stop flaming, I have an immediate "true" to the units.hit function, like the function understand that I just hit the target.

 

Instead, if I reactivate the function after the target stop flaming, it works correctly waiting for another real "hit" to activate.

 

PS:

Is there a way to get the units.hit function to work with smoke rockets (S-8 TsM, for example)?

ChromiumDis.png

Author of DSMC, mod to enable scenario persistency and save updated miz file

Stable version & site: https://dsmcfordcs.wordpress.com/

Openbeta: https://github.com/Chromium18/DSMC

 

The thing is, helicopters are different from planes. An airplane by it's nature wants to fly, and if not interfered with too strongly by unusual events or by a deliberately incompetent pilot, it will fly. A helicopter does not want to fly. It is maintained in the air by a variety of forces in opposition to each other, and if there is any disturbance in this delicate balance the helicopter stops flying; immediately and disastrously.

Link to comment
Share on other sites

Yes I had cleared it first. But in the night I understand why It was not working... it's a SW CONDITIONS trigger and I had problems due to the type of trigger.

 

But, maybe, I can report you something useful: any time (even if I use stopflag and then reactivate the function) the "units hit" function have an interesting behaviour... example:

 

I shoot rockets, hitting some units/building. They goes in flames, and the units.hit function turn on flag. Then, I reset the units.hit funtion with the stopflag and clearing the stopflag.

 

Now, if I reactivate the units.hit function before the target stop flaming, I have an immediate "true" to the units.hit function, like the function understand that I just hit the target.

 

Instead, if I reactivate the function after the target stop flaming, it works correctly waiting for another real "hit" to activate.

 

I understand what is going on here. I should have probably started the events search at the number of events at function call time + 1; instead, events are searched for at the current number of events at function call time. So a lot of the time, if you restart the units_hitting function right after a unit was hit already, the latest event will be the unit being hit and thus, it will come true immediately. When a unit dies, it generates a new event, so that will keep the units_hitting function from going true.

 

I suppose I will fix this behavior in the next update of the mod; in the meantime, if you want to fix it yourself, you can change line 5043 for slmodbeta5_3.lua from

		evnt_ind = #slmod_events 

to:

		evnt_ind = #slmod_events +1

 

BTW, I wouldn't use units_hitting in the way you are describing. There are better ways. You should never have to really use the stopflag on it unless you want to re-use its flag for something else entirely. Here's one way how I use it.

 

Once->(Condition)->(Start units_hitting func)

Continuous->(units hitting flag is true)->(units hitting flag off, flag X on)

Once/Switched/Continuous->(flag X is true, any additional conditions)->(do mission logic)

 

There is no reason you should use the stopflag on units_hitting if you plan to just restart it again in a few seconds or minutes. Also, if you think you might be having a problem with Switched triggers, then you only need to avoid them when the flag is directly operated on by Slmod.

 

PS:

Is there a way to get the units.hit function to work with smoke rockets (S-8 TsM, for example)?

 

No... that's one of the things I'd like to eventually get a weapons impacting in zone function working for.


Edited by Speed

Intelligent discourse can only begin with the honest admission of your own fallibility.

Member of the Virtual Tactical Air Group: http://vtacticalairgroup.com/

Lua scripts and mods:

MIssion Scripting Tools (Mist): http://forums.eagle.ru/showthread.php?t=98616

Slmod version 7.0 for DCS: World: http://forums.eagle.ru/showthread.php?t=80979

Now includes remote server administration tools for kicking, banning, loading missions, etc.

Link to comment
Share on other sites

I'm glad to see that you suggest a way that I already found to not implement the stopflag... but I thought that stopflag is best suitable than the workaround :)

ChromiumDis.png

Author of DSMC, mod to enable scenario persistency and save updated miz file

Stable version & site: https://dsmcfordcs.wordpress.com/

Openbeta: https://github.com/Chromium18/DSMC

 

The thing is, helicopters are different from planes. An airplane by it's nature wants to fly, and if not interfered with too strongly by unusual events or by a deliberately incompetent pilot, it will fly. A helicopter does not want to fly. It is maintained in the air by a variety of forces in opposition to each other, and if there is any disturbance in this delicate balance the helicopter stops flying; immediately and disastrously.

Link to comment
Share on other sites

What I intended stopflag to be used for was cases like this:

1) You are NEVER going to need to detect that same units_hitting logic again, and you want to make a what will most likely be an infinitesimal increase in the host's frame rate.

2) You want to re-use the flag operated on by units_hitting for something else

3) You need to only detect units_hitting during a certain time frame (this can also be applied through things like TIME MORE and other trigger conditions, but it's nice to give folks a choice.

 

stopflag is also in there because the function is more logically complete with it, and because units_LOS, which has a very good reason for stopflag, has it too. Also, I included it for other random uses people might think of it (it is better to provide more flexible tools and let people decide how to use them than narrowly define how something should be used).

 

But anyway, I thank you, you found what I consider to be a bug in the logical implementation of this function. Events-based and chat-based commands need to begin operations on the next event/chat message after the function is called. I'll see if this logical error exists in any other Slmod functions as well. Some of these errors/inconsistencies exist because I hadn't fully fleshed out all the logical minutiae before I wrote the function. I've found a few cases where different functions treat stopflag slightly differently. I should probably standardize all of these details as much as possible starting with the next Slmod version.


Edited by Speed

Intelligent discourse can only begin with the honest admission of your own fallibility.

Member of the Virtual Tactical Air Group: http://vtacticalairgroup.com/

Lua scripts and mods:

MIssion Scripting Tools (Mist): http://forums.eagle.ru/showthread.php?t=98616

Slmod version 7.0 for DCS: World: http://forums.eagle.ru/showthread.php?t=80979

Now includes remote server administration tools for kicking, banning, loading missions, etc.

Link to comment
Share on other sites

Glad to be useful , and looking forward to version 6.0, obviously when it will be ready ;)

ChromiumDis.png

Author of DSMC, mod to enable scenario persistency and save updated miz file

Stable version & site: https://dsmcfordcs.wordpress.com/

Openbeta: https://github.com/Chromium18/DSMC

 

The thing is, helicopters are different from planes. An airplane by it's nature wants to fly, and if not interfered with too strongly by unusual events or by a deliberately incompetent pilot, it will fly. A helicopter does not want to fly. It is maintained in the air by a variety of forces in opposition to each other, and if there is any disturbance in this delicate balance the helicopter stops flying; immediately and disastrously.

Link to comment
Share on other sites

Hi again, Speed :)

 

I need an information about rand_flags_on... Can I re-call the function many times in the same scenario?

 

Example: on time "15 sec" I activate a rand_flag for 6 different flags. Than, on time 40, I force them all "off". on time 60 I want to reload the rand_flag function.

ChromiumDis.png

Author of DSMC, mod to enable scenario persistency and save updated miz file

Stable version & site: https://dsmcfordcs.wordpress.com/

Openbeta: https://github.com/Chromium18/DSMC

 

The thing is, helicopters are different from planes. An airplane by it's nature wants to fly, and if not interfered with too strongly by unusual events or by a deliberately incompetent pilot, it will fly. A helicopter does not want to fly. It is maintained in the air by a variety of forces in opposition to each other, and if there is any disturbance in this delicate balance the helicopter stops flying; immediately and disastrously.

Link to comment
Share on other sites

Hi again, Speed :)

 

I need an information about rand_flags_on... Can I re-call the function many times in the same scenario?

 

Example: on time "15 sec" I activate a rand_flag for 6 different flags. Than, on time 40, I force them all "off". on time 60 I want to reload the rand_flag function.

 

That's right, you can call rand_flags_on as much as you want without worrying about slowing the game down or anything. rand_flags_on doesn't start a process running like functions such as units_LOS or units_firing do.

Intelligent discourse can only begin with the honest admission of your own fallibility.

Member of the Virtual Tactical Air Group: http://vtacticalairgroup.com/

Lua scripts and mods:

MIssion Scripting Tools (Mist): http://forums.eagle.ru/showthread.php?t=98616

Slmod version 7.0 for DCS: World: http://forums.eagle.ru/showthread.php?t=80979

Now includes remote server administration tools for kicking, banning, loading missions, etc.

Link to comment
Share on other sites

Anyway, for some time I've been needing to give an update as to the status of the next full version I said I would be done with already a month ago.

 

Sorry but I just can't keep up with any kind of schedule. I've got numerous things preventing me from working on Slmod as much as I would like to- higher priority projects of both DCS and real life, for example. I hope to get a lot of it out of the way and get working on Slmod closer to full-time soon.

 

But I haven't been NOT working on it either... in little 30 minute, 1 hours intervals of free time, I wrote the object oriented menu system, then scrapped it and am in the process of re-writing it now. I really like how the new one is shaping up. I've also had some pretty cool ideas recently that would be very worthy to put into the next full version, so it's not all bad.

 

So anyway, I can't even begin to guess when I might be done with the next major version. It's largely out of my control, in fact, for the time being. However, minor updates similar to what version 5.3 was would be possible in the interim if folks are interested. Some of the ideas I want to implement wouldn't take long in fact to get working. I was dead-set on making the next version be v6, but it could be v5.4 too, I guess.

Intelligent discourse can only begin with the honest admission of your own fallibility.

Member of the Virtual Tactical Air Group: http://vtacticalairgroup.com/

Lua scripts and mods:

MIssion Scripting Tools (Mist): http://forums.eagle.ru/showthread.php?t=98616

Slmod version 7.0 for DCS: World: http://forums.eagle.ru/showthread.php?t=80979

Now includes remote server administration tools for kicking, banning, loading missions, etc.

Link to comment
Share on other sites

You're doing an excellent work, that it's part of 100% of my edited missions since I wrote the first post here :) (like this: http://forums.eagle.ru/showthread.php?t=85081)

 

Also, I know that at least 3 of 5 italian mission designer in contact with me use SLmod, even if they don't write here :).

 

I never stop saying that you bring us better editing capabilities and, therefore, better sim experience.

 

So, for me... when it will be ready, it will be ready, no matter time-scheduling :)

ChromiumDis.png

Author of DSMC, mod to enable scenario persistency and save updated miz file

Stable version & site: https://dsmcfordcs.wordpress.com/

Openbeta: https://github.com/Chromium18/DSMC

 

The thing is, helicopters are different from planes. An airplane by it's nature wants to fly, and if not interfered with too strongly by unusual events or by a deliberately incompetent pilot, it will fly. A helicopter does not want to fly. It is maintained in the air by a variety of forces in opposition to each other, and if there is any disturbance in this delicate balance the helicopter stops flying; immediately and disastrously.

Link to comment
Share on other sites

At last, I had some good time to devote to Slmod, but thinking ahead to my schedule for the next week, this may be the last time I get for a while.

 

I went ahead and built the coordinate converter to help test the OO menu system. There's still some bugs, but at least it's beginning to function. Currently the coordinate converter supports conversion between these coordinate systems:

 

-MGRS

-Lat/Long (accepts input in any valid format, but output format will always be degrees and minutes to the third decimal place)

-BR (bearing and range from your aircraft, in degrees and nautical miles)

-Bullseye (bearing and range from your coalition's bullseye, in degrees and nautical miles).

 

I am also considering the addition of one further input/output coordinate system:

 

-MPBullseye (multiplayer client bullseye- the bugged, incorrect bullseye coordinates that we hear on the radio in multiplayer when we are not server host)

 

and a further additional output coordinate format, Lat/Long in DMS. Anyway, from the following screenshot, you'll see, you don't even need to be reel gud at speeling to use the coordinate converter utility:

attachment.php?attachmentid=62949&stc=1&d=1329798883

 

Now I need to go find some victim to help me test this with clients :D The coordinate converter is supposed to send the converted coordinates as a private message to you (can't really test that without a client), and, further, I am planning on making the actual coordinate conversion request chat message itself not displayed on the screen. And the "to" is supposed to be optional, but whenever I omitted it, the converter failed so I need to figure out what's up with that. But it feels good to finally get some of this done.

coordinate_converter_first_chats.thumb.jpg.6ec539c3d4d05dfb68977375b7b98f66.jpg


Edited by Speed

Intelligent discourse can only begin with the honest admission of your own fallibility.

Member of the Virtual Tactical Air Group: http://vtacticalairgroup.com/

Lua scripts and mods:

MIssion Scripting Tools (Mist): http://forums.eagle.ru/showthread.php?t=98616

Slmod version 7.0 for DCS: World: http://forums.eagle.ru/showthread.php?t=80979

Now includes remote server administration tools for kicking, banning, loading missions, etc.

Link to comment
Share on other sites

first victim lined up, but you have to wait next week, cause I will be out for work :)

ChromiumDis.png

Author of DSMC, mod to enable scenario persistency and save updated miz file

Stable version & site: https://dsmcfordcs.wordpress.com/

Openbeta: https://github.com/Chromium18/DSMC

 

The thing is, helicopters are different from planes. An airplane by it's nature wants to fly, and if not interfered with too strongly by unusual events or by a deliberately incompetent pilot, it will fly. A helicopter does not want to fly. It is maintained in the air by a variety of forces in opposition to each other, and if there is any disturbance in this delicate balance the helicopter stops flying; immediately and disastrously.

Link to comment
Share on other sites

OK... the coordinate converter is pretty much complete. It was a lot more work than I initially thought. Requests to the coordinate converter, and its replies back to you, are now filtered from chat and text so that no one sees them but the person actually using it.

 

I do have a bit of delimma. Remember how until a few patches back, TAD and HSI were mis-aligned by 5-10 degrees? The problem was, the game map's x direction is considered due north by some calculations, but by others, it's way off. In lat/long coordinates, for example, the x direction only points due north at 33 degrees longitude. Around the Kutaisi/Senaki/Zugdidi area, for example, there is like a six degree difference between lat/long north and the x direction.

 

So when they fixed the TAD and HSI a few patches back, this misalignment went away. However, radio calls still reference the x axis to determine BRA and Bullseye coordinates. So should I make the Coordinate Converter work in radio bearings or instrument bearings when working with BR and Bulls coordinates? Hmm. There is a third option maybe, perhaps it might be possible to make a mod to fix radio bearings, or at least, drastically improve their azimuthal accuracy? Maybe create the fix multiplayer bullseye calls while I was at it too? I'll investigate. Such a thing would have to be installed on your machine locally, it couldn't be a server mod.

 

Anyway. I have also made some performance improvements by revisiting older code and applying better techniques I've learned since. I found and fixed a few bugs, and added the "units_killed_by", "units_ejected", "units_crashed", and "pilots_dead" functions. Those could come in pretty handy. You can sorta detect some of those with the current function set, and/or mission editor triggers, but a bazillion trigger conditions are often needed (I remember, my trigger that holds the record for the most conditions (54) was used for detecting crashed aircraft).


Edited by Speed

Intelligent discourse can only begin with the honest admission of your own fallibility.

Member of the Virtual Tactical Air Group: http://vtacticalairgroup.com/

Lua scripts and mods:

MIssion Scripting Tools (Mist): http://forums.eagle.ru/showthread.php?t=98616

Slmod version 7.0 for DCS: World: http://forums.eagle.ru/showthread.php?t=80979

Now includes remote server administration tools for kicking, banning, loading missions, etc.

Link to comment
Share on other sites

Units_ejected will simplify a lot my "CSAR" sub-mission... it will be great :)

 

To check about the misalignment, maybe you could test it by comparing the SLmod answer in BRA with the actual position given in F10 view by the ruler.

ChromiumDis.png

Author of DSMC, mod to enable scenario persistency and save updated miz file

Stable version & site: https://dsmcfordcs.wordpress.com/

Openbeta: https://github.com/Chromium18/DSMC

 

The thing is, helicopters are different from planes. An airplane by it's nature wants to fly, and if not interfered with too strongly by unusual events or by a deliberately incompetent pilot, it will fly. A helicopter does not want to fly. It is maintained in the air by a variety of forces in opposition to each other, and if there is any disturbance in this delicate balance the helicopter stops flying; immediately and disastrously.

Link to comment
Share on other sites

I know that maybe this is not the right time to make suggestions/whislist, but I had a couple of in-work observations to report:

 

1. It could be really useful to have some kind of "reverse" LOS function. Example: if a (table unit 1) is not in LOS of (table unit 2), flag. This could lead to turning on and off some logic related to the lose of line-of-sight. Useful with IADS logic and SAMs.

 

2. It could be REALLY useful to have some kind of "coalition-to table-units" LOS function. This could be really useful for IADS simulation improvement. Something like "If (table units) is in LOS with (blue coalition), flag".

 

3. It could be good to have the ability to turn off flags also into the functions (I know, it could be done by two trigger using another flag, but this will longer the designer work a lot for a great amount of unit).

 

What do you think about those?

Is there a way that I could be help you (take in account that I really do not know anything about lua)?

ChromiumDis.png

Author of DSMC, mod to enable scenario persistency and save updated miz file

Stable version & site: https://dsmcfordcs.wordpress.com/

Openbeta: https://github.com/Chromium18/DSMC

 

The thing is, helicopters are different from planes. An airplane by it's nature wants to fly, and if not interfered with too strongly by unusual events or by a deliberately incompetent pilot, it will fly. A helicopter does not want to fly. It is maintained in the air by a variety of forces in opposition to each other, and if there is any disturbance in this delicate balance the helicopter stops flying; immediately and disastrously.

Link to comment
Share on other sites

I know that maybe this is not the right time to make suggestions/whislist, but I had a couple of in-work observations to report:

 

1. It could be really useful to have some kind of "reverse" LOS function. Example: if a (table unit 1) is not in LOS of (table unit 2), flag. This could lead to turning on and off some logic related to the lose of line-of-sight. Useful with IADS logic and SAMs.

As far as I can think, the units_LOS function is logically complete (meaning, any LOS situation you want to detect with units_LOS can be detected with the units_LOS function + some other triggers). That doesn't mean though that units_LOS can't or shouldn't be improved (or more likely, a new, "units_LOS2" function be introduced) to do a bit of the common logic for you automatically, as you suggest.

 

The way I ususally take care of things like this is that I am continuously evaluating the units_LOS flag(s) and when they go true, I disable them, and do some other logic. So later down the line in my trigger logic, its quite simple- if the flags or logic that were to occur if the units_LOS flag had been enabled does not occur, then the units are not LOS.

 

Another good way of doing this is to remember that when the game does a cycle of trigger evaluations, it goes down your list of triggers one after the other, in order from first to last. So if your last trigger on the trigger rules list is one be one that turns off all units_LOS flags, then everywhere else in your trigger logic you know that if the units_LOS flag(s) are true, then the one of the units in the first set is LOS to one of the units in the second set. If the units_LOS flag(s) are false, then none of the units are LOS to each other.

 

2. It could be REALLY useful to have some kind of "coalition-to table-units" LOS function. This could be really useful for IADS simulation improvement. Something like "If (table units) is in LOS with (blue coalition), flag".

Something like this is one of the planned features:

"<g>group name": indicates ALL units in that group.

"<coa>red" or "<coa>blue": all units in that coaltion.

I may add a country signifier too. Also in consideration would be some kind of expression format:

{"<coa>blue<->client1<->client2<-><g>patriots", "<g>SA-10s"} - all of blue coalition's units except the units named "client1" and "client2", and the group "patriots", plus the group "SA-10s". So units_LOS used for detecting LOS between any units of one coalition with any units of another coalition would be:

 

slmod.units_LOS({"<coa>blue"}, 2, {"<coa>red"}, 2, .........)

 

3. It could be good to have the ability to turn off flags also into the functions (I know, it could be done by two trigger using another flag, but this will longer the designer work a lot for a great amount of unit).

 

The problem is perhaps I make the functions less logically complete by doing so. Automatically turn off the units_LOS flag when no longer LOS? Sometimes you want it to stay on till you handle it with your trigger logic perhaps 3, 4, 5 seconds later. This would need to be an optional variable, and until I enhance the way that data is passed, I've pretty much reached the limits on variables in many functions.

 

In the enhanced way to call functions, you would do something like this:

 

units_LOS({ unitset1 = {<units>}, unitset2 = {<units>}, altoffset1 = <number>, altoffset2 = <number>, flag = <number>, stopflag = <number>, radius = <number>, auto_turnoff = <boolean>})

 

Now, you don't have to input the variables in the proper order, as the variables are just table keys.

 

But I donno when or if I will introduce this method.

 

An easier way for me to do it would be some kind of intermediary function:

 

Slmod.call(units_LOS, { unitset1 = {<units>}, unitset2 = {<units>}, altoffset1 = <number>, altoffset2 = <number>, flag = <number>, stopflag = <number>, radius = <number>, auto_turnoff = <boolean>})

 

The Slmod.call function (in next version of Slmod, by the way, both Slmod.<func> and slmod.<func> work, I added the line "Slmod = slmod" at the end of MissionScripting.lua) would interpret your table, and automatically fill in any unnecessary optional variables with proper "don't care" values.

 

This way, I can keep the ~1000 ish lines of my current data passing code, which while not perfect, and is the oldest code in the mod (it dates back to July, when I probably knew 1/3 as much about Lua as I do now), at least has proven to be 100% reliable and safe so far.


Edited by Speed

Intelligent discourse can only begin with the honest admission of your own fallibility.

Member of the Virtual Tactical Air Group: http://vtacticalairgroup.com/

Lua scripts and mods:

MIssion Scripting Tools (Mist): http://forums.eagle.ru/showthread.php?t=98616

Slmod version 7.0 for DCS: World: http://forums.eagle.ru/showthread.php?t=80979

Now includes remote server administration tools for kicking, banning, loading missions, etc.

Link to comment
Share on other sites

First: very clear answer, thanks :).

 

For point 1: I understand the solutions, I should simply turn off the flag with a coontinous action trigger every time, and be sure that this cont.action is placed immediately above the trigger ruled by SLmod.. exaple (the "slmod.function" is the number of the flag activated by the LOS):

 

...

CONT.ACT -> FLAG TRUE (slmod.function) -> FLAG OFF (slmod.function)

SW.COND -> FLAG TRUE (slmod.function) -> (desidered actions)

...

 

This way the sim will consider the flag true every cicle since the SLmod function is not true. Is that correct?

 

At point 2... the group feature could really help ;). I'll wait and in the meantime find a workaround :)

 

At point 3 there is a misunderstanding, I do not explain correctly what I was thinking: what I mean is that when the conditions in the function is reached, the function turn off a flag instead of turning it on.

 

Obviously, I can get it in another way, using a slmod.function that turn on a flag and then:

 

SW COND -> FLAG ON (slmod.function flag) -> FLAG OFF (my.flag.objective) + FLAG OFF (slmod.function flag)

 

the blue part is optional depending on the use I need. But this way I need a trigger there and a flag used just to have the behaviour I need. But... it really doesn't matter much: it work good as it is.

ChromiumDis.png

Author of DSMC, mod to enable scenario persistency and save updated miz file

Stable version & site: https://dsmcfordcs.wordpress.com/

Openbeta: https://github.com/Chromium18/DSMC

 

The thing is, helicopters are different from planes. An airplane by it's nature wants to fly, and if not interfered with too strongly by unusual events or by a deliberately incompetent pilot, it will fly. A helicopter does not want to fly. It is maintained in the air by a variety of forces in opposition to each other, and if there is any disturbance in this delicate balance the helicopter stops flying; immediately and disastrously.

Link to comment
Share on other sites

First: very clear answer, thanks :).

 

For point 1: I understand the solutions, I should simply turn off the flag with a coontinous action trigger every time, and be sure that this cont.action is placed immediately above the trigger ruled by SLmod.. exaple (the "slmod.function" is the number of the flag activated by the LOS):

 

...

CONT.ACT -> FLAG TRUE (slmod.function) -> FLAG OFF (slmod.function)

SW.COND -> FLAG TRUE (slmod.function) -> (desidered actions)

...

 

This way the sim will consider the flag true every cicle since the SLmod function is not true. Is that correct?

 

 

Ok, here's how triggers work, to the best of my knowledge:

 

Once every second, the simulation says, "hey, let's check the trigger table" (remember, a table, in this use, is a list). So the simulation goes to your trigger table. It goes down the list of existing triggers, one by one, in order from first to last. If the conditions are true, then it does the actions. There are some additional actions that can be inserted based on trigger type, but let's not get too complex.

 

Anyway, the point is, remember this- if you turn off a flag with a trigger, and no other trigger in your list turns that flag on, then it's still going to be off when the sim reaches the end of the trigger list. NOTHING can turn it on, because DCS is not multithreaded- there are no back-ground things going on to turn flags on or off while the sim is stepping through your trigger list- other than perhaps the sound engine.

 

Now, in-between the game's evaluation of the triggers list, which occurs once every second, other things CAN set flags- such as Slmod or perhaps the F10 "Other" radio options menu.

 

Anyway, the point is, in the example you give, you turn off the flag that was possibly set true by Slmod before you do anything with it. That means that the boolean (true/false) information contained in that flag is forever lost.

 

Another important thing to remember is that Slmod is not operating in the mission scripting Lua environment, so when you call an Slmod function, it could take anywhere from 0-2.5 seconds for that information to filter up to the Lua environment where Slmod does things. Slmod functions return no values because there ARE no values to return; there is no memory link between the mission scripting environment, where you usually call Slmod functions, and net environment, where Slmod primarily operates.

 

Anyway, all that said, there's like an infinite number of ways to use the units_LOS function, but here's two ways that I see as being simple and easy:

 

ONE WAY TO DO IT:

 

Beginning of trigger list

........

........

Continuous->Flag is true(units_LOS flag)->Flag off(units_LOS flag), Flag on(flag X)

Once/Switched/Continuous ->Flag is true (flagX) -> Do Actions, <optional, for repeating actions: Flag off(flag X)>

.......

.......

End of trigger list

 

ANOTHER WAY TO DO IT:

 

Beginning of trigger list

........

........

Once/<Switched?>/Continuous ->Flag is true (units_LOS flag) -> Do Actions

.......

.......

Continuous->ALWAYS TRUE CONDITION->Flag off(units_LOS flag)

End of trigger list

 

 

Both ways should work; I put the <Switched?> as questionable because I'm not quite sure if it will behave correctly; Switched MAY malfunction when flags are set by a force outside of the triggers.

 

Anyway, the point is, both ways should work; in the second method, you know that, if the units_LOS flag is true, it's true because on the last evaluation of units_LOS, there were units line of sight. The same holds true of "flag X" in the first example, but with the first example, I know for a fact it will be "safe" to use Switched triggers on flag X.

 

At point 3 there is a misunderstanding, I do not explain correctly what I was thinking: what I mean is that when the conditions in the function is reached, the function turn off a flag instead of turning it on.

 

Obviously, I can get it in another way, using a slmod.function that turn on a flag and then:

 

SW COND -> FLAG ON (slmod.function flag) -> FLAG OFF (my.flag.objective) + FLAG OFF (slmod.function flag)

 

the blue part is optional depending on the use I need. But this way I need a trigger there and a flag used just to have the behaviour I need. But... it really doesn't matter much: it work good as it is.

Maybe add an optional variable that tells the function to TURN OFF the flag when the conditions are reached rather than turn it on? I suppose that's possible. Understand that the first Slmod releases have been intended mainly to add functionality;flexibility was not considered as important, as the users could just make up for such things with an extra trigger or two. This next release WILL focus more on user-friendliness; the aforementioned feature of "<g>groupname" is one of the two or three significant improvements planned in this regard.

Intelligent discourse can only begin with the honest admission of your own fallibility.

Member of the Virtual Tactical Air Group: http://vtacticalairgroup.com/

Lua scripts and mods:

MIssion Scripting Tools (Mist): http://forums.eagle.ru/showthread.php?t=98616

Slmod version 7.0 for DCS: World: http://forums.eagle.ru/showthread.php?t=80979

Now includes remote server administration tools for kicking, banning, loading missions, etc.

Link to comment
Share on other sites

I put the <Switched?> as questionable because I'm not quite sure if it will behave correctly; Switched MAY malfunction when flags are set by a force outside of the triggers.

 

to be honest, in the scenery I'm preparing i used something like one hundred or two of SW.COND trigger activated by SLmod... and since now noone fail.

 

But I'll report if something do not go as planned.

ChromiumDis.png

Author of DSMC, mod to enable scenario persistency and save updated miz file

Stable version & site: https://dsmcfordcs.wordpress.com/

Openbeta: https://github.com/Chromium18/DSMC

 

The thing is, helicopters are different from planes. An airplane by it's nature wants to fly, and if not interfered with too strongly by unusual events or by a deliberately incompetent pilot, it will fly. A helicopter does not want to fly. It is maintained in the air by a variety of forces in opposition to each other, and if there is any disturbance in this delicate balance the helicopter stops flying; immediately and disastrously.

Link to comment
Share on other sites

to be honest, in the scenery I'm preparing i used something like one hundred or two of SW.COND trigger activated by SLmod... and since now noone fail.

 

But I'll report if something do not go as planned.

 

Ah! Thanks. I need to investigate it more fully anyway, but it sounds like my concerns may be unfounded then.

Intelligent discourse can only begin with the honest admission of your own fallibility.

Member of the Virtual Tactical Air Group: http://vtacticalairgroup.com/

Lua scripts and mods:

MIssion Scripting Tools (Mist): http://forums.eagle.ru/showthread.php?t=98616

Slmod version 7.0 for DCS: World: http://forums.eagle.ru/showthread.php?t=80979

Now includes remote server administration tools for kicking, banning, loading missions, etc.

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...