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

[Shadowmage]

1 minute ago, tater said:

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

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]

[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]

6 minutes ago, 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.

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]

8 hours ago, 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.

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]

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]

Just now, tater said:

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

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]

1 hour ago, 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.

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]

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]

3 minutes ago, 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).

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]

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]

On 7/31/2016 at 3: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.

 

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]

@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]

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]

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]

USI-LS patch for the COS docking hubs:

 

Spoiler

// 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.

 

[tater]

3 hours ago, 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.

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

[Domfluff]

25 minutes ago, tater said:

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

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]

3 hours ago, 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.

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]

12 hours ago, 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.

 

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]

 

3 hours ago, 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.

 

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.

 

1 hour ago, tater said:

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

 

1 hour ago, 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)

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

 

11 minutes ago, 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.

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)

12 hours ago, 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.

 

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.

9 hours ago, 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

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.

9 hours ago, 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.

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]

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]

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]

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]

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]

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.