Speed

Not possible through the export Lua environment. You need to be accessing the "main simulation" aka "server" environment for this. I'm not sure how to select the various radio menu items via Lua, or even if it is possible. I've never studied or been much interested in VAC or modding the radio menus.

AFAIK, there is no way to disable it. Personally, I find the effect so distracting that I can't even begin to start the aircraft until it's over.

Once deactivated, units cannot be reactivated again, sorry. Deactivated units are erased from existence.

That is 700 or 800 total, including units that are not even activated yet. It's not a hard limit either- 700 to 800 is just the results of my own personal experiments, and I've seen some folks claim they had not problems with missions with over 1000 units (though I could not verify their claims myself). You know you are having a problem when you start seeing a lot of "invalid sound source" errors in dcs.log. Just keep an eye on that. I have, however, thought of a work-around for missions that have a large number of randomized units, where the final number of units, after randomization, is less than the unit limit: 1) Place ALL air units and player units on a mission start + 1 second start time. Maybe place ALL units on mission start + 1 second start time. 2) Use MISSION START type triggers to randomly deactivate units you will not use. DEACTIVATED units are removed entirely from memory, and thus do not count towards this 700-800 unit limit. Now, when you spawn aircraft and allow players to spawn 1 second after mission start, the mission no longer exceeds the maximum unit limit, and there are no problems. Due to this issue http://forums.eagle.ru/showthread.php?t=91884 , it is desirable to have triggers that explode any players that force their way into an aircraft before 1 second has elapsed in the mission. I put in the brief, "DO NOT JOIN AN AIRCRAFT UNTIL 1 SECOND HAS ELAPSED IN THE MISSION!". If they still join an aircraft anyway, they get exploded, and sent the message "The Defense Department regrets to inform you that your sons are dead because they DIDN'T READ THE BRIEFING."

I gotta go to bed, so I'm keeping this a little short. Hopefully not too short. units_killed_by detects when specific units kill other specific units. Look at the input variables- it accepts two tables of units, "dead_units" and "killer_units". It sets the flag true when one of the "killer" units kills one of the "dead" units. Just to confirm you understand how the unit table short cuts work: The unit table short cuts (such as "[blue]") just tell Slmod to automatically add certain categories of units to those unit tables. You don't have to use them. For example, if the red team has only three total units on its side, and the names of those units are "tank1", "tank2", and "tank3", then these unit tables are exactly the same: {"tank1", "tank2", "tank3"} is the same as {"[red]"} when red coalition has only three total units, and they are named "tank1", "tank2", and "tank3". As far as "base raping" goes, I think your reasoning is correct- the easiest way could be a weapons impacting in zone script. However, you're wrong about it being tedious. That's my bad there, in my documentation, I forgot to note one very important thing: if you set the weapons input variable equal to {"all"}, then it detects ALL types of weapons impacting in zone (in fact, the "all" shortcut should work for all functions that accept weapon names) :thumbup: For example, slmod.weapons_impacting_in_zones{ init_units = {'[red]'}, zones = {'airbase'}, weapons = {'all'}, flag = 10} should set flag 10 to true whenever any weapon fired by any unit on the red coalition impacts inside the zone named "airbase". Note however: cluster bombs will not be properly detected. If you want to detect cluster bombs, you might want to use a "weapons_in_zones" function instead. That function goes true when weapons pass inside of a zone (or zones).

I wouldn't think this would be a problem, but it's definitely an untested area. Every time I've tried to do something similar to what you describe, I get CTDs pretty quick.

It sounds like an incorrect installation, but I can't really know anything unless I have your entire dcs.log. Dumb question: this is DCS World 1.2.0, right?

Last I checked, multiplayer clients won't slide off moving ships, just server hosts and single player players.

Once you exceed around 700 or 800 units, you might start to have a problem. Sounds will stop working, dcs.log will begin to approach 10, 100, even 1000MB in size (filled with "invalid sound source" errors), and the server host will probably crash eventually.

No. Why would the F-22 be required? Also, polls showed that Americans were already mostly angry about the Libyan intervention, adding Syria to the mix would seriously piss off the electorate... and it's an election year. And production ended on the F-22, not the program.

Not sure what your question is (there is no way to "link" trigger zones to anything, you just use them to detect certain conditions). Just understand: don't worry about triggers slowing down the game. Just don't. Make whatever triggers you need, and as many of them as you need. Triggers are incredibly simple compared to any AI algorithms.

More like an ansible :thumbup: For those who get US TV programming, there's a show scheduled on the Nat Geo channel tonight at 10 PM EST/EDT/whatever-the-hell-god!@#$-stupid-time-change-thing-we-are-on-now, called "Martian Mega Rover", covering the construction of the rover, it's capabilities, and the mission so far, up to and including the landing.

LOL yea, you're right, they shouldn't be doing that. Or maybe the AI secretly gets to use LJDAMs :D

