Speed

Here's a source, not a very good one, but one anyways, claiming that most likely, the comet impact would improve Mars habitability: http://rt.com/news/mars-comet-tito-flyby-601/ In regards to Martian habitability, it sounds like a battle between global warming, allowing Mars to keep its supplemented and melted atmosphere in a gaseous phase, and global cooling causing the atmosphere to freeze out, with the person quoted (this Robert Matson) feeling that global warming would probably prevail overall, leaving a post-impact Mars with a thicker atmosphere. It would be nice to get more sources, but I don't see any. Personally, I'm thinking that yes, dust would be kicked up into the Mars atmosphere causing a global cooling effect, but we have to remember that the Martian atmosphere is much thinner, so that dust probably could not stay suspended for as long as decades it can on Earth. Then again, even a dust-clouded Earth isn't cold enough for large parts of its atmosphere to freeze out on the ground. Mars is already that cold today- it's polar ice caps are largely dry ice. Hell, it snows dry ice on Mars during the winter. IIRC, the Pheonix lander even spotted a time where it was snowing water ice and dry ice simultaneously.

Personally, I do neither. I figure out what features the mission will require, and form a broad outline of the mission design in my head. Then, the features that are easiest to do with triggers, I do with triggers. The features that are easier to do with Lua or can only be done with Lua, do I with Lua. It is becoming increasingly possible to replace more and more of a mission's triggers with Lua, but we haven't reached that stage where a 100% Lua, complex mission is possible. But the idea that Lua is being developed to replace mission trigger logic is inaccurate. The point of the Lua scripting engine is to provide a much more powerful scripting tool than triggers can ever hope to be. How you use it is up to you.

If I was a soldier, I think I'd rather have a Super Tucano available to provide me support 24/7, than an A-10 that is available just 1/3 of the time :) I wonder though, will the USAF find another mistake in the paperwork so that they can give the domestic AT-6 a third shot at it?

First of all, make sure that you only have ONE instance of the ME open. I've seen cases where people, minimizing the ME to do some sound editing or find some picture or do some research, actually re-opened the ME instead of maximizing it when they were ready to work on the mission again. Now they had TWO copies of the ME open, editing the SAME mission. Now, after finishing editing the mission in the second instance of the ME and closing that instance, if they weren't careful they would then save the mission in the FIRST instance of the ME too, overwriting ALL the changes they had made in the second instance of the ME. Then, when they reopened the mission later, the user was like, "WHAT THE !@#$, IT DIDN'T SAVE ANY OF MY CHANGES!!!!!!!111" and got really furious at the mission editor. I've seen people lose HOURS of work to this mistake. :( To combat this goof, and this is ALSO just a good idea in general, I always make a new save of the mission like every 15 minutes. Like I'll have Kashuri CAS_1, fifteen minutes later, I'll save it as Kashuri CAS_2, and so on. This can lead to 100 or more saves of the same mission, but at least I'll never lose very much (if any) work if I make the mistake described above, and sometimes, I'll actually need to revert to something that I deleted many versions back. You can always go back in later when you really are done and delete the extra saves.

The only time I know of when a big aircraft was hit by multiple missiles was when the Soviets shot down Korean Air flight 007 (a civilian Boeing 747) in 1983. The Su-15 fired two R-8s, and according to the Soviet pilot, both missiles hit their mark. The pilots of the 747 were actually able to fly the aircraft for a little while but eventually lost control. So maybe it's not entirely implausible for something like the A-50 to survive two missile hits- but it should be a RARE occurrence. And I would imagine (or at least, hope) that the warhead on an AIM-120 would be more deadly than the one on an R-8.

I find it very implausible for that A-50 to be able to fly as described. It's an A-50, and it has this giant, draggy radar dome on top. And furthermore what engine was it that he had left? If it was one of the outer engines, then he should have been a huge thrust imbalance, causing him to yaw badly when he applied power. Now, he could have corrected that with rudder maybe, at higher speeds, but at just 96 knots I doubt the rudder would have the control authority to override the thrust imbalance, even if it was one of the inner engines. Furthermore, all that applied rudder would have further increased his drag. It is important to keep in mind that the AI does fly a much simplified flight model. If they didn't then your computer would quickly bog down trying to compute all their flight parameters, and you would need very elaborate and complex control algorithms to make them fly the plane correctly. So this would probably be a place where the AI needs some tuning in some regard. Anyway, it's not implausible at all though, that an aircraft like the A-50, reduced to a single engine, could keep its airspeed high, and use the thrust of that engine to get it to the nearest airfield. I just don't think he could actually USE that engine during landing, I think he would probably have to just glide it in, because at slower speeds, the effect of the asymmetrical thrust would be too much for his rudder to compensate. Keep in mind though, I'm just an armchair pilot, so anyone with better knowledge feel free to correct me.

