Anyone care to make some simple models?

[ZodiusInfuser]

21 minutes ago, whale_2 said:

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.

There is not really any use case for priming the other end, other than possibly preventing a hostile docking attempt? Yea, if both indicators lit up then that would make the behaviour more understandable.

21 minutes ago, whale_2 said:

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?

I don't have any better sound I can give you, but something like this may be cool (Edit: couldn't find what I was thinking of, but some sort of relay or solenoid sound slowed down could work)

21 minutes ago, whale_2 said:

If this is electromagnets without moving parts, should they constantly drain EC? There's a config option for that.

Electro-permanent magnets , they're actually used quite a bit for connectors like this. They're basically a magnet that can be switched on and off, only requiring power on the transition state (something like 50V for a nanosecond).

21 minutes ago, whale_2 said:

Yellow is just Color.yellow from Unity, you're right, I'll better pick up the original color on module startup.

Or make all the colours be exposed in the cfg?

----------------------------------------------------------------------------------------------------

This is cool! https://drive.google.com/open?id=1_H0IPDQcJTwnz7wbggBxineD2QVWaWQ3

Connected it to that truss that was on the craft and decoupled it (with no decoupler force) and it stayed connected

Oh and sorry about this, but I exited to the space center and went back to the craft from that image and bit with the decoupler was gone but the connector was still green. I proceeded to disengage it and got this:

LockMechanism: MoveNext:0: (part id=2825291401): finalize unlock; master: True; slave: False
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)

NullReferenceException: Object reference not set to an instance of an object
  at InnerLock.LockMechanism.disengageLock () [0x00000] in <filename unknown>:0 
  at BaseEvent.Invoke () [0x00000] in <filename unknown>:0 
  at UIPartActionButton.OnClick () [0x00000] in <filename unknown>:0 
  at UnityEngine.Events.InvokableCall.Invoke (System.Object[] args) [0x00000] in <filename unknown>:0 
  at UnityEngine.Events.InvokableCallList.Invoke (System.Object[] parameters) [0x00000] in <filename unknown>:0 
  at UnityEngine.Events.UnityEventBase.Invoke (System.Object[] parameters) [0x00000] in <filename unknown>:0 
  at UnityEngine.Events.UnityEvent.Invoke () [0x00000] in <filename unknown>:0 
  at UnityEngine.UI.Button.Press () [0x00000] in <filename unknown>:0 
  at UnityEngine.UI.Button.OnPointerClick (UnityEngine.EventSystems.PointerEventData eventData) [0x00000] in <filename unknown>:0 
  at UnityEngine.EventSystems.ExecuteEvents.Execute (IPointerClickHandler handler, UnityEngine.EventSystems.BaseEventData eventData) [0x00000] in <filename unknown>:0 
  at UnityEngine.EventSystems.ExecuteEvents.Execute[IPointerClickHandler] (UnityEngine.GameObject target, UnityEngine.EventSystems.BaseEventData eventData, UnityEngine.EventSystems.EventFunction`1 functor) [0x00000] in <filename unknown>:0 
UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object)
UnityEngine.DebugLogHandler:LogException(Exception, Object)
UnityEngine.Logger:LogException(Exception, Object)
UnityEngine.Debug:LogException(Exception)
UnityEngine.EventSystems.ExecuteEvents:Execute(GameObject, BaseEventData, EventFunction`1)
UnityEngine.EventSystems.StandaloneInputModule:ProcessMousePress(MouseButtonEventData)
UnityEngine.EventSystems.StandaloneInputModule:ProcessMouseEvent(Int32)
UnityEngine.EventSystems.StandaloneInputModule:ProcessMouseEvent()
UnityEngine.EventSystems.StandaloneInputModule:Process()
UnityEngine.EventSystems.EventSystem:Update()

 

Oh and I did get a point where I disconnected two locks and the sound played / indicators changed but the joint remained. Nothing logged for that though.

Edited February 24, 2018 by ZodiusInfuser

[whale_2]

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!

[whale_2]

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

[ZodiusInfuser]

