Speed

Now that we have the scripting engine, the thought of someone trying to do something like that through triggers just makes me want to: You could probably learn Lua from scratch and program this concept in 50 lines of Lua before you could figure out the trigger logic and implement all the hundreds or thousands of triggers and hundreds or thousands of zones it would take to make something like that work very well.

Horray! I can finally join MP missions with tankers now :)

No, it's called adherence to an NDA. I just hope the patch comes out before the quantum vacuum state settles to a lower energy level.

No

:D

Perfection? I'm glad to see you're not setting your expectations too high! :D

A server shut down time stamp is only possible for normal application termination. There is no way to tell if a CTD is coming and to print something to the log. Once the CTD hits, everything shuts off, it's like DCS takes a bullet to the head, so to speak, so how can I write anything to a log then? There would have to be a separate process running that monitors the DCS.exe process and writes to the log when DCS dies an unnatural death, and that is not worth the time it would take to program. However, like a said, time stamp on normal server termination is very easy.

All the features you mention, with the exception of the MOTD periodically being resent, are things I'm already planning or have already implemented. The autokick/autoban feature will be drastically improved, for example, and more customizable. I'm thinking getting rid of the "chat logs" concept and replacing it with the "server logs" concept. Basically, a server log would only log whatever you told it to log- be it chat, friendly fire hits, kills, whatever. I'll have to think more on it though. Temporary bans for a limited amount of time- "time-outs", will also be implemented. Also, the auto-kicking feature will be overhauled and made to integrate with SlmodStats. I will have to do something about mid-air collisions in regards to friendly fire kills- like not count them towards kicks/bans, maybe. People warp around on the ground, you don't want to ban people for warping into someone else, or for someone else warping into them. Which reminds me, I also need to group all enemy kills by using your aircraft as a weapon into a single "kamikaze" category. I also need to build a self-defense clause into SlmodStats- if you kill someone who has been team killing or team damaging, you will not face negative consequences. That kind of stuff. Oh and the pause when empty feature needs to unpause when a client joins a slot, not when they connect. I also need to implement server groups, shared stats, mission voting, mission rotation... it's a long list. ANYWAY, please keep up the suggestions, that's where I get a lot of my ideas. I wouldn't ask for suggestions if they didn't help me. It's just that the suggestions you suggested... well, I've already got stuff like that planned.

Grimes is now testing Slmod Stats on the 3 Squadron public dedicated server. After a day or two of testing there, if everything goes well, I'll start sending instructions on how to test it to the people who volunteered.

I've been keeping my fingers crossed on this one ever since I first heard about the Skylon a couple years ago. Seems almost too good to be true. I do wonder how can they cool the air so fast. I'm not an ME or CE so I don't know my thermo very well though.

Probably because the DCS integrity checker is not smart enough to tell the difference between legitimate mods and a cheat. There's no way to add a mod to an "exception" list or something like that- the only two options for a file or directory are all mods accepted or no mods at all.

Last night, I implemented the admin menu command to temporarily enable/disable stats keeping. Now, stats are effectively on "feature freeze" while I review the logic and try to catch any last-minute bugs. The beta version of SlmodStats (and Slmod version 7.0) should hopefully ship out to the first multiplayer servers who have volunteered to help test it tonight- if not tonight, then tomorrow. An earlier version has been running just fine for days now on one of the VTAG servers.

