Speed

Incorrect. Triggers are in fact Lua functions themselves. They are just wrapped into a GUI interface so that you don't know that you're actually doing Lua scripting. And you can have thousands of triggers and not have a noticeable impact on game performance.

This sells it for me, personally:

There would probably only be one trigger in a generated dynamic campaign mission: Mission Start-> <No conditions> -> DO SCRIPT Triggers are a nice GUI convenience designed to make mission logic comprehensible to human beings, but they would just get in the way of an AI campaign logic engine. It would be MUCH more work to adapt your mission logic to run within in the limited capabilities of triggers than to just leave it in an actual programming language. It wouldn't be that hard to run all this mission logic either, even if DCS were to still be primarily a single core when this came out. I'd think the primary obstacles are the amount of work required, assembling a team, and working on this project while the DCS code is in a state of constant flux.

I thought about more complex methods, but in the end, I just decided to solve it this way- last person to hit a unit before it dies, gets credit for the kill. 99% of the time, this will be correct, and even if in the rare cases it's not correct, it will average out over time. I solve this by keeping a record of the runtime ID of human-shot weapons in the main simulation environment. If a target is hit by a human-shot weapon, then I know which human shot the weapon :) I call this code up only when the initiator of the hit event is not identified. This method is not perfect however- there is a bug in DCS where the runtime IDs of weapons in hit events are incorrect for multiplayer clients; however it only affects, to my knowledge, guns and CBU submunitions. So if you like, drop a CBU-97, and get blown to tiny pieces sometime after the bomb is dropped but before the munitions attack the targets, you might not get credit for any hits or kills. Additionally, this bug forces me to assume, for multiplayer client hits where the weapon was guns or CBUs (and hence, the weapon is not identified), that the weapon that did the hitting was the last weapon fired by the client. This will be correct at least 95% of the time though. Disconnect problem solved by continuously monitoring the existence of all humans that have been hit by a weapon. If a hit human suddenly stops existing without a dead event preceding their non-existence, then a crash is put on their record, and if applicable, a kill is awarded to the human who hit that client last. Additionally, to make sure that the "dead" event is not just simply delayed somehow, for the next 10 seconds, deaths are not counted on that unitName. As the kill/loss records are kept on the server and are indexed by UCID, you can be awarded kills even if you are no longer on the server- so if you damaged someone or something, left, and then that someone or something died at a later time without being hit by something else, you are awarded the kill. All this logic has been tested and as far as I can tell, is working correctly. I just need to make the interface, and decide how much more in-detail I want the stats to be. In the current version, kills are just tracked by these categories: vehicle ship static helicopter plane (the PvP system is a separate thing). I am considering importing the unit attributes list from the main simulation Lua environment so that I can have more detailed categories, like: -------------------------- Ground Vehicles: SAMs AAA Radar Artillery/MLRS Armored Vehicles Unarmored Vehicles Other?? Planes: Fighter Aircraft Attack Aircraft Unarmed Aircraft Other?? Helicopters: Attack Helicopters Scout Helicopters Utility Helicopters Other?? Ships: Armed Ships Unarmed Ships Other?? Buildings: Static objects Map objects?? --------------------- If so, I haven't yet decided what exactly the categories will be, I would need to review the categories ED uses and make sure I have all-inclusive categories. I might be a good idea to just go ahead and decide to call it a "wrap" for now so that I can get the current code extensively tested on a few public servers. On the public servers, I imagine most people interested in stats will be more interested in the PvP stats anyway.

Negative. I have no intention of working on a swear filter, I'm contemplating a private messaging system. If I decided to make it could be used for anything- giving warnings, coordinating meetings with other players, sending a nine-line, etc. I would think that the biggest problem would be no one realizing it is there or thinking to use it. Sorta like the coordinate converter- I wonder if anyone has ever used it besides me. It's a useful tool, but no one knows about it.

