Speed

The script I posted doesn't unzip anything, it only opens files that are already unzipped. It is a decent option for getting the mission file from just about any Lua environment, when computation time is not a concern (such as, when you are opening a mission, computation time is not really a concern- if running this script causes it to take an extra 300ms to open a mission, no one is really going to notice or care). The script I linked is also a good option for getting a mission file that includes the triggers in a string format- as the actual mission table, in the mission environment, has the trigger conditions and actions compiled into functions, and thus you can't inspect what's really going on in them. Like I said, to get the mission table through memory, you need to either modify debriefing.lua to save a mission table in the main simulation environment and export it from there, or use net.dostring_in to bring the data from the mission environment into the net environment, where it can be exported. If you're worrying about wasting CPU cycles, why are you trying to bring in the whole mission table? It can be very huge. Why not just grab the parts that you need? Also, if you're going to serializing the mission table, you need to be aware that the mission table utilizes cycles- table references to other tables that contain references back to the original table. So many/most serialization functions will enter an infinite loop when attempting to serialize the mission table. The table serialization function I use in Slmod for the serialization of tables that may contain cycles is shown below. It's mostly out of Programming in Lua, but I think I made a modification to the string concatenation to enter the strings I want to concatenate into a table and then run table.concat on that table when I'm done (which makes a HUGE difference for very long strings- for very long strings, the standard Lua string concatenation operator is MASSIVELY inefficient): --mostly straight out of Programming in Lua function serialize_wcycles(name, value, saved) local basicSerialize = function (o) if type(o) == "number" then return tostring(o) elseif type(o) == "boolean" then return tostring(o) elseif type(o) == "string" then return string.format("%q", o) end end local t_str = {} saved = saved or {} -- initial value if ((type(value) == 'string') or (type(value) == 'number') or (type(value) == 'table') or (type(value) == 'boolean')) then table.insert(t_str, name .. " = ") if type(value) == "number" or type(value) == "string" or type(value) == "boolean" then table.insert(t_str, basicSerialize(value) .. "\n") else if saved[value] then -- value already saved? table.insert(t_str, saved[value] .. "\n") else saved[value] = name -- save name for next time table.insert(t_str, "{}\n") for k,v in pairs(value) do -- save its fields local fieldname = string.format("%s[%s]", name, basicSerialize(k)) table.insert(t_str, serialize_wcycles(fieldname, v, saved)) end end end return table.concat(t_str) else return "" end end Anyway, come to think of it, if you take the main simulation, modify debriefing.lua approach, you don't need to do table serialization at all. You merely need to save the relevant data within the relevant function in the debriefing module. More specifically, the debriefing module is in ./Scripts/UI/debriefing.lua. Modify the updateMissionData function, which is passed the missionStr (mission string, from the mission file) at the start of every mission, to save the missionStr variable to the global environment. Or, if you prefer a mission table, over a string then save the env.mission local variable that is created. Edit: Modified the serialization function, I just realized I left a "safestring" call in there. I replaced it.

That's probably because you were in the wrong UTM zone. An MGRS coordinate looks like 38T KM 553 112, where the 38T is the UTM zone. If you have 37T instead of 38T, you'll be hundreds of miles off. JTAC doesn't tell you UTM zone by default, but you can install mods to fix this.

