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

Shadowmage · August 1, 2016

On 8/1/2016 at 11:52 PM, tater said:

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

Expand

Shouldn't be a problem, as I have KJR in my dev testing install.

You could try posting up a .craft file that manifests the problem and I can take a look. It could even be that I've already fixed whatever was causing it, have fixed quite a few odd bugs today with various bits of the code.

If I can duplicate it, I'll try and get it fixed for tonights update as well; will be investigating another issue for a bit (that I probably won't get solved tonight), but the release is otherwise ready.

tater · August 1, 2016

[WRN 17:57:19.404] [Part]: PartModule TransferDialogSpawner at SSTU-ST-HAB-H, index 8: index exceeds module count as defined in cfg.
Looking for TransferDialogSpawner in other indices...
[WRN 17:57:19.404] ...no TransferDialogSpawner module found on part definition. Skipping...
[EXC 17:57:19.438] NullReferenceException: Object reference not set to an instance of an object
	ShipConstruct.LoadShip (.ConfigNode root)
	ShipConstruction.LoadShip (System.String filePath)
	FlightDriver.Start ()

OK, I rebuilt the craft, this time with the torus as root. Added the station core, and a solar array truss on top, CSM on bottom. Boom, crashed.

That was where the crash started, a little down starts all the constant null refs until I killed the process.

Edited August 2, 2016 by tater

Shadowmage · August 2, 2016

On 8/1/2016 at 11:58 PM, tater said:

OK, I rebuilt the craft, this time with the torus as root. Added the station core, and a solar array truss on top. Boom, crashed.

Expand

