boywithumbrella

Thanks for the suggestions. I tried replacing the hinge with a basic rotatron and then bearing rotatron. The basic rotatron showed the same amount of slack (45-90°), while the bearing rotatron behaved even worse - straight upon takeoff the wings flipped out, and due to a slight roll of the craft one wing promptly folded 180° onto the fuselage. Would you mind pointing me to what node exactly I have to change in order to increase stiffness of the joint between the two halves of the hinge, as per your other suggestion? // --- Node Definitions --- node_stack_top = 0.0, 0.1, -0.3, 0.0, 1.0, 0.0, 1 node_stack_bottom = 0.0, -0.1, -0.3, 0.0, -1.0, 0.0, 1 node_attach = 0.0, -0.1, -0.3, 0.0, -1.0, 0.0

As you can see in the picture, I do use quantum struts where applicable. As you should understand, they are not a solution to my problem, since while they're active, the wing won't move (which defies the purpose of the hinge), and as soon as I deactivate them in the air, the hinge joint "dislocates". Is there some kind of engine limitation on that? When the wings are surface-attached to the fuselage, the connection is stiff enough (let alone for joint nodes), why is the IR joint's internal connection so much weaker? Is this limitation somehow connected with the fact that it's dynamic?

I have a question about joint stiffness of the hinge joints. I know I'm probably not the first one, but I haven't found any recent info on that. I'm also unsure if the question belongs here or in the IR thread, so please redirect me as needed. So what I'm trying to do is attach a wing (B9proc) by a hinge, in order to have variable sweep. It works beautifully in the SPH as well as on the runway. However, as soon as any strain is put on the wing (e.g. the craft lifts off and the wing bears the load) the hinge joint dislocates completely and the wing flaps in the wind at angles up to 45° to the actual hinge plane. So my question is, is there a way to make the hinge joint stiffer, so it stays in plane even under load? Or is there another way to implement the turning of a wing (e.g. a powered washer like in the Legacy IR parts, but with a stiff joint)? I tried increasing the mass of the hinge to 1.5 (from 0.1), which had no effect Here's an album showing the setup in question:

Regarding Hotfix II / Build 33 The tip offset slider for control surfaces only goes in one direction (starts at 0 and can be dragged into positive range), which means they can be offset only in one direction - although one might need offsetting them in any direction. The button does offset them into negative range, however it does so in steps of 2000, which is a bit much, so not really practicable. Edit: looking at github, it seems you're working on offset right now, so I'll just wish you luck and keep my fingers crossed! Also, let me say thank you for the work you do, we appreciate it greatly!

Regarding the stack node adjustments: for me, the B9 Mk2 cockpits/fuselage do not line up with stock Mk2 parts (B9 are higher / have the stack node lower than stock). Is this intended? Am I doing something wrong?

You seem to have downloaded the wrong thing. Delete the "B9 PWings Fork" folder from your GameData - that is not what you need. You need the last release zip from the releases page on lzy's github (NOT the source code!) - unpack that into your KSP dir and you're good to go

I had the same issue as Lrauka (and probably andreasblom) - i.e. the game did not recognize the IVA of the cockpit (I only tested SC-TD). I then looked into the internal.cfg for it and renamed the seat module from Seat to InternalSeat (details in spoiler) - after this the game recognized the IVA. I'm not sure why that fixed the problem - do you have an idea / could you look into it? I can provide logs if they'd be of any help.

Of course, if FAR already calculates lift based on body shape, then the additional "magic wing" inside the cockpit throws the CoL much too far forward. Thanks for your input, blowfish! I'll delete the module and test it now. I understand that should be rather a question to Ferram, but if FAR already calculates lift by shape (of body and wing), shouldn't it disregard any ModuleLiftingSurface anyway? Or is it that it uses the module to identify wings as wings and calculate more lift for them than body parts etc.? Also, while I'm at it, thanks for your work on B9 that is greatly appreciated!

Hey Baha, first off I wanted to say that I love the cockpits' design and (especially) the IVA (dat HUD!) Function-wise I met difficulties regarding the interaction of my typical design with the lifting-body characteristic of the intake-less cockpit. (Disclaimer: I use FAR) The cockpit has comparatively a lot of lift, which shifts the CoL forward by a big margin. Basically I only get acceptable stability if I build my SSTOs like an arrow - with the wings concentrated in the aft fifth of the craft. Is this intended / is it not specifically compatible with FAR / am I just doing something wrong? Edit: I'm using it with stock Mk2 fuselage, haven't reinstalled B9 since 1.0. I remember B9 having lifting body in its fuselage pieces - I guess that could account for the difference in CoL displacement.

