Speed

Designing your entire air force to be able to dominate an enemy equipped with SA-11s and Su-27s is incredibly wasteful when the majority of conflicts an air force fights in pits its aircraft against enemies equipped with AK-47s or, at best, Zu-23s and a rare MANPAD. Even in conflicts where the enemy initially has sophisticated equipment, that equipment eventually gets destroyed. We just need cheap, effective CAS aircraft.

You can't activate static objects.

Great research. I tried to make my Ka-50 shoot an AMRAAM, but was obviously met with failure. The thing is, an active radar AAM will pitbull right off the rail, so it would actually work. It's just horribly unrealistic. What is not answered in this post is whether or not you can actually make the Igla guide on anything. Anyone know?

Work on stats system is proceeding at a good clip. The basic file and stats compilation/updating/persistence system was completed over the weekend. The stats system now keeps persistent records for all clients of flight time in each aircraft/platform (including CA), weapons fired, and weapons hit. Next, I have to tackle a challenging component: the rules for kill and death scoring. This part will take some time, it is about 100X harder than it sounds. The plan is that once SlmodStats is complete or mostly complete, we can start beta testing Slmodv7 on various servers, even some public servers. Beta tests will require that you run Slmodv7 on your server, and report any irregularities/problems to me, and upload dcs.log and Slmod.log files after long hosting sessions. If you'd like to beta test Slmodv7 and the included SlmodStats system on your server, let me know. I expect to be ready for these tests sometime in the next 2-4 weeks.

The plan is to make SlmodStats, which will probably be completed in 2-4 weeks, record a disconnect or change of aircraft, while damaged, as a kill for whoever damaged that aircraft even if they are no longer on the server. This discussion leads me to think I need more than this, though. Unlike a purely events-based stats system, Slmod can access the actual game objects. The idea is that I could make a disconnect or change of aircraft while an air-to-air or surface-to-air missile is pointed in your direction and closing on you, count as a kill to whoever fired the missile, and a death to you. There are some caveats: - Should it count as a "death" on your record, or should I make it a separate category- "desertion under fire" or something like that? - I probably should not make it count if it would have been friendly fire. You can easily guide a missile past friendly aircraft in front of you (though.... it's not exactly a safe thing to do, not if it's an AMRAAM or R-77). I don't want to incorrectly blame people for friendly kills, and people trying to escape a team-killer by changing aircraft or disconnecting should not be punished. So, only make this work for opposing aircraft. - This will add a significant amount of additional code work. It's very possible to implement, it's just gonna add an extra layer of complexity- probably about 2-4 hours of programming and testing. How bad is this problem, really? I suppose if people are competing for top dog in stats on a server, the temptation to cheat could be bad enough for this problem to intensify. Maybe this feature is mandatory. Then, of course, there's the question of whether it should count as a death for you and a kill for an opposing player if you disconnect while an enemy aircraft is very close to you. Without this protection, you could cheat the system when you were getting your butt kicked in a BVR or guns fight by disconnecting before anything hit you. But nothing is as simple as it sounds on the surface. You'd have to close the loopholes that would otherwise allow people to farm kills by just like, flying a Ka-50 to an enemy airbase, parking it in a hidden spot, and waiting for people to land and disconnect.

Yes, that's where you say the day number for a waypoint, but to set the day number for the start time of the mission, you need to click on the button (forgot it's name- it's the one that takes you to the screen where you can enter the mission briefing text, IIRC).

What's going on is that the "fall/spring/summer/winter" setting in the ME just sets the terrain tile coloration and probably a few other cosmetic things. Sunrise/sunset, the moon phases, and the stars are determined by the start time of the mission. The stars, sun and moon are fairly accurate to real life, however, there are no planets. Day 1 (or does the ME start at day 0? I don't remember) is currently June 1, 2011. So really, what you need to do is use spring tiles for days 1-20 and days 294-365, summer tiles for days 21-112, fall tiles for days 113-225, and winter tiles for days 226-293. And, yes, you can go past day 365, so just repeat this pattern for missions starting past day 365.

Agreed, but MadTommy never cited a source for his data, so we can't verify if the times he has are accurate or not. From the way he states it, I kinda get the feeling he generated the sunrise/sunset times and lunar cycle data via some math equation or website. Maybe we should send him a PM and find out if he doesn't see this post soon enough.

A .miz file is just a .zip file, named .miz. So unzip the mission and see for yourself what the structure is. The "mission" file is the most important component; it is a serialized Lua table. There may also be other serialized Lua tables (like warehouses) included with the mission. There's no documentation, but it's really rather straightforward if you just look at all the components of a .miz file after you unzip it. If you need a Lua interface in Java, this may help: http://www.keplerproject.org/luajava/index.html

