Speed

OK. Doesn't matter. Then the US would be the only nation with nuclear weapons. Checkmate :P After the UK became the 51st state, I suppose the US would get jet engines too. :D

No, you're incorrect. When you drop a GBU-12, in the absence of laser guiding, it will impact near the SPI you had at the moment you dropped. The reason your GBU hit your SPI and not your laser was because your SPI was so far away from the point that your TGP was looking at that the bomb never saw the laser- the laser spot never passed within the FOV of the bomb. So the bomb just flew ballistically and hit near your SPI. If you were able to hit under the same situation using manual lasing, it would be because you activated your laser manually long before auto-lase would have. The bomb was far enough away at the time manual lasing began that the laser spot was still in its field of view. It's the same reason that manually lasing from the moment the bomb is released is generally superior to auto-lasing against moving targets.

Agreed. However, during actual gameplay use, manually lasing (especially when manual lasing is defined as manually turning the laser on from the moment the bomb is released) will generally mean that the laser is turned on long before auto-lase would have turned it on.

Here's a little illustration why auto-lasing when you're trying to hit a moving target from high altitude is a bad idea.

I don't understand- you mean that in real life, everything doesn't explode and burn for 10 minutes when it is destroyed?!?! :huh: Clearly, you're wrong. Yea, they were the shipping containers holding all the explosive barrels that had been stockpiled for use in Half Life 2: Episode 3. SOMETHING had to be done with them.

I used a script to automatically place down brown container boxes down on a perimeter defined by a set of Vec2 points. It's not perfect, but it's better than nothing. I'll see if I can adapt it into something more user-friendly than it currently is.

You can do it if the server host is running Slmod with the coordinate converter enabled. Other than that... F10 map?

Only if it's an AT-802.

Yes, it's currently broken in 1.2.2. It will probably be fixed in the next patch.

OH OF COURSE... those are necessary. For now. A little history lesson: From DCS A-10C 1.1.0.1 to 1.1.0.8, the "mission scripting" Lua environment did not exist. All Lua scripts were run in the "main simulation" Lua environment. This meant you could actually make a mission that would mess up your Windows install or install a virus. In patch 1.1.0.9, Saint rectified this problem by creating the "mission scripting" Lua environment and making the mission scripting Lua environment have NO access to dangerous functions. Even some non-dangerous functions were removed, such as the print function. Unfortunately, this made the mission scripting environment virtually useless. Eventually, I was able to figure out a work-around: During mission scripting environment initialization, I could save a reference to the print function before it was "sanitized". Then, with about a thousand lines of Lua and a Visual Basic Script "daemon", I could use dcs.log and the print function as a sort of transport layer to get scripting commands from mission scripting into a Lua environment where they could actually be executed. This is where the situation stood until DCS World came out. Saint moved the sanitization code to MissionScripting.lua (previously, it was done in C++), so it finally became possible to use something PROPER, like UDP via LuaSocket, as a transport layer. However, since the previous print function method Slmod had been using for most of a year seemed to work flawlessly, replacing it wasn't a very high priority for me. My internal versions of Slmod I am working on now use UDP as a transport layer to send information from the mission scripting to the net Lua environment. I was able to replace 1000+ lines with maybe 150, and significantly improve the speed and efficiency of the code. So there are no print statements used anymore. This is one of the code base updates I am working on for Slmod version 7. If you really need a copy of this internal version that uses UDP instead, then send me a PM with your email and I can send it to you. It's an internal version so it could have bugs in it though, and obviously, it's not ready to share with everyone.

So that they can.... what? Continue to circle unthinkingly around a star until the next mass extinction? Or die off completely in 500 million years when the Sun finally gets too hot for the Earth's climate feedback systems to stabilize? Intelligence is the only way a biological system can survive in the very long run. Obviously, you have a value system that doesn't value intelligence and self-awareness much. Keep in mind that without intelligence, value systems do not even exist. The universe has no way of knowing that it is even alive. I do think we're doomed for some radical changes... our current population and civilization is obviously not sustainable.