Do you have some craft files I can try out? Or more precise details on the steps to recreate (I'm not sure what part you are referring to by 'station core')?

I just tried the largest torus as root, with the modular solar truss on top, and did not encounter any problems; but it sounds like I might be missing a part or some other steps. (Could also be I've already fixed the problem as-per-above, which is why I would like a craft file, as that eliminates any differences in building styles).

Unless you are saying that it is crashing in the editor, before you can even save to a craft file?

Sorry for all the questions, just trying to make sure I can get whatever problem this is fixed up for tonight's bugfix release.

Boris-Barboris · August 2, 2016

On 8/1/2016 at 4:06 PM, Shadowmage said:

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.

Expand

Honestly, I would say this is exactly the problem, not AA's rearrangement per se. Finding a module by index sounds like a bad design.

tater · August 2, 2016

I upped the craft to the github issue. It's the autosave (I assume, since it crashed).

Sorry, the core was the TKS part.

Edited August 2, 2016 by tater

Shadowmage · August 2, 2016

On 8/2/2016 at 12:26 AM, tater said:

I upped the craft to the github issue. It's the autosave (I assume, since it crashed).

Expand

NP, thanks

That craft file let me confirm the problem, and yes it had already been fixed (but the bad data was saved into the craft file). Fix will be available with the update later this evening.

Shadowmage · August 2, 2016

On 8/2/2016 at 12:19 AM, Boris-Barboris said:

Honestly, I would say this is exactly the problem, not AA's rearrangement per se. Finding a module by index sounds like a bad design.

Expand

Its common with stock modules; notably the science lab is -very- picky about module indexing. I believe the cargo bays use indexes to mange their animations, and probably a few others that I'm unaware of (I don't use stock modules much). It was a concept found to work with stock code and and modules, so I went with it. It is perfectly stable as long as people don't re-order modules, which they shouldn't be doing as stock code often relies on the module index. I had -thought- that it was common knowledge/good practice to not muck with module ordering for that reason... but apparently not everyone wants to play nicely.

I have a workaround in mind, but it will be a huge number of config edits in order to get it implemented, so it'll have to wait until I'm back from my camping trip. Essentially instead of referring to the module by raw-index, refer to it by the index of the module within the list of just that type of module on the part; e.g. index=0 would refer to the first module of that type regardless of if it was actually in the Part.Modules list at index 5. Sadly, this will require editing/updating every single part that uses that animation module (and a few other modules), which is... nearly every part at this point.

Edit:

Wanted to make you aware that the stock ModuleSurfaceFX also references engine by raw module index; if re-ordering of modules is necessary for the function of your mod, you may want to consider adding some special handling to the code to also patch the config nodes for any ModuleSurfaceFX to update their 'thrustProviderModuleIndex'. I'm not aware of any other stock modules that rely on engine-module-index, so that may be the only stock module you'd have to worry about.

Edited August 2, 2016 by Shadowmage

tater · August 2, 2016

Sorry if I'm less than helpful/precise in my reports. I posted that, then had to think about feeding kids (son has a friend for a sleepover, wife is on call and trapped at the hospital till who knows when).

Shadowmage · August 2, 2016

On 8/2/2016 at 12:51 AM, tater said:

Sorry if I'm less than helpful/precise in my reports. I posted that, then had to think about feeding kids (son has a friend for a sleepover, wife is on call and trapped at the hospital till who knows when).

Expand

No worries, I understand how it goes. I'm grateful that you even post the reports with the details that are there; its far more helpful than some of the reports I get.

Good news is I'm certain that I've fixed both of the problems you were encountering.

Bad news is that some of the bad data would have been saved into .craft files; so craft using any of the DOS parts or the HUB-COS will have to be remade from scratch in the editor.

Packing up the release now and should have it available shortly.

Shadowmage · August 2, 2016

Updated testing release is available:

https://github.com/shadowmage45/SSTULabs/releases/tag/0.5.32.121

Fixes numerous issues with many of the new station parts. Should hopefully be much more reliable now.

Please keep the bug reports and feedback coming in; I may have time to do one more bug-fixing patch this week before I leave, and will try and get all of the bugs fixed that I can/have time for.

I've opened up feedback tickets for the station parts in general, and for their use with USI-LS. Please try and keep the relevant information there if possible as it will help ensure nothing gets missed or forgotten about.

The general feedback ticket is: https://github.com/shadowmage45/SSTULabs/issues/343

The USI-LS ticket is: https://github.com/shadowmage45/SSTULabs/issues/340

Gerbwerz · August 2, 2016

On 7/31/2016 at 8:27 PM, Shadowmage said:

Updated testing release is available:

https://github.com/shadowmage45/SSTULabs/releases/tag/0.5.32.120

This release consists mostly of prototype station parts, though there are a few other minor fixes/changes in place too. Please see the link for the full change-log and downloads. Also please note the 'known issues' section at the bottom of the change log. Github, Curse, and AVC have all been updated for this version.

I'll work on putting up a list of things to test / what I'm looking for feedback on for this release, should hopefully have it up later today but might not be until tomorrow morning.

Expand

Finally tracked down what is making the SM auto decouple. Its a mod called Routine Mission Manager. http://spacedock.info/mod/362/Routine Mission Manager

If you have the CM set to SM DC Staging Disabled it will auto decouple on return from scene change. If you Enable it won't. Easiest way to repro is is create a stack of CM and SM, go to pad, F5 quicksave, F9 Reload. Bam, decouples every time.

Edited August 2, 2016 by Gerbwerz

StickyScissors · August 2, 2016

@Shadowmage So, i have found an issue between SSTU and FAR. Specifically your engines and FAR.

To reproduce:

1. Install SSTU

2. Install FAR

3. Make some sort of craft in the editor

4. select engine (or any other part with an integrated engine)

5. NullRef. NullRef. NullRef. NullRef. NullRef. NullRef.

Note: Service modules such as the Orion, Apollo, and Soyuz spit out s*** loads of NRE's at once, while engines only spam out 2 when you select them. Also, im not on the latest version, i don't have the internet speeds or data to support downloading this mod every few days, so i'm on the previous patch.

Output_log: https://www.dropbox.com/s/u0g01j1imuyvdn9/output_log.txt?dl=0

tater · August 2, 2016

HUB-COS is now working nicely. The welded ports might be nice with some "this end forward" markings (I'm terrible about forgetting to flip the bloody 2.5m stock port, lol).

Regarding the inflatables and game balance, how are the container volumes considered? I would suggest that whatever they end up holding, perhaps they start with the volume available after inflation, but, well, empty. This would require supply launches, just as a Bigelow will need a launch to get the thing up there, and more to fit it out. I'm thinking in particular of the tori given the huge volumes that would need fitting out vs the collapsed sizes. Dunno if that's worthwhile or not, but It seems like there should be a cost/benefit trade between solid and inflatable. The inflatables in general, and the tori in particular are nice late-tech tree items.

I would sort of like to see an ability to stop rotation. In RL turning the thing when loaded and spun up would be non-trivial.

Domfluff · August 2, 2016

You might have spotted this already, but all of the COS modules (ST-COS-HAB and LAB) have the same mass (3.2) - I haven't spotted where the problem is yet.

Domfluff · August 2, 2016

USI-LS patch for the COS docking hubs:

Reveal hidden contents

This works fine, and I think I'm happy with the resulting numbers.

I've figures for the rest of the parts (aside from the COS-HAB and COS-LAB, since the masses are wrong), but I think I'm running foul of the way you've defined the parts - applying something like the above (with different values) to the SSTU-ST-DOS-COM part, for example, shows supplies and mulch in the right-click menu in the VAB, but not on the actual part. Equally, defining multiples involves some other weirdnesses - some values are shared between parts, etc.

I'll upload the patch as written to the Github thread, but it's not really functional at the moment.

tater · August 2, 2016

On 8/2/2016 at 9:07 AM, Domfluff said:

You might have spotted this already, but all of the COS modules (ST-COS-HAB and LAB) have the same mass (3.2) - I haven't spotted where the problem is yet.

Expand

The masses, etc have not been balanced at all, it was mentioned up the thread.

Domfluff · August 2, 2016

On 8/2/2016 at 12:55 PM, tater said:

The masses, etc have not been balanced at all, it was mentioned up the thread.

Expand

Sure, but that doesn't look like what the part config files are trying to do - the different sizes of LAB and HAB module don't all have 3.2 tons set, which presumably means that something isn't working the way it's supposed to (which could indicate further errors)

Domfluff · August 2, 2016

On 8/2/2016 at 10:44 AM, Domfluff said:

I've figures for the rest of the parts (aside from the COS-HAB and COS-LAB, since the masses are wrong), but I think I'm running foul of the way you've defined the parts - applying something like the above (with different values) to the SSTU-ST-DOS-COM part, for example, shows supplies and mulch in the right-click menu in the VAB, but not on the actual part.

Expand

Actually, SSTU-ST-DOS-COM shows up fine when it's launched, and in the right click menu in the VAB parts list, but the part in the VAB isn't showing the resources correctly, which is a bit odd.

JoseEduardo · August 2, 2016

On 8/2/2016 at 2:43 AM, Gerbwerz said:

Finally tracked down what is making the SM auto decouple. Its a mod called Routine Mission Manager. http://spacedock.info/mod/362/Routine Mission Manager

If you have the CM set to SM DC Staging Disabled it will auto decouple on return from scene change. If you Enable it won't. Easiest way to repro is is create a stack of CM and SM, go to pad, F5 quicksave, F9 Reload. Bam, decouples every time.

Expand

weird part is that I don't use this mod and I still have this issue... I'll try checking which is the culprit on my install

Shadowmage · August 2, 2016

On 8/2/2016 at 10:44 AM, Domfluff said:

USI-LS patch for the COS docking hubs:

Reveal hidden contents

// The US ISS docking hubs consist of the primary Life support equipment for US-style modules.

@PART[SSTU-ST-HUB-COS]
{
   MODULE
   {
       name = ModuleLifeSupport
   }

   RESOURCE
   {
       name = Supplies
       amount = 500 // One kerbal for a month before recycling
       maxAmount = 500
   }
   RESOURCE
   {
       name = Mulch
       amount = 0
       maxAmount = 500
   }
RESOURCE
{
name = ReplacementParts
amount = 500
maxAmount = 500
}

   MODULE
   {
       name = ModuleLifeSupportRecycler
       CrewCapacity = 4
       RecyclePercent = .75 //ISS recycles at 75% efficiency
       ConverterName = Life Support
       tag = Life Support
       StartActionName = Start Life Support
       StopActionName = Stop Life Support

       INPUT_RESOURCE
       {
           ResourceName = ElectricCharge
           Ratio = 1
       }
   }
   MODULE
   {
       name = USI_ModuleFieldRepair
   }

}

This works fine, and I think I'm happy with the resulting numbers.

I've figures for the rest of the parts (aside from the COS-HAB and COS-LAB, since the masses are wrong), but I think I'm running foul of the way you've defined the parts - applying something like the above (with different values) to the SSTU-ST-DOS-COM part, for example, shows supplies and mulch in the right-click menu in the VAB, but not on the actual part. Equally, defining multiples involves some other weirdnesses - some values are shared between parts, etc.

I'll upload the patch as written to the Github thread, but it's not really functional at the moment.

Expand

No worries, every little bit that is up there will help in the end when I start working on putting it all together. Thanks for your help with the USI-LS stuff, your input and info will certainly go a long way towards getting the initial balance figured out with that mod... which is very much needed now that it has progressed past the supplies-timer stage.

On 8/2/2016 at 12:55 PM, tater said:

The masses, etc have not been balanced at all, it was mentioned up the thread.

Expand

On 8/2/2016 at 1:25 PM, Domfluff said:

Sure, but that doesn't look like what the part config files are trying to do - the different sizes of LAB and HAB module don't all have 3.2 tons set, which presumably means that something isn't working the way it's supposed to (which could indicate further errors)

Expand

Indeed, they have not had any sort of final balance or fine tuning... but they should have a rough balance pass on them which (I thought) included some mass differentiation between them.

Is the 3.2 what you are seeing listed on the part, or what it weighs in the VAB? As they are completely unrelated values; that which is listed on the part in the part list is taken from whatever is specified in the part.cfg mass = field. The actual value used for the mass however is determined by the plugin and has zero relation to whatever is displayed in the parts list. (On an unrelated note, I wish there were a way to make those values consistent; but the stock mass-modifier method queries for mass prior to the PartModules being initialized and as such they have no internal data and cannot modify it at that point as they should)

Either way, I'll take a look at it today/tonight

On 8/2/2016 at 2:35 PM, Domfluff said:

Actually, SSTU-ST-DOS-COM shows up fine when it's launched, and in the right click menu in the VAB parts list, but the part in the VAB isn't showing the resources correctly, which is a bit odd.

Expand

Note that you need to patch SSTUVolumeContainer module to add the resources to its approved list and to modify its default resource ratio. Trying to modify the part-resources directly will cause problems and will not work well.

(have not yet taken a look at your patch data to see how you were doing it, but that would be the main cause off the top of my head)

On 8/2/2016 at 2:43 AM, Gerbwerz said:

Finally tracked down what is making the SM auto decouple. Its a mod called Routine Mission Manager. http://spacedock.info/mod/362/Routine Mission Manager

If you have the CM set to SM DC Staging Disabled it will auto decouple on return from scene change. If you Enable it won't. Easiest way to repro is is create a stack of CM and SM, go to pad, F5 quicksave, F9 Reload. Bam, decouples every time.

Expand

Thanks for taking the time to investigate

The fact that you've narrowed these problems down to a single conflicting mod means that I may actually be able to get them fixed (if the problem is something that I -can- fix).

I've already got the Atmosphere Autopilot conflicts fixed up (last night, after the release, so not available yet), and will take a look at RMM today to see if I can spot where the problem is at.

On 8/2/2016 at 4:52 AM, StickyScissors said:

@Shadowmage So, i have found an issue between SSTU and FAR. Specifically your engines and FAR.

To reproduce:

1. Install SSTU

2. Install FAR

3. Make some sort of craft in the editor

4. select engine (or any other part with an integrated engine)

5. NullRef. NullRef. NullRef. NullRef. NullRef. NullRef.

Note: Service modules such as the Orion, Apollo, and Soyuz spit out s*** loads of NRE's at once, while engines only spam out 2 when you select them. Also, im not on the latest version, i don't have the internet speeds or data to support downloading this mod every few days, so i'm on the previous patch.

Output_log: https://www.dropbox.com/s/u0g01j1imuyvdn9/output_log.txt?dl=0

Expand

I do not use or offer support for FAR, sorry.

I think its a great concept, but the execution runs into too many errors (such as these). If my parts work fine in stock, they should work fine under FAR; otherwise there is something being done by FAR that it shouldn't be (last time he was caching meshes instead of copying them; likely the same problem that never got fixed).

-If- I feel like torturing myself someday I may install FAR and take a look at things; but I wouldn't hold your breath on it... I'm quite sick of installing mods that I don't use to test problems that I'll never run into.

On 8/2/2016 at 5:42 AM, tater said:

HUB-COS is now working nicely. The welded ports might be nice with some "this end forward" markings (I'm terrible about forgetting to flip the bloody 2.5m stock port, lol).

Regarding the inflatables and game balance, how are the container volumes considered? I would suggest that whatever they end up holding, perhaps they start with the volume available after inflation, but, well, empty. This would require supply launches, just as a Bigelow will need a launch to get the thing up there, and more to fit it out. I'm thinking in particular of the tori given the huge volumes that would need fitting out vs the collapsed sizes. Dunno if that's worthwhile or not, but It seems like there should be a cost/benefit trade between solid and inflatable. The inflatables in general, and the tori in particular are nice late-tech tree items.

I would sort of like to see an ability to stop rotation. In RL turning the thing when loaded and spun up would be non-trivial.

Expand

Ability to stop rotation, sure. The choices are 'auto rotate' or 'only rotate through user selected toggle' though, cannot have it both ways.

Inflatables -- I really don't feel like dealing with the inflated/deflated differences; would be a ton of coding for zero additional useful features. I'm fine using the honor system in my games... if other people want to 'cheat'... well.. I'm not going to stop them.

tater · August 2, 2016

Yeah, that makes sense regarding the honor system. The trick of course is in estimating what should be reasonable. Is the current max volume the actual volume of the inflated part? I wonder what a "realistic" guideline would be for a part that is to be used as habitation as a function of total volume?

Perhaps the default state of the part assumes use as a hab with the stated crew, then has EC, mono, LS, etc. judged to be reasonable for that number of crew.

Is the large torus 5860 m³(a 5m cross sectional diameter)? That would not count wall thickness, obviously. I could imagine coaxial tori, where the space between the interior torus (the living space) and the outer skin is filled with propellant/LS/etc (water, basically, it's good radiation shielding).

Even with no IVA I like to try and visualize the interior .

tater · August 2, 2016

Spitballing:

A 0.5m wall thickness (including tankage) means that ~64% of the large torus would be tankage (slop it down for the actual shell). That leaves 36% of the interior volume for crew. That still leaves over 170 hitchhiker volumes to play with .

From a LS standpoint (I'm thinking USILS right now) I would perhaps give it... all the capabilities. I might even be inclined to treat the tori all as labs, or certainly the large ones. there is enough volume for 30 crew to all have large volumes for habitation, AND have multiple labs of the stock volume.

Anyway, those kind of back of the envelope calls can inform decision making in terms of how players use them. I think the tori should be expensive in career mode, and perhaps off the end of the existing tree.

If I throw cryogenic engines back in my mod mix, I bet I could make some cool long-duration ships with those spherical tanks and the large torus . (that has a retro look that appeals to my design sense).

tater · August 2, 2016

Is it possible to have a part that is like the small central torus part, but no torus, and instead maybe 3-4 radial nodes for attaching stuff?

Edited August 2, 2016 by tater

Domfluff · August 2, 2016

I don't know if it's possible to animate a node like that, but it would be cool.

One thing re:inflatables - in Roverdude's in-progress UKS stuff, he has some code to make all radially attached parts drop off when the module inflates. It's a nice solution to the clipping problem.

blowfish · August 2, 2016

It's not really possible to have a part move other parts. At least not easily. That's what Infernal Robotics is for (but it's still not perfect - for instance, this is incompatible with KJR).

Actually there is a stock module but it's pretty hacky and probably incomplete. My recommendation would be: don't bother.

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

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation