Speed

1) No. I've made these observations: a) The overwhelming majority of players are either unaware of Slmod or unaware of the chat commands to use Slmod; b) The majority of players do not even know how to send a chat message in the first place; c) The majority of players do not read the briefing; d) Even those people who were told the chat commands usually forget them- you use something only a handful of times, you're not going to remember it two weeks later! If the Slmod information is removed, then how are players supposed to know how to how to use the stats system, coordinate converter, the admin menu, etc? You can't tell them in the briefing, because they won't read it. The number of commands will increase in future Slmod versions too, so remembering the commands will become even harder as time goes on. Also consider: The MOTD is only delivered to you when you select a new slot (on a 10 sec cooldown). You will only see the MOTD once per mission unless you need to get a new aircraft and you didn't crash your old aircraft, or you want to change slots. Even then, the MOTD is nominally six lines of chat delivered over 30 seconds that is only sent to you. Considering these things, I think it is important for the Slmod info to be delivered in the MOTD. What I would still like to do, however, is try to reduce the number of lines it takes. I can probably get it down to four, maybe three (but probably not). It was eight lines (and delivered less information) in one of my beta tests... you see, I already attacked the problem of reducing the length once. At only four lines, I could make them delivered much faster, over 20 seconds. 2) No- that's the kind of thing coming in Slmod version 7.1. If you want to try installing Servman, first try to get Servman working (it may be completely incompatible now for all I know though, but I'm sure you could tweak it and make it work eventually), then follow the directions I included in the first post for installing Slmod into another Scripts/net/server.lua mod. Anyway, Slmod verison 7.1 should make Servman pretty much superfluous. 3) Unfortunately, that's not possible. We only have two options- chat and trigger text. With a very complex system of time stamps, a_out_text_delay_g/trigger.action.outTextForGroup, and individualized message construction, we might get a better trigger text message system, but we run into the problem of Combined Arms players, to whom we cannot send an individual trigger text message as yet. What I could do is allow the output mode of the stats system to be switched to chat as a server option, however, the detailed stats pages are formatted for the trigger text box. Alternatively, I could allow the stats menu to be entirely disabled by the server (but still allow the stats system to run invisibly to allow for data exporting of stats and autokick/autoban), but I'm not sure why you would want to disable the stats menu. Further edit: I don't mean it to sound like I am putting down the majority of the player base in my reply to 1). For one, after a two month absence, I had trouble remembering some of the Slmod commands, and I programmed them myself! Secondly, as the keystroke for send chat is different depending on what module you are playing (obviously, not a good situation), it's understandable and expected that people don't know how to send a chat message. Before I implemented the "The default keystroke in your module is <>" line to the MOTD, I had to usually hunt myself for the proper keystroke (now I know that it's always either tilde, Tab, or RCNTL-M). Third, I try to avoid reading the briefing myself unless it's absolutely necessary. So if I'm dissing anyone, I'm also dissing myself.

It's good to hear that Interceptor is back! The first suggestion is the kind of stuff I'm considering for 7.1. The second suggestion is already implemented in 7.0- the MotD is editable. See the custom_MOTD option. I know it says that just the first line is editable of the MOTD, but that is just a simplification. If you just use the newline character, you can have multiple lines. custom_MOTD = "Welcome to STP II! We like to make long MOTD messages that need multiple lines.\nPlease come visit our Teamspeak at <TS3 ip> port <TS3 port>, password: <password>\nOur forum URL is at <url>." :P But if you really do need multiple lines (quite likely if you're trying to put both a forum URL and TS3 info, or if you want to state a set of server rules), look at that example. See the "\n" characters?- those start a new line.

The most important thing is to understand tables. They are Lua's only data structure, so once you have an understanding of tables, you have an understanding of a huge portion of Lua.

newpoint has components of x, y z- it looks like this: newpoint = { ["x"] = number, ["y"] = number, ["z"] = number, } So when you type newpoint.1000 there are two things wrong with that. First, you are asking for the value of newpoint at the index that is a string equal to "1000". That's not the number one thousand- that's the one character followed by three zero characters. Huge difference. If you want to get the value of a table at an actual number index you must use this notation: newpoint[1000] The table.<index> method is a shortcut that only works for string indexes. Anyway, so the other thing wrong with it is that newpoint.1000 is undefined- nil. The only defined parts of your table are newpoint["x"], newpoint["y"], and newpoint["z"]. (As those are string indexes, we can get those values by using the newpoint.x, newpoint.y, and newpoint.z). Anyway, there is a third thing wrong too. land.getHeight uses a 2D vector, not a 3D vector. So Vec3.x gets mapped to Vec2.x, and Vec3.z gets mapped to Vec2.y, and Vec3.y gets thrown away. There is a mist function that does this for you, but in the code below, I do it manually so you can see what is happening. Also, functions are called with parenthesis ( ), not { }. The { } characters are for defining a table. (There IS a Lua shortcut that allows you to skip using the ( ) in a function call in some situations, but don't worry about that right now.) Finally, I'm not sure where do script is run- environmentally, I mean. It might be running in a closure, or it might be running directly in the global environment. If the latter, you should enclose your function in a do - end statement to make your own closure and make your local variable declarations truly local. Anyway, try this. do local pos = trigger.misc.getZone('Zone1') local newpoint = mist.getRandPointInCircle(pos.point, pos.radius) local vec3 = { x = newpoint.x, y = land.getHeight({x = newpoint.x, y = newpoint.z}), z = newpoint.z } trigger.action.explosion(vec3, 2000) end

Yup thanks for pointing that one out! I think I wrote that code without thinking about it too much, and then never tested it :blush: (it is, after all, a function you will rarely, if ever, need). Anyway, there is no problem with removing entries from the table you are iterating through. The problem with this code is but the fact that the numeric for only evaluates the conditions ONCE. So you should get an attempt to index nil value error with the way this function is written. I had other code that I've used quite a bit that's very similar, but it uses a while loop and a variable that is incremented or not (depending on whether or not the table had an entry that was removed), and maybe I just logically copied it and changed it to a for without thinking about it. Anyway, that implementation would look like this: mist.removeFunction = function(id) local i = 1 while i <= #Tasks do if Tasks[i].id == id then table.remove(Tasks, i) else i = i + 1 end end end That code would work just fine, and could even handle the case of there being multiple matching entries in the table that need to be removed. The major difference to understand is that the while loop evaluates the condition every time the loop loops, while the for loop just does the evaluation once. ----------------------------------------------------------------------------------- Anyway, internally mist.removeFunction is used for nothing and all it would cause would be that when you tried to use it, the script that tried to run it would not work, raising an attempt to index nil value error. So if you were not using it, that was not the reason you had a problem. NOW LISTEN CAREFULLY: There was a bug a few versions of DCS ago where timer.scheduleFunction (upon which mist.scheduleFunction is dependent) would just stop working when the host's aircraft crashed (odd, huh?!?!). Other things likely triggered the bug too, but I never found them. It is possible this bug came back or was never really fixed in the first place. Maybe this bug was only fixed for the case of the host's aircraft crashing, and you found a new, different way to trigger it. I SURE hope not, a bug like that is absolutely devastating to Lua scripting in DCS! timer.scheduleFunction must NEVER fail, it's one of the foundations on which the whole stack of cards is built! Anyway, if you were NOT using mist.removeFunction, then please let me know! It is possible you stumbled across a major problem with the scripting engine!

Thanks. I wouldn't do it if I didn't get enjoyment out of it. As mission builders, modders, etc. know, there is great satisfaction to be had in building something. Anyway, something hilarious is that I pasted all my Slmod files into a single file recently. 15600 lines... at the default size that I view text (a little over one line per 4mm), I would need a monitor 70 meters (230 feet) tall to display all of Slmod at once LOL Don't worry though, over the course of a few seconds, only a small fraction of that code will have actually run on your server. Added complexity does not mean added computation time, in fact, added complexity can even REDUCE computation time. Anyway, I don't have much more to add before I will be satisfied with the features of Slmod and be ready to move to something else. Basically... I think I can see the end in sight (as far as added features goes- obviously, I will still need to support the code and keep it working in the latest versions of DCS).

Slmod version 7.0 has been finished. Or, at least, I can't find any more bugs, everything appears to work, and I've finished the docmentation :) I'm making a topic here because I let the Slmod thread (which is now mis-titled- mission scripting is now just a small portion of what Slmod does!) turn into a sort of Slmod blog. The problem is, anything I announce there will likely be largely ignored- my fault- people are used to seeing inconsequential updates there :D ANYWAY, you can download Slmod Version 7.0 by visiting the main Slmod post here: http://forums.eagle.ru/showthread.php?t=80979 The big improvements over Slmodv6_3 is the addition of SlmodStats, a greatly enhanced autokick/autoban system, and enhancements to the Admin Menu (kick by id, ban by id), a server MOTD system, a help menu, refactored and more efficient code, and probably a lot more stuff I'm forgetting. Oh yea! Slmod now installs into Saved Games/DCS, and does not get removed by the autoupdater :) Here's a link to the Slmod Version 7.0 manual: http://forums.eagle.ru/attachment.php?attachmentid=82648&d=1369789738 And here's a change log from Slmod version 6.3 to Slmod version 7.0 that covers *most* of the changes, I think (there were so many it's hard to keep track): http://forums.eagle.ru/showpost.php?p=1768536&postcount=589 SlmodStats Anyway, here's the opening section about SlmodStats from Slmod manual: Anyway, I do plan to expand SlmodStats to allow multiple servers to share stats. I've got a number of ideas on how this could be done, and will be investigating them when I start getting time to work on Slmod v7.1 or v7.2 SlmodAutoAdmin, new autokick/autoban system Here's the opening section about SlmodAutoAdmin, the new autokick/autoban system, taken from the Slmod manual: Anyway, those are the two biggest things, but there have been numerous other improvements. Please see the Slmod manual and the Slmod thread for full lists of features and changes. So finally, I can get back to Mist and ED testing. However, a low level of work will begin soon on the next version of Slmod. The number one priority feature for the next version of Slmod is mission rotation and mission voting. Note: Slmod Version 7.0 will not be compatible with Interceptor's InSeMa mod of Slmod version 6.3. Unfortunately, Interceptor has gone MIA (he was actually going to help me and co-develop Slmod Version 7.0 with me). Hopefully he returns ASAP!

Slmod Version 7.0 is as ready as it's gonna get. The change log, from Slmod Version 6.3 to Slmod Verison 7.0, is basically this post: http://forums.eagle.ru/showpost.php?p=1768536&postcount=589 Anyway, attached is Slmod 7.0. and the Slmod 7.0 manual, which I actually completed this time! Be advised, install directions have changed, see the Install Instructions.txt file, or wait for me to update the first post in this thread. Anyway, I got a couple long posts to make now before I'm finally DONE! When that is finally out of the way... I can't wait to try out this DCS game I hear people talking about, I think I used play it a long time ago, but that was so long ago I am not sure anymore. Slmodv7_0_060.zip Slmod v7_0 Manual rev0.pdf

That's just freaking awesome. I bet this could be modified for pilot SAR very easily, too. A long time back, I wanted to make a script to automatically dispatch an AI SAR helo, but I never got around to it. Your concept is much better though, as it really gives the UH-1 pilots something cool and useful to do. It's far better than the cumbersome ideas that I had (though it helps a lot having an actual human pilot to do it...) Maybe in the next version of Slmod, I could add the ability to add a custom stat to SlmodStats via Slmod mission scripting. So maybe, if you're interested, a future verison of your script could call the Slmod function (if it exists) to add a stat to player- in particular- number of injured persons saved. So we could have the people you saved added to your logbook, in a very real sense! Oh and what if your script was modified further- the patients you pick up, maybe they could have randomized injuries. Some would be only lightly injured, while others could be critically injured so badly that if you don't get them back to the MASH really fast, they die! You could have the on-board "Medic" outTextToGroup stuff like, how badly is the guy injured, and whether or not you have time to pick someone else up or you need to book it back to base. Of course, you need to have patients randomly die and there be nothing you can do about it. Frequently. And the injury timers need to start when the person is hurt, not when you pick them up. Anyway, I see huge potential in this concept... basically- DCS: MASH!!!! This idea has me greatly excited!

Slmod version 7.0 is completed, or at least, all the desired features are in. The latest changes need to be tested, first by me, and then by a few public servers. Meanwhile, I need to complete the Slmod v 7.0 manual. This will take a few days. Major changes over Slmod v6.3: Efficiency changes: - Data/command passing code (from MissionScripting to net) overhauled and refactored; now uses LuaSocket. - Active units database code overhauled and refactored - Numerous other efficiency tweaks - Added SlmodStats multiplayer stats tracking system Major features: - Added Slmod "-help" menu - Added server Message of the Day (MOTD) system Features: - Advanced Autokick/Autoban system Features: - Slmod now installs into Saved Games/DCS/ - Added option to the Admin Menu to enable/disable stats recording - Added kick-by-id and ban-by-id options/submenus to the Admin menu. - Countless other tweaks Hopefully everything will be completed, tested, written, and ready to go sometime this weekend, but no guarantees... Anyway, sorry if you were hoping for mission voting or mission rotation, those aren't coming until Slmod v7.1, and ED testing and Mist will keep me from working on Slmod v7.1 for quite a bit of time.

Only if the mod modifies the files that are integrity checked. There are very few files that are integrity checked- by default, Config/Weapons and Scripts/compile.lua. No mods that I am aware of modify these files. Now, as server host, you can expand your integrity check to cover other files, and some server hosts do that- especially server hosts that run player-vs-player missions. Still, most mods are OK even with expanded integrity checks.

Are any of the servers running an kick-on-high-ping script? I seem to remember Interceptor creating such a feature. I always get a pretty high ping to the STP servers. Where is he anyways? Dragon, you need to drag him back here :)

There's no easy such thing as an easy DCS-level module, unless maybe it was DCS Wright Flyer. You must model almost every single system to exacting detail; even a Su-25A is a very complex beast to code.

No, that data is not available to the mission scripting environment.

mcfly, Those are normal warning messages in Slmod v6.3. Did you enable the option in the Saved Games/DCS/Slmod/config.lua file? You have to set export_world_objs = true to make it export world objects. ------------------------------------ The autokick/autoban features is tested and nearly complete, at least for 7.0. Thanks Greywo1f and Grimes! I was debating, in future versions, having a "forgive" option after you are teamkilled. Bascially, you can chose to forgive someone for their teamkill on you. I was worried though- could this sow drama? Basically, a vote NOT to forgive someone is potentially a vote to have them permabanned from the server. It's like saying, "I hope you get banned from the server". This wouldn't be a problem in a community as disparate and childish as a CoD-like game, but the DCS community is a lot smaller and more tightly-knit. I'm a little worried that a forgive option could cause people to become angry and no longer be friends with each other- basically, "OMG WHY DID YOU NOT FORGIVE ME?!?! IT WAS AN ACCIDENT!!! YOU WANT ME TO BE BANNED FROM THIS SERVER?!?!!" Obviously, the forgive menu would be optional and there would be a server setting to enable/disable it. What do you guys think?

Must have missed the part where it warned me not to go near southern Georgia due to the nascent, Earth-consuming black hole in the process of destroying that region.

Can anyone find a screenshot of the monolith that used to appear over the water? I tried, but the best I could find was an image of this neutron star I got sucked into. As you can see, the tidal forces are about to rip my A-10 apart.

On one of the public servers that are helping to test Slmod v7 (Eno's Firehouse), I've seen cases of players engaging in consensual team killing. While it might seem all good and fun right now, the not-very-distant day that the autokick/autoban feature is implemented, these players might find themselves already banned for team killing/hitting. It's not a good idea to do team killing... especially on a server that tells you right up front in the MOTD that it's tracking your stats. A few days ago, Grimes went through and manually banned about 5 or 6 guys for team killing from the 3Sqn dedicated server... many of the incidents had happened months ago.

I released slmod build 057 to some public servers a few days ago. So far, so good. I had to release build 057 because build 056 had a bug, introduced with 1.2.4, where kills against aircraft were counting twice in many cases. The problem stemmed back to a change in the way Object.isExist works- in 1.2.4, when pilots eject or are killed, Object.isExist used on their aircraft returns false. This doesn't make much sense, and this function has never worked like that before. Anyway, I added (optional) server chat announcements for team hits, team kills, and PvP kills. Note that the PvP kills announcements follows the rules laid out for scoring SlmodStats PvP kills as detailed previously in this thread, and will be generated even when the normal kill announcements fail to work properly (such as when a fatally-damaged player rage-quits the server rather than waiting for his aircraft to crash). Additionally, I recently discovered that c0ff added Scripts/net/server.lua to the list of files that DCS checks for in /Saved Games/DCS. So yesterday, I set it up so that Slmod will install into Saved Games/DCS/. Slmod still requires modifications to ./Scripts/MissionScripting.lua to run, but these modifications are now installed automatically via an auto-installer script when you start DCS. The take-away point is this: Slmod is now really easy to install and is not uninstalled when you do an auto-update. I have completed the (initial) design for the advanced autokick/autoban system. It will be fully configurable, and will operate through SlmodStats. Here's the settings/design, at least as it stands right now: -- autoAdmin design/config settings autoAdmin = {} autoAdmin.autoBanEnabled = true autoAdmin.autoBanLevel = 100 -- a player is temp-banned when he reaches this level autoAdmin.autoKickEnabled = true autoAdmin.autoKickLevel = 50 -- kick player when he reaches this level autoAdmin.autoKickOnEveryAdditionalOffense = true -- if player is above the autoKickLevel, autoKick on every additional offense. ----------------------------------------------------------- autoAdmin.teamHit = {} autoAdmin.teamHit.enabled = true autoAdmin.teamHit.penaltyPointsAI = 8 -- penalty points for team-hitting an AI. autoAdmin.teamHit.penaltyPointsHuman = 12 -- penalty points for team-hitting a human. autoAdmin.teamHit.decayCurve = { [1] = {day = 0, weight = 1}, [2] = {day = 3, weight = 1}, [3] = {day = 90, weight = 0.25}, [4] = {day = 180, weight = 0}, } autoAdmin.teamHit.minPeriodAI = 30 -- the minimum period between team hits on AI that are counted towards autokick/ban. autoAdmin.teamHit.minPeriodHuman = 5 -- the minimum period between team hits on humans that are counted towards autokick/ban. ----------------------------------------------------------- ----------------------------------------------------------- autoAdmin.teamKill = {} autoAdmin.teamKill.enabled = true autoAdmin.teamKill.penaltyPointsAI = 12 -- penalty points for team-killing an AI. autoAdmin.teamHitKill.penaltyPointsHuman = 23 -- penalty points for team-killing a human. autoAdmin.teamHitSettings.decayCurve = { [1] = {day = 0, weight = 1}, [2] = {day = 3, weight = 1}, [3] = {day = 90, weight = 0.25}, [4] = {day = 180, weight = 0}, } autoAdmin.teamKill.minPeriodAI = 20 -- the minimum period between team kills on AI that are counted towards autokick/ban. autoAdmin.teamKill.minPeriodHuman = 0 -- the minimum period between team kills on humans that are counted towards autokick/ban. ----------------------------------------------------------- ----------------------------------------------------------- autoAdmin.friendlyCollisionHit = {} autoAdmin.friendlyCollisionHit.enabled = true autoAdmin.friendlyCollisionHit.penaltyPointsAI = 1 -- penalty points for colliding with AI autoAdmin.friendlyCollisionHit.penaltyPointsHuman = 5 -- penalty points for team-hitting a human. autoAdmin.teamHitSettings.decayCurve = { [1] = {day = 0, weight = 1}, [2] = {day = 1, weight = 1}, [3] = {day = 30, weight = 0}, } autoAdmin.friendlyCollisionHit.minPeriodAI = 10 -- the minimum period between friendly collision hits on AI that are counted towards autokick/ban. autoAdmin.friendlyCollisionHit.minPeriodHuman = 10 -- the minimum period between friendly collision hits humans that are counted towards autokick/ban. ----------------------------------------------------------- ----------------------------------------------------------- autoAdmin.friendlyCollisionKill = {} autoAdmin.friendlyCollisionKill.enabled = true autoAdmin.friendlyCollisionKill.penaltyPointsAI = 10 -- penalty points for colliding with AI autoAdmin.friendlyCollisionKill.penaltyPointsHuman = 15 -- penalty points for team-hitting a human. autoAdmin.teamHitSettings.decayCurve = { [1] = {day = 0, weight = 1}, [2] = {day = 1, weight = 1}, [3] = {day = 30, weight = 0}, } autoAdmin.friendlyCollisionKill.minPeriodAI = 0 -- the minimum period between friendly collision kills on AI that are counted towards autokick/ban. autoAdmin.friendlyCollisionKill.minPeriodHuman = 0 -- the minimum period between friendly collision kills humans that are counted towards autokick/ban. ----------------------------------------------------------- Basically, the way it works is you earn penalty points for committing offenses. Earn enough penalty points and you will get kicked or even temp-banned. The penalty points will decay over time (or not- depends on the config settings), allowing a player who was temp-banned to eventually rejoin the server after his points have decayed enough. The settings will be changeable through the config file. The settings may be complex, but I plan to have fairly reasonable default settings. The new AutoAdmin autokick/autoban system will be vastly smarter than the crude autokick/autoban system included with Slmodv6.3 and the autokick/autoban system included with Servman. Anyway, I'm thinking of some way to modify this design further to allow an auto perma-ban too. This might consist of a "reallow level"- basically, the number of points that a banned player's penalty score needs to decay to in order to be re-allowed into the server. If that number was set to 0, then they would never be allowed to re-enter the server.

If that 330 Mm^2 area is for all areas with terrain height variation, it is important to remember that not all of that area is populated with objects. There are some REALLY cool areas down in Turkey that are, unfortunately, not populated with objects. The best use for these areas that I've found is to play at night, and pretend it's desert terrain on some Middle Eastern theater.

Hmm...., it wouldn't be that hard to slip a Lua script into a mission in a relatively hidden place... make a UFO appear on a low probability... it would be fun to screw with peoples' minds :D Though probably, it would be funnier to just spawn like a sports stadium in the middle of the runway right as a player is making their takeoff roll, and right before they are about to crash into it, have it go shooting off in some direction at like 1000 knots and explode :D It's too bad that Saint fixed the "blue" flares that instead shot out a geyser of dead bodies, those were fun to play with. Can you imagine how someone would react if they were flying around and just randomly, the view out their front windscreen was filled with a swarm of dead bodies flying through the air?

Where does 138 knots come from? Anyway, air density will have a measurable effect on ball fall velocity. Even before an object hits terminal velocity, drag counteracts some of the gravitational force accelerating the object, making the object accelerate at less than 9.8 m/s^2. At terminal velocity, the force of drag is equal to the force of gravity, and the object accelerates no more. Needless to say, the force of drag is dependent on air density.

Maybe not a high school student, but at the least, but I imagine that someone with some kind of FEA aerodynamics computer program to predict drag coefficients should be able to easily and accurately predict the drag coefficient for something like a Mk-84. We know exactly what the dimensions and shapes are on these bombs, and we know how much they weigh- so we know their ballistic properties. Missiles are a little harder to predict the ballistic properties for, since I believe that the amount of solid rocket propellant inside them is usually classified, but if we make educated guesses, then we should be able to predict their ballistic properties too.

The zones are indexed by name in mist.DBs.zonesByName. They are indexed by an arbitrary number value in mist.DBs.zonesByNum. For example, mist.DBs.zonesByName['RescueZone'] will be the zone you called "RescueZone".

There's a big problem with that code- your unitId could be a duplicate of a current unit, or the two unitIds could be the same. You do not want to use math.random to generate the unitId, the unitId needs to be generated based off of units currently alive in the game world, and needs to be a unique value that no other unit has. Also, the name needs to be unique too, and it is randomized here also. It may be you do not need to even specify a unitId, that the game will assign one automatically, but I would need to check on that.