FishBike

You have it right. The mission editor correctly shows the physical location that stores will be loaded on, but the numbers shown there do not match the station numbers selected from the cockpit.

I don't know about the MiG-21 specifically, but it's normal for transonic and supersonic aircraft to need significant nose-up trim as they accelerate up to and past Mach 1. There's even a name for this: Mach tuck.

The bug seems to be that the oxygen is consumed too quickly. So you can fly at high altitude for a little while, but must keep an eye on the oxygen gauge and return to low altitude before it's all gone.

I'm not sure if this is a bug. When shutting down at the end of a flight, if I turn off the battery switch first, and the try to turn off the fuel pumps, they stay on. If I turn the battery switch back on again, then I can turn off the fuel pumps. It seems like the pumps should turn off when the battery is turned off, even if the pump switches are still on.

This happens to me on every flight where I stay at 30,000 feet long enough. I'm sure it's meant to be simulating pitot icing, but it happens even with pitot heat on (unless I am not turning it on correctly). It also causes the vertical speed indicator to read 0, which doesn't seem right--that instrument should work based on the static system only. The altimeter, that also works on the static system, continues to function normally.

That's normal, it becomes quite unstable in roll as you approach Mach 1.

I've done a few flights lately that involved getting the Sabre up to fairly high altitudes (30,000+ feet) and have consistently run into what looks like a problem with the pitot/static system. Symptoms include: the airspeed indicator getting stuck at its current reading, the machmeter reading much higher than it should (Mach 1.2) and the vertical speed indicator getting stuck at zero. The altimeter still works fine, though. These problems go away after returning to lower altitudes for a while. I'd call it pitot icing except for a couple of things. I have pitot heat ON when this happens, and the vertical speed indicator shouldn't be affected by that. Any thoughts what this is? e.g. pilot error combined with a bug? Just pilot error? Just a bug?

I went into the folder with all the F-86 cockpit sounds in it. This sound comes from "TransferPump.wav" so it would seem to be the sound of a fuel transfer pump.

It has been a few years since I played with the Level D 767 add-on for FSX, but the big difference compared to the A-10C is the sophistication of the autopilot and flight management system. With the 767 FMS you can program in a complete flight plan, but then it will interact with the autopilot to fly it for you with almost no manual input. It will figure out where your top-of-descent needs to be for a perfect landing approach. It will figure out the most efficient speed to fly at based on a "cost index" you give it. The 767 autopilot has a ton of different modes as well. Not just holding altitude, heading, and airspeed, but fancy stuff like the "flight level change" button that will make an altitude change as quickly as possible using full throttle (for climb) or idle thrust (for descent) while maintaining your selected airspeed. Oddly I felt quite at home the first few times running through the startup sequency for the A-10C as it has some similarities. It was strange to realize the 767 is faster and climbs better, though!

Myself and two friends flew a mission last night which involved a lot of time flying in icing conditions. The mission uses the template "snowstorm" weather with the winds removed, and we spent all of it within a few hundred feet of the ground. On the way back to our landing field after quite some time in those conditions (close to an hour I think), all three of us lost airspeed indication within a few minutes of each other. The airspeed indicator acted like an altimeter instead, just as you would expect from pitot icing. However, all three of us confirmed we had pitot heat switched on. I had the same thing happen at about the same place when I was testing the mission the day before, too. I'm not sure if this is a bug, pilot error, or something working the way it's supposed to be. Is there some way we can diagnose what happened? Is there a total time limit for how long pitot heat can be on? From testing the mission earlier, I know the same problem will happen pretty quickly if pitot heat is off.

I'm having a very difficult time landing the Mi-8 on unpaved surfaces. What seems to happen is no matter how little sideways motion I have, and how gently I touch down, it will suddenly bounce violently after the wheels touch down. Often one side does this before the other, tipping the helicopter over rather quickly. When landing on a paved surface, it doesn't seem to do that. Is this a problem with pilot technique? A bug? The Mi-8 should not be landed on dirt?

Has anybody noticed anything funky with headings in this latest patch? I have a mission I've been using for a while and now the headings generated by scripting are suddenly off by 180 degrees, and so is the radio compass indicator at startup. The standby magnetic compass is right though. This is in the Huey. Now it could be I broke something in my script trying to fix it for the previous patch. And at the same time there's been a change in the startup procedure where you have to set the RCI to the correct heading now. But it seems odd this all happened right after applying the Aug 2nd patch.

I just finished building something like this for a single smoke colour. I'm not sure I understand exactly what you want to do though. It sounds like there will be something that happens in the mission to make the smoke appear. Will all three colours appear at the same time, or are there three separate events in the mission that will each make one colour appear?

Has anyone been able to get this to work? I figured out that my expression conditions were gone, so triggers that use them fire all the time. I put in a LUA PREDICATE condition instead but am unable to get the trigger to fire at all with it now. Even a predicate condition of true, or return true, doesn't seem to make it fire. Has the syntax changed as well compared to what EXPRESSION wanted? Edit: so it appears the LUA PREDICATE condition doesn't work at the moment. See http://forums.eagle.ru/showthread.php?t=110430

