[1.9-1.10] Global Construction

[allista]

4 hours ago, DStaal said:

@Paadwyn - I've had a similar issue, and I have a suspicion on what's causing it.  (Untested so far.)  Could you try something?  Switch from KerbalJointReinforcementContinued to KerbalJointReinforcementNext and put in the following patch:

@PART[OrbitalKitContainer2]
{
	MODULE
	{
		name = KJRExcluded
	}
}

https://forum.kerbalspaceprogram.com/index.php?/topic/184206-kerbal-joint-reinforcement-next/

My suspicion is that KJR is setting up joint connections to the center of DIY Kit, and not adjusting them as the size of the kit changes.  The above steps should exclude it from being reinforced.  (You could also try just removing KJRc.  I don't believe KJRc has a simple way to exclude parts, or I’d suggest that.)

1 hour ago, Paadwyn said:

Ok, I removed the mod, and it expanded fine.

So at least I can safely say that KJRc is a culprit.

Next will be using KJRn, maybe it fixed it in there.  If not, then I'll modify it with the change to see.

I think it's safe then to add the KJRExcluded module to DIY kits in GC itself, so that at least the users of KJRc won't have that problem.

[Paadwyn]

I've been unsuccessful in finding where to put this module. I've tried a few places, but it hasn't made any effect yet.

I'll keep plugging away at it, unless somebody has the best place to stick it.

[Johould]

@allista Trying to install 2.3.1 from your spacedock link above, I notice that the AT_Utils it includes has a .version file identical to the github release of AT_Utils 1.6.3 from the github release, but other files differ. I install mods manually and try to check that any common dependencies are either identical or one mod includes a newer version, so this was pretty confusing.

I got Ground_Construction-2.3.1.zip (md5sum 902aa00ff18f7b373071c0ee424858be) from  https://spacedock.info/mod/1123/Ground Construction/download/2.3.1

and AT_Utils-1.6.3.0.zip (md5sum bb0a52a56ef42998e6ea60b5e0b37ada) from https://github.com/allista/AT_Utils/releases/download/v1.6.3/AT_Utils-1.6.3.0.zip

diff says

Binary files gc2.3.1/GameData/000_AT_Utils/Plugins/000_AT_Utils.dll and at.1.6.3.0/GameData/000_AT_Utils/Plugins/000_AT_Utils.dll differ
Binary files gc2.3.1/GameData/000_AT_Utils/Plugins/001_AnisotropicPartResizer.dll and at.1.6.3.0/GameData/000_AT_Utils/Plugins/001_AnisotropicPartResizer.dll differ
Binary files gc2.3.1/GameData/000_AT_Utils/Plugins/002_MultiAnimators.dll and at.1.6.3.0/GameData/000_AT_Utils/Plugins/002_MultiAnimators.dll differ
Binary files gc2.3.1/GameData/000_AT_Utils/Plugins/ConfigurableContainers.dll and at.1.6.3.0/GameData/000_AT_Utils/Plugins/ConfigurableContainers.dll differ
Only in at.1.6.3.0/GameData/000_AT_Utils/Plugins/PluginData/000_AT_Utils: config.xml
Only in at.1.6.3.0/GameData/000_AT_Utils/Plugins: SubmodelResizer.dll
Only in gc2.3.1/GameData/: GroundConstruction

The 000_AT_Utils.version files in particular are identical.

Spoiler

{ 
    "NAME":"000_AT_Utils",
    "URL":"https://raw.githubusercontent.com/allista/AT_Utils/master/GameData/000_AT_Utils/000_AT_Utils.version",
    "DOWNLOAD":"https://github.com/allista/AT_Utils/releases",
    "CHANGE_LOG_URL":"",
    "VERSION":
     {
         "MAJOR":1,
         "MINOR":6,
         "PATCH":3,
         "BUILD":0
     },
    "KSP_VERSION_MIN":
     {
         "MAJOR":1,
         "MINOR":7,
         "PATCH":0
     },
    "KSP_VERSION_MAX":
     {
         "MAJOR":1,
         "MINOR":7,
         "PATCH":0
     }
}

 

Here are MD5 checksums of the DLLS in case that's of any use

Spoiler

md5sum *.dll in GameData/000_AT_Utils/Plugins from AT_Utils-1.6.3.0.zip: 
60f6993823a0df4c8ea83c9296cf54fc  000_AT_Utils.dll
cd4d1e954e538bdd41eac90df103ed26  001_AnisotropicPartResizer.dll
d15803cd341efa610e0e7de87c6d06ec  002_MultiAnimators.dll
489c73b8a311b2f8b823e8e49309a8d5  ConfigurableContainers.dll
913e7ee334608190c78058a824997280  SubmodelResizer.dll
These files are all dated April 28, 13:06

md5sum *.dll in GameData/000_AT_Utils/Plugins from Ground_Construction-2.3.1.zip:
4ca36f72a2b0cafe0d039eaddd6f548c  000_AT_Utils.dll
8227837cf5b869b3f17027d3e3b2912d  001_AnisotropicPartResizer.dll
46f8d82a9b04125be54140c4004e3f77  002_MultiAnimators.dll
d04b71fdf459b1a1820945a8e93b4f80  ConfigurableContainers.dll
These files are all dated May 9, 18:45

 

With identical version numbers and the extra SubmodelResizer.dll I assumed the AT_Utils.1.6.3.0.zip was better, and have been playing with it with no problems so far.

[allista]

1 hour ago, Paadwyn said:

I've been unsuccessful in finding where to put this module. I've tried a few places, but it hasn't made any effect yet.

I'll keep plugging away at it, unless somebody has the best place to stick it.

Tried it myself. Even tried to implement the IJointLockState interface as suggested by @Rudolf Meier in the OP of KJRn, but nothing helped save for the removal of KJRn itself. So I guess my way of resizing of a container is too hacky to work with any external joint tweaking. 

[Rudolf Meier]

9 minutes ago, allista said:

Tried it myself. Even tried to implement the IJointLockState interface as suggested by @Rudolf Meier in the OP of KJRn, but nothing helped save for the removal of KJRn itself. So I guess my way of resizing of a container is too hacky to work with any external joint tweaking. 

Try to use the debug version of KJRn 4.0.1 ... then you can see the joints it's building. Maybe this helps to figure out what's wrong.

[allista]

1 hour ago, Johould said:

@allista Trying to install 2.3.1 from your spacedock link above, I notice that the AT_Utils it includes has a .version file identical to the github release of AT_Utils 1.6.3 from the github release, but other files differ. I install mods manually and try to check that any common dependencies are either identical or one mod includes a newer version, so this was pretty confusing.

I got Ground_Construction-2.3.1.zip (md5sum 902aa00ff18f7b373071c0ee424858be) from  https://spacedock.info/mod/1123/Ground Construction/download/2.3.1

and AT_Utils-1.6.3.0.zip (md5sum bb0a52a56ef42998e6ea60b5e0b37ada) from https://github.com/allista/AT_Utils/releases/download/v1.6.3/AT_Utils-1.6.3.0.zip

diff says

Binary files gc2.3.1/GameData/000_AT_Utils/Plugins/000_AT_Utils.dll and at.1.6.3.0/GameData/000_AT_Utils/Plugins/000_AT_Utils.dll differ
Binary files gc2.3.1/GameData/000_AT_Utils/Plugins/001_AnisotropicPartResizer.dll and at.1.6.3.0/GameData/000_AT_Utils/Plugins/001_AnisotropicPartResizer.dll differ
Binary files gc2.3.1/GameData/000_AT_Utils/Plugins/002_MultiAnimators.dll and at.1.6.3.0/GameData/000_AT_Utils/Plugins/002_MultiAnimators.dll differ
Binary files gc2.3.1/GameData/000_AT_Utils/Plugins/ConfigurableContainers.dll and at.1.6.3.0/GameData/000_AT_Utils/Plugins/ConfigurableContainers.dll differ
Only in at.1.6.3.0/GameData/000_AT_Utils/Plugins/PluginData/000_AT_Utils: config.xml
Only in at.1.6.3.0/GameData/000_AT_Utils/Plugins: SubmodelResizer.dll
Only in gc2.3.1/GameData/: GroundConstruction

The 000_AT_Utils.version files in particular are identical.

  Reveal hidden contents

{ 
    "NAME":"000_AT_Utils",
    "URL":"https://raw.githubusercontent.com/allista/AT_Utils/master/GameData/000_AT_Utils/000_AT_Utils.version",
    "DOWNLOAD":"https://github.com/allista/AT_Utils/releases",
    "CHANGE_LOG_URL":"",
    "VERSION":
     {
         "MAJOR":1,
         "MINOR":6,
         "PATCH":3,
         "BUILD":0
     },
    "KSP_VERSION_MIN":
     {
         "MAJOR":1,
         "MINOR":7,
         "PATCH":0
     },
    "KSP_VERSION_MAX":
     {
         "MAJOR":1,
         "MINOR":7,
         "PATCH":0
     }
}

 

Here are MD5 checksums of the DLLS in case that's of any use

  Reveal hidden contents

md5sum *.dll in GameData/000_AT_Utils/Plugins from AT_Utils-1.6.3.0.zip: 
60f6993823a0df4c8ea83c9296cf54fc  000_AT_Utils.dll
cd4d1e954e538bdd41eac90df103ed26  001_AnisotropicPartResizer.dll
d15803cd341efa610e0e7de87c6d06ec  002_MultiAnimators.dll
489c73b8a311b2f8b823e8e49309a8d5  ConfigurableContainers.dll
913e7ee334608190c78058a824997280  SubmodelResizer.dll
These files are all dated April 28, 13:06

md5sum *.dll in GameData/000_AT_Utils/Plugins from Ground_Construction-2.3.1.zip:
4ca36f72a2b0cafe0d039eaddd6f548c  000_AT_Utils.dll
8227837cf5b869b3f17027d3e3b2912d  001_AnisotropicPartResizer.dll
46f8d82a9b04125be54140c4004e3f77  002_MultiAnimators.dll
d04b71fdf459b1a1820945a8e93b4f80  ConfigurableContainers.dll
These files are all dated May 9, 18:45

 

With identical version numbers and the extra SubmodelResizer.dll I assumed the AT_Utils.1.6.3.0.zip was better, and have been playing with it with no problems so far.

Thanks for the keen observation. I'll look into it more thoroughly.

But the first thing that comes in mind is:

Between April 28 when AT_Utils-1.6.3 were released and May 9 when GC-2.3.1 was I've switched between different branches of both mods and recompiled them multiple times. And the script that makes the distro uses files currently present on the file system. So in the end, the AT_Utils in GC distribution is compiled from the same source code as the full one from github, but binary assemblies differ. Though I'm not sure exactly how Monodevelop's compiler works to produce this result.

As for the additional .dll, like all others in AT_Utils, it does nothing unless used in other mods or configured in dedicated parts.

Edited May 12, 2019 by allista

[allista]

26 minutes ago, Rudolf Meier said:

Try to use the debug version of KJRn 4.0.1 ... then you can see the joints it's building. Maybe this helps to figure out what's wrong.

While the box resizes, IsJointUnlocked returns true, and each physical frame the vessel.CycleAllAutoStrut(); is called.

Here's what happens, though I'm not sure what that means:

 

[Rudolf Meier]

13 minutes ago, allista said:

While the box resizes, IsJointUnlocked returns true, and each physical frame the vessel.CycleAllAutoStrut(); is called.

*hmm* I've some questions

1) Who is calling CycleAllAutoStrut?