LockMechanism: checkRollAndDot:0: (part id=2906528708): dotup = -0.9979391; dotfwd = -0.0002038725; offset = 0.01890041
LockMechanism: checkRollAndDot:0: (part id=2906528708): dotup = -0.9980423; dotfwd = -0.000202706; offset = 0.03287748
LockMechanism: checkRollAndDot:0: (part id=2906528708): dotup = -0.998212; dotfwd = -0.0002029877; offset = 0.03141457
LockMechanism: checkRollAndDot:0: (part id=2906528708): dotup = -0.9987131; dotfwd = -0.0002042482; offset = 0.02648287
LockMechanism: checkRollAndDot:0: (part id=2906528708): dotup = -0.9996161; dotfwd = -0.0002056783; offset = 0.01399477
LockMechanism: checkRollAndDot:0: (part id=2906528708): dotup = -0.9997553; dotfwd = -0.0002061621; offset = 0.01096608
LockMechanism: checkRollAndDot:0: (part id=2906528708): dotup = -0.9999364; dotfwd = -0.0002106741; offset = 0.01235008
LockMechanism: checkRollAndDot:0: (part id=2906528708): dotup = -0.9999173; dotfwd = -0.0001917784; offset = 0.01554141
LockMechanism: checkRollAndDot:0: (part id=2906528708): dotup = -0.9999368; dotfwd = -0.0002083529; offset = 0.01074668
LockMechanism: lockHasp:0: (part id=2906528708): lockHasp; part = IR.LockConnector; id = 2842179534; relock = False
LockMechanism: lockHasp:0: (part id=2906528708): acquiring master status
LockMechanism: MoveNext:0: (part id=2906528708): finalize lock; other part=2842179534
LockMechanism: MoveNext:0: (part id=2906528708): latch slipped
LockMechanism: lockHasp:0: (part id=2906528708): lockHasp; part = IR.LockConnector; id = 2842179534; relock = False
LockMechanism: lockHasp:0: (part id=2906528708): acquiring master status
LockMechanism: MoveNext:0: (part id=2906528708): finalize lock; other part=2842179534
LockMechanism: lockHasp:0: (part id=2906528708): lockHasp; part = IR.LockConnector; id = 2842179534; relock = False
LockMechanism: lockHasp:0: (part id=2906528708): acquiring master status
LockMechanism: MoveNext:0: (part id=2906528708): finalize lock; other part=2842179534
LockMechanism: MoveNext:0: (part id=2906528708): creating joint
LockMechanism: MoveNext:0: (part id=2906528708): locked
LockMechanism: MoveNext:0: (part id=2906528708): master; otherLock id = 2842179534
LockMechanism: MoveNext:0: (part id=2906528708): creating joint
LockMechanism: MoveNext:0: (part id=2906528708): locked
LockMechanism: MoveNext:0: (part id=2906528708): master; otherLock id = 2842179534
LockMechanism: MoveNext:0: (part id=2906528708): finalize unlock; master: True; slave: False; broken: False
LockMechanism: MoveNext:0: (part id=2842179534): finalize unlock; master: False; slave: True; broken: False
LockMechanism: MoveNext:0: (part id=2906528708): destroying joint

NullReferenceException: Object reference not set to an instance of an object
  at InnerLock.LockMechanism+<finalizeUnlock>d__42.MoveNext () [0x00000] in <filename unknown>:0 
  at UnityEngine.SetupCoroutine.InvokeMoveNext (IEnumerator enumerator, IntPtr returnValueAddress) [0x00000] in <filename unknown>:0 

NullReferenceException: Object reference not set to an instance of an object
  at InnerLock.LockMechanism+<finalizeUnlock>d__42.MoveNext () [0x00000] in <filename unknown>:0 
  at UnityEngine.SetupCoroutine.InvokeMoveNext (IEnumerator enumerator, IntPtr returnValueAddress) [0x00000] in <filename unknown>:0 

Whoops  The joint failed to be removed when disconnecting.

Both sides turning cyan is definitely better

[Rudolf Meier]

On ‎30‎.‎01‎.‎2018 at 10:53 AM, whale_2 said:

And important note - this can't be fixed in any reasonable way in IR code.

oh come on... why did you say that? now I want to solve it!!

[whale_2]

2 minutes ago, Rudolf Meier said:

oh come on... why did you say that? now I want to solve it!!

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.

[kcs123]

