totm sep 2021 [1.12] Stockalike Station Parts Redux (August 14, 2024)

[Vanamonde]

Some posts have been removed. Remember, guys, asking for mod updates is not against any rules. It only becomes a problem if it's done rudely or repeatedly, and then if it does, that's a problem for the moderators to deal with. Please do not scold update requesters yourself. That just leads to arguments, hard feelings, and off-topic posts which clutter the discussions. 

[darthgently]

Do the autoleveling bases need any support parts like electrical power or a KAL9000 etc?  Or do they just "work"?  Thanks for all you do!

[darthgently]

I'm trying to sort out how these autolevelers work using HyperEdit.  Is there any way to control the force at which the landing legs on the autoleveling bases deploy?  In low grav the autolevel isn't working for me as it launches vessel off the surface as they deploy.  Do they work by detecting ground contact as they deploy or by making internal reference to the slope and its direction?  It seems the former.  Once the first pad comes into contact with Minmus, it launches the vessel up such that the other legs don't stop at the correct point and keep going so even after it settles back down the legs are all wrong.  I've tried using RCS to hold the craft down when I click autolevel but the legs just overpower it and its just hopping around like a frog as I keep trying

[Nertea]

9 hours ago, darthgently said:

Do the autoleveling bases need any support parts like electrical power or a KAL9000 etc?  Or do they just "work"?  Thanks for all you do!

No they don't, they're effectively just landing legs.

7 hours ago, darthgently said:

I'm trying to sort out how these autolevelers work using HyperEdit.  Is there any way to control the force at which the landing legs on the autoleveling bases deploy?  In low grav the autolevel isn't working for me as it launches vessel off the surface as they deploy.  Do they work by detecting ground contact as they deploy or by making internal reference to the slope and its direction?  It seems the former.  Once the first pad comes into contact with Minmus, it launches the vessel up such that the other legs don't stop at the correct point and keep going so even after it settles back down the legs are all wrong.  I've tried using RCS to hold the craft down when I click autolevel but the legs just overpower it and its just hopping around like a frog as I keep trying

It's the latter, when you click the button it'll do some math and set the legs right. To be honest I don't recall testing this on minmus recently (perhaps ever) so maybe some screenshots of your craft so I can try to reproduce it?

[darthgently]

6 hours ago, Nertea said:

No they don't, they're effectively just landing legs.

It's the latter, when you click the button it'll do some math and set the legs right. To be honest I don't recall testing this on minmus recently (perhaps ever) so maybe some screenshots of your craft so I can try to reproduce it?

After dealing with the kraken on Minmus too many times I'm experimenting with a leveling modular platform where each piece is a hexagonal procedural structural element that is light enough that a single kerbal can assemble the bigger platform on the surface using KAS.  Basically  an IKEA deck that a base can be built on later, or even just a storage area for KIS containers or whatever.  So the craft is very light weight.  I was planning on having a leveling base under the center hex, level the platform, then nail it in place with a launch clamp or something like that (kind of fuzzy at that point).  But on the current experimental craft I've tweakscaled the single base to 10m and I'm just hyperediting it to the surface with some RCS thrown on.  I edited the part cfg to reduce the ExtensionRate of the base to 1/8th at 0.0125 and that helped a lot.  No more launching off the surface.  But the platform is nowhere near level once the legs stop moving.  It almost looks like in the low g, it will be teetering on 2 opposing legs, and by chance reach a point near level, and decide it is done which leaves other legs hanging.  I've ruled out the speed of the legs pushing down in by slowing ExtensionRate to 0.025, so it must be something else.  I'm thinking the combined dV of the extending gear needs to be less than some number related to whatever body the base is on, and perhaps some indicator to the player that the base is busy doing this stuff if the rate is very slow for a low g surface; indicating that it might take awhile (blinking the lights above the gear "A", "B",... labels?)

 

https://drive.google.com/file/d/1ADU6wZYjcTPciPPeDFM1Pqp2HOj3uINE/view?usp=sharing

https://drive.google.com/file/d/1Lk6YA9fj_SnGPP_TF7fOGgCODMZNv5Kx/view?usp=sharing

https://drive.google.com/file/d/1iLJQ-fKJ31ZF1h3TaFeJYkdlvk_51VNf/view?usp=sharing

 

