[WIP][1.8.x] SSTULabs - Low Part Count Solutions (Orbiters, Landers, Lifters) - Dev Thread [11-18-18]

[-MadMan-]

21 hours ago, Shadowmage said:

Thanks for the quick reply

You'r welcome. 

I'll  try investigate this issue/conflict...

Sry for my english....

[Gerbwerz]

Thanks Shadowmage. Ill add more to the ticket if I find anything new.

[tater]

I opened a new issue (not well titled, sorry) and included a craft and log file (zipped).

I made a craft with the large torus, a COS hub, and a station core, with an Orion attached so I could test docking ports. I hit launch, and the thing flew into space by itself, lol, and I could not hi map view, etc, had to quit KSP.

Only mods are SSTU, KJR and hyperedit. I had planned on popping the station into orbit with HE, but it flew into space before I could ever do that. Next testing I will just launch the stuff, but I was being lazy.

Edited August 1, 2016 by tater

[Shadowmage]

9 minutes ago, tater said:

I opened a new issue (not well titled, sorry) and included a craft and log file (zipped).

I made a craft with the large torus, a COS hub, and a station core, with an Orion attached so I could test docking ports. I hit launch, and the thing flew into space by itself, lol, and I could not hi map view, etc, had to quit KSP.

Only mods are SSTU, KJR and hyperedit. I had planned on popping the station into orbit with HE, but it flew into space before I could ever do that. Next testing I will just launch the stuff, but I was being lazy.

Ahh, noted.  Was wondering who's report that one was

I'll update the ticket with the info you've posted here;  I certainly didn't run into any such problems during my testing though.

Will see if I can duplicate it with that craft setup when I can do some in-game testing (stuck at work for..well.. far too long.. so going to be a while).

15 hours ago, Domfluff said:

Brief thoughts on the DOS modules, and USI-LS. Obviously actual figures here are meaningless until the parts are finalised/balanced, but still worth thinking about.

[snip]

Have opened up a github issue ticket to track information regarding the USI-LS setup for these parts; gives a central place for all of the information and makes sure it doesn't get lost/forgotten about in the forum

https://github.com/shadowmage45/SSTULabs/issues/340

Have copied in the information I've seen posted so far, but in case I missed something feel free to just reply and add it on the end somewhere.

 

Hopefully I'll have time to go over all of the LS stuff before too long, would like to get the LS balance figured out before I move out of the prototype stage.  Sadly is going to take a bit of time for me to figure out all the new changes to USI-LS before I will even understand half of what you've posted, as last time I played with it, it was nothing more than a simple supplies timer and a few recyclers (none of this hab stuff even existed or was planned at that time... but it _was_ like a year ago).

[Shadowmage]

48 minutes ago, tater said:

I did some quick testing with the large torus with a multi-port COS module (the larger one) on the end. Targeting was only possible on the white port (that one was on the axis of the station), the other colors would select, then immediately say "No Target." I was also unable to dock at all with any of the ports. The only mods I have on this test installation are KJR and hyperedit (so I can throw stuff into orbit fast for testing). 

Regarding life support, the torus parts should have a huge multiplier. I have always disagreed with roverdude using mass for that one multiplier, it should be volume related. Regardless, the large torus should have a habitability multiplier high enough that pretty much only supplies limit anything. Gravity is a huge LS multiplier from all current data we have.

Noted on the HUB parts.