Well, it's already possible, last I checked, to create exploits like that, even if the server has disabled LOGetWorldObjects and LOGetPositionByID or whatever the other one is. You just use modifications to the main simulation Lua environment to do your data export instead of the Lua export environment. You can't turn off main simulation Lua environment scripts when you gotta use them to make the game work right ;)

I might agree that significant atmospheric loss could occur if this were an asteroid, but it's a comet, and it's largely made up of water ice and dry ice, so it should deliver far more than it takes away. Mars still has a respectable level of gravity- its escape velocity is like 5 km/s. Those billions or trillions of tons of volatiles in the comet will come to a dead stop in an instant, and then rapidly cool as they expand outward. For a significant amount of carbon dioxide to escape from Mars from thermal heating alone, it must heat up to hundreds or thousands of degrees, and stay at that temperature for a long time. In reality, Mars will quickly cool again. The shockwave will probably be enough to locally blast a portion of the atmosphere into space, but again, that ought to be far outweighed by the increase the comet provides. The mass of the volatiles in a large comet is not insignificant in comparison to the mass of the Martian atmosphere. If the comet were like, 30 km across, it might contain as much CO2 as 10% or more of the Martian atmosphere! AFAIK, the current thinking is that the most damaging factor to the Martian atmosphere is Mar's lack of a magnetic field. Without a magnetic field, it cannot shield its atmosphere from being slowly eroded by the solar wind. Oh and finally, using comet and asteroid impacts to terraform Mars is one of the main terraforming methods that has been proposed...

Not really related, but good news: ESA teaming up with Russia for Mars sample return mission Basically, it looks like they are going to try to drill 2 meters underground, retrieve a soil sample, and return it to Earth. It seems very ambitious to me, considering that neither the ESA or Roskosmos has ever had a successful Mars lander, and heck, Russia has never even had a fully successful Mars mission (the ESA has though). Let is hope that this time, the Russian Mars curse won't strike again... after a string of failures, Russia badly needs a successful interplanetary science mission! And if it actually works... we might finally figure out if there is or was life on Mars. There is the very real prospect Martian life could still alive today, hiding from the radiation underground, and this mission just might bring some back :)

While Lua is better in this case, I think this comparison is slightly more favorable towards triggers than normal. Normally, a mix of triggers AND Lua will handle complex logic either vastly better or infinitely better than triggers alone can, and do so in a way that is easier to understand and trouble shoot. I say infinitely better, because there's so many things that triggers simply can't do that Lua CAN do. For example, how do use triggers to detect if a unit's altitude above ground exceeds a certain value? You can't. However, a fairly simple script will do this: do local unitName = 'Hawg11' local alt = 1000 -- meters local unit = Unit.getByName(unitName) if unit then local pos = unit:getPosition().p local height = land.getHeight({x = pos.x, y = pos.z}) if pos.y - height > alt then return true end end end More examples include line of sight detection, radar simulation, detecting when a specific unit fires a specific weapon, tracking weapon flight and determining where they hit, dynamically ordering groups of air or ground units, detecting when a specific type of unit is in a zone, getting a unit's fuel quantity, getting a unit's life, outputting dynamic messages with like coordinates in them, running logic at faster than 1 time per second, being able to use complex logical statements, getting precise timing, etc etc, etc. None of which is possible at all through triggers. Then there's all the things that are possible to do with both triggers and Lua, and easy to do with Lua, but extremely tedious to do with triggers- things like scoring systems, randomized objectives/missions/groups, detecting multiple units in multiple moving zones. The detection of multiple units in multiple moving zones is what first forced me into using Lua scripting two and a half years ago. I had 18 enemy artillery units (three groups) advancing against 100 friendly units. The 100 friendly units would be under Battle Commander control (back when Battle Commander was going to be a part of DCS: A-10C). The enemy artillery units needed to advance slowly, to stay within range of the friendly units and be able to lay down fire. Well, how many triggers does that require? The only moving zone trigger is Unit in Moving zone. Each of the 18 artillery units needed 100 triggers to detect each friendly unit! That is 1800 triggers total! That is not completely impractical to do, just very time consuming. Then I realized how many fire at points in zones I would have to make to handle the artillery engagement logic- that added like another 1000 triggers to the mission! In the end, I was able to learn Lua, reverse-engineer the scripting engine available at that time (once Swift showed me how to do a _G dump, and I explored some of the Lua files included with the game), and create the same thing through Lua in less time that it would have taken to complete all those triggers! Not only that, the end result worked vastly better than the triggers version would have. Now-a-days, we can just use Mist and accomplish the same action as those 1800 triggers would have done in a single line of Lua. That speaks volumes as to the simplicity of using Lua scripting over triggers for some things. In the end, I feel that triggers are good for simple logic, and for creating a graphical framework from which your Lua logic can run. Most of the time, the best way to do your mission logic will probably be a mix of triggers and Lua, with everything complex being done through Lua.