2) this magenta line to the top right from the box... where is it going to? to a child of the box? then it's correct... to a parent? then it's not

3) is the box implementing IsJointUnlocked? if yes, then... this means, that it's not allowed to build joints from parent objects to this box or it's children ... do you see a problem here? (it is allowed to build joints from children to it)

... and, the green lines (first show-option in the gui) ... those are the default connections of KSP... when you turn them off, you see only the extra joints of KJR

Edited May 12, 2019 by Rudolf Meier

[allista]

5 minutes ago, Rudolf Meier said:

*hmm* I've some questions

1) Who is calling CycleAllAutoStrut?

2) this magenta line to the top right from the box... where is it going to? to a child of the box? then it's correct... to a parent? then it's not

3) is the box implementing IsJointUnlocked? if yes, then... this means, that it's not allowed to build joints from parent objects to this box or it's children ... do you see a problem here?

1) the PartModule on the box (DockedKitContainer) that performs the resizing

2) it's going to the root part; the box is a child of the docking port that it's attached to

3) yes, the same DockedKitContainer module

The problem here is that just after the resizing the box is shifted a little, so that a gap is formed between it and the docking port. If the box were to grow instead of shrinking, this would mean part intersection and consequent explosion. Note, that with KJRn-4.0 the shift was much bigger; and the box was moved to the spot where its center was before the resizing.