If you look really close you can see in the last 2 images the right click menu for the base shows the "finished" level reading in degrees of 4.x and 8.x degrees, and in both attempts I noticed it reach a teeter-totter point of near zero on 2 opposing gear at which point it seemed to stop moving (but hard to tell at 1/8th speed)

I'm wondering if this is an artifact of scaling it up to 10m.  But I don't see how as those pad offsets would make even less sense at the smaller, original, 3.75 scale.  I guess it depends on how the code is determining how to move the pad to where it needs to be and whether that is scaling those values correctly.  Or maybe scaling some, but not others.  If getting the pad to the position depends on the extension rate and moving for a period of time then maybe my changing the extension rate triggered this out-of-plane condition if the extension rate doesn't scale right and it is used on for positioning the pads

The pads should end up in a 2d plane tangent to the slope if all works right, so whatever the extension rate or scale just moving the pads into that plane, but not too fast for the local gravity, is one way of looking at it.  And verifying that everything scales correctly

 

EDIT:  Just tested at default scale and it works mostly (2.2 degrees off of level, but all the pads are on the ground) so I'm fairly sure the autolevel doesn't scale correctly.  And not sure if the 2.2 degrees off is normal or a bug; if not normal, then its a bug.  So the only big issue is keeping the ExtensionRate down with regards to local gravity and the level algo needs to take scale into account. 

https://drive.google.com/file/d/1zf1r7wsyyyQV8YZzv85DqCtJcKsN1zIO/view?usp=sharing

Edited July 29, 2020 by darthgently

[darthgently]

How big a task would it be for someone to fork a version of the Falcon landing gear so they could autolevel?  I want it bad

[edit wrong image url]

https://drive.google.com/file/d/1UQFpCKFYuzrehm_A84Fct9SImlPct8OZ/view?usp=sharing

Edited July 29, 2020 by darthgently

[Space_Coyote]

On 7/20/2020 at 2:21 PM, Vanamonde said:

Some posts have been removed. Remember, guys, asking for mod updates is not against any rules. It only becomes a problem if it's done rudely or repeatedly, and then if it does, that's a problem for the moderators to deal with. Please do not scold update requesters yourself. That just leads to arguments, hard feelings, and off-topic posts which clutter the discussions. 

Long story short, if you keep bugging the Developer about when this next version is going to come out, expect a 1 day delay as he has to stop and answer all your silly questions.. Now, back to the regularly scheduled conversation

Space_Coyote

[Nertea]

6 hours ago, darthgently said:

After dealing with the kraken on Minmus too many times I'm experimenting with a leveling modular platform where each piece is a hexagonal procedural structural element that is light enough that a single kerbal can assemble the bigger platform on the surface using KAS.  Basically  an IKEA deck that a base can be built on later, or even just a storage area for KIS containers or whatever.  So the craft is very light weight.  I was planning on having a leveling base under the center hex, level the platform, then nail it in place with a launch clamp or something like that (kind of fuzzy at that point).  But on the current experimental craft I've tweakscaled the single base to 10m and I'm just hyperediting it to the surface with some RCS thrown on.  I edited the part cfg to reduce the ExtensionRate of the base to 1/8th at 0.0125 and that helped a lot.  No more launching off the surface.  But the platform is nowhere near level once the legs stop moving.  It almost looks like in the low g, it will be teetering on 2 opposing legs, and by chance reach a point near level, and decide it is done which leaves other legs hanging.  I've ruled out the speed of the legs pushing down in by slowing ExtensionRate to 0.025, so it must be something else.  I'm thinking the combined dV of the extending gear needs to be less than some number related to whatever body the base is on, and perhaps some indicator to the player that the base is busy doing this stuff if the rate is very slow for a low g surface; indicating that it might take awhile (blinking the lights above the gear "A", "B",... labels?)

 

https://drive.google.com/file/d/1ADU6wZYjcTPciPPeDFM1Pqp2HOj3uINE/view?usp=sharing

https://drive.google.com/file/d/1Lk6YA9fj_SnGPP_TF7fOGgCODMZNv5Kx/view?usp=sharing

https://drive.google.com/file/d/1iLJQ-fKJ31ZF1h3TaFeJYkdlvk_51VNf/view?usp=sharing

 