It actually sounds like both are working correctly. You cannot unpause the server when you are in the server alone if you have pause_when_empty enabled. This is because the server is empty! The server host must always be present in a multiplayer server and thus is not counted. If you have pause_when_empty enabled and you want to temporarily take back manual control of pause/unpausing, simply use the Admin menu commmand "-admin pause override". The events output implementation is currently a little non-intuitive- it just outputs the latest events. Read the description carefully: --Set to true to output the latest events to the file "slmod_events.txt" in \Saved Games\DCS\Logs events_output = false -- if the above variable was true, then this variable controls how often the latest events are output events_out_intv = 5 -- default: events_out_intv = 5, new set of events output every 5 seconds. That's right- only the events that have occurred within the last events_out_intv are output to the file. Why was it done this way? Well, when I started Slmod, I was a Lua noob and I thought that you had to execute all file writes in a single step unless you had the file open in append mode. DCS used to support file append mode, but this changed the same patch as the old, real-time debrief.log file writing was changed (1108). This contributed to my incorrect belief- it turns out the reason for the change in the events file was more arbitrary. However, it's not hard to modify Scripts/UI/debriefing.lua (or any other Lua file that is in or can access the main simulation Lua environment, where the debriefing module lives) to output events in real time to a file using an alternate events serialization method. Anyway, Slmod version 7 changes the events file to be output in a method that is more familiar- events are output to the file as the occur, and the file is only wiped clean on every new mission. I appreciate your ideas… they are similar to some of the ones I’ve had. However, there is only so much I should try to implement right now. If you want to try to help, try to think of ways to rank PvP players. SlmodStats keeps track of players by pvp kills- kills over losses. Also, it only counts kills if it thinks it was a “fair fight”- for example, a fighter killing a helo or attack plane does not count as a PvP kill, but a helo killing a fighter or attack plane does. So anyway, I’m trying to identify what kind of mathematical equations would make a good ranking system for these PvP kills. I want, for example, someone with 100 kills and 10 losses to be ranked above someone with 200 kills and 300 losses. I also do not want someone with 7 kills and 0 losses to be ranked above the person with 100 kills and 10 losses. It is a multipurpose server mod. It started out as what you say- a scripting framework- but it’s grown. This is because to get the scripting functions I wanted, I had to do/access things like: Output to screen text information as chat or trigger text. Get and analyze all world events. View all data in the mission file. Query just about any imaginable unit property, in real time. Get chat messages by players. Build a database of active units. Get all information about the unit that a multiplayer client is flying. Have a functioning, highly capable and flexible object-oriented “menu” system. And so on. With all that complete, I basically had the foundation to expand into new areas, and hopefully give these areas a better treatment than other mods have been capable of doing. No other mod has ever accessed and collected data from more than one Lua environment before; Slmod uses four Lua environments (down from five in Slmodv6_3 – in v7_0, I have withdrawn almost all code from the Export Lua environment- there’s just nothing useful there that I can’t get more easily from somewhere else).

The MOTD will be implemented for Slmod version 7.0. You can use the default MOTD, which provides the players with information on what Slmod menus they can access, or define your own MOTD in the config file. These are the rules I decided for displaying the MOTD, at least for now: When you join a slot, you are sent the MOTD. Additionally, the MOTD cannot be sent to you more often than once every 10 minutes- so you will not get spammed by the MOTD if you are rapidly switching through spots at the beginning of the mission, you will just get it once. If you fly for two hours, and then switch spots, you will be sent the MOTD again. If you leave the server and come back, you will be sent the MOTD. The MOTD can be recalled at any time by saying "-motd" in chat. By default, the MOTD is sent as trigger text, displayed for 20 seconds, but you can change that as well in the config file.

Yes, stats are saved continuously as a file. When the server starts, the stats file is compiled as Lua, and then serialized (converted back into a string), and written back to the file. However, I leave the file handle open, and changes to the stats are written into this file as they occur. This is a very fast process- DCS tells Windows to write to the file, and then goes on its merry way while Windows finds a time to position the hard drive correctly to do the file writing. So you never lose stats due to server crashes, and your server is never waiting for access to the hard drive.

No, altitudes are not dependent in pressure in the ME- your altitude is just the your aircraft's y coordinate (assuming you're in "Vec3" coordinates).