@Rudolf Meier also note that during the resizing each physical frame the PartJoint between the box and the docking port is destroyed, then part.partTransform and part.orgPos are updated, than the PartJoint is recreated and part.ResetJoints() is called.

[Rudolf Meier]

8 minutes ago, allista said:

1) the PartModule on the box (DockedKitContainer) that performs the resizing

ok... well... in your resizing process... can't you just change what IsJointUnlocked returns, then call CycleAllAutoStrut() once, do your resizing, change again what IsJointUnlocked returns and call CycleAllAutoStrut() again? ... some sort of -> start ... do your stuff ... end ... and from start to end nothing changes, so no CycleAllAutoStrut need's to be called

but that's just a performance problem you would get from not doing this. it should still work

8 minutes ago, allista said:

2) it's going to the root part; the box is a child of the docking port that it's attached to

3) yes, the same DockedKitContainer module

The problem here is that just after the resizing the box is shifted a little, so that a gap is formed between it and the docking port. If the box were to grow instead of shrinking, this would mean part intersection and consequent explosion. Note, that with KJRn-4.0 the shift was much bigger; and the box was moved to the spot where its center was before the resizing.

aha... ok... and this child (the one attached with the magenta joint)... do you move this as well?

and just to make sure... are we talking about 1 or 2 vessels? (the type "Vessel")