I wonder how Madtommy got that data? Personally, I've always used this for Sun and Moon data: http://aa.usno.navy.mil/data/docs/RS_OneDay.php Plugging in values for Tbilisi on September 1, 2011, (GMT +4, 41 45'N 44 45'E) I get significantly different data than what Madtommy posted: The real-life moon position is nearly a week earlier than the moon data Madtommy posted. I think it's fair to say that the USNO data quoted above is correct to real life. However, where did Madtommy get his data? He doesn't say, so I can't tell if his data should be more accurate to the game than the real life data.

Just think: with its more powerful gun (with more ammo, too!), lower cost, higher resistance to battle damage, and lower speed, the F-35A that will replace the A-10 will do this CAS job so much better! /sarcasm off

Nice! I wish I could have been more help, but I've been pretty busy. If you're interested in doing more Lua, the #1 thing I can recommend is to buy a Lua manual. The first edition is available for free online, but nothing beats a physical copy: http://www.amazon.com/Programming-Second-Edition-Roberto-Ierusalimschy/dp/8590379825 It's very well written and easy to understand.

I disagree- the point that she is a woman DOES deserve admiration. Why? Because she has to not only fight the enemy, but also fight sexist stereotypes at the same time.

It's not complicated. IF there really is a bug, then it should apply ONLY to aircraft that are being flown by multiplayer clients. So if a human being is operating an aircraft (plane OR helo), and that human being is not the person hosting the game, then the bug would apply. So, it would potentially apply to units in the ME that were marked with either "Player" or "Client" skill levels, as both of those kinds of units are humanable in multiplayer.

That is correct, Mavericks are magic. We should be able to lock dead targets, but we can't. Tracking algorithms in DCS cheat by knowing where all the live game objects are; there is no actual image processing being done.

The daemon I mentioned will not be necessary, I have conceived of a better method. When Slmod opens, it will open the stats file, run it, then re-serialize the stats file and output it again to the file, and leave the file handle open for future writing. The purpose of that seemingly unnecessary step will be clear in a moment. I was thinking of how inefficient it is to re-serialize this big table, when most of the data does not change. Then it hit me- to update the stats file, I need only append the stats updates changes to the end of the stats file: Stats = {........ -- the stats, big long file... } --end of Stats, now the "stats updates" begin Stats["af920db91402a"][time]["A-10C"] = Stats["af920db91402a"]["time"]["A-10C"] + 5 Stats["af920db91402a"]["weapons"]["AGM-65D"]["shot"] = Stats["af920db91402a"]["weapons"]["AGM-65D"]["shot"] + 1 So basically, I'm just appending new lines of Lua code to the end of the stats file that change the value within the Stats table. When the file is re-opened the next time Slmod opens, it will just incorporate all these changes into the Stats table. :) You do have to worry now about the Stats file getting "corrupted". If my code is perfect, then it shouldn't be a problem... but you never know. You don't want to lose people's stats. I will need to program in a method to keep an older backup around.

Well, the daemon does not read events. All the daemon does is offload the process of serializing and writing the stats file. Compiling statistics is all done through Lua, in Slmod. The stats file is written so that: 1) Stats are backed up in case of server crash 2) Stats are re-read into Slmod on server start, so that stats are persistent across multiplayer sessions. 3) Stats can be output to another location, where some other external process can compile them with stats from other servers. 4) Stats can be read into an online database.

