Gizmata

Thank you for your response, that was helpful.

I tried this Sunday and again today, and could not locate where in the DSMS or Profile pages for the GBU-54 to change the code. I see the code in the center of the profile menu for the 54, but there wasn't an option to change it. Where should I be looking? I am not new to the A10, just haven't used the 54 much since it can't triple rack so it wasn't my first choice.

I would like to see this option added as well. I create portable scripts to spawn static objects on certain maps to add to the ambience, but currently they aren't a surprise and litter the map with icons. Thanks

My crash was with the LIGHTING pod on station 4 each time, my wingman had it on station 5, we both had the CTD when switching on the LTD/R. His second crash he believe he tried to VVSLV the TGP when it CTD.

Same issue on Multi. As soon as I clicked the arm switch the game hard crashed multiple times (was in the air, master arm, A2G, FLIR page active (probably SOI). I also saw a weird issue using old saved loadouts, so I created a new load from "empty" and saved that, but it still crashed the game when I armed the laser. (the other oddity was MK83/84 were not giving MFUS options, but showing EFUS in the stores page when using an old saved loadout, but worked fine when built from scratch in the rearm menu). add: I use a unique code, not 1688, and didn't get to change it in the FLIR page before the crash.

My experience is the target point moves when the targeting pod must flip the camera over. So, I keep my nose above the target during my turn back towards a target and it never must flip which keeps the target point from moving/walking. If I make a hard turn and my nose (probably the boresite of the TGB in reality) ends up below my target area and I pull my nose up to fly level again, that is when the camera flips and the target point moves. No idea if this is how it works in real life, but it took me months to figure out what caused the move as it happened seemingly randomly.

Since a recent patch, the below trigger stopped making a cone shape of flares, and all the flares fire the same direction as seen in the screenshot. This was working well for a long time, as it makes a cone shape of fireworks, but not anymore. null It is pretty obvious that the bearing value is being ignored now, and is a recent change/bug.null

I noticed this as well recently in the A10Cii. The trim hat on the Emergency Flight Controls panel pulls the stick back when you push the hat forward which should push the nose down. Simply click the switch next to the hat so its not in the forward position (Emergency Override position), and click it either up or down and watch the stick "trim" the opposite direction as it should.

Great suggestion, that worked nicely and is faster.

Thanks for figuring that out. I spent hours frustrated with no progress until I found your post. It is not fun having to boot DCS World for every code change, but it solves the problem.

I have a custom designed script that kept "drones" (S3-B) flying around, that began crashing the server recently due to reading a "nil" value for a destroyed unit/group health. I tracked them every few seconds and queried the health of each aircraft and this worked fine for the past few years. I added some dumps to my log to see what the aircraft table looked like, and it was full of data before the plane got hit and was missing afterwards, as though the plane never had existed. To work around it, the order of testing would need to change, to assume that if the unit/group doesn't exist, then it has been destroyed. I just don't know all the places I have script snips that can't be used without rework/retest. I only tested the single unit S3-B groups, so I don't know how if other vehicle types are removed from tracking the same way, or if this is due to it being a single unit group.

How do I hide objects in the live F10 map? A couple of patches ago items like Airshow Cones and Big Smokes have an icon that show up on the live F10 in game map for everyone. Is there a way to suppress them, so the map is not cluttered with them?

Looking at your lua file I noticed something: ["psi"] = 1.6651584930974, ["heading"] = -1.6651584930974, Which looked too similar to be a coincidence,. From a quick search I found "delta_psi = , -- aspect angle rad" on https://wiki.hoggitworld.com/view/DCS_Export_Script which explained nothing. So, some quick testing and it seems that setting the psi value, sets the spawn direction. psi = 0 = north, pi = south, 1/2 pi = west, 1.5pi = east. Yes this is 90 degrees out of phase of normal heading radians where 0 would be east and pi would be west. I never wondered what psi was used for, but I guess I have some idea of it now. Thanks for your help.

Not a fix. I moved the waypont to the west by decreasing the Y position by 10000, and it still spawned flying east but turned slowly to fly west. Thanks for the suggestion.

I can spawn a refueling tanker easy enough, but it ignores the heading field and always seems to spawn flying east. I have tried it with a couple different airplanes and groups, but they all fly east to begin and then turn towards the first waypoint. What am I missing, or is this a bug? Included is the spawn script for the KC135 which is just the group table where I hard coded the heading to 3.14155 which should be west. The mission file is simply that script being called at time > 2. KC135_Table_Spawn.txt Testing_Tanker_Script.miz

I saw this once on Syria so far (A10CII), and my friends were watching my perfectly smooth approach to land when the nose just went to the stars with no input or changes from me. I tried the emergency disconnect of the elevators which didn't help. I tried the manual reversion switch, and after switching it back to normal, the plane flew just fine again. Not sure it helped, and this was 40-50 seconds after the problem began as I was trying and checking for any indication of what was wrong (no caution lights). However, when it happened, I had full forward on the stick and the nose would barely descend. I put flaps up and that didn't help as I recall. It was also a 1.5 hour long mission I didn't save a track of as it happened at the very end. It was a liberation mission on Persian Gulf, landing on 31L at Al Dhafra.

Looking at the A10C manual, quoted below, nothing says I must use the TMS to get the seeker to try to lock. I haven't used TMS in launching over 1000 mavericks in the past 2 years, until 2.7 came out. 4. Slew the tracking gate over the target and release the slew control. When you release, the Maverick will attempt to lock onto the center of mass of a target it detects inside the tracking gate. If it cannot lock on to a target, after a few seconds, the seeker will go into Break Lock mode and the crosshairs will expand out to the edges of the display. To try to lock again, slew the tracking gate back on to the target and release the slew control. Depending on the range to target and the size of the target, this may take a few tries. 6. In addition to the slew and release method of locking a target, you may also keep the tracking gate in boresight and fly to place the tracking gate over the target and then press TMS Forward Short to initiate a lock. You can also do this when the tracking gate has been moved over a target while in a slave state (such as slaving your Maverick to the SPI). Maybe they updated the A10 to work more realistic, it just seem wrong that the seekers won't even try to lock with me touching nothing besides the china hat and slew.

I found a work around. TMS forward short will make it try to lock when it doesn't even seem to be trying. I hadn't needed to use TMS forward, to lock my targets before, so I didn't know that "feature" was added. I always just used the slew to put the crosshair on a target and it would lock, but with 2.7 it seems to get into a mode where it doesn't try. Also for anyone reading that missed it, TMS aft will break Maverick lock now, which should be helpful. TGP targeting should be easier as well as once you slew the Maverick to the target point you don't need to bump the slew to get it to lock, just TMS forward short. I still think something is off with the Maverick as it gets confused and won't target like it did prior to 2.7.

I ran it again and created a track. The first 65D (right rack) locked just fine, but the second (right rack) would not lock on anything. I deselected the right rack and the left side rack locked fine, went back to the right rack and it still would not lock. I then shut down the EO and started it again, and it locked fine. 65D fails to lock until reset.trk

I have been flying the A10 for 2 years and am well versed on using the 65D maverick. Since 2.7, some seekers refuse to lock on anything, however after cycling the EO power, they return to function. Typically the first missile will lock fine, but switching to the second rack (carrying 3 per side) will result in a non-locking missile. Included test mission file which recreates what I saw one Syria map and a different Caucuses map Test mission is on Caucuses using the A10CII with 3x 65D on each side. Active pause (Left Windows + Left Shift + Pause) shortly after spawn with ground targets ~3 miles ahead. Target and launch all on right wing, or fire one from right wing, then deactivate the right wing station in the DSMS, the Maverick camera will reset to the left wing missile and the new active missile won't lock unless you cycle EO power (3 minutes). China Hat zoom level didn't make any difference. Boat switch was forward. I haven't seen anything like this in 2 years, so hopefully I am not the only one seeing this problem. A10_Maverick_Test_04.miz