BrassEm

Easy as. Start with the basics like; do you know how to code missions for DCS world? ChatGPT said: Absolutely—I've worked with DCS World mission editing and scripting quite a bit. and go from there. Have fun! asked; give me a working .miz chatgtp said; Here is your working single-player mission file for DCS World on the Caucasus map: Download Simple_A10_Attack.miz Contents: Player Aircraft: A-10C II at Kutaisi (cold start, player controlled) Enemy Vehicles: BTR-80s placed nearby as ground targets No advanced scripting yet — just a basic setup to fly and attack NOTE: Ask "do you know about..." the thing you want to add to the mission to get detailed help. Ask for the FULL mission code as it will keep giving you code snippets. Start with the very basics and add one "feature" at a time to slowly build up the mission. (As with actual hand coding )

I don't think using MOD's is a valid way of testing for this fault. All tests should be done with vanilla ED files and NO MOD's installed at all. I do appreciate that you have taken the time to investigate and further highlight this major problem for carrier operations with motion, but It complicates the issue when MOD's become involved.

@Tea-Pig Sorry to hear your having issues there on the CVN-73. Thanks for posting the pics and files as it really helps. I haven't tried the A-4 yet. I will install it and try it out, but this will take a few days before I can get to that stage. (Once you get familiar with the F-18 I hope you will find that it is a very capable airframe.) NOTE: While looking at the readme documentation for the A4 MOD to install: #### Known Bugs and Incompatibilities - Pilot occasionally blacks out when throttling up to hook up to catapult on SuperCarrier. <<<<<<<<<<< Maybe high g load shaking perhaps @hannibal Things are really hectic now that I can start doing all the things I had planned for carrier ops, including at some stage, the "holy grail" of hooking into the stall effect for motion output. Great video (again!) that you posted the other day too!

Very nice setup there mate! Does your motion controller or motion interface software have a spike filter at all? If not then you would need to look at the telemetry from DCS and monitor/limit excess changes of rates there.

G'day Craig, Great work with adding motion to your rig. You won't look back if you've flown without motion (Ghosting) before. I've only just found out about SimHub and it ticks so many boxes. I too am transferring my rig to SimHub and looking at profiles for DCS. It would be good if there was a Forum for this where we can have a repository for DCS profiles and discussions. (I hate Discord.) At this time the only profile I have found is on the SimHub discord channel under "motion-profiles-sharing" for an F-18 (by ZeroCool). I have tested it with a replay and it seems to work okay. I have not flown it actual yet.

G'day Bojanglez, It would appear so. I have flown for several days with many cat shots without issue on the George Washington. I have not tried any other CVN yet. I am just really enjoying jumping in, getting to the cat and go without issues. It is not the answer as the CVN's are still broken, but at least we get to fly properly (and safely) on one.

G'day Hannibal, So many thanks to your findings, I have been catching up on much lost time. It is such a relief to hook up without fear of the rig breaking shakes. I have just been flying the Washington with all sorts of stupid alignments for the shot, and it all works good. I understand that the Forrestal will be different because that is a HeatBlur product, but I don't understand why 3 out of the 5 ED carriers are broken. From a programmers point of view they should all be accessing the same code? If the code is supposed to be the same for all, then it is a simple matter of comparing code and looking for the differences. I am sure it will be a matter of a wrong character typed in, or missing in the code, somewhere when integrating it into the last 3 carrier's. So I believe at this point in time for us motion rig users that use surge, the following carriers are broken and out of bounds until fixed. CVN-71 Theodore Roosevelt CVN-74 John C Stennis CVN-75 Harry S. Truman I have included a graph of a good working cat shot with surge and nose gear suspension deflection. The surge has been blunted with a 200hz notch filter in the export.lua in my futile attempt to remove the shakes. I can take it out now and get a crisper launch profile.

@hannibal I've sent you a PM.

It is getting up to 5 years since I have not been able to fly carrier ops because of this issue. Anyone with a full motion rig will have to address this problem that should not be there.

Great video! (And motion rigs!) Thanks for adding your voice to the issue. You mention about the oscillations around 15:27. The commanded oscillations are extreme and intermittent, and not part of any simulated event. You may be able to filter them to reduce the problem but at the expense of motion fidelity, negating the whole point.

I am very sorry to hear about the damage. I have the pause button on the throttle where my thumb usually sits so I can activate it in an instant. But that was after I was bitten as well. I have E-stops fitted as part of the primary build. I understand your concerns as a missile hit is sometimes impossible to predict. I am not aware of what motion controller you are using but I hope that there is some spike filter feature that you could investigate? It may be possible to put some sort of spike filter into the export.lua but that would need more research. Definitely need it for the ejection sequence for sure. Note that the filter does not work for the intermittent continuous 7.5g high frequency oscillation commanded by broken game code. (I have spike filters on my motion controllers.)

BrassEm

Same issue????

I bet you THIS reported problem has not fixed this update. Call it a hunch. It would appear that the shuttle tension algorithm may be borked. Just another hunch...