Ahem... 00022.692 ERROR Lua::Config: load error Scripts/MissionScripting.lua:can't open 'Scripts/MissionScripting.lua'. Your MissionScripting.lua file did not exist. Did you install Slmod, uninstall Slmod, and then forget to restore the old MissionScripting.lua file?

Yes, but judging by the ridiculously over-sized Sun in DCS, that time isn't long from now... Look at the bright side though- at least we get the spectacular new Su-27 3D model in 1.2.3.

SlmodStats, at least, the first test-worthy version of it (which might not be the same version I finally settle on for the "official" Slmodv7_0 release), is nearly complete. I have thought of an interesting possibility: a server-only, private messaging system. It would tie-in with SlmodStats, which keeps a database of player names and UCIDs. For example, a player types "-pm id 87 <message>", and the text of <message> will be stored for the recipient with SlmodStats ID# 87. When this player logs in to the server, he will get a notification that he has a "New Private Message", which he can view with "-pm show new" (which will show the latest unread private message). I haven't really fleshed out the details yet, but I think it could be very useful for things like server warnings- RECEIVED CHAT MESSAGE: "You have 1 new private message(s), Speed. To view it/them, say '-pm show new' in chat." REPLY: "-pm show new" RECEIVED TRIGGER TEXT: "PM 4 of 4, from: "Goose" (server admin): speed you now have 2 warnings for using foul language on our server. one more and you are banned. please watch your mouth, we have a no swearing policy. Thx, Goose" What do you guys think? It's very doable, and not terribly difficult. The object oriented SlmodMenu class I created last spring is really paying off :)

If it happens again, before you fix it, please upload dcs.log, and make note of the latest things you did.

No idea, I had no idea such a bug existed. I can hardly stand flying the A-10 anymore... it's just too easy and slow- by far the most effective tactic for the majority of missions is to just sit up, invincible, at 25k feet and plink tanks and SAMs all day. Yawn. You do remind me though, I need to check up and find out whatever happened to that bug with the Ka-50 (an aircraft that is actually fun to fly and fight in :P) HUD not getting repaired.

Some of you guys might have seen this already, but if not... (Make sure to click on it to expand the image and make the text more readable :))

And a six pack to go :music_whistling:

Odd. Thanks for the report. Which is it though, does it not log team hits for you, or does it not generate a chat log? For future reference, you might want to use the Slmod thread to report things like this- it's a common place that I will look at at least once every few days. A report some place like here, I might miss. It might be that you have a Lua error in your config file. If so, Slmod will ignore your config file and revert to default settings. It will generate a message in dcs.log if this is the case. If you're using an admin registration password, don't forget that it must be in quotes, like in the example I provide. To try to figure out what is going on, first off do some team-hitting, say some chat message(s), then upload the server's dcs.log file- that's Saved Games/DCS/Logs/dcs.log. I would possibly also need the server's config.lua file, and the chat log itself, if you get one.

Yup, it's not uncommon to spend hours on a single bug. Lots of "fun".

Yea, I agree, good job. I must admit, I was very afraid that this guy would go off on some Mayan conspiracy theory clairvoyance whatever stuff, but he kept it very much on the level. It was some great press for DCS! The commercials were funny though... each time a new one came on, I was half expecting it to be for .

Helicopters don't have radars, except for a small number of exceptions, and those are not modelled in DCS. The first thing that pops to mind for NH is Nike Hercules, but those are also not modelled in DCS. Maybe it was a ship of some kind, those sometimes have "odd" RWR symbols.

In the default scoring, a loss is supposed to be counted when the aircraft is destroyed. In the stats system I am working on, a loss is counted when the aircraft is destroyed, or the aircraft is damaged and the client flying it leaves the server or switches aircraft (or anything where their aircraft stops existing) without landing and coming to a stop.

If it's true that ED is working on these aircraft (I haven't heard the radio interview yet), what's wrong with F-15, F-18, and Su-27? That's a great combo. What were you hoping for, an F-22? :huh:

