Maulkin

I believe the shroud is in fact the ground. I am not counting the pin that has been removed. I am referring only to pins that are still there. :) One of the pins (that is not removed) is not connected on the female side. This means only 4 of the five pins can get a signal through the cable. In the video I have reproduced the problem with the stick (and extension) removed, but it still persists with the extension. I didn't show that in the video because that would have made the video longer and it was not really relevant. I agree that it could be the weight of the stick bearing down on the connector, but if you look at the base of the unmodified stick you will see that it has a cross-shaped fitting that actually bears the weight of the stick. I find it particularly odd that this setup was working fine for months and now will not work at all. I am very concerned that the stick has a threshold defect. :( An interesting new development is that now when I use the extension cable the stick will not even be detected at all. Nothing. This is occurring 100% of the time now with both cables. But once again, if I mount the stick in the default configuration it works perfectly. So odd.

Yeah that is the cable I was provided with the extension. Basically he modifies a PS/2 connector which is a 6-pin mini DIN. I have ordered some 5-pin ones to try out.

that is a 6 position connector. The TM Warthog uses the 5 pin connector: Female: http://cablesandconnectors.com/PIX/phiema3.jpg Male: http://cablesandconnectors.com/PIX/phiemamini.jpg There is something funny about the Warthog's connector however. The guide-post in the middle is slightly larger so I will have to modify the female connector.

If it needs all 5 wires then I already know the problem is in the cable since I determined there is a loss of continuity with one of the five (see post and picture above)

hansangb, I just tried what you suggested and found one thing interesting. There are five pins but one of the pins does not appear to be connected to anything at all. This may be by design because it was the same pin on both of the cables. It will be difficult to determine without getting a specification on the pinouts of the stick. The specific pin that appears to be connected to nothing is pin #6 (the one with the wire sticking out of it) on the female side and pin #1 on the male side. I have attached a picture.

So funny you mention that. I literally just pulled out my multimeter right now! The only problem that might invalidate my test is that I'll have to push a wire into the female port and if the problem is during to a loose connection I will get a false positive. But hey at least I'll know there is something. :)

