FishBike

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?

What's the weather setup in the multiplayer missions where this is happening? Specifically, the temperature? If the temperature is significantly colder than standard, it would be expected that the barometric altimeter would read higher than actual altitude, and this is not corrected for by the altimeter setting. At least that is what happens in the real world, so I'm wondering if that is modelled in the sim too. In which case perhaps the TAD info is driven by the altitude from the EGI rather than the barometric altimeter, and so it's not affected by the temperature? Just a theory that could use some testing as I have seen similar mismatch between baro alt and waypoint alt in missions I've design with cold weather.

I think I might have stumbled onto the trick to getting this to work. Today I tried changing all my AI flights' waypoints from locked time to locked speed, and still they ignored the required speeds. Except for the four planes I intend to turn into player-controlled ones. Each of those has only one plane in the flight, and they seem to be working properly. So I tried changing one of my other flights to a single plane and it worked! It's kind of looking like their attempts to maintain formation cause them to ignore the times/speeds in the flight plan. I'll redo the whole mission as single-aircraft flights and see what happens, but I have a strong feeling it's going to work.

I'm working on a mission with several flights of AI aircraft. For some reason, I'm having a heck of a time getting them to arrive at their assigned waypoints along their route at the time specified in the mission editor. Just wondering if there is some trick to it that I'm missing, beyond giving them a route where the ETA of some waypoints is locked? In all the different ways I've tried it, there have been no red indications on any of the waypoints to indicate an invalid flight plan, and the calculated speeds between waypoints seem like they're well within the capabilities of the aircraft. For comparison I have one flight assigned to "escort" duty and they are quite happy to go much faster to catch up with the planes they're supposed to escort.

To save you some time, here's a copy of my X-52 Pro profile. It maps the mini-stick to the HOTAS slew keyboard commands, and leaves everything else assignable through the controls setup in DCS World. As the previous poster mentioned, you do also have to disable the "clutch" button in the Saitek control panel before you will be able to map the (i) button in-game. DCS A-10C-Saitek X52 Pro-FishBike.zip

Yeah, StarTrekMike and I fired up a mission right after installing today's update to see if it fixed the problem, and unfortunately it did not. I'm the one running the server in this case, and it didn't crash on my computer. I don't know if there's any information from the server end of things that would be helpful for diagnosing this, but if there is, I can post it.