Slmod stats tracks you by UCID, and I'm pretty sure any other stats systems would/do, so there is no anonymity unless you manage to change your UCID. There was a bug that made UCIDs change, but c0ff said he fixed it, and that UCIDs should be permanently associated with your DCS account now. So to change your UCID and fly anything other than the Su-25T, you'd have to make a new DCS account and re-purchase modules. Right?

do local unitNames = mist.makeUnitTable({'[g]M1s_1', '[g]M1s_2', '[g]M1s_3', '[g]M2s_1', '[g]M2s_2'}) local totNum = #unitNames local numDead = 0 for i = 1, totNum do local unit = Unit.getByName(unitNames[i]) if not unit then numDead = numDead + 1 end end local fracDead = numDead/totNum local fracAlive = (totNum - numDead)/totNum --<Now do whatever...> end

Judging by the website of the radio host, Matt better have his tinfoil hat ready :D

It's already decided that a simple function to order a ground unit to a point will be included in the next version. Retreat will probably be in there... but retreat might have a certain difficulty I need the check about some time.

Sounds like a good idea, but this is a logical nightmare. It's not an insurmountable problem, it's just a lot of work, a lot more work than the one might initially suppose. Examine, for example, the brute-force method: Say you want to detect incoming enemy fire on a group of units we can refer to as "Group A". - Each time the enemy fires ANY weapon, that weapon goes into a Lua table of fired weapons. - At least 10 times a second, every weapon is checked if: a) the weapon is still "alive" and if so, b) that weapon is within a certain radius of EACH unit in "Group A". c) if the weapon is no longer alive, remove it from the list of checked weapons If a) and b) are true, and we are not logically suppressed from creating a message (you would want to avoid sending up to hundreds of messages every second, so you would need some suppression logic to limit the rate at which the players receive messages) then we get that weapon's velocity, and convert the velocity direction into a compass direction, and then continue on with making an incoming fire message, However, consider the possibility that 500 enemy bullets are in the air at the same time, which is not a rare event, really, and you have 20 units in "Group A". Now, you are doing 500*20*10 = 100000 checks a second. Each check involves getting a unit by a name, then that unit's position, getting a weapon's position, and doing some calculations. This is clearly not ideal, and might lead to a big reduction in frame rate- especially if you had like, 200 units in "Group A" (in that case, "Group A" would probably dozens of groups) and thus you were doing 1,000,000 checks a second. It is possible to optimize this script though. One optimization might be to ignore weapon launches that were further than a certain distance away from your group. A better way would be to scale the rate at which the weapon positions are checked based on how close they are to your group. This starts to get very, very complicated logically. Of course, I mention the group itself. Another optimization might be to get the average position of the units in "Group A" and use that instead of the position of each individual unit- but what if the units are spread out? Do you revert to individual units, or can you analyze the positions of units and break them into clumps? So it gets even MORE complicated now. Oh yea, since cluster munitions are not generated with a shot event, you can't see them. Cluster munitions will not work with this. So, like I said, while the brute force method isn't too terribly complicated, once you add the necessary optimizations, this code gets very complicated, very fast. I did a number of optimizations with the Slmod weapons_impacting_in_zones functions, and got it to run pretty well.. but some of those optimizations are not applicable here. Anyway with the amount of time this takes, other, simpler things are going to take priority first.

That's kinda like saying, while staring at the empty lot you just bought, "Yea, so my new house is basically already done!"

Looks like lots many of these "killed by building" issues comes from situations such as an aircraft/unit gets hit by a weapon that was fired from a unit that no longer exists at the time of weapon impact. This is fixable if each time a weapon is fired, that weapon's unique identifying number, its runtime ID, is stored in a table along with information on the unit that fired the weapon. Later, if that weapon hits anything, and the original firing unit is dead or otherwise non-existent at the time of weapon impact, we just look up who fired that weapon from the data that was stored about the shooter at weapon launch time.