Edited May 12, 2019 by Rudolf Meier

[allista]

11 hours ago, Rudolf Meier said:

aha... ok... and this child (the one attached with the magenta joint)... do you move this as well?

and just to make sure... are we talking about 1 or 2 vessels? (the type "Vessel")

This is a single Vessel made in editor as is. It's a rigid structure, the only thing that moves is this box, which is a leaf of the part tree of the vessel. The magenta joint links the box with the root part.

The box moves as follows:

1. The scale of its root Transform is changed a little.

2. The PartJoint between it and it's parent is destroyed.

3. It's location and orgPos are changed so that the DockingNode transform relative position does not change

4. The PartJoint is recreated.

[Rudolf Meier]

1 hour ago, allista said:

This is a single Vessel made in editor as is. It's a rigid structure, the only thing that moves is this box, which is a leaf of the part tree of the vessel. The magenta joint links the box with the root part.

The box moves as follows:

1. The scale of its root Transform is changed a little.

2. The PartJoint between it and it's parent is destroyed.

3. It's location and orgPos are changed so that the DockingNode transform relative position does not change

4. The PartJoint is recreated.

ah, ok... I see...

try this:

1) IsJointUnlocked to true for the part

2) CycleAllAutoStrut

3) check if there is any line except a green one to your box

... do nothing else, just as a test. And then, second step:

4) IsJointUnlocked to false for the part

5) CycleAllAutoStrut

6) check if there is the line again... (doesn't have to be there, but if it was there before, it should be there also after)

... if this works, then you can use this to do whatever you want to do between step 3 and 4. Otherwise it may be a bug and we'd have to investigate this further.

Edited May 13, 2019 by Rudolf Meier

[allista]

7 hours ago, Rudolf Meier said:

ah, ok... I see...

try this:

1) IsJointUnlocked to true for the part

2) CycleAllAutoStrut

3) check if there is any line except a green one to your box

... do nothing else, just as a test. And then, second step:

4) IsJointUnlocked to false for the part

5) CycleAllAutoStrut