Maybe, but it's much easier to open the track in the mission editor (make sure you tell the ME to look for .trk files), disable external view restrictions, and then re-save the track (AS A .TRK FILE!). Much more simple.

I must admit I'm confused. There shouldn't be any recording of chat messages to dcs.log. Can you give me a sample of what you are seeing in dcs.log? By the way, and such output would just be the result of a print statement somewhere. I use them quite liberally for debugging, but any such print statements would/should all be commented out or removed in "release" versions, unless that print statement is outputting some kind of error message.

If you hear "270 for 160 at 6000" over the radio, it could mean one of two different things, depending on if the country you're flying for uses metric or not. If flying for US: 270 degrees from the common bullseye reference point at a range of 160 nautical miles, at an altitude of 6000 feet. Also commonly included is the aspect- "hot" is coming towards you, "cold" is going away. If flying for Russia: 270 degrees from the common bullseye reference point at 160 kilometers, at an altitude of 6000 meters. Bogey Dope should give you the nearest bandit (though you would think it would give you the nearest bogey- but in DCS I don't think there are bogeys). Used correctly: Bogey- unidentified aircraft Bandit- confirmed hostile aircraft

So you're feeling a little guilty for enjoying the simulation of one the darker sides of human nature? If so, you should also feel guilty for watching any kinds of war movies, action movies, etc. I know that doesn't help much. Maybe view it this way- you're not harming anybody or making the world a worse place, so your feelings make no sense at all. Ultimately, guilt is often one of the most nonsensical emotions, so maybe just tell yourself that and get on with doing what you enjoy.

It looks like I reported that the function was not working back in September. Saint says he accidentally had the function using a boolean enumerator for AM/FM modulation, not a numeric enumerator like the documentation says. It was supposedly fixed in internal versions a while back, but I haven't gone back and verified that that is truly the case. I should probably do that :D Anyway, that means that here in 1.2.2, you could try using simply true or false to determine AM/FM modulation (donno which corresponds to which though, so you'll have to experiment). If it does work with a boolean, maybe you could put it inside a pcall and call both the numeric and boolean enumerator versions to make your mission insensitive to the 1.2.2 to 1.2.3 transition (assuming it is really fixed in 1.2.3).

Slmod has had this feature for over a year now. Right now, it outputs all events since the last time the file was written. As of Slmodv6_3, you can turn this feature on/off and adjust how often the file is written with your Saved Games/DCS/Slmod/config.lua file. I added it for Moa, but then he quit DCS before adapting his stats mod to use it, so no one uses it that I know of. That said, the coming Slmod stats system, at least in its final implementation, could be quite a bit improved over what was possible before, simply because Slmod can access all Lua environments that the game uses. I remember Moa telling me of all the difficulties he had had due to bugs with debrief events- Slmod can actually access two different simulation event systems, and also things like the real-time locations of aircraft and weapons fired, solving any kinds of ambiguity as to what was going on in the game world. You can see, for example, one significant benefit already in the events that are output- locations (x, y, z) are known. But anyway, since no one, to my knowledge, is currently making use of the events output feature of Slmod, I'm free to make any changes to it that you might like. One thing I could do is make it so that it does not only output the events that have occurred since the file was last output. Another thing that would be possible is to output the events over the network via LuaSocket.

trigger.action.radioTransmission It's been a while since I tested it though... I forgot if there were any bugs or quirks with it in the current released version of DCS. If it didn't work, you could also try using the transmit message AI command. It's not in the scripting engine documentation, but it should still work: just unzip a mission where the AI use it to see how to code it in Lua.

Yea, back when I had the X-52, I had a really tough time refueling. I had no choice but to add a curve. After that, I was able to refuel finally, but it still tough. Let's just say that after upgrading to an X-65, refueling became vastly easier... Another thing I might say is if you have pilot-induced oscillation, you are probably not anticipating your aircraft enough. You need to think ahead of what your aircraft is currently doing, and correct for increases/decreases in speed/altitude a little BEFORE they actually happen.

