1.1.2 Magic Smoke Industries Infernal Robotics 2.0.2

[ZodiusInfuser]

@GrafZahl

The problem is IR parts need to be attached in a specific way on a vessel. The model rework mod shows it in an easy way.

The small arrows show where the base of that part is. If you dock two crafts the root part of the vessel can change. If you got into a situation like I built in this screenshot one of the joints will be oriented the wrong way and thus not work correctly anymore.

Sure you could 'simply' rotate the joint in the right orientation and reattach it to the vessel in the plugin. But it's very likely to provoke the kraken that way.

http://i.imgur.com/Ag11GdK.jpg

To expand on this, I've just done some quick testing as its been a while since I've played with this bug. The fundamental problem is that when you dock two craft together the tree structure of the craft causes some parts to be reversed (that we knew), but it causes the created joint to behave strangely almost as if there's two fighting each other, and if you force this then the craft is liable to be krackened.

Now if you save and load the craft again the joint will be fine but the part would just be visually reversed. Also any rotation you applied before the save will be treated as zero when you reload, potentially causing the part to move more or less than you intended. This seems to be true for translational parts too, but the position of the part gets changes. Basically, because IR does not know if this part switch-around has occurred, there's no way for the plugin to even begin to flip the models or whatever to overcome this issue. If you're willing to spend the time, you may find situations which will work, but ultimately the original disclaimer still applies.

[Fuel]

https://github.com/MagicSmokeIndustries/InfernalRobotics/releases/tag/v0.21.3

Or you can wait for KS and Curse release, but sirkut is a bit busy

Thanks a lot mate, for the link although I don't seem to be able to test it do to a glitch in the 1.0.4.861 build, building upgrades do not take effect.

[ZodiusInfuser]

Thanks a lot mate, for the link although I don't seem to be able to test it do to a glitch in the 1.0.4.861 build, building upgrades do not take effect.

<Slow clap> Well done Squad </Slow Clap>

[Fuel]

<Slow clap> Well done Squad </Slow Clap>

It was solved, it turned out that the problem was with 0.0.9 kopernicus it was added to the updated vs of Kerbol Plus and I did not noticed, so updating it with 0.1 solved the issue, anyhow I am not very happy with the 1.0.4 update as it interferes with quite some mods generating severe issues, for such a small update I don't think squad did a proper testing before it's release.

[GrafZahl]

Thanks @Aqua and @ZodiusInfuser for explaining this. I'm still new to all the KSP modding stuff, so sorry for the silly questions

Let's summarize your explanation with my less professional words, to be sure I understood everything correctly:

- for the movement of the robotic parts a well-defined root-part is necessary, because every movement is relative to that part

- when the root part changes (what happens when you dock), then the movement will be wrong, since the direction of movement is done in respect of the old root-part, but there is a new root-part and it should be relative to this now

- for mods it seems not to be possible to determine the root part to correct the direction of movement

- and mods can also not determine when the root-part is changed, since there is no event triggered for that

Best regards,

GrafZahl

[ZodiusInfuser]

Thanks @Aqua and @ZodiusInfuser for explaining this. I'm still new to all the KSP modding stuff, so sorry for the silly questions

Let's summarize your explanation with my less professional words, to be sure I understood everything correctly:

- for the movement of the robotic parts a well-defined root-part is necessary, because every movement is relative to that part

- when the root part changes (what happens when you dock), then the movement will be wrong, since the direction of movement is done in respect of the old root-part, but there is a new root-part and it should be relative to this now

- for mods it seems not to be possible to determine the root part to correct the direction of movement

- and mods can also not determine when the root-part is changed, since there is no event triggered for that

Best regards,

GrafZahl

That's pretty much it, although I suspect the game does tell mods that a dock / undock occurs. Without the other information though there's not much that can be done from there. Someone is more than welcome to try and figure it out though

[*Aqua*]

@GrafZahl

Because of your nickname I assume you're German: Es gibt keine dummen Fragen, nur dumme Antworten.