That is one way I've done it. Another is to use trigger.action.outText to display text on the screen, which makes it easier to tell when in the mission something happened.

I'm trying to build a mission where a large number of tanks (e.g. a couple of hundred) will fight each other. The idea is that the enemy will win the battle unless player-controlled aircraft effectively take out lots of enemy tanks. It's sort of an experiment to see if the game can handle a large number of AI ground units. Performance is actually really good for the initial part of the mission. But once the fighting between tanks starts, frame rates become really bad (e.g. approaching 1 fps), but only when looking at the AI tanks. Look away from them and performance remains very good. My question is, how can I determine which effect is causing the severe frame rate loss? Is it the smoke, the fire, the explosions, the tanks shells and missiles? I am happy to make modifications to various .lua files to scale back or get rid of visual effects to make this playable, but is there a summary somewhere of all the things I could disable and where?

I find the best way to do this is set everything up for the first player in the flight, then just copy and paste that unit to create the second player's flight. You should only need to do a couple of things to the second player's flight like correcting the name and callsign. Do this while zoomed in all the way and with the mouse pointer close to the first unit (otherwise all the waypoints etc for the second player will be created with a large offset from the first).

First of all, thanks for SCT and MIST! Unlike a lot of fancy things I've tried to do with various mission editors, these worked perfectly the first time I tried them. I'm using them to build some simple missions now where there is a fair bit of random variability, e.g. a patrol mission where you don't know exactly what you will encounter or where. I found it useful to add a 'disableRoads' parameter to mist.groupToRandomZone, which it can then pass along to the groupToRandomPoint function that it eventually calls. It was easy enough for me to add that myself, but thought it might make a good addition to the official code.

I'm helping a friend with some mission building, and one thing we'd like to have is a trigger that fires when a specific airbase has been killed. So far I'm not having any luck getting at this information via scripting. I'm pretty sure in my test mission, the airbase is actually being killed, because it's reported as dead in the debriefing. Am I missing an easy way to determine if an airbase is alive or dead? Or do I need to use event handlers to catch all dead objects and see if the ID is the one for the Airfield (or use MIST to do the equivalent of this)? Here's what I've looked at so far: The Airbase class is derived from CoalitionObject, which is derived from Object. Object has an isExist() function, but this seems to return true even after the airbase has been killed. Object.Desc contains a life value, but this seems to be the initial life points of the Airbase and stays at 1000 all the time. CoalitionObject only adds coalition and country data to Object. Airbase only adds a category to CoalitionObject. So no new data items are added that could be checked. Unit has a getLife() function that returns the current life points of a Unit, but Airbase is not derived from Unit. Airbase does add a getUnit() function, but apparently that is only for ships (carriers).

I have a mission I've been working on where the winds are set at 0 but the turbulence is 60 (which gets divided by 10 to give 6 m/s). It's quite noticeable but maybe not what people think of as "turbulence". It's more like wind gusts, and they do indeed get lighter and then disappear altogether with increasing altitude.

I don't know if it was part of an update, but I wouldn't consider it a bug. CEP for GBU-31 is 13m (so 50% of JDAMs dropped would land within 13m of the target). That's very good compared to unguided bombs, but not good enough to score direct hits on tanks. If you want to hit tanks fairly reliably, you would need something like a laser-guided bomb (CEP of about 1m for a GBU-12) instead. And with those you can hit moving tanks as well.

I had some success today with scripting inside the mission file to randomize the dynamic weather. This required changing a single line of code in each of two script files that come with DCS World, to open up access to the math.random() function in the environment where the mission script file runs. Anyway, one problem I ended up with is weather that is a bit too severe. For example, the test flight I just did ended up with me landing into a 135-knot headwind! The question, then, is how to set the various parameters MadTommy listed above to avoid creating such extreme winds. Is it a matter of too much pressure excess? Too much rotation? Weather systems too close together?

Curious what the TGP IR fix refers to. Something with the FLIR, or the IR pointer, or...?

I made a startup checklist of my own, originally with the goal of getting the INS alignment started as early as possible and then getting as much as possible done before it completes. I did a lot of work on it since the first version, adding more items and moving things around so it flows better. Friends and I use it every time and it's still satisfying everytime we "beat" the INS alignment and end up having to wait for it to complete.

Just searching through the manual for more info on this, and found the description of the altitude readout on the HUD might be relevant: Barometric Altitude. The altitude display is in feet and is displayed up to 5 digits. The barometric altitude range is -2,000 to 38,000 feet and is displayed to the nearest 10 feet. In NAV and Air-to-Air modes, the display is the uncorrected CADC barometric altitude. The displayed altitude in these modes should be the same as the cockpit altimeter. In GUNS, CCIP, and CCRP Modes, the displayed altitude is corrected by LASTE for installation errors, non-standard temperatures, and non-standard pressures. Does the altitude shown on your HUD change to match what's showing up on the TAD if you (for example) go into GUNS master mode?