I like your invisible FARP idea. I'd love it if "FARP" and "FARP INVISIBLE" were options in the "Heliports" static objects menu! My conception of how it might be done was to somehow create an ATC/ground service zone, and effectively, that's what you're trying to do. I was thinking/hoping that maybe it might be possible to figure out how the game assigns ATC and ground service zones and just be able to define an arbitrary one; but you're right- just making an invisible FARP is by far the most simple and easy way to do this. The only problem is that it will not be possible to have planes re-arm and refuel in this invisible FARP zone, as planes cannot rearm and refuel on FARPs (yes, I've tried :D). So we couldn't use your invisible FARP to make like, a highway M4 rearming and refueling base for A-10s.

Well, it would be evolving a lot further if I would just sit down and get the last major thing that needs to be done for the next version done, then do a bunch of testing and documentation... I have some nice features in Slmodv6, fully working already. Anyway, there were a few problems with your mission you uploaded, but it looks like the reason nothing worked was because you stumbled across a probable bug in DCS- it looks like triggered actions may no longer work for naval units. This may be a new, unreported bug. As soon as I moved your triggered actions onto a land unit ("SCRIPT2"), things started working again. Who knows, maybe this bug only afflicts certain triggered actions. Somehow, I doubt it- a bug in naval triggered actions could go unnoticed for a while, except by someone like you who decides to go against the grain and make your script unit some dude in a boat :P Heck, I used to have a need for triggered actions on naval units (TLAM strikes), but fire at point doesn't work for ships any more :cry: (or at least, last I checked). Anyway, I'm uploading the fixed version. I also had to fix the trigger logic in the first two triggers, which I'm sure was only messed up because you were pulling your hair out trying to figure out WTF was wrong. Operation Raindrop fixed.miz

The reason you saw no scripts in the scripting group's actions was probably because you were looking in the waypoint actions. Don't look there. Look in the triggered actions tab: Triggered actions only run when they are told to by a mission editor trigger, thus making them vastly more flexible; they can also be run as many times as you want. Waypoint actions are only useful when you want something to occur when a group hits a waypoint. Look in the triggers list and you will see when and under what conditions various Lua scripts are run, via the AI ACTION trigger action (the AI ACTION trigger action is the trigger action that runs a triggered action). Tasks do not automatically delete themselves- you have to do it with the remove_task function. I suppose it might be possible to some day have an option to make certain kinds of tasks (the group-based tasks) automatically remove themselves when the units are dead, but as of right now, you need to do it manually. Remember that each task has a unique ID number. That's how you identify tasks with the add_task and remove_task functions. To have more than one task, you need to use more than one unique ID- otherwise, you will just over-write the previous task. For example: slmod.add_task(101, 'msg_out', 'Destroy enemy HQ', 'Destroy enemy HQ at 38T KM 074 221') slmod.add_task(102, 'msg_MGRS', 'Destroy enemy armor', 'We have spotted enemy tanks at: ', {'tank1_1', 'tank1_2', 'tank1_3', 'tank1_4', 'tank1_5'}, 6) This code will add two tasks, because the unique ID, the first variable, is different for each task. So basically, if you wanted the 'Destroy enemy armor' task, task 102, (where 102 refers again, to its unique identifier number) to go away, you will need to run the following code: slmod.remove_task(102) which will delete task 102 from both the red coalition and the blue coalition's task lists.

It might be possible to have you start in the same same SADL group as another MP client, but with a different own ID at mission start, but for multiplayer clients to actually start in the same aircraft group, that's impossible. ED's code simply doesn't support it, and don't I think that the code's group mechanics/assumptions that forced this restriction could be changed easily.

Considering I didn't touch any of the scripts dealing with the aircraft's radios (I don't even know offhand where those scripts are), and only modified the scripts that govern what the AI say on the radios, and that NATO.lua and common.lua live in their own separate module namespace from anything that actually does control aircraft radio knobs, one can be reasonably certain that this mod has nothing to do with that.

Hmm... look in ./Scripts/Database/db_units_misc.lua: Heliport = { [1] = { CLSID = "{24FC9197-F225-4f2a-8A31-BD51DC7BDAB6}", Name = "FARP", DisplayName = _("FARP"), }, -- end of [1] }, -- end of Heliport Part of adding a new kind of FARP object would likely involve adding a new entry here. P.S.- to find more files about FARPs, you should use Notepad++'s "Find in Files" feature. Search for the word "FARP" in all files in the DCS directory of your choice.

Chromium, I think the problem may be that the FARP is much more than a 3D model. You need to find the Lua files- if there are any at all- that tell the game itself what to consider a FARP. Just because you switched out a 3D model doesn't mean the game fully understands that this new object is supposed to be a FARP. Anyway, that would be my guess as to why this isn't working. There is ./Scripts/World/FARP.lua, but that seems to control FARP service, not telling the game what is a FARP and what is not. Peronally, I'd just love a placeable, ground service zone, where we would simply allow ground service from anywhere. AI wouldn't be able to use it, but humans could. Anyway, your chance of success is pretty low. That doesn't mean you shouldn't try, most of my Lua experiments end in failure, that's to be expected. But every once in a while, one of your experiments will actually succeed.

This is a true story. I really mean it- see for yourself: 1) Open Google Earth 2) Enter these coordinates: 48 04'N 12 52'E It's the town of F*cking, Austria! Apparently, they are tired of all the jokes, and want a name change: http://gma.yahoo.com/blogs/abc-blogs/small-town-wants-change-f-king-name-122908356--abc-news-topstories.html The best quote: Unfortunately (or fortunately) this seems unlikely:

Servers have no problems hosting more than 10 people if the server's bandwidth is high enough to do it. Upload the mission. This sounds like perhaps some of the aircraft further down the list don't have their start times set correctly. If you have a humanable aircraft that has a start time set for after mission start, then until that start time is reached, the aircraft will show up as an available multiplayer slot, but if you try to actually join it and fly, you will just be stuck staring at the F10 map.

Stupid fun: The Ka-64. Actually, Hellfires work quite well. They're one of the few cheat weapons I've found that work as well as a "real" weapon... it works similar to a cross between the Kh-25 and the Vikhr.

I'm not saying your point of view is wrong, I'm just saying it's wrong to consider this a bug, and not working correctly. It's not possible to reactivate deactivated units... they're gone. If you've found some way, I'd love to find out what it is, because that would basically allow endless respawning. Unfortunately, every single test I've ever made shows that once deactivated, groups are erased from existence, permanently. Sorta like they were victims of a Star Trek transporter failure :D I do believe that the way that group dead is evaluated is by simply detecting the existence or non-existence of that group. A group that has been killed in battle also does not exist. Which is why group dead goes true when that group is deactivated.