It is a known problem that the 'control from here' and 'target port' options on those parts will not work properly, I only added docking transforms and did not include the control transform (as such it uses the Parts' root transform for both control and target).

Strange that you were unable to dock with them though; perhaps I messed something up with the docking-transform naming or orientation on that part.  Did you have the same problem with the DOS based HUB part? (I know that I tested multi-docking on that one).

[tater]

Wonder if it was the engine bell of the Orion SM making it bounce into space... Except I never even saw the pad, it immediately switches to a distant view (I can see the craft as an extended dot) but I cannot zoom at all... everything locks up aside from me seeing it rise.

Had to pick "taterkerman" as my github name.

1 minute ago, Shadowmage said:

Noted on the HUB parts.

It is a known problem that the 'control from here' and 'target port' options on those parts will not work properly, I only added docking transforms and did not include the control transform (as such it uses the Parts' root transform for both control and target).

Strange that you were unable to dock with them though; perhaps I messed something up with the docking-transform naming or orientation on that part.  Did you have the same problem with the DOS based HUB part? (I know that I tested multi-docking on that one).

Not yet. My next test was to try that craft that zipped to space. I put Orion on there as a good craft to use for docking tests. I was going to try the station for port, then retry the multi-hub. I am home today so I can mess around a bit after I caulk a window that was leaking (monsoon finally hit, and we're scheduled to get slammed by some afternoon storms down here in NM). My daughter is finally awake, so I can leave to buy caulk, but I'll mess around later.

[Shadowmage]

2 minutes ago, tater said:

Wonder if it was the engine bell of the Orion SM making it bounce into space... Except I never even saw the pad, it immediately switches to a distant view (I can see the craft as an extended dot) but I cannot zoom at all... everything locks up aside from me seeing it rise.

Had to pick "taterkerman" as my github name.

No worries; I'll see if I can duplicate the problem this evening.

I went into this knowing that there would be some problems related to the docking port stuff.  They are already buggy enough in stock... how could they _not_ cause me problems as well? 

If you do have any further information on it, please add it to the ticket there, every little bit can help in tracking down the root of the problem.

 

[-MadMan-]

On 31.07.2016 at 2:33 PM, -MadMan- said:

Spam in log...

[EXC 13:05:49.240] NullReferenceException: Object reference not set to an instance of an object
	SSTUTools.SSTUAnimateEngineHeat.updateHeat ()
	SSTUTools.SSTUAnimateEngineHeat.FixedUpdate ()

 

Conflict with [1.1.3] AtmosphereAutopilot 1.5.6

 

Edited August 1, 2016 by -MadMan-

[Shadowmage]

32 minutes ago, -MadMan- said:

Conflict with [1.1.3] AtmosphereAutopilot 1.5.6

 

Thanks for the information;  I'll try to find some time to take a look over their source and figure out what they are improperly messing with.

[Domfluff]

Quick ISS for testing:

Other angle, truss segments removed for clarity:

Will update with some further thoughts on the life support front. First thing that came up with regards to the ISS is how there *aren't* any dedicated "hab" parts on the ISS, and that the life support functions are mostly performed by the docking hubs, rather than the modules.

Ha, forgot the Cupola module :). Should go under the one (Tranquility) that the BEAM is attached to.

[Shadowmage]

47 minutes ago, -MadMan- said:

Conflict with [1.1.3] AtmosphereAutopilot 1.5.6

 

Pretty sure this issue is related to Atmosphere Autopilot re-arranging the config nodes for parts.  This causes errors as SSTUAnimateEngineHeat relies on config-specified module index in order to find the engine module.  Will likely also cause errors for any other modules that relies on gimbal or engine module index.

https://github.com/Boris-Barboris/AtmosphereAutopilot/blob/master/AtmosphereAutopilot/GimbalRearranger.cs#L40-L75

Nothing that I can do to fix the problem; someone will need to file an issue with Atmosphere Autopilot and tell them to stop re-arranging modules.

I'll look around a bit more and see if I can spot any other potential causes of the problem, but fairly certain it is as pointed out above.

10 minutes ago, Domfluff said:

Will update with some further thoughts on the life support front. First thing that came up with regards to the ISS is how there *aren't* any dedicated "hab" parts on the ISS, and that the life support functions are mostly performed by the docking hubs, rather than the modules.

Indeed, I noticed that as well; all of the USOS parts are 'labs' of one sort or another.  However some stand-alone habs were needed for generic gameplay use (interplanetary crafts)... which is why there are both hab and lab versions of each length of module

HUBS - indeed, I intend to add some storage/life-support/etc to the Node styled HUB parts (which is why they are so heavy currently); right now I'm more worried about making sure they will actually work as hubs though (which apparently there are some problems with at the moment).

1 hour ago, tater said:

Wonder if it was the engine bell of the Orion SM making it bounce into space... Except I never even saw the pad, it immediately switches to a distant view (I can see the craft as an extended dot) but I cannot zoom at all... everything locks up aside from me seeing it rise.

Had to pick "taterkerman" as my github name.

Not yet. My next test was to try that craft that zipped to space. I put Orion on there as a good craft to use for docking tests. I was going to try the station for port, then retry the multi-hub. I am home today so I can mess around a bit after I caulk a window that was leaking (monsoon finally hit, and we're scheduled to get slammed by some afternoon storms down here in NM). My daughter is finally awake, so I can leave to buy caulk, but I'll mess around later.

No problem; if you can nail down any more specific information that would be great   Otherwise I should have time to do some testing and fixing this evening.

Will likely try and fix up the Hubs a bit more, add control/target transforms, and try to push out an updated release for those this evening.

[Domfluff]

2 hours ago, tater said:

Regarding life support, the torus parts should have a huge multiplier. I have always disagreed with roverdude using mass for that one multiplier, it should be volume related. Regardless, the large torus should have a habitability multiplier high enough that pretty much only supplies limit anything. Gravity is a huge LS multiplier from all current data we have.

I think I agree entirely with this (although specific numbers will need some testing out) - it's very possible that artificial gravity is pretty much mandatory for missions to Mars and beyond (certainly a good idea).

I'm even fairly happy with treating "multiplier" as "counteracting weightlessness", at least as a shorthand. Therefore the ST-DOS-FEM "entertainment" module could have a low multiplier, since the exercise equipment etc. are dedicated for that purpose.

[tater]

My big issue with the mass figure on USILS is that the cupola is incredibly heavy, hence spamming anything with those increases habitability more than adding more living volume, which seems absurd to me. Basically, if we imagined kerbal engineers deciding on part design, they'd say, "what we need is something incredibly small, but incredibly massive---with windows!"

A cleaner looking cupola would be a nice part.

I'm waiting on some sealer to cure on my atrium (which looks like a giant cupola), then I have to add a coat (I have some corner leaks)... was hoping to test but my son is playing minecraft (he's online, and I "get" that he can't just quit, long time online gamer that I am). Maybe after lunch  

[Shadowmage]

1 minute ago, tater said:

My big issue with the mass figure on USILS is that the cupola is incredibly heavy, hence spamming anything with those increases habitability more than adding more living volume, which seems absurd to me. Basically, if we imagined kerbal engineers deciding on part design, they'd say, "what we need is something incredibly small, but incredibly massive---with windows!"

A cleaner looking cupola would be a nice part.

I'm waiting on some sealer to cure on my atrium (which looks like a giant cupola), then I have to add a coat (I have some corner leaks)... was hoping to test but my son is playing minecraft (he's online, and I "get" that he can't just quit, long time online gamer that I am). Maybe after lunch  

No worries, you'll still likely get to testing before I can get home from work to do anything about it / with the info

On the HUB-COS -- it -looks- like I may have not setup the docking transforms properly in Unity (they likely still had the imported names from blender appended with .00X), so that -may- have been the cause of the problem.  Sadly, I don't keep my Unity project synched in Git, so cannot open it up to look until I get home.

Either way, tonight I'll be re-exporting both of the HUB parts with the addition of proper 'control' transforms so that the 'control from here' and 'target port' options work for each specific port, and I'll fix up any docking-transform names at the same time.

[Domfluff]

Quick Mir for testing.

Notable that aside from the Core module, most of the parts of Mir are also some kind of lab.

Three Kerbals to a module equates to a 150 day hab time without any bonuses. Longest time Mir went without resupply was 240 days, so there has to be some kind of bonus or multiplier in here. Having one of these modules as a FEM module at a x1 multiplier (which is x2, since every module is x1) would turn that into 300 days without an issue, plus any attached Soyuz, Shuttles, etc.

How do multiple labs work on the same vessel in stock right now? They've certainly been changed a couple of times since 1.0. Obviously more labs does mean more science storage, so there's that at least.

[tater]

I'm gonna dump hyperedit, hyper edit seems useful for testing, but it's cancer, lol.

[V8jester]

8 minutes ago, tater said:

I'm gonna dump hyperedit, hyper edit seems useful for testing, but it's cancer, lol.

And in what way would you classify that post as helpful or productive? I can say SPAM is the best food on the planet but regardless of how loud I get, it won't change simple facts it's mystery meat in a can.

In much the same way, noting a mod is "cancer" leaves no relevant information on how to improve said mod or how to fix what you say is "Broke" - Mod bashing is neither needed nor appreciated by anyone on the forums.

[tater]

It introduces more problems than it solves. Hyperedit a craft with a sub craft to the standard Kerbin orbit (100,000). Decouple the carried craft to practice docking. It now shows my craft as unable to time warp above terrain. Swap to the station to time warp, try to swap back after warping maybe 20 seconds forward (craft was drifting away at 0.2 m/s). Craft is now 40 km away. Hyper edited the crafts separately to orbit to test docking. Started the Orion with the default rendezvous lag. It's ~800m away I think. Hit RCS and think I'm closing... I close a while, then I'm drifting apart, fast when I had just been closing at 2 m/s. I set up a proper rendezvous in the map view. Do the burn, I'll get within 0.2 km. Warp forward watching the intercept... it's increasing constantly. HE puts KSP into bizarro mode, and it has happened in the past on numerous occasions for me. It's unpredictable. I use HE a lot, but it has seriously screwed things up in multiple versions more than once for me. 

I think my new HE methodology will be to install it for a specific purpose (I've replaced craft that have automagically vanished before, for example), use it, then remove the mod just in case. 

Note also that I considered the idea that the perfect circular obit of HE might have been a problem, so the first thing I did up my HE to orbit was to push the orbit slightly eccentric to avoid any issues that might cause, then I undocked the test craft  to test different docking ports. Kraken happened afterwards with HE, no kraken with it removed.

PS---note the LOL, please.

Edited August 1, 2016 by tater

[Shadowmage]

Indeed, hyper-edit has some problems with clearing/setting the 'landed' state of craft when they are HE'd into orbit.  Mostly this seems to effect docking ports, but I've seen a few other odd problems because of it as well.

The solution that I use is to HE the craft into orbit, quick-save, and then quick-load;  have never had a problem after doing it that way.  However I mostly just use the orbit editor, and haven't played around much with the RV tools or other functions... so can't guarantee that it'll solve all the oddities.

 

In other more positive news, the problems with the HUB-COS were indeed due to mis-named docking transforms; have fixed the names (and added proper control transforms), and it appears to be working much better now

Am now moving on to investigating a few of the other issues that were reported with the parts since yesterday, and will hopefully be publishing an updated release later this evening.

[tater]

Just tested the same craft* minus HE. At least I could actually dock without the station and craft magically kraken-zooming away from each other (so the kraken-drive was HE-related, not a function of the torus rotation).

The ST-DOS-TKS docking port works fine, I can both target it and dock. HUB-DOS worked as well, but not HUB-COS.

 

*the craft in both my 2 recent tries (with and without HE) was in fact a LC2 with an MFT full of mono, not an Orion. I tested Orion again, and with the SM it does NOT like being launched on the engine bell with a huge mass on top. It's easy to reproduce a crash. Make an Orion CSM with those 2 parts. Put the huge torus on top. Launch. Game crashes. The CSM by itself is fine. I wonder if it's a combination of the pad mass limit, and engine impact resistance? 

 

[StickyScissors]

More "testing" (read: screwing around) has given great results, especially since some more designs of things can be dependant on only 1 mod now instead of the many previously installed ones. For example, my modular nuclear tug/long-duration cruiser/cargo mover.

[tater]

11 minutes ago, Shadowmage said:

Indeed, hyper-edit has some problems with clearing/setting the 'landed' state of craft when they are HE'd into orbit.  Mostly this seems to effect docking ports, but I've seen a few other odd problems because of it as well.

The solution that I use is to HE the craft into orbit, quick-save, and then quick-load;  have never had a problem after doing it that way.  However I mostly just use the orbit editor, and haven't played around much with the RV tools or other functions... so can't guarantee that it'll solve all the oddities.

 

In other more positive news, the problems with the HUB-COS were indeed due to mis-named docking transforms; have fixed the names (and added proper control transforms), and it appears to be working much better now

Am now moving on to investigating a few of the other issues that were reported with the parts since yesterday, and will hopefully be publishing an updated release later this evening.

I remember you saying that up thread now that you say it again! I did, indeed see the status of that craft as "landed" after I undocked it (the one that warped away so I could never test the docking ports). I forgot the quick save work around. Interestingly, after the crash, it would no longer load the saved or auto-saved craft files at all in the VAB. It would accept them, move the camera angle as if it was loaded, and show an engine icon on the right, but no craft.

[Shadowmage]

17 minutes ago, tater said:

Just tested the same craft* minus HE. At least I could actually dock without the station and craft magically kraken-zooming away from each other (so the kraken-drive was HE-related, not a function of the torus rotation).

The ST-DOS-TKS docking port works fine, I can both target it and dock. HUB-DOS worked as well, but not HUB-COS.

 

*the craft in both my 2 recent tries (with and without HE) was in fact a LC2 with an MFT full of mono, not an Orion. I tested Orion again, and with the SM it does NOT like being launched on the engine bell with a huge mass on top. It's easy to reproduce a crash. Make an Orion CSM with those 2 parts. Put the huge torus on top. Launch. Game crashes. The CSM by itself is fine. I wonder if it's a combination of the pad mass limit, and engine impact resistance? 

 

I'm trying to reproduce this now (the crash with the CSM+torus), and not seeing it.

 

If you are using the HUB-COS in your testing -- don't.  It is totally bugged out by the docking-transform names and will cause you nothing but grief.  Will have that fixed up with the release later this evening.

[Domfluff]

Recreation of earlier linked design, probably limited to near-earth/kerbin asteroid rendezvous (HAB and LAB parts).

Clearly could be used to blitz Gilly's biomes, if the hab time were sufficient.

As an aside, part of my interest in things like the above is that I've been pretty convinced recently that this is the ideal way to go about doing science at things (assuming the initial setup isn't too much) - have a lab in-situ, and a lander that can take science from as many biomes as possible and return. That's not usually possible on the surface without ISRU refueling/large scale mining and processing, but is certainly possible in orbit with a tiny lander and large mothership. Something like the above (a little larger) would be great for taking all of Minmus' science and processing in a lab in Minmus orbit, over an extended period. Assuming the use of a Life Support mod, the lack of decent hab options starts to become really apparent.

Edited August 1, 2016 by Domfluff

[tater]

My only other mod is KJR. Is that an issue?

Disable the side panels!

Nope, now it works for me. Odd. Wonder if it was HE?

Edited August 1, 2016 by tater