Apparently, the latest odds put a collision with Mars at 1 in 1250, or 0.08%. It's two weeks old, but Phil Plait (the "Bad Astronomer") has an interesting article on comet Siding Springs here: http://www.slate.com/blogs/bad_astronomy/2013/02/28/mars_impact_the_red_planet_may_get_hit_by_a_comet_in_october_2014.html So apparently, the comet may be as large as FIFTY kilometers. It's also moving faster than solar escape velocity, and backwards around the Sun now too (as compared to the other planets), so the impact with Mars would be at an incredibly fast 56 km/s. So it will become an interstellar wanderer assuming it doesn't hit Mars. Something must have given it a boost in velocity... why can't they run the orbit backwards yet and figure out what that was? :huh: Plait also points out that there would be enough suborbital debris kicked up that it would probably destroy our Martian satellites too. Certainly, if the thing was 50 km in diameter, I wouldn't give anything on Mars much of a chance- this would be one of the most energetic impacts Mars has experienced since the end of the Late Heavy Bombardment. In comparison, using a comet density of 0.6 g/cm^3, if the comet really had a diameter of 50 km and it hit Mars at 56 km/s, it would pack around 300 times the energy of the impact that killed off the dinosaurs here on Earth. Also, I looked it up, and now they think that the comet WON'T cause a meteor storm on Mars, which is confusing to me, because Mars will be DEEP within the coma of the comet. I guess the dust grains get launched off the nucleus at much slower speed than the gas?

One idea I had was to give them home field advantage, some SAMs to help them out (arranged into a crude integrated air defense network), and early warning radars/AWACS to give them GCI. The GCI can be created entirely through scripting- we can give each individual red aircraft continuous BRA to the nearest bandits, if any are in range. The GCI will take into account LOS and the Doppler notch. So, while red is heavily outnumbered, they have a huge SA advantage against any blue aircraft that get within range. In combination with the SAMs, this will mean they will be greatly encouraged to stay within their defensive perimeter, and it will probably force blue fighters to group up and work together in order to survive. The air to ground strikers will need to get in and get out quickly, before red is able to relaunch from their home base, and they will need to group with blue fighters to take out the EWR sites. Alternatively, you could try to sneak in low, using terrain masking to keep yourself hidden from the EWR. F10 allies only view would be enabled to help the Flaming Cliffs people find each other and group up. Possibly, some sort of additional data-link-like feature could be implemented for blue. Anyway, I'm not 100% sure this would be more fun than the current missions, but I do know that at the least, it would be something different. Like I said before, there's nothing necessarily bad with the 104th's missions, except that we've been flying what is essentially the same mission since at least FC2. We need some variety! I'm thinking that between the VTAG server and the 3 squadron server, I could probably set this mission up to be available to the community, but if I do decide to take this route, it will be some time. I've got a lot of things to do- maybe if I can make Graywolf and Grimes excited at the mission idea, we can team up and create it more quickly.

No real surprise there. Clients must be in charge of all the computations involving their own aircraft. What are you supposed to do- expect the host to run like 8 or more realistic flight models simultaneously? Clients would have to wait 150 milliseconds after they apply an input for the server to tell them how much they are allowed to roll? You'd need to be connected over a local network to a Cray supercomputer to make that work. So anyway, in order to optimize the network code, clients just don't send the server data that is unnecessary for the server to know. Since the amount of fuel a client has does not affect anything in the outside world (at least, by default), then it is simply not sent over the network. We'll need ED to make it so client fuel is sent over the network for Unit.getFuel to work on clients. I can't say whether or not this will happen.

I feel that, in most situations, F10 is a cheat. Does that mean you shouldn't use it? That's up to you. Cheating isn't bad per say, unless you are getting an unfair advantage with it in multiplayer. If you're just doing single player, then it's entirely your business how you play the game.

What are you talking about? Autopilot works fine. If there's a problem, this is the first I have heard of it. Have you checked your keyboard settings?

There is an else and and elseif in Lua, but they are not necessary. They are frequently used, but in this case, I gave you just about as simple of a script as I could think of.

