whale_2

No, the log is fine, but it captured only one single case that the mod tried to handle.

Can't say for sure what happens there without a log file. Hold on, I'm trying to cobble together a quick fix for that.

@maculator, I think I know the reason. This is a real corner case that I thought of but never actually addressed. The raycast shot from topmost part and raycast from bottom-most part hit different colliders because the vessel is in fact lying on the edge of two colliders - this was the safety measure when the mod can't say for sure how high above the ground is the vessel. In that case it just refuses to ground the vessel. I think, no further config tweaking can help here, but I can make a switch, that would force this check for different colliders to be ignored. This could lead to explosions in other situations, something like placing one vessel on top of the other, but could help in your case. Or maybe something in between like still moving down, but with greater "safety" margin, like it still will be dropped to the ground, but from 2 m instead of 50. What do you think?

I'm definitely not aware how one can detect the default or non-default terrain. I do raycasts with some reasonable (at least it seems to me so) mask - do you mean that there should be some some other mask for detecting non-default terrain colliders? (However, I try to detect not only the terrain, but parts as well, though maybe this if of little help here) MinDownMovement has different meaning - if you set it to 100, WST won't put the vessel down below 100 m, so I'd suggest you leave it as is and maybe increase grounding ticks to 10-20 but not above stabilization ticks. Checking your log file now...

@maculator, hmm... I don't quite understand what's happening on these screenshots. Could you please upload a log file? I tried 1.4.1 and found no situation where WorldStabilizer is helpful, so have yet no reason to rebuild it for 1.4.1, but your case could change it...

Likely it will. I didn't check that particular situation, why not give it a try?

So, while @pizzaoverhead is being silent, I drafted a fix that makes landing gear screech every time as they supposed to. Works in 1.3.1, not sure about latest KSP release. Download from GitHub

I hope I've fixed this. https://github.com/whale2/WorldStabilizer/releases/tag/0.8.4 Seems like Squad finally had fixed this bug - I can't reproduce any bouncing in 1.4.1. One mod less to care about Some stuff still might be here - like vessels moored with KAS harpoons and winches and KAS ground blocks. I didn't check it yet, so if anyone have something to say, please do.

Just threw in 1.3.0.6. First thing to notice was all my Eve statics gone. Instance files are in place, no relevant errors in log. Reverting back to 1.2.9.9 brought them back. @Ger_space, do you want me to look deeper into it? (Also, I must fix some NPEs in AutoKourse, I know)

How about making a maintenance release for 1.3.1 with all attributes and methods names changed for not clashing with 1.4? That would simplify all feature backporting should such thing happen.

@Hotel26 that's most likely a bug in WorldStabilizer, I didn't test that exact situation. Theoretically the vessel should not be moved that high, there's a limit of 2 meters and the roof seems to be a bit higher. Still it would be nice if you could check it without the mod.

This would be done, for sure. Some stuff behaves odd when parts got undocked or broken or other way detached, as said by ZodiusInfuser, so I have to fix it. Real life holds me strong for now

@kcs123 No, it should not work like this. Normally, parts having InnerLock module should collide only with other parts having the same module. There's another parameter, isActiveForAll which controls this behavior - if set to true, the part will collide with anything regardless if there's InnerLock on the other part or not. isSwitchable initially intended for cargo bays which you might want to make holding everything inside. I still hope for appropriate part for intra-collisions to be designed. As of engaging lock in editor - probably possible, but I don't see a use case for it, except of checking if it placed correctly or not. Could you please provide an example?

This was written some time before your post about IR Next. I watch your efforts there, but still not sure how are you going to deal with the strain applied to joints and consequent time warp- or save/load- induced drift. If you can make it - it would be perfect. Besides, this would be "new" IR and I was talking about patching existing one. Not hindering your work in any way.

Drafted another alpha. Both halves turns cyan when locking/unlocking. When part and/or joint breaks, unlock procedure performed. Still unsure what would happen in case you lock to something, decouple and jump to Space Center. As it is 3.00 AM here, I'm about to take a nap. https://github.com/whale2/InnerLock/releases/tag/v0.0.1

Thanks for the input. Configuring colors is nice idea. I didn't test all the corner cases and actually realized that I'm not addressing part break events at all. (that's why I called it "alpha" ) There's definitely something to fix!

Sure, cyan would be nicer. I don't think that priming the other end really makes sense. What is the use case? Lighting both indicators cyan during the locking is the other thing, I can make it. Sure, sound is awkward, it's just something I've found in public domain, actually it is said to be the sound of car electric window motor. Have anything better? If this is electromagnets without moving parts, should they constantly drain EC? There's a config option for that. Yellow is just Color.yellow from Unity, you're right, I'll better pick up the original color on module startup.

Oh, that's what I forgot. Should be fixed soon.

Hmm, the indicator should turn red, sound of actuator should be started and after that it should lock, with indicator turning green. Can I take a look at your log file? That's how it looks for me:

Ok, here comes the alpha. Kudos to @ZodiusInfuser for awesome part model. v0.0.0 on GitHub

KJR just ignores parts having IR PartModule, so it should be easy fix: from GameData/KerbalJointReinforcement/Plugin/PluginData/KerbalJointReinforcement/config.xml <string name="exemptPartType0">MuMechToggle</string> <string name="exemptPartType1">MuMechServo</string>

Not really. If you watch a video in the top post, you'll see that girder segments push against each other, while being the parts of the same vessel. Normally they would just pass through each other. So function is to attach to some place where you want to prevent the other part from passing through (provided that similar rail or bumper is attached to that other part). On that video I just modified girders so that they can't pass through each other, but it's better to leave them as is and have special part for this.

Regarding the rails and slider - the closest real-world thing I can think of is this boat trailer - the boat rests on the black rails. The difference is that in KSP the boat would usually fall through them. Idea is to have a placeholder for intra-collisions, I don't think enabling them everywhere is a good idea. However, I think black color should be replaced with something more "spacey"

Hi, Thank you for looking into this. I should have written it earlier, ZodiusInfuser made a different model, far superior to my crude sketch and in current IR Model Rework style. However, if you'd like, this one could be made into working part too.

Wow, that's sounds really exciting! IR is fantastic, but there's really much space for improvement. Can you please elaborate? The fact the joints behave like rubber also bugs me - they should not do so and I tried to tweak joint parameters to no avail. That's something I'm already doing, however I want to warn that enabling collisions en masse could be CPU-costly and not very convenient. I thought it would be more convenient if there would be a special part like placeholder for internal collisions.