If you look really close you can see in the last 2 images the right click menu for the base shows the "finished" level reading in degrees of 4.x and 8.x degrees, and in both attempts I noticed it reach a teeter-totter point of near zero on 2 opposing gear at which point it seemed to stop moving (but hard to tell at 1/8th speed)

I'm wondering if this is an artifact of scaling it up to 10m.  But I don't see how as those pad offsets would make even less sense at the smaller, original, 3.75 scale.  I guess it depends on how the code is determining how to move the pad to where it needs to be and whether that is scaling those values correctly.  Or maybe scaling some, but not others.  If getting the pad to the position depends on the extension rate and moving for a period of time then maybe my changing the extension rate triggered this out-of-plane condition if the extension rate doesn't scale right and it is used on for positioning the pads

The pads should end up in a 2d plane tangent to the slope if all works right, so whatever the extension rate or scale just moving the pads into that plane, but not too fast for the local gravity, is one way of looking at it.  And verifying that everything scales correctly

 

EDIT:  Just tested at default scale and it works mostly (2.2 degrees off of level, but all the pads are on the ground) so I'm fairly sure the autolevel doesn't scale correctly.  And not sure if the 2.2 degrees off is normal or a bug; if not normal, then its a bug.  So the only big issue is keeping the ExtensionRate down with regards to local gravity and the level algo needs to take scale into account. 

https://drive.google.com/file/d/1zf1r7wsyyyQV8YZzv85DqCtJcKsN1zIO/view?usp=sharing

I don't support rescaling my models, even less so TweakScale, unfortunately. 

3 hours ago, darthgently said:

How big a task would it be for someone to fork a version of the Falcon landing gear so they could autolevel?  I want it bad

[edit wrong image url]

https://drive.google.com/file/d/1UQFpCKFYuzrehm_A84Fct9SImlPct8OZ/view?usp=sharing

It's not possible to port landing legs to this system, they work completely differently. 

[Tokamak]

@Nertea I used the old version of this mod back in the day, before you redid everything. It was pretty cool then, but I must say, wow! This is ridiculously detailed and high quality, from the IVAs to the part descriptions. Kudos!

I know mod support is a community thing, not up to you yourself, but I noticed something that I figure I ought to mention, regarding MKS support. When you expand MKS inflatable modules, there is a MaterialKits cost, but because of MKS logistics, that is automatically taken from any nearby vessels with the available resources. 

I assume that the expansion cost of the inflatable modules in this mod isn't handled through that mechanism, because with them, the MaterialKits have to be on the active vessel when you are expanding/inflating the part.

I don't know if this is by design or not. If it's by design, then pretend I didn't say anything. If it isn't...  I don't know how hard it would be to use MKS's mechanism. I think the module is named "USIanimate", if memory serves.

If it's working as it is meant to, or if fiddling with it would be a pain, no worries. It's something I can easily adapt to. I just figured I'd mention it.

 

[TBenz]

14 minutes ago, Tokamak said:

@Nertea I used the old version of this mod back in the day, before you redid everything. It was pretty cool then, but I must say, wow! This is ridiculously detailed and high quality, from the IVAs to the part descriptions. Kudos!

I know mod support is a community thing, not up to you yourself, but I noticed something that I figure I ought to mention, regarding MKS support. When you expand MKS inflatable modules, there is a MaterialKits cost, but because of MKS logistics, that is automatically taken from any nearby vessels with the available resources. 

I assume that the expansion cost of the inflatable modules in this mod isn't handled through that mechanism, because with them, the MaterialKits have to be on the active vessel when you are expanding/inflating the part.

I don't know if this is by design or not. If it's by design, then pretend I didn't say anything. If it isn't...  I don't know how hard it would be to use MKS's mechanism. I think the module is named "USIanimate", if memory serves.

If it's working as it is meant to, or if fiddling with it would be a pain, no worries. It's something I can easily adapt to. I just figured I'd mention it.

 

You may want to ask @JadeOfMaar or @Pulsar about that, they wrote the MKS patch for SSPXR. However, looking through the configs, it looks like you are right in that USIAnimate is how MKS modules handle inflation and their resource costs being pulled from logistics. Given that SSPXR parts are handled by ModuleDeployableHabitat and ModuleDeployableCenrifuge, I assume it would be non-trivial to change them to USIAnimate, or adapt them to function similarly when MKS is installed. If you or someone else felt like digging into the ModuleDeployable___ code to make those changes and then put up a PR for it, Nertea might consider rolling that in. Otherwise, I wouldn't anticipate any more comprehensive support than the patch that is currently bundled with SSPXR.

