BrassEm

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.

RAAF No. 464 Squadron SB-E 1943 Download Here. Download the Fix for the Outer Wings problems here. This skin is a representation of the Fighter Bomber version of the Mk IV mosquito flown by no. 464 Squadron of the RAAF, 1943. This aircraft is coded SB-E, serial number HX901. Photos of the aircraft in this squadron show that the exhaust shrouds must have been removed at some time and they have left the aluminium underneath it unpainted. A blank texture and a description.lua has also been included in the zip for use with the Bort Number system. (Copying or referencing to the rest of the SB-E skin files required.)

RAF No. 105 Squadron GB-C 1942 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. 105 Squadron of the RAF, 1942. This aircraft is coded GB-C, serial number DZ372. It is an example of the early version of camouflage used by the RAF. A blank texture and a description.lua has also been included in the zip for use with the Bort Number system. (Copying or referencing to the rest of the GB-C skin files required.)

For those who are having trouble painting those pesky hinges on the nose, The multipart hinges are in the Mosquito_guns_2_DIFF.dds texture as highlighted in Red. Cheers,

To help test out your skins in ModelViewer, You can set the custom arg values to your needs in description.lua or with the ModelViewer Arg dialog box. Cheers, custom_args = { -- Bort Numbers MMM NNSSS [445] = -1.0; -- Blank [443] = -1.0; [444] = -1.0; [481] = -1.0; [482] = -1.0; [442] = -1.0; [31] = -1.0; [32] = -1.0; -- OTHER [0] = 0.0; -- 0.0 Tail Wheel Extension [1] = 0.0; -- 0.0 Tail Wheel Suspension [2] = 0.0; -- 0.0 Tail Wheel Direction [3] = 0.0; -- 0.0 Landing Gear RHS [4] = 0.0; -- 0.0 Landing Gear Suspension RHS [5] = 0.0; -- 0.0 Landing Gear LHS [6] = 0.0; -- 0.0 Landing Gear Suspension LHS [9] = 0.0; -- 0.0 Flaps RHS [10] = 0.0; -- 0.0 Flaps LHS [11] = 0.0; -- 0.0 Aileron RHS [12] = 0.0; -- 0.0 Aileron LHS [15] = 0.0; -- 0.0 Elevator [17] = 0.0; -- 0.0 Rudder [23] = 0.0; -- 0.0 Wheel Chocks [26] = 0.0; -- 0.0 Bomb Bay Doors [38] = 0.0; -- 0.0 Entry Door [50] = 0.0; -- 0.0 Pilots Visible [190] = 0.0; -- 0.0 Port Nav Light [191] = 0.0; -- 0.0 Starboard Nav Light [192] = 0.0; -- 0.0 Tail Nav Light [193] = 0.0; -- 0.0 Nose Nav Light [196] = 0.0; -- 0.0 Port Aileron Light [197] = 0.0; -- 0.0 Starboard Aileron Light [200] = 0.0; -- 0.0 Identification Light RED [201] = 0.0; -- 0.0 Identification Light GREEN [202] = 0.0; -- 0.0 Identification Light AMBER [203] = 0.0; -- 0.0 Both Aileron Identification Lights - Multiple Colours "Smelted Lamp"? [311] = 0.0; -- 0.0 Bomb Rack LHS [312] = 0.0; -- 0.0 Rocket Rack LHS [317] = 0.0; -- 0.0 Bomb Rack RHS [318] = 0.0; -- 0.0 Rocket Rack RHS [348] = 0.0; -- 0.0 Cockpit Window LHS [349] = 0.0; -- 0.0 Cockpit Window RHS [426] = 0.0; -- 0.0 Weapons 20mm Cannons Visible [427] = 0.0; -- 0.0 Weapons Machine Guns Visible [428] = 0.0; -- 0.0 Weapon Access Panels Open/Closed [413] = 0.0; -- 0.0 Propellor Pitch LHS [414] = 0.0; -- 0.0 Propellor Pitch RHS [475] = 0.0; -- 0.1 Propellor Rotating LHS [476] = 0.0; -- 0.1 Propellor Rotating RHS }

Just a heads up for skinners. The RAF top roundels in the template may be a little... goofy.

Thanks for that Micarra, I can confirm that the file I have is exactly the same as yours. So reverting to default should have the same behaviour but it does not. Must be something after the loading that is corrupting/overwriting the behaviour. Thanks again!

Thanks Miccara, Cleared and reset both Combined Arms and General mouse assignments. - Didn't work. I believe resetting back to default refers to C:\Program Files\Eagle Dynamics\DCS World OpenBeta\Config\Input\Aircrafts\Default\mouse\default.lua There is nothing about; Rotate Turret - a2033cdnil Turn left/right - a1664cdnil Turret Elevation - a2034cdnil Looks like a will have to raise a ticket? What is the contents of your default.lua? Thanks,