(It's a German expression and means something like: There are no stupid questions but there are some stupid answers.)

Just ask if you don't know how something works.

[GrafZahl]

Thanks for confirming

Since I'm new to that modding stuff, I don't think I can find a workaround. However I will look at the IR code anyway to understand how it works. When I have an idea to improve this situation I will tell you.

[*Aqua*]

There are several events IR could attach to if a vessel docks another:

GameEvents.onSameVesselDock - self-explanatory

GameEvents.onSameVesselUnDock - self-explanatory

GameEvents.onUndock - self-explanatory

GameEvents.onVesselWasModified - fires whenever the vessel docks, undocks, decouples, explodes etc.

Note there's no GameEvents.onDock.

[GrafZahl]

Sorry for more silly questions.

I downloaded the source from github "git clone https://github.com/MagicSmokeIndustries/InfernalRobotics.git" and tried to compile it.

However I get an compile error in Rescale.cs, Line 24 ( https://github.com/MagicSmokeIndustries/InfernalRobotics/blob/develop/InfernalRobotics/InfernalRobotics/Module/Rescale.cs ) since the compiler cannot convert "factor.relative.linear" (that is a float) into a TweakScale.ScalingFactor object that is expected by the OnRescale method from the MuMechToggle class.

Basically this is not a big issue, since inside of the OnRescale method only the "relative.linear" member of the ScalingFactor is used. So I can simply pass the whole object to the method and from the semantic point of view everything will stay the same. However I would expect to find a consistent version as download, that will compile out of the box (since there are several releases of that mod available). So I wonder, if I did something wrong? Maybe I downloaded an invalid version with bugs inside?

[*Aqua*]

TweakScale is another mod. You'll probably need the .dll from there.

[GrafZahl]

Hi Aqua,

thanks for your answer. I know about TweakScale, everything seems to be fine with that. It is more, that the IR code itself does not be consistent here.

Inside of the IR code the method OnRescale is called differently that this method is specified (also inside the IR code).

So I can correct this code, but I wonder why the downloaded source it not able to compile out of the box. Maybe I downloaded a wrong version of the IR source?

Best regards,

André

[ZodiusInfuser]

Hi Aqua,

thanks for your answer. I know about TweakScale, everything seems to be fine with that. It is more, that the IR code itself does not be consistent here.

Inside of the IR code the method OnRescale is called differently that this method is specified (also inside the IR code).

So I can correct this code, but I wonder why the downloaded source it not able to compile out of the box. Maybe I downloaded a wrong version of the IR source?

Best regards,

André

The best people to ask about this are Ziw, erendrake and pellinor (our current coders). They're able to compile it just fine for all the preview builds I've tried, but maybe there's something missing from the repo.

[pellinor]

Sorry for more silly questions.

I downloaded the source from github "git clone https://github.com/MagicSmokeIndustries/InfernalRobotics.git" and tried to compile it.

However I get an compile error in Rescale.cs, Line 24 ( https://github.com/MagicSmokeIndustries/InfernalRobotics/blob/develop/InfernalRobotics/InfernalRobotics/Module/Rescale.cs ) since the compiler cannot convert "factor.relative.linear" (that is a float) into a TweakScale.ScalingFactor object that is expected by the OnRescale method from the MuMechToggle class.

Basically this is not a big issue, since inside of the OnRescale method only the "relative.linear" member of the ScalingFactor is used. So I can simply pass the whole object to the method and from the semantic point of view everything will stay the same. However I would expect to find a consistent version as download, that will compile out of the box (since there are several releases of that mod available). So I wonder, if I did something wrong? Maybe I downloaded an invalid version with bugs inside?

Is Rescale.cs still needed at all? It looks like MuMechToggle now implements IRescalable (which comes from TweakScale) directly instead of using an intermediate class IRRescale. Anyway, your solution looks good to me, you are on the right version and something is wrong in the github repo.

My guess is that the github version InfernalRobotics.csproj is not up to date. This file contains paths to the KSP binaries which are different for all of us, so we don't keep it as synchronized as the other files. This would be a bug that is only found if a new person tries to compile the code.

[Kolago]

I see some Texture load errors in the log:

Load(Texture): MagicSmokeIndustries/Parts/Legacy/dockingwasher_free/washer

(Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Texture load error in 'C:\Kerbal Space Program 1.0.4\GameData\MagicSmokeIndustries\Parts\Legacy\dockingwasher_free\washer.dds'

(Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Load(Texture): MagicSmokeIndustries/Parts/Legacy/dockingwasher_free/washer1

(Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Texture load error in 'C:\Kerbal Space Program 1.0.4\GameData\MagicSmokeIndustries\Parts\Legacy\dockingwasher_free\washer1.dds'

(Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Load(Texture): MagicSmokeIndustries/Parts/Legacy/dockingwasher_free/washernorm

(Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

Texture load error in 'C:\Kerbal Space Program 1.0.4\GameData\MagicSmokeIndustries\Parts\Legacy\dockingwasher_free\washernorm.dds'

[Dr_Goddard]

Quick inverse kinematic hexapod update.

Edited June 28, 2015 by Dr_Goddard

[Shanty]

Hi guys , i have a problem with the open powered hinges.

when i scale them with tweakscale over 150% their function to fold breaks for some reason. it seems like it has something to do with the position where the folding needs to take place. kind of like the axis position. When i scaled it back down to 100% or 150% it worked just fine. so it must be something caused by the scaling.

Am i the only person who has that problem?

I really hope someone can help me with that

ah and yes, i made sure that ive got the latest version of tweakscale and infernal robotics

edit: using them inside the VAB does work just fine but as soon as im on the launchpad it doesnt work anymore.. it looks like its stuck and is pressing against itself. one side of the hinge is slowly moving up instead of rotating to fold.

Edited June 28, 2015 by Shanty

[ZodiusInfuser]

IR has issues if parts are scaled up too much, as KSP does some funky stuff with joints and attachment nodes. If you really want to have a part at a large size you're best to make a copy of its .cfg and change the rescaleFactor.

[Shanty]

Thank you very much, your idea with the config file worked perfectly.

[sirkut]

Updated to the latest and greatest. Enjoy!

[Gaalidas]

I don't mean to be the rear end of a donkey here (okay, maybe a teeny bit) but I'm curious... from the change log it says "Fixes for tweakscale interaction for transalting IR parts". What the heck is "transalting"?

[ZodiusInfuser]

I don't mean to be the rear end of a donkey here (okay, maybe a teeny bit) but I'm curious... from the change log it says "Fixes for tweakscale interaction for transalting IR parts". What the heck is "transalting"?

"translating" , e.g pistons.

[Fuel]

Thank you very much, your idea with the config file worked perfectly.

Just out of curiosity are You using KSP 1.0.4?

- - - Updated - - -

@Sirkut, mate, may the laws of physics bless You !!!!!

Edited June 29, 2015 by Fuel

[Jodo42]

I'm having some extremely frustrating issues with the docking washer. In the VAB it displays it rotating one section of my ship, but in flight it rotates the other.

In the VAB, the ring rotates.

In flight, the lower tanks rotate.

I'm unable to get the ring portion to rotate, actually. Every configuration I've tried with the washer causes the lower tanks to rotate instead of the upper. What's going on?

[V8jester]

I'm having some extremely frustrating issues with the docking washer. In the VAB it displays it rotating one section of my ship, but in flight it rotates the other.

http://i.imgur.com/ZHAH1ql.png

In the VAB, the ring rotates.

http://i.imgur.com/eLA9bYS.png

In flight, the lower tanks rotate.

I'm unable to get the ring portion to rotate, actually. Every configuration I've tried with the washer causes the lower tanks to rotate instead of the upper. What's going on?

It's all about relative mass. The mass of the ring is far greater than the mass of the command pod (root part) at the rings hub. Now the mass needs to be considerably different as leverage is also at play here. In the VAB the ring rotates because of which side of the docking washer it is on. In space you aren't connected to anything. When the Canadarm 2 moves an item around on the ISS. The station is moving in the opposite direction as the payload on the arm. Push the item away you push the entire station away in the opposite direction. But the mass of the station as well as the cushioning of the canadarm's joints slowly changing speeds is such, it moves very slow / not at all, with a light payload at the end of the Canadarm 2. So in short make the hub / station heavier, the ring lighter. Adjust the acceleration curve of the docking washer, as well as add SAS to the stationary bits. No SAS on the ring and it should work.

Edited June 29, 2015 by V8jester