[Nertea]

27 minutes ago, Tokamak said:

@Nertea I used the old version of this mod back in the day, before you redid everything. It was pretty cool then, but I must say, wow! This is ridiculously detailed and high quality, from the IVAs to the part descriptions. Kudos!

I know mod support is a community thing, not up to you yourself, but I noticed something that I figure I ought to mention, regarding MKS support. When you expand MKS inflatable modules, there is a MaterialKits cost, but because of MKS logistics, that is automatically taken from any nearby vessels with the available resources. 

I assume that the expansion cost of the inflatable modules in this mod isn't handled through that mechanism, because with them, the MaterialKits have to be on the active vessel when you are expanding/inflating the part.

I don't know if this is by design or not. If it's by design, then pretend I didn't say anything. If it isn't...  I don't know how hard it would be to use MKS's mechanism. I think the module is named "USIanimate", if memory serves.

If it's working as it is meant to, or if fiddling with it would be a pain, no worries. It's something I can easily adapt to. I just figured I'd mention it.

 

@TBenz summarized quite well. My modules do different things than the USI ones. A quick glance at the USI code does not make me think that integration would be easy.

[dylsh]

@Nertea I’ve sunk in probably 3k hours into this game. I just keep going back to it. But sadly the last year I’ve been away due to life and damn responsibilities. Despite being away, I read the forums every single day and keep current on the community and the moderators. And I just feel a need to reach out to you and express my complete admiration and level of impression. I know that must mean nothing from a complete stranger. But your work is truly top-notch. Every time I found myself back in the Kerbal universe I found myself adding a large amount of your work into my game. And the fact that you do it for free is just baffling to me. I don’t know what you do in real life, but as the Joker said: “if you’re good at something, never do it for free”. Anyway, enough of all my babbling. Thank you for years of enjoyment due to your quality mods and surely countless hours of hard work. It is truly appreciated. 

[Tokamak]

On 7/30/2020 at 9:59 PM, TBenz said:

You may want to ask @JadeOfMaar or @Pulsar about that, they wrote the MKS patch for SSPXR. However, looking through the configs, it looks like you are right in that USIAnimate is how MKS modules handle inflation and their resource costs being pulled from logistics. Given that SSPXR parts are handled by ModuleDeployableHabitat and ModuleDeployableCenrifuge, I assume it would be non-trivial to change them to USIAnimate, or adapt them to function similarly when MKS is installed. If you or someone else felt like digging into the ModuleDeployable___ code to make those changes and then put up a PR for it, Nertea might consider rolling that in. Otherwise, I wouldn't anticipate any more comprehensive support than the patch that is currently bundled with SSPXR.

 

On 7/30/2020 at 10:02 PM, Nertea said:

@TBenz summarized quite well. My modules do different things than the USI ones. A quick glance at the USI code does not make me think that integration would be easy.

That totally makes sense, but actually doing it is above my pay grade, and no mistake. 

It's okay anyway. Having different things using different mechanisms just increases the challenge and complexity of the game.  

Thanks again for the cool mod. Your work is definitely appreciated.

[Nertea]

On 7/31/2020 at 7:57 PM, dylsh said:

@Nertea I’ve sunk in probably 3k hours into this game. I just keep going back to it. But sadly the last year I’ve been away due to life and damn responsibilities. Despite being away, I read the forums every single day and keep current on the community and the moderators. And I just feel a need to reach out to you and express my complete admiration and level of impression. I know that must mean nothing from a complete stranger. But your work is truly top-notch. Every time I found myself back in the Kerbal universe I found myself adding a large amount of your work into my game. And the fact that you do it for free is just baffling to me. I don’t know what you do in real life, but as the Joker said: “if you’re good at something, never do it for free”. Anyway, enough of all my babbling. Thank you for years of enjoyment due to your quality mods and surely countless hours of hard work. It is truly appreciated. 

Thanks for the kind words, comments like these are very encouraging. I'm glad you're enjoying the mods. 

[Nertea]

Station Parts Expansion Redux 1.3.6