This might be true if you weren't playing the music in the middle of flying an aircraft, with loud engine noises in your ears, and if you had unlimited bandwidth. Just FYI, almost everyone downloading the mission will vastly prefer the 5X-10X smaller file size over an imperceptible (or nearly so) decrease in sound quality. Honestly, to my ears, engine noise masks almost all differences between GSM 6.10 @ 22kHz sample rate (35kb/s bit rate) and high quality sound. Even at GSM 6.10 @ 11kHz sample rate (so like, 17kb/s), the difference for some sound tracks isn't very noticeable once in the pit. Perhaps you have a more discerning auditory system than me, but I'm probably pretty average in that regard, and if you are making your missions for public "consumption", then it's probably a good idea to make them for folks with average hearing :)

Well, you see, that's your opinion. I think considering the group dead because it no longer exists is perfectly natural. For ED to change it, that could require significant code changes on their part that could cause bugs in other parts of the program. And not only that- this change would break the logic of some people's missions. I've actually depended on deactivated groups being considered dead as part of my ME trigger logic before. All you need to prevent this is a single flag that goes true when the group lands/is deactivated, that prevents the message from being played. I think you're already using this solution, right?

Well, actually, I converted a pair of old missions of mine into BS2 just the other day. I was able to just open them in A-10 and save them. If there are going to be any issues, most will probably involve AI aircraft, I would guess. Someone who does/did a lot of conversions, like STP Dragon, would know better than I would.

Who says I don't already? uxZj5n4vdpw :) Problem is, it doesn't work in multiplayer :(

Agreed. Now the only thing we need is for ED to release this "fast mover" ;)

Well, if you want to carry Kh-25s on your inner pylons and Vikhrs on your outer pylons, it's a fairly simple matter to modify your unitPayloads.lua to allow this. I'd feel a little unpure though, using such a modification in multiplayer :D

Sure, what details do you need? Now, I don't do Luasocket, which is the Lua module you'll need (and is already included with the game) to export data over TCP/UDP, but I have a pretty good idea of how to get started with it though. You can always get working programming examples from working mods that use Luasocket, and there are some examples ED has done too, somewhere. I've just never needed to do Luasocket for any mods myself. Now getting the mission data itself is pretty easy, there are multiple ways I can think of right off hand- First off, "mission" table - a Lua table containing all the mission's triggers, units, waypoints, loadouts, weather settings, options, bullseyes, briefing text, etc. A Lua table is an associative array- it's an object in your computer's memory (RAM). "mission" file - a text file of the mission table in a serialized form (serialized == converted to a string in Lua syntax so that a future loadstring call on that string will create a function that re-creates the table). .miz file - a zipped archive containing the "mission" file, plus any other sounds/pictures/various scripts that might be included with the mission Anyway, net.dostring_in (a "net" environment function) can access the "mission" environment, where the "mission" table is (with the triggers compiled as well). You can return whatever data you want from the "mission" environment to the net environment, after which you can send that data where ever you want with Luasocket. Also, the debriefing module in the "server" aka "main simulation" environment has a function that is passed the mission file (as a string),; you can potentially make a modification to this function to store whatever information you need (which is what I did in the "Radio Patch" mod). Finally, any unsecured Lua environment in DCS has the lfs (Lua File System) module, and with the lfs module you can create a function that is able to deduce which file in C:\Users\<user name>\AppData\Local\Temp\DCS Warthog is the real mission file. The following is some Lua code I wrote to do just that:

What can we say... cigarettes kill :)

There are trigger actions that allow you to play sound to all, sound to country, sound to coalition, or even, sound to group. See the GUI manual.

Use a better audio converter :) Part of your problem is that you're using .ogg, when .wav using the GSM 6.10 codec can in fact be a lot smaller. Here's your Gravity.ogg, remade into 2.22 MB .wav file: It could be made less than half again this size, in fact, but it wouldn't sound very good. Edit: actually, it's not that bad, here's the 1.11 MB .wav file. Edit 2: Actually with all the base, your file doesn't sound too much more awful than it already is ( :P ) all the way down at a 8000 Hz sample rate using GSM 6.10, and now, it's only 826 kB. Lesson of the day: .OGG IS TEH MAJOR SUCK. .WAV IS DOMINATE! Gravity.zip Gravity_1.zip Gravity_2.zip

This is not a bug; deactivating a group permanently deletes that group from the game world. Why should it not trigger the unit/group is dead trigger condition? The group is no longer in existence, so of course it's dead.

Since no one has said it yet, the best way to survive against SAMs is to fly high, >22k feet AGL or so, and avoid the SAMs that can hit you at high altitude (SA-3, 6, 8, 10, 11, 15). You often won't face SAM threats like those anyway, and you will also usually see them show up on your RWR before you fly within range. Just snipe targets with PGMs from high altitude in high threat environments.