4 Years and another Major Supercarrier update and still not fixed. As previously described. --Accelerations: accel = LoGetAccelerationUnits() accel_longitudinal = accel.x <<<<<<<<<< local surge = accel.x Export.zip

All good motion controllers should have an emergency stop. It is a total emersion breaker to implement the stop at best. (And the 7.5g oscillation doesn't always happen every launch. And may, or may not, stop after starting.) Unfortunately the DCS program is calculating a wildly incorrect physical moment during the cat launch sequence due to a fault in program logic. We are at the mercy of Eagle Dynamics programmers for a fix.

I've disable outputting motion data for about 4 seconds at the start of a mission by adding some code to the export.lua file. (Extracted from my full export.lua) local t = LoGetModelTime() if t >= 4.0 then -- Allow 4 seconds for aircraft to settle on ground after loading in before outputting motion. -- output code here end

I am sure that if more motion users were to try this shuttle hookup setup, they would feel this intermittent abnormality and report it if they knew that it is not being introduced by a fault with their motion rig. After trying to come to terms with this problem, I believe that there is certain out of field parameters, or a combination, that trigger this feedback problem. And I am sure there are many mass, velocity, inertia and position parameters being tested for. There is obviously a software routine that ensures that the aircraft is lined up to suitable parameters for a successful cat shot. This software routine will, and does move the aircraft to realign it for the cat shot if the aircraft is out of position. I have seen the aircraft slide into position. However the oscillations do not always occur, so the parameters tested for in this routine that are being corrected for, are met most of the time, and only a specific set of parameter conditions will induce the oscillations. Just throwing this out there. If for example the stationary aircraft is a large distance away from the correct shuttle hookup position, it has gone forward and past the correct position. The shuttle hookup routine moves the aircraft backwards into position, but mass and inertia is being calculated in the shuttle hookup routine. The move is so great that the calculated inertia of the aircraft overshoots the position of the aircraft nosewheel away past the desired shuttle hookup position. The routine should test to see if its move is satisfactory, which it is not, it has overshot backwards. So it does another calculation to correct the overshoot and move it forward. Inertia calculations do their thing and the aircraft overshoots in the forward direction. So the routine hunts backwards and forwards to try and put the aircraft into the right position. Now imagine if the aircraft had some added inertia by moving forward into the shuttle position when the routine is started. If friction is being calculated then it eventually may dampen the overshooting. A fix may be not to calculate inertia to influence the aircraft positioning in the shuttle hookup routine. @Bojanglez The "Export Grapher" is a program I am writing in Visual Studio C# to help with understanding the DCS export values, as using Excel spreadsheets was way too clunky. Unfortunately it is not ready for distribution just yet and has not been beta tested also. I can understand your reluctance to test this problem as some motion rigs may not be that robust. Does ED really want to visually see our motion rigs being damaged before they fix this problem? We are talking about a raw high frequency, full amplitude swing 7.5g motion. What would that do to a real plane? Anyways, just make sure your values are turned way down, (but then it wouldn't look as drastic as it is, would it?). @Swson Thanks for helping by reporting your valuable observations!

I got excited... Wrong shake. Still there.... DCS f-18 Problem 20231119.zip

Many thanks BIGNEWY. The problem still exists. @Bojanglez Thank you for the follow up too! - After 2 years! New video of Shudder. @ 1:37 The whole Aircraft is shuffled across to align up. There is some shudder then. Once the launch bar goes over the shuttle, that is when the major 7g shudder occurs. See the graphs. Surge being the offender shown in red. The ground motion is usually amplified to give it some better fidelity but with this intermittent high g shudder, that is not feasible. dcs.log Export.log Export.lua

No Worries Gorn_GER, I appreciate your efforts in trying to help me. I had no inkling that the NeckSaver was the issue. It was not even running to my knowledge when I had this problem with DCS.

Many Thanks Shug Ninx, That fixed it. I was running beta5a of VRNeckSafer. I didn't have any issues running other VR software. I have since found that the normal DCS.exe was okay but the mt version suffered from the NeckSaver issue. Trouble is NeckSaver lives up to its name... Also DCS on the command bar was showing a question mark over it when bugged.

Cleared environment and reset home. No change. All the other VR titles work okay?????

G'day, I fired up DCS to do some motion testing again and found that I could not use the headset. On my screen I get the image posted, which is the startup view in the hangar if I were turned completely 180° around to the opposite direction. The view in the actual headset is now this, but also inverted 180° upside down as well??? I've uploaded the Nvidia drivers and repaired the DCS installation without a fix? (And no, I am not putting the headset on the wrong way... )

RAF No. 109 Squadron HS-F "Grim Reaper" Download Here. Download the Fix for the Outer Wings problems here. This skin is a representation of the bomber version of the Mk IV mosquito flown by no.109 Squadron of the RAF, 1943. This aircraft is coded HS-F, serial number DK333 with the distinctive "Grim Reaper" nose art. It was flown by Flying Officers Harry B Stephens and Frank Ruskell DFC, From 109 Squadron, No 8 Group(PFF) based at RAF Wyton in Jan. 1943. At this time this skin is not Bort Number compatible.