• KSP 1.10.x
• Updated ModuleManager to 4.1.4
• Updated B9PartSwitch to 2.17.0
• Updated NearFutureProps to 0.6.3
• Improvements to Snacks compatibility from Wyzard256
• Added a scaling factor to auto-leveling base frames which reduces their extension speed in proportion with the Celestial Body's gravity

[softweir]

Excellent and thankyou! It's good to see high-quality mods being improved upon and maintained!

I've barely scratched the surface of this mod, but I'm enjoying using it.

[JorgeCS]

16 hours ago, Nertea said:

Station Parts Expansion Redux 1.3.6

• KSP 1.10.x
• Updated ModuleManager to 4.1.4
• Updated B9PartSwitch to 2.17.0
• Updated NearFutureProps to 0.6.3
• Improvements to Snacks compatibility from Wyzard256
• Added a scaling factor to auto-leveling base frames which reduces their extension speed in proportion with the Celestial Body's gravity

Thank you so much for the super fast update, @Nertea

I'm downloading from CurseForge as SpaceDock is returning a 404 Not Found: Looks like this was deleted, or maybe was never here. Who knows. This is the download URL, after the main one which works properly:

https://spacedock.info/mod/1682/Stockalike Station Parts Expansion Redux/download/1.3.6

I tried both with Chrome and Edge, same error.

Again, thank you for the new version!

[Nertea]

Just now, JorgeCS said:

Thank you so much for the super fast update, @Nertea

I'm downloading from CurseForge as SpaceDock is returning a 404 Not Found: Looks like this was deleted, or maybe was never here. Who knows. This is the download URL, after the main one which works properly:

https://spacedock.info/mod/1682/Stockalike Station Parts Expansion Redux/download/1.3.6

I tried both with Chrome and Edge, same error.

Again, thank you for the new version!

I can't seem to download anything from Spacedock this morning so I think they're having issues. 

[JorgeCS]

Just now, Nertea said:

I can't seem to download anything from Spacedock this morning so I think they're having issues. 

Honestly yours was the only mod I tried to download today, so thank you for the heads up and sorry to disturb you!

[Kerminator K-100]

This isn't working on CKAN either, it gives me a kraken error and refuses to let me download.

Also downloading scatterer from space dock gives a 404 error

2 hours ago, JorgeCS said:

I can't seem to download anything from Spacedock this morning so I think they're having issues. 

 

Edited August 3, 2020 by Kerminator1000

[ShawnPhillips]

The download issues are and issue with SpaceDock servers. CKAN usually downloads through SpaceDock.

 

VITAS has reboot the servers and downloads are to be working again.

[GigFiz]

I apologize if I'm just blind and missing something, but it seems like the 3.75m size is a bit lacking for cargo/payload units (Pointing the finger at squad, not you). I acknowledge that there are lots of them in the MK3 airplane form factor, but it looks a bit funky (and can have gaps) if you just slap them together, and the only adapter is a rather inelegant big fuel tank (There is the service tank as while, but there isn't that much actual storage space in there). I mean this not as a criticism, but a humble request/suggestion, that a true round 3.75m service bay/cargo bay would be a great thing to have.

Much thanks

Edited August 5, 2020 by GigFiz

[Nertea]

On 8/5/2020 at 2:05 AM, GigFiz said:

I apologize if I'm just blind and missing something, but it seems like the 3.75m size is a bit lacking for cargo/payload units (Pointing the finger at squad, not you). I acknowledge that there are lots of them in the MK3 airplane form factor, but it looks a bit funky (and can have gaps) if you just slap them together, and the only adapter is a rather inelegant big fuel tank (There is the service tank as while, but there isn't that much actual storage space in there). I mean this not as a criticism, but a humble request/suggestion, that a true round 3.75m service bay/cargo bay would be a great thing to have.

Much thanks

Maybe so, but not really a thing for this mod, IMO. 

[GigFiz]

6 hours ago, Nertea said:

Maybe so, but not really a thing for this mod, IMO. 

Fair enough. Thinking about it, the reason I went here was that I was making a station that size with a bunch of your station parts and it was the one thing that wasn't fitting in.  Also, what I had in my head was essentially a PPD-TRUSS or PTD-C from this mod or the ECR bays from NFLV, just sized to 3.75.

[Kunosheru]

kerbal: * spinning and trying to understand the text above *