Maybe you should have pause_when_empty ENABLED. If it is enabled, then it should automatically unpause when someone joined the server, regardless of your setting in network.cfg. I will be looking at changing this feature slightly- a better implementation is to have the server unpause when someone joins a SLOT, instead of just connecting. I need to get around to making a multiplayer server set-up guide. I have been intending to do some for some time.

Without the mission, I can only guess that maybe you misnamed a unit or a zone.

Sorry, but this is all I can think about when the Star Wars Blue Ray edition is mentioned: Nnnooooo! Gimme the original VHS! Yea, last few times I saw him on TV, it was like he was on drugs or something.

I also saw that Mythbusters episode, I admit, I was a little surprised what it took to break the windows. But yea, an F-18 doesn't superheat the air around it to like 50,000 degrees or whatever, and then suddenly dissipate hundreds of kilotons of kinetic energy in less than a second.

I will implement a server MOTD (message of the day) system so servers running Slmod won't feel the need to make threads like this one: http://forums.eagle.ru/showthread.php?t=101450 Unless someone has a better idea, my plan is to send the MOTD to players when they join a slot as a trigger text message, not a chat message (though, CA players WILL receive it as a chat message, regardless). But I wonder when the MOTD should be sent? Every time they join a new slot, or just the first time in each mission that they join a slot? Should it be on some kind of periodic repeat as well? If so, players could be very annoyed at this trigger text popping up in their screen periodically. I suppose I should also let players recall the MOTD with "-motd". Do any of you guys have some suggestions? Edit- it is easy enough to allow servers to optionally send the MOTD as a chat message instead- I will provide that option, though I think it's better if it's trigger text.

Then I suppose you agree with this Onion news satire? http://www.theonion.com/articles/more-than-1000-russians-injured-in-freaking-cooles,31321/ So far, maybe it's OK to joke about it because no one was killed (even if that wasn't the case, the Onion wouldn't care though, I'm sure :D). However, I was worried that with so many windows broken, some people could die from exposure to the cold. Do you know if everyone warm enough? If not, it could be that this meteor DID in fact kill somebody, albeit, indirectly.

Actually coroutines do in fact block execution of DCS- coroutines are not parallel processing. What coroutines are is just a fancy way to split a long calculation into a series of discrete steps. So, if you get into an infinite loop in your coroutine, you will get DCS stuck in an infinite loop too (unless your infinite loop is escaped out of with coroutine.yield- in which case, you will just resume the infinite loop again with the next call of coroutine.resume). Anyway, splitting a long calculation into smaller bits is still useful- I use it in Mist and Slmod v7 to calculate the active units database in small enough steps that this calculation will not cause a microstutter even on fairly slow machines running really huge missions. If I do need to eventually make some serialization function for SlmodStats that will run real-time, while the mission is running, then the idea of doing it in a coroutine is a good one. However, like I said earlier in the thread, for now I found a way of writing stats that I like better- computationally, it's much more efficient than serializing, and no stats are ever lost due to CTDs.

The stats display system is largely complete. I need to do some tweaks to it still. Maybe I need to change the way "-stats show" works. I still need to implement some kind of "top 10" functionality or something. Unfortunately, there's not much I can do to make all the columns line up. Aligning text is pretty much impossible when different characters are different widths. The main menu, "-stats" "-stats me" "-full stats id 10" (page 1) "-full stats id 10" (page 2) There are is some kind of bug with DCS that makes the weapons hit tracking a little buggy for some kinds of weapons, so that's why some of the "hit" information doesn't make sense. It is more accurate for missiles.

Well, I can't really argue with that- who would have thought that the biggest known/confirmed meteor explosion in over 100 years would occur within hours of the closest recorded pass of hazardous asteroid in history? However though, you don't want to give any credence to wildly unlikely explanations if there is a far more likely, mundane explanation. Most people agree with this, but a lot of folks have a hard time telling the wildly unlikely explanations from the more likely ones... probably because the wildly unlikely explanations are a lot more fun to believe in.