6) check if there is the line again... (doesn't have to be there, but if it was there before, it should be there also after)

... if this works, then you can use this to do whatever you want to do between step 3 and 4. Otherwise it may be a bug and we'd have to investigate this further.

In this test I've noticed that the green and magenta lines seem to z-fight each other, and there's one of each color going from the root part to all the others. 

Results:

Between 3 and 4 the short green line connecting the box to its immediate parent (the docking port) vanishes. But the green+magenta lines from the root to the box remain.

After 5 the short green line reappears.

[Rudolf Meier]

4 minutes ago, allista said:

In this test I've noticed that the green and magenta lines seem to z-fight each other, and there's one of each color going from the root part to all the others. 

Results:

Between 3 and 4 the short green line connecting the box to its immediate parent (the docking port) vanishes. But the green+magenta lines from the root to the box remain.

After 5 the short green line reappears.

yes, they are overlapping... but normally the green ones are not needed (they only show how the ship parts are connected without KJR)

but... what is strange for me... those green lines should always go from a child to its parent.

... do you have something I can try out on my computer?

[allista]

1 hour ago, Rudolf Meier said:

yes, they are overlapping... but normally the green ones are not needed (they only show how the ship parts are connected without KJR)

but... what is strange for me... those green lines should always go from a child to its parent.

... do you have something I can try out on my computer?

This is how the vessel looks like:

And here's a crude analog using arbitrary stock parts:

Note that the Service Bay does not have the joint to the root part (the top-most fuel tank). No moving parts, of course.

And here's the .craft file:

https://drive.google.com/open?id=1XOwWKYeCqBt_1JLcHpwFWEQh8QPaWeOe

Edited May 13, 2019 by allista

[Rudolf Meier]

those connections to the FL-T800 tank... why do you have them? I guess that's some sort of autostrut... but then why are they not shown in orange? ... have you activated the advanced tweakables? ...

but the first question really is: what autostrut settings do you use?

or have you installed multiple kjr-dlls in the same folder??

[allista]

32 minutes ago, Rudolf Meier said:

those connections to the FL-T800 tank... why do you have them? I guess that's some sort of autostrut... but then why are they not shown in orange? ... have you activated the advanced tweakables? ...

but the first question really is: what autostrut settings do you use?

or have you installed multiple kjr-dlls in the same folder??

I have advanced tweakables, but no autostruts configured.

But, indeed, there's two dlls in the KRJn archive and thus in my GameData:

And sure enough, removing the KerbalJointReinforcement.dll fixes the problem: both purple joint from the root part and the green joint from parent disappear when resizing starts, then reappear when it's finished, and this time the box stays where it should be.

@Rudolf Meier thanks for the help!

Now my code is compatible with both autostruts and KJRn. While you just need to fix the distro, I suppose 

Edited May 13, 2019 by allista

[Rudolf Meier]

13 minutes ago, allista said:

Now my code is compatible with both autostruts and KJRn. While you just need to fix the distro, I suppose 

Great! that's what we want... that everything is compatible with KJRn  

The problem is, that the dll name changed from 4.0.0 to 4.0.1 ... it would fix itself when installed via CKAN (I think), but when you install it manually, you have to delete the file by hand... somewhere I did put a warning in the thread, but... well  is always the same problem with those warnings... some don't see them

but that reminds me, I should mark this mod as "incompatible" with the old KJR in CKAN...

Edited May 13, 2019 by Rudolf Meier

[Paadwyn]

I been following this, hoping to see the process, and it looks like it's coming along.

When I grab Kerbal Joint Reinforcement Next from CKAN, 4.0.0, it only has the KerbalJointReinforcement.dll in the folder (36KB)

When I grab it from the site, V4.0.2, it has both KerbalJointReinforcement.dll (64kb) and KerbalJointReinforcementNext.dll (40kb)

[Rudolf Meier]

9 minutes ago, Paadwyn said:

I been following this, hoping to see the process, and it looks like it's coming along.

When I grab Kerbal Joint Reinforcement Next from CKAN, 4.0.0, it only has the KerbalJointReinforcement.dll in the folder (36KB)

When I grab it from the site, V4.0.2, it has both KerbalJointReinforcement.dll (64kb) and KerbalJointReinforcementNext.dll (40kb)

ah, crap... my automatic packer system didn't delete the folders first... that's completely wrong 

but I have updated it now...

Edited May 14, 2019 by Rudolf Meier

[Paadwyn]

Well, glad we're working out a few bugs at the same time

Yeah, that looks alright there.

I decided to try it all with the .dll deleted and see. It does a different things now, the crate expands off center, tips over and explodes. Just wanted to see what would happen.

I'll wait until Allista gets his code updated. In the meantime, I can do design tweaks to my stations. I tried to do some work with KJR uninstalled...I must have been spoiled, everything was all floppy

[allista]

Version 2.3.2 for Kerbal Space Program 1.7.0

Released on 2019-05-14

• Made docked deployment compatible with auto struts and Kerbal Joint Reinforcement Next >=4.0.1
• Added ability to change UI color scheme at runtime
  • To access the Color Scheme dialog, right-click the GC toolbar button

 Download 

[allista]

With the correction for GC toolbar button, of course.

[Paadwyn]

Now that I can get the rest of this going, I noticed that when building the craft from the Orbital Workshop, you add it to the queue and hit start construction. Away it goes, assembling the craft.

If I leave the vessel, it stops the construction. Gotta go back in and hit start to have it resume. Looks like this will be a long 45 days, since I'm too close to Kerbin for full Time Acceleration.

[allista]

17 minutes ago, Paadwyn said:

Now that I can get the rest of this going, I noticed that when building the craft from the Orbital Workshop, you add it to the queue and hit start construction. Away it goes, assembling the craft.

If I leave the vessel, it stops the construction. Gotta go back in and hit start to have it resume. Looks like this will be a long 45 days, since I'm too close to Kerbin for full Time Acceleration.

Do you have enough resources stored, especially EC? The workshops do "background construction", but as there's no actual background execution in KSP (at least there wasn't at the time I made this), it is implemented as a "catch up": the moment you switch back to the workshops, it calculates what it would have had done in that time, and does it in a single big step. But if there's not enough resources for that, the step is made proportionally to what you have, and the construction is paused.

While away from the workshop, you can see the simulated status of the construction in the main GC window (opens with toolbar button).

Edited May 15, 2019 by allista