Ok, just tested the fixed code, it does in fact work- at least for the single player/host. (I am kinda doubtful of it working in multiplayer, but at least there's a chance.) However, it works so well that it detects what must be some infinitesimal amount of fuel used when I switch on the fuel pumps :doh: So I might suggest the following modification: function getEngineStartedFunc(unitName) local unit = Unit.getByName(unitName) if unit then local startingFuel = unit:getFuel() return function() if unit:isExist() then if unit:getFuel() < startingFuel - 0.005 then return true end end end end end By adjusting that 0.005 to be a smaller number, you can make the engine started condition come true earlier in the startup sequence. However, in the attached test mission, it seems just about perfectly timed- when I tested it, the "engines started" message popped up right as the 2nd engine of my Ka-50 finished spooling up. Engine started test.miz

It makes perfect sense if you drop the assumption that I write perfect code. I wrote that code at work and never had a chance to test it, so it was easy for me to miss a mistake. function getEngineStartedFunc(unitName) local unit = Unit.getByName(unitName) if unit then local startingFuel = unit:getFuel() return function() if unit:isExist() then if unit:getFuel() < startingFuel then return true end end end end end Try the above code- I had forgotten a "then" after one of the "if"s.

Why remake Georgia, which everyone is sick of, if they could just make a whole new combat theater instead? That would seem the more logical course to me, unless large portions are reusable... which they might be.

I do remember someone saying that 1.2.3 would not be released until the Sun started swelling into a red giant; maybe they were right.

Yes, it's possible to do this with a script, so if you grow dissatisfied with your solution, let us know.

Last I checked, the only way to create synchronized TOTs for clients was to make them already started at mission start, and have all clients already in the pit. You see, the TOT counter for clients is relative to client start- CDU start specifically, I think (I'm not completely certain on that what exact event determines waypoint timing). For example, if in the mission editor, the TOT for a waypoint is 1800 seconds after mission start, then when you get in the pit, and finally get your CDU booted up, then the TOT for that waypoint will be 1800 seconds after that point. Really sucks for coordinated strikes. I discovered this drawback when I had a mission where the players needed to arrive at the target area just moments after cruise missiles blasted away the air defenses, which happened at a very specific time in the mission. That said, you could "fake" it with script output messages to clients- but that would be pretty lame. Instead of looking at the HUD for their desired speed and TOS, they look at the trigger text box... yea, lame. Anyone know if ED has made any improvements in this department yet? If not, I think they will have to for a fast mover module. A-10s generally are not part of big packages that have to rally or coordinate with other flights by arriving over specific waypoints at specific times, but if you are simulating a fast mover, which very frequently is a part of a multiflight package, TOS must behave correctly.

Back in BS 1.0.1, I investigated the possibility of making a mission where you fired illumination rockets for Su-25As. It worked. Once I put illumination rockets on the targets, the AI engaged them, and continued to engage as long as I kept the targets lit up. So it's a workable concept. Similarly, you should also be able to set one group of AI to drop illumination bombs, while another group does the actual engagement. That said, it's been a while since 1.0.1, and while the general direction of DCS is forward towards more features and more advanced behavior, it can always go backwards in a selected area.

:doh: Great thinking! I was going to say the cockpit argument trigger method, but of course, 1.2.3. adds the Unit.getFuel Lua function. I haven't tested Unit.getFuel on multiplayer clients though. I wonder if it works for them? Regardless, cockpit argument triggers will not work on multiplayer clients either, so Unit.getFuel remains the best, and easiest method to do this. Unfortunately, you cannot do this with just one time sample, and you cannot tell the difference between deliberate defueling and actual engine operation, unless you want watch a few samples of fuel flow to determine if it is normal fuel flow or ground crew removing fuel, and that increases the complexity of the script and requires you to determine what the normal fuel flow actually is. Anyway, building on Bushmanni's idea, I think this script will work (though, like I said, I don't know if it operates correctly on MP clients): Run this script on mission start: function getEngineStartedFunc(unitName) local unit = Unit.getByName(unitName) if unit then local startingFuel = unit:getFuel() return function() if unit:isExist() if unit:getFuel() < startingFuel then return true end end end end end This makes the global function, "getEngineStartedFunc". Now, every time a unit whose engine start you want to detect is spawned, do this script: Hawg11Started = getEngineStartedFunc('Hawg11') Where in this case, the unit's name is "Hawg11". Now, in a Lua expression trigger condition, do this script: return Hawg11Started() Your Lua Expression trigger condition should go true when the unit named "Hawg11" starts its engines.

In your ideal system, how do you prevent people from just changing their digitalcombatsimulator.com login and thus changing their UCID? UCID needs to be associated in some way with the activation keys if UCID is to be the kind of hard-set, unique identifier that can be used to ban trouble makers or track multiplayer statistics. Should each activation key have its own, unique UCID? Again no- how do you determine which key to use? Then everyone could have like 5 UCIDs, depending on which modules they have installed, and which one is "dominant". It does seem like the best solution to the dilemma is to associate the UCID with the digitalcombatsimulator.com login account and activation keys so that all activation keys purchased under the same account result in the same UCID. Again, I don't know how the system works actually, but this is the best way I can think of. The "which UCID has dominance?" problem is then just reduced to the rare instances of people simultaneously using modules purchased by two or more digitalcombatsimulator.com accounts. You might be able to fix the problem with a support ticket.