Jump to content

BrassEm

Members
  • Posts

    243
  • Joined

  • Last visited

Everything posted by BrassEm

  1. 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!
  2. I got excited... Wrong shake. Still there.... DCS f-18 Problem 20231119.zip
  3. 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
  4. 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.
  5. 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.
  6. Cleared environment and reset home. No change. All the other VR titles work okay?????
  7. 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... )
  8. 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.
  9. 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.)
  10. 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.)
  11. 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,
  12. 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 }
  13. Just a heads up for skinners. The RAF top roundels in the template may be a little... goofy.
  14. 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!
  15. 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,
  16. I have the same issue. I have; Slow Repaired DCS. No Change. Uninstalled CA and reinstalled. No Change. Deleted and reset to default controls in Game Controls Setup for Combined Arms. No Change. This is the first time I have gone CA for quite a while. I had been using joystick inputs for turret control for a long time but have updated my controller hardware recently and want to go back to Keyboard and mouse for some quick CA action. Everything else works as expected except no mouse axis control? (Mouse buttons work okay.) Any assistance greatly appreciated.
  17. New Zealand IS real. New Zealand aliens have been invading Australia for ages. "Chariots of the Gods" Man!
  18. Thank you Blue73 for sharing. I can appreciate the time and effort you have put into this. Excellent documentation and model. Printed on a Prusa and works great. Many thanks!!!
  19. G'day Chrjs, I have not programmed for that option. I have had a look at the coding and there is a 20ms debounce with a 100ms keyscan loop. I have changed these to 50ms and 200ms. Make sure you back up before running the exe to be safe. Let us know if that helped at all. Not sure whether this change will fubar the encoder rates. Oooops. Wrong exe linked. Will edit this here when the right .exe uploaded. Sincere apologies for the problems caused. Cheers, BrassEm.
  20. Sorry to trouble you mods, I have modified my original post as I have narrowed the cause down to a Syria Map texture. Is it possible to move this thread over there to the bugs sections. If not let us know and I will start a new thread there.
  21. UPDATE: NOISE ALSO FOR OTHER MOTION AXIS OUTPUTS. Oscillations intermittently breaks out simultaneously for the motion outputs as per the graph above and seen in the export.log file; LoGetAngularVelocity() Pitch, Roll, Yaw. LoGetAccelerationUnits() Surge, Heave, Sway. The whole aircraft literally shakes which you can see on the screen and also feel in the motion. This is on the Syria map. Will try other maps in the same configuration. Further Findings: F-18 Light loadout - Rock and Rolls. F-18 Heavy loadout - Rock and Rolls dampen out after a couple of minutes. F-16 Light loadout - Rock and Rolls to take-off (almost.) F-16 Heavy loadout - Solid. New Clouds or Old makes no difference.
  22. G'day, There appears to be a problem with particular tarmac park surface textures that interact with the player model sitting on top of it. The texture shakes the model intemittently to the point that the model starts to roll. I have verified the texture in the example supplied. The texture also appears on 03 park for Kiryat Shimone where it behaves the same. Other park locations not using that texture appear stable. I am sure if I test other parks with that texture the problem will occur. As per the supplied example; A clean F-18 hot on the tarmac with no wind or turbulence set, will rock both graphically and in motion. (See graph.) Eventually the F-18 will start rolling where the SWAY drops off until the aircraft is stopped, and the SWAY starts rocking again. Ensured throttle is Idle but brakes were not set. Parks in Haifa, Rosh Pina are okay but testing for that texture has not been exhaustive. As a side note, other maps Caucasus, Nevada, Gulf test okay. DCS Sway Noise.zip
×
×
  • Create New...