Negatory. JTAC grids are never incorrect. They are just not giving you all the information. A full MGRS grid includes the UTM zone. On Caucasus map, there are only ever going to be two UTM zones you will use: 37T or 38T. The "GG314534" coordinate was, in full, 37T GG 314 534, while the other coordinate was 38T KM 688 559. The problem is, you needed to change the UTM zone from 37T to 38T for that second coordinate, and you did not do so. I will be releasing a mod in probably a week or two that will make the JTAC give the full MGRS coordinate to help solve this confusion, as well as adding other fixes. The reason the JTAC skips the UTM zone is probably that, in real life, you as a pilot would already know this information (it would be obvious, UTM zones are very big). The problem is when the JTAC is giving target coordinates near a UTM zone boundry, as is the case for this mission.

The problem is, from what I've read, the US is either running out, or has already run out of the Plutonium 238 that we need to make RTGs (radioisotope thermoelectric generators). Unless we want to launch a full nuclear reactor (funding for research on nuclear reactors for deep space missions was recently cut from NASA's budget too), RTGs are absolutely required for missions beyond Mars, where there is too little sunlight to power a spacecraft. Plutonium 238 has no applications besides RTGs (that I know of, at least). Unfortunately, Congress has not given the go-ahead to resume Plutonium 238 production. The US might have to buy the Plutonium 238 for the next mission from Russia, and Russia's supply is dwindling too. If Congress doesn't approve the resumption of Plutonium 238 production, then exploration beyond Mars will simply no longer be possible in the near future, unless Russia decides to bail out NASA again by resuming production themselves. Though, I suppose, any state with nuclear power might also be able to make the stuff for us.

Nice pic there, Pilotasso, and I see, it looks like they're starting to receive the full resolution images taken during the landing: That should be the resolution of every frame of the landing "movie" once all the images come down :)

Ok, thanks for the help. The issue exists just as you describe it in current version 1.2.0, but I cannot replicate it in internal versions. Hopefully, that means it will be fixed next patch.

It may be that interstellar space flight is not done by advanced civilizations on a regular basis simply because it is very expensive, and there is not as much motivation to do it as we might think. Once a civilization acquires the technology and the resources to actually attempt an interstellar voyage, it may have also solved the problem of self-sustaining colonies in space. If your colony can sustain itself using just the materials mined from an asteroid or comet, and the energy derived from say, nuclear fusion, then the motivation to leave your home system is much reduced. Why do you need to find a new home? You don't need to, you can live anywhere.

The low res version of the landing video has been beamed back! http://www.space.com/16961-curiosity-rover-s-descent-images-reach-earth-video.html Over the coming days and maybe weeks, it will be sending us back more frames from the video, and many times the resolution :)

Ok, this morning, I accidentally removed the Slmodv6_0 guides, they should be back up now, sorry :doh:

Actually, I digressed so badly that I forgot the main point: we have the technology to start developing such a mission, but we simply lack the money. I donno what the cost would be, probably somewhere on the order of $1B-10B. And then of course, what is almost certainly an extraterrestrial liquid water ocean, with likely geothermal energy sources, only like 500M miles away under the ice of Europa (a moon of Jupiter). Extraterrestrial life might just be sitting there on the surface, frozen in the water ice "rocks". Can't get money to do that one either.

The problem has been reported.

Yea, it's pretty sad, isn't it? We have the technology, or know how to develop the technology fairly quickly, to fly a large space interferometry mission within 10-20 years that could capture the spectral fingerprints of any habitable worlds out to a few dozen light years, if not more. It could even prove to a high certainty the existence of life on them, because, if you have the spectrum, then it becomes possible to detect biological activity on the surface- you look for atmospheres that are not in chemical equilibrium. For example, for like the past 1.5 billion years, Earth's spectral signature (specifically, very abundant O2) has been screaming "HABITABLE PLANET WITH A LARGE BIOSPHERE" out into interstellar space for any intelligent civilization to see. The fact that, in all that time, aliens haven't arrived to subjugate our planet makes all the Hollywood alien invasion flicks even that more ridiculous. :D Anyway, I severely digress...

Ok, disregard what I said about Track IR causing the problem with crash on master server connection. I believe it is a different issue. And no, it has nothing to do with Slmod. I think you just have to wait the problem out :(

Sorry for the confusion. Latest official release version is DCS: World 1.2.0. The previous official release version was A-10C/Ka-50 1.1.1.1. What happened was, before 1.2.0, both A-10C and Ka-50 were stand-alone, and had to be installed separated. 1.2.0 release integrated the Ka-50 and A-10C modules into a single install (if you own both Ka-50 and A-10C, at least). So to install, first install the DCS World core (1.2.0). Next, you download and install the A-10C/Ka-50/P-51/Combined Arms modules- whichever you happen to own.