This is not correct. Triggers are run 1 time every second. So one time every second, your flag would have a value of 10 added to it. It would be no more precise than incrementing by 1. Really, an air race mission begs for implementation via the Simulator Scripting Engine (SSE). Using Lua, you can, for example, get precise times with timer.getTime, and create functions that very rapidly check conditions with timer.scheduleFunction.

I really don't know that much about networking, and I don't know how FTP servers are set up. Do you think I should I have a reason to believe FTP will work better than Dropbox? Actually, I haven't looked at Case's work. I'm not really a FC player, so I am only vaguely aware of previous stats systems. I know, for example, Moa also had one. A listing of what stats he kept up with might be nice just for reference of what was previously done. One of the first things that will need to be done is to make up a listing of stats that would be nice to keep.

I donno about global statistics- but like Grimes said, I plan on including the first implementation of the Slmod statistics system with Slmod version 7. Statistics would be kept on each player that joins the server, and indexed by each player's unique UCID. The stats would be kept in a text file which would be a serialized Lua table. The kind of statistics that would be kept would be things like flight time, units killed, number of crashes, etc. I still need to come up with an exact list and plan on how to implement it. Right now, I'm working on upgrading the Slmod code base, not adding new features. Global statistics would be something that server admins would have to negotiate amongst themselves. Basically, if you wanted globally shared statistics, you could have the Slmod stats for each DCS server output to a different shared Dropbox folder. There would be some "central" server (doesn't need to be running DCS) that all the DCS servers share their individual Dropbox stats folder with. This central server would just be running some simple process/script that would open up each DCS server's stats file, compile all the stats together, then output some global stats file somewhere. Oh and the final link in the chain could be that this global stats file is then shared back to all the DCS servers that contributed to it. When a player on one of the servers asks Slmod to display his stats on screen (the command will probably be "-stats me"/"-statsme"), then Slmod simply uses the global stats file instead of the local stats table/file for that specific server. In summary, making the probable future Slmod stats system become a global stats-keeping system simply comes down to having two new options in the /Saved Games/DCS/Slmod/config.lua file: one option specifies what file to use for the server's local stats. The other option specifies what file to use as a reference for displaying player stats. The "hard" part is getting the stats system completed, and getting server admins to coordinate and agree on using it. Actually writing it won't be hard, just time consuming.

I don't believe it does anything at this time, but I might be wrong. A little tip: When making tasks for groups, I find it helpful to create the task or one similar to it first in the mission editor. Save the mission with the waypoints like how you want the Lua-assigned task to look. Now, just unzip the mission, open the "mission" file up, find that group, and simply copy the task out of there. A few things might be different- like in some cases, in the mission file, for Vec2 points, I believe x = number, y = number is used, while in the SSE, it's usually point = { x = number, y = number}. However, I believe that the AI engine is overloaded to accept either.

1) You're the second person in this thread to admit this mistake, so that's probably just the tip of the iceberg. If can you tell me a way in which I can make the instructions in the config.lua file more clear, I'd be happy to hear it. 2) First, AFAIK, windows doesn't care. It will open paths with double slashes in them, even if they are different. Secondly, you appear to be incorrect- the file path that Slmod assembles will not contain two slashes, I deliberately set up logic to make a slash at the end of the admin_tools_mission_folder directory optional. See the code in the create_LoadMissionMenuFor function in the SlmodAdminMenu.lua file: local path if slmod.config.admin_tools_mission_folder and type(slmod.config.admin_tools_mission_folder) == 'string' then path = slmod.config.admin_tools_mission_folder if (path:sub(-1) ~= '\\') or (path:sub(-1) ~= '/') then path = path .. '\\' end else path = lfs.writedir() .. [[slmod\Missions\]] end The Lua File System (lfs) module returns folder directory strings with slashes as the end of them, which is why I followed that convention. However, you are probably correct that the slash should not be there at the end, because a slash at the end is not required to specify a folder. I'll remove it.

Is it time to finally do something about North Korea? t8nrdiQqFAs Nope.