Is it possible to be able to engage lock while still in SPH/VAB ?

I was created patches for stock parts like this:

@PART[strutCube*]
{
	%MODULE[InnerLock]
	{
		isPermaLock = true
		isSwitchable = false
	}
}

@PART[structuralMiniNode*]
{
	%MODULE[InnerLock]
	{
		isPermaLock = true
		isSwitchable = false
	}
}

It seems that this one makes such part collideable with everything. It makes cliping into other parts dangerous (kraken invitation). Is it possible to create MM patch that new part only collide with same part type that have such option enabled, not with all other parts ?

That would be much safer to use when you want to hide such parts by cliping into other parts for aestetic reasons.

 

[whale_2]

@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?

Edited March 3, 2018 by whale_2

[kcs123]

10 hours ago, whale_2 said:

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 no

Ah, that explains. I was set it to true in SPH and it was colliding with everything, while only thing I needed on my craft is just to place such part on craft. Learning something new each day.

As example, not the best picture, this one is from runway, but I would like to use same parts used for intended collision to lock otherwise free moving rover legs while it is inside fairing of rocket, for example. I used struts for such purpose that were able to decouple when I need.

This one was from testing how locking works, on that craft I only need collision, not locking once craft is going to be released from cargo bay. If something like that is not easy to create, no worries, I will secure such craft in flight in different way.

[kcs123]

Forgot to mention, would be nice to have ability to engage/ulock abd toggle lock of parts trough acrion group command.
Haven't encountered anything ultimately wrong with mod otherwise.

[whale_2]

10 hours ago, kcs123 said:

Forgot to mention, would be nice to have ability to engage/ulock abd toggle lock of parts trough acrion group command.
Haven't encountered anything ultimately wrong with mod otherwise.

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]

15 hours ago, whale_2 said:

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  

Take your time, neither I was able to test this and some other WIP mods properly to provide proper feedback. I wanted to try this mod with new IR next mod on variable sweep mechanizm, but encountered few bugs in IR next mod that prevented me to do it properly.

[Colonel Cbplayer]

This is actually perfect! My mechs have a problem with the arms and wings not properly returning to place because of the lack of colliders so this is very helpful. 

The arms actually overextend for a bit if you see it. 
Also it possible to add a pulling force between parts to snap them together nicely.  

[kcs123]

9 hours ago, Colonel Cbplayer said:

This is actually perfect! My mechs have a problem with the arms and wings not properly returning to place because of the lack of colliders so this is very helpful. The arms actually overextend for a bit if you see it.

Also it possible to add a pulling force between parts to snap them together nicely.  

Have you tried creating some mech-a like craft with WIP IR next plugin ?

I become quite a short on available free time for playing KSP and I was unable to continue testing with foldable wings, how strong IR joints need to be, discovering bugs and giving proper feedback. Feedback from someone who know how to create complex crafts with IR parts will be of high value at this stage of IR next development. We all want for IR to be good as much as game engine allows it, to be able to create even more crazy stuff.

[whale_2]

Put some lines of code after a while. Also, I started using this in my career game, so chances are I'll get it polished sooner. Got some models for rails and bumpers from Idel, kudos to him. Parts need some polishing, I didn't include them into this another alpha-pre-release, but at least I've got Action Groups working and fixed a bug when lock becomes inoperable after unlocking.

On GitHub --> 0.0.2

 

[whale_2]

Works good so far. However, still need to iron out failure modes, such as when the lock is broken and similar

Spoiler

 

[whale_2]

Too fast. Locks break off of craft body when I switch to it, parked in front of SPH. It happened before, when I was using Active Struts for that purpose and I attributed it to tension in struts and/or IR actuators due to absence of internal colliders so the upper fairing could not simply rest on something. Now there should be something else, need to investigate and fix.

[whale_2]

Replaced FixedJoint with ConfigurableJoint. FixedJoint often gave broken lock connection to parent part, I have no idea why, maybe because ConfigurableJoint is not rigid. Still sometimes lock breaks off of the part it is connected to. However, managed to make the craft two posts above able to survive scene load with locks engaged. Also, made this (lock survives towing back and forth):

Spoiler

 

 

On GitHub --> 0.0.3

Edited May 4, 2018 by whale_2