I thought that as well which is why I asked wasyl00 to send a new one but the new one did not help. Then why does the stick work normally if I remove the extension cable and plug the stick into the base directly? You would think if it was a defective base this problem would persist regardless of how the stick was connected? I am going to go to the hardware store tomorrow to pick up some wires and connectors so I can try connecting the leads individually such that I can use a multimeter to measure what is going on but to be honest I dont think it will help. I am very afraid I am going to have to open up the base to see if something is going on in there. EDIT: BTW guys thanks so much for replying so fast. It helps just to know you guys are trying to help me. I feel so lost with this malfunctioning the way it is. :(

I did not have have multiple axis assigned. This was happening without even moving the controls once I entered into the oscillation state. Does anyone know if the update 1.5.4.57013.162 fixed the issue? I saw in the notes that "Wing slat will be animated" but does not sound like it did anything to the flight model.

Some time ago I bought the TM Warthog extension from here: https://forums.eagle.ru/showthread.php?t=121242 And I would recommend this to anyone looking for an extension. Absolutely wonderful. I have been using this extension for just over 8 months without any problems until recently. Suddenly I noticed that if I moved my stick around it would also cause the stick to indicate that all buttons were being pressed? Keep in mind that up to this point the stick was working perfectly. I removed the extension and plugged the stick directly into the base expecting that the problem would persist but much to my surprise this fixed the issue. I contacted wasyl00 to see if he had heard of this happening before and he was very kind in sending me a new cable to see if this would fix the issue. Unfortunately swapping out the old cable with the new one did not fix the issue. :( I am now at a loss. I know that the problem is not the extension but I don't understand why the problem would disappear when I plugged the stick directly into the base. Has anyone else had this problem and/or has any suggestion on what else I could try? Here is a video illustrating the issue I am having: Thanks, --Maulkin

I have been following along with your pdf document and I must say it is very well formatted and concise. I did run into a bit of trouble however and I am not sure if I managed to misunderstand something, or if there is something I am trying to do that is not doable. I am trying to bind the "Tail Wheel Lock" system to JOY_BTN7 on my TM warthog such that when the switch is activated the tail wheel is locked and when it is not activated the tail wheel is unlocked. I have added the following code to the 'default.lua' in the Bf-109K-4: -- Sporn / Tail Wheel Lock { down = device_commands.Button_21, cockpit_device_id = devices.CONTROLS, value_down = 1.0, name = _('Tail Wheel Lock LOCKED'), category = _('Systems')}, { down = device_commands.Button_21, cockpit_device_id = devices.CONTROLS, value_down = 0.0, name = _('Tail Wheel Lock FREE'), category = _('Systems')}, { down = device_commands.Button_22, cockpit_device_id = devices.CONTROLS, value_down = 1.0, name = _('Tail Wheel Lock (toggle)'), category = _('Systems')}, { down = device_commands.Button_21, up = device_commands.Button_21, cockpit_device_id = devices.CONTROLS, value_down = 1.0, value_up = 1.0, name = _('Tail Wheel Lock 2-Pos On/Off'), category = _('Systems')}, The last line is the new one I have added. I then bound Button-7 on the TM Warthog Throttle to the new command "Tail Wheel Lock 2-Pos On/Off" In game I can verify that pressing the button will activate the tail wheel lock but releasing the button does not deactivate the tail wheel lock. It just leaves it on.

I used CTRL-ENTER to monitor my input and it was rock steady

Sadly it is pretty much unflyable in this state :(

I would agree with the stalling but the way it oscillates is almost like a loose aileron flapping around and less like a stall. I confirmed that auto rudder is disabled, and take-off assistance, aileron trim and rudder trim are set to zero.

It has been this way since day-1 but since it is no longer in a beta mode I figured I would report it now. Opening and closing the canopy is very choppy. To compare, you can see that the L-39, whose canopy also opens to the side, is animated very smoothly.

I have been trying to learn how to dogfight in the Bf-109 and it has been a real struggle. It seems that I easily enter into a rolling oscillation (despite holding my controls steady) making it impossible to turn with a P-51D. I have been keeping my speed above 300km/h so I have no idea what I am doing wrong. It gets so bad at some points that I can get no response from the controls. Does anyone have some suggestions on what I am doing wrong?

How do I install the eclair pod? I didn't see it in the armament list in the mission editor.

Yeah thanks you are right. I was a work and had to guess. :)

Chuck you might want to make some adjustments for the "Special modes" in regards to CCM. I was a bit confused when you say: "You can cycle through them using the SPECIAL MODES FWD/AFT controls on your HOTAS." It was my understanding that FWD would cycle through all modes, as would AFT, but in fact FWD will only cycle through the Horizontal modes (BA2 and BAH), and AFT will cycle through boresight and either Vertical or HUD-scan mode depending on if you have the 530D selected on the PCA. Also, Slide 38 should indicate there is a control for button 5 when depressed (which is to unlock I believe)

This can be observed using the instant action mission "Takeoff". Start the aircraft in a roll and the polygons of the pilot will be flashing through 1st person view. The only way to mitigate this is to disable the pilot body (LSHIFT-P). I am using a single monitor view with 1920x1200 resolution.

Hollowman, I got stuck on exactly the same thing. ;)

Ah thanks! I though I had read in the documentation that FWD or AFT would cycle through all of the CCM modes, but now that I understand it this makes more sense.

I am using build1.5.4.55584. I am able to toggle between the two horizontal scan modes (BA2 and BAH) using the "special modes FWD" button but it does not go to the boresight or vertical scan mode. But the "special modes AFT" will get to the boresight mode and something called 'SVI', but not to the BA2 or BAH horisontal scan modes. What is SVI? Is this the vertical scan mode? Where is the HUD symbology? Why doesn't the FWD and AFT buttons cycle through all of the modes?

I retested this mission but had the target aircraft fly a perpendicular vector and the 530 missile does not do that nose dive manuver when the rocket engine shuts off. Only when I am flying a parallel course directly behind the target as I have in the mission file attached above. I think it is safe to say this is a bug and the thread could be moved into the "Bugs" section.

I confirm Fredref's results. The threshold is 60%. I have attached the mission file I have been using to test this. M-2000C cold start.miz