An update: Refactoring of base Slmod code to new version 7 standards is pretty much complete: -Moved all global variables in all environments into a "slmod" table (90% complete). -completely re-write all data passing code to use LuaSocket and greatly improve efficiency (complete) -completely re-write the active units database compilation code to greatly improve efficiency (complete) -General code reorganization (complete) -Re-write slmod events output (complete) Now, Slmod runs significantly more efficiently than before. This is thanks to the Eagle Dynamics team fixing a number of bugs in the game, and making improvements to the scripting engine. This has allowed me to remove several thousand lines of old Slmod code, replacing it with a much smaller number of lines of new code that runs more efficiently. Now, this shouldn't really cause a noticeable difference, as Slmod was already programmed to have an undetectable (or, at the very worst, only an extremely slight, in really huge missions) impact on game performance when you are hosting. However, as I add more features, and as missions get bigger (we are no longer limited to just ~800 units anymore!), I will need this extra elbow room. Anyway, with code upgrades pretty much complete, I'm now working full time (definition of full time: all my modding time) on Slmod Stats. This is the design template I am currently pursuing for how your stats record will look in Lua: --[[slmod.stats version = 1, -- what version of Slmod stats- could be useful for later, if I need to change the format of this table. ["c893ad9013fc8b03"] = { -- a unique UCID, one player. id = 43, -- identifier ID# - must be local server only- when re-merging separately compiled stats, must be careful with this. names = { -- list of names the player uses [1] = "John", [2] = "Speed", -- use the highest-numbered name to refer to in menus. }, time = { -- flight time, in seconds. "A-10C" = 23221, "Ka-50" = 10042, "CA" = 9531, "F-15C" = 6920, "Su-27" = 2420, }, weapons = { --shot: number shot --hit: how many actually hit something --objHits: total number of objects hit with this weapon --[[Definition: "weapon tracked"- this means that after a weapon is fired, if that initiator was a human, then the human is associated with that weapon. If that weapon hits anything, then that human gets credit for those hits. Periodically, tracked weapons are tested for continued existance; if they don't exist, they are erased. --CBUs cannot be tracked easily. ]] "30mm HE" = {shot = 1039, hit = 140, objHits = 140, acc = 0.212}, -- only non-shells are tracked (for now). "30mm AP" = {shot = 7002, hit = 1319, objHits = 1319, acc = 0.191}, "AIM-9M" = {shot = 10, hit = 4, objHits = 4 }, "AIM-120C" = {shot = 57, hit = 19, objHits = 19}, "Mk-84" = {shot = 12, hit = 8, objHits = 21}, "CBU_97/CBU_105" = {shot = 43, hit = 0, objHits = 91}, -- CBUs not tracked, and they never hit anything themselves. So must use BLU-108 and BLU-97 for hits. "CBU_87/CBU_103" = {shot = 9, hit = 0, objHits = 23}, ... }, PvP = { -- these stats only for player-vs-player- -- for fighter: to get a kill, must be killing a fighter. To get death, he must get shot down by fighter, attack, or helo. -- for attack: to get a kill, must be killing a fighter or attack. To get death, he must get shot down by attack or helo. -- for helo: to get a kill, must be killing a fighter, attack, or helo. To get death, he must get shot down by a helo. kills = 30, deaths = 19, }, kills = { plane = 26, friendlyPlane = 3, humanPlane = 10, friendlyHumanPlane = 2, vehicle = 119, friendlyVehicle = 6, ship = 2, friendlyShip = 0, helicopter = 9, friendlyHelicopter = 1, humanHelicopter = 5, friendlyHumanHelicopter = 1, static = 9, friendlyStatic = 2, }, friendlyKills = { planes = { [1] = 1004215421, -- Unix time. These will slowly be erased from your record.. according to a setting in config.lua [2] = 1004912310, }, vehicles = { [1] = 1005031051, [2] = 1005031054, [3] = 1005031057, [4] = 1005031061, }, }, deaths = { crash = 15, eject = 7, }, }, -- end of UCID# "c893ad9013fc8b03" }]] One thing I worry is this: Stats need to be backed-up periodically, and not just when the server shuts down. So, if the server host is having to serialize and save a massive stats file every minute or so, that could lead to a periodic server host stutter. I've created some fairly efficient table serialization functions, but if you're trying to serialize and save a table with like 900 entries in it, each entry of a similar length to the example shown above, that could too much to handle without generating a stutter of greater than ~100ms. There are two potential solutions. The first is for me to try to minimize the size of the stats table. This could definitely lead to less detailed stats being kept. I don't like that. Maybe, however, there could be ways I could logically “compress” the data. The second possible solution is to use a "stats daemon". The stats daemon would be a separate Lua process, started as an executable. I could make this using LÖVE. Data would be sent to the daemon over a UDP or TCP connection through localhost. The daemon would then go through the processor-intensive process of serializing and writing the stats file instead of DCS having to do it. Obviously, the “stats daemon” approach is a lot more work, and I’d like to avoid using it if at all possible. I hope to run a few tests very soon to determine if I need to use the stats daemon approach or not. If I do, it will probably mean a few extra weeks of delay before I finish SlmodStats. I am considering an optional achievements system, but I doubt it will/would make it for the first version. I particularly like the PvP stats system I have thought up. It's pretty simple: If you're in a fighter: - You get a kill for shooting down a human flown-fighter - You get a death for being shot down by a human-flown fighter, a human-flown attack aircraft, or a human-flown helo. If you're in an attack aircraft: - You get a kill for shooting down a human flown-fighter or a human-flown attack aircraft. - You get a death for being shot down by a human-flown attack aircraft or a human-flown helo. If you're in a helo: - You get a kill for shooting down a human flown-fighter, a human-flown attack aircraft, or a human-flown helo. - You get a death for being shot down by a human-flown helo. This way, players are not penalized in the PvP scores by flying a Su-25 or Ka-50 and being shot down by a fighter. They SHOULD be shot down by a fighter in this scenario, so why penalize their scores? Keep in mind that these are PvP stats, separate from the regular air-to-air stats. See the above table. Anyway, your stats, and the stats of other players will be accessible to you in-game via the menu system used for the parallel options/tasking lists, the coordinate converter, and the admin menu. I haven't exactly designed it yet, but I do know what some of the commands will be: "-stats" - main menu/help menu. "-statsme" or "-stats me" - get a summary of your own stats. "-stats <optional "for"> name <name of currently connected player>" - view this player's stats "-stats <optional "for"> id <Slmod stats Id of currently connected player>" - view this player's stats

Wait... you have a trigger that is MISSION START -> Time More (2) -> FLAG (1) off, FLAG (9999) On?? That is an impossible trigger to execute. The conditions are always false. You see, MISSION START is a condition, too.

Which triggers don't work? I did see you're using "part of group in zone". I never recommend using any kind of "group in zone" triggers for multiplayer clients. Yes, this trigger condition is supposed to work for multiplayer clients, but in actuality, in the simulator, multiplayer clients do not have a group. As far as I understand it, this issue is worked-around on a case-by-case basis so that to the end user, it does look like the multiplayer client has a group. But they don't. So you're just opening yourself up and asking for your mission to be buggy by using any kind of group in zone condition with multiplayer clients. Use unit in zone for multiplayer clients. I don't know if that is your issue or not- I did think that "part of group in zone" works for multiplayer clients in the current patch, but I haven't really tested it. I just wouldn't depend on it.

Yea, have you seen their Dec. 31, 2012 announcement? :hmm: :huh: :blink: :megalol::megalol::megalol:

It allows you to use a Lua script as a trigger condition. No longer is it necessary to have a Lua script set a flag so that the flag is sensed in the condition; the Lua script can directly be a trigger condition itself. While this has a bunch of complicated implications, the most simple use of it allows you to completely, or almost completely, abandon the use of flags. Flags cannot be named, and can only take up a very limited number of values. Lua is infinitely more capable. For example, say you have the logical condition: (Condition 1 OR Condition2) AND Condition 3 AND Condition 4 AND (Condition 5 OR Condition 6) In regular ME logic, this might have to be divided into three triggers: Flag 11 is true AND Flag 31 is true AND Flag 32 is true OR Flag 21 is true AND Flag 31 is true AND Flag 32 is true -> Set Flag 41 Flag 12 is true AND Flag 31 is true AND Flag 32 is true OR Flag 22 is true AND Flag 31 is true AND Flag 32 is true -> Set Flag 42 Flag 41 is true AND Flag 42 is true -> Set Flag 100 But with the new Lua conditions, this can all be combined into a single, more simple condition that is easy to read: return (player1Dead or player1HomeZone) and (player2Dead or player2HomeZone) and timeMore3600 and playerEnteredTargetZone

Glad to see you survived. I assume you had to hide in your bunker to survive that nuclear flame fest :P But no, the vast majority of the regular community, all the testers, all the devs- everyone, pretty much- acknowledges there are significant stability issues in 1.2.2 multiplayer. You are the first I've ever seen to claim that 1.2.2 multiplayer stability is good. That's just an honest fact.

Well, I did test some "nukes" in DCS recently, albeit not in an F-84.

Yes, I'm also seeing the problem- on the AI A-10's second target, he shares SPI on something off the map, and then flies around like a chicken with its head cut off. However, I don't think I should forward this mission to the devs, not in its current state- it has too much non-related stuff in it. I certainly don't want to forward it to them. Think of it this way: they are working on patches, adding new features to the game, working on DCS: Next, working on trying to support 3rd party modders, working on EDGE, etc.- so we need to make missions that illustrate bugs as simple as possible. And I'm working on Slmod, Mist, scripting engine testing, regular testing, helping people with scripts, etc. Before a bug can be fixed it must be known what is causing it. It's not uncommon for me to spend 1-4 hours just narrowing a bug down. So, I was curious if you could delete as much non-related stuff as you can- delete as many units, triggers, etc, from the mission as possible. Anything- trigger or unit- that doesn't have any relation to the actions of this AI pilot- get rid of it. You would probably know immediately off hand which components of the mission are related to this AI pilot, but I'd have to go through and figure out how the mission worked before I would. It would probably be a good idea to leave in the human A-10, as that lets you see when the AI starts referencing this weird SPI location.