I apologize for the odious question-before-trying-myself, but maybe someone made the experience and could save me the hassle: Does this mod work well with Saitek drivers (specifically for Cyborg X aka FLY5 joystick)? Why I ask: there is some compatibility issue between KSP/Unity and Saitek drivers (don't know if for all or only specific joysticks) that causes noticeable (>500ms) input lag. I have a Cyborg X (Saitek FLY 5) joystick and see the same problem (on Win 7 64-bit, with both 32 and 64-bit KSP). I had to uninstall the Saitek driver as a work-around - when Win uses the built-in generic joystick drivers, all is well (but I lose all the customization options from the official drivers, effectively halving the number of usable keys). If this mod can accept the Saitek driver input without introducing input lag like KSP does, I'd be so happy. Before I try it out myself I wanted to ask the community though, because completely removing the once-installed Saitek driver from Windows is a huge hassle.

I too have encountered the "warp out of focus" bug with my craft using RealChute. Another consistent bug: when loading a quicksave or reverting to launch, RealChutes disappear from staging (and probably cause other strange behaviour, haven't tested it thoroughly). Reverting to VAB and re-launching helps - but can't be used in an ongoing flight.

While it should be possible to simply stack two s2 fuselages using part welding, I assume it would involve a measure of fiddling. As a simpler (and thus a bit uglier) alternative, may I suggest an idea I used in a cargo/transport plane of mine:

the whole point of the unique opening mechanism, as DaMichel wrote: The "tweak" you suggest would defy the point of this opening mechanism. For a lot of clearance just use the B9 S2 cargo bay.

Sounds like you agree that there are problems to be fixed. I'm afraid the licence on the Dragon Rider Capsule mod will prevent you from doing that (legally, at least).

iirc the b9 flaps and winglets had a spoiler animation. It does not display for me in 0.23 (I am up-to-date on all community fixes) - has that been fixed by anyone? And before I do my own testing - does the spoiler function itself work (with FAR)?

This bug is triggered by the part having a resource with maxAmount=0 (Electrical Charge in case of b9 engines). If you installed the b9 tweakables fix, you can right-click the engine in SPH/VAB (note that it says NaN/0 for Electric Charge amount) and move the electric charge amount slider. The bug can be retriggered and "resolved" by the same method an unlimited amount of times. You can prevent that bug by either changing the maxAmount to a non-zero value or removing the Electric Charge resource module altogether in the configs of the engines.

as my question apparently got buried, I'll try once more:

I'm not sure what you mean by combining animations, but regarding Neutrinovore's point (that I agree with) that non-IVA-visible functions (like exterior lights) should be toggle-able from the outside - it is definitely possible to have them triggered the "vanilla way" (right-click or action group) as well as RPM - at least with the new Vessel Viewer Plugin

neat ^__^ thanks!

So just in case we still have a misunderstanding about installation (which is what I assume it is, because the wheels work for me): You have to download the last version of TT Modular Multiwheels (v0.6.2.3 on Kerbal Spaceport) AND BloodyRain2k's tech-tree-modified archive. First, unpack the TTModularWheels v0.6.2.3.zip (that you got from spaceport) into a folder named TTModularWheels (you have to create it yourself) in your GameData folder. Next, unpack BloodyRain2k's TTModularWheels-v0.6.2.3_for_0.23.zip and copy the "Parts" folder contained within into the TTModularWheels folder that you created and filled in step 1. In TTModularWheels there will already be a folder "Parts" (among Internals, Plugins, Ships), choose "merge" and "overwrite (all)" when prompted. tldr; make sure you have the plugin dll as well as the parts Also, see the problem that I had - sure you have fuel to the engines / power to the wheels? What exactly do you mean by "the wheels don't work"?

literally on the same page in the thread as both your questions: To clarify, the folder within the .zip contains the whole Parts folder of the MMWheels installation, where the configs were edited to appear in the tech tree in career mode. Just overwrite the existing Parts folder of your MMWheels with the one from the linked .zip

I narrowed down the problem to something that the plugin Scene Jumper does. I uninstalled the plugin and the problem was gone. I was using the latest Toolbar version (1.5.2) as opposed to the one packaged with Scene Jumper. So I guess the ball is in theSpeare's court.

Yes, I mean the rover AP. Could you elaborate? From what I see as user, in "Rover Mode" the Multiwheels respond to the rover controls I set up in settings (WASD as default, as well as my joystick bindings) - is there another level where the control scheme is customized / can differ? Seeing as Multiwheels have not been updated since 0.21 asking for a compatibility patch by either you or TT would probably be pointless; but it's a pity, because I really like those wheels and would also like to use the rover AP.

I've skimmed the thread and seen mentions of camera feeds in Telemachus - is this feature being worked on / possible with another plugin? I would love to have an external camera feed. I apologize if this has been explained earlier in the thread, I admittedly did not take the time to read all posts in detail.

Is the reason why MechJeb doesn't work with TT Modular Multiwheels known / is there a solution?