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

[RedParadize]

I think you have something interesting there. Right now the external support look like something strap around the torus as a after taste. Obviously thats just a first draft, but if the external support would blend more with the rest of the torus, it could feels like torus is unfolding under it. See what I mean? I don't know how to explain that clearly...

[Akira_R]

@Shadowmage

Is there a reason that changes made to the PARTUPGRADE nodes using MM wouldn't actually change anything in game?

Currently I am trying to change a number of things but for example this:

Spoiler

PARTUPGRADE
{
    name = SSTU-MFT-M1
    partIcon = SSTU-SC-TANK-MFT-A
    techRequired = propulsionSystems
    entryCost = 25000
    title = Modular Tank Min Diameter Decrease (0.625m)
    description = Decreases the minimum diameter available for modular fuel tanks (SSTU-SC-TANK-XXX).  This upgrade allows tanks as small as 0.625m to be created.
}

With this:

Spoiler

@PARTUPGRADE[SSTU-MFT-M1]:FIRST
{
    !techRequired = DELETE
}

MM is supposed to work on config nodes other than just PART, and according to the logs it is applying the patch with no error:

Spoiler

[ModuleManager] Applying node z_AkiraLTD/Akira_CTT_Adjustments/@PARTUPGRADE[SSTU-MFT-M1]:FIRST to SSTU/Parts/Upgrades/UpgradeParts-MFT/SSTU-MFT-M1

And in the MM Config Cache the techRequired node is gone and in the ones I'm changing it reflects the changed tech node:

UrlConfig
{
    name = SSTU-MFT-M1
    type = PARTUPGRADE
    parentUrl = SSTU/Parts/Upgrades/UpgradeParts-MFT
    url = SSTU/Parts/Upgrades/UpgradeParts-MFT/SSTU-MFT-M1
    PARTUPGRADE
    {
        name = SSTU-MFT-M1
        partIcon = SSTU-SC-TANK-MFT-A
        entryCost = 25000
        title = Modular Tank Min Diameter Decrease (0.625m)
        description = Decreases the minimum diameter available for modular fuel tanks (SSTU-SC-TANK-XXX).  This upgrade allows tanks as small as 0.625m to be created.
    }
}

But it doesn't remove the upgrade part from the tech tree, and the other ones that I am trying to move around aren't moving either, I am asking here first because it looks like MM is doing it's thing properly.

I was wondering if maybe something one of your plugins is doing is doing it's stuff before MM has a chance to do it's thing?

 

If you need any more info like the complete .cfg I have made or my output_log let me know.

EDIT: Oh and changing it manually does have the expected results.

Edited November 9, 2016 by Akira_R

[Jimbodiah]

What are you trying to do there? You are removing the techrequired before the mm patch is applied. If you want to change it do it like this:

@PARTUPGRADE[SSTU-MFT-M1]:AFTER[SSTU]
{
    techRequired = start
}

[Shadowmage]

10 hours ago, Akira_R said:

@Shadowmage

Is there a reason that changes made to the PARTUPGRADE nodes using MM wouldn't actually change anything in game?

Currently I am trying to change a number of things but for example this:

With this:

MM is supposed to work on config nodes other than just PART, and according to the logs it is applying the patch with no error:

But it doesn't remove the upgrade part from the tech tree, and the other ones that I am trying to move around aren't moving either, I am asking here first because it looks like MM is doing it's thing properly.

I was wondering if maybe something one of your plugins is doing is doing it's stuff before MM has a chance to do it's thing?

 

If you need any more info like the complete .cfg I have made or my output_log let me know.

EDIT: Oh and changing it manually does have the expected results.

If you want to remove the upgrades completely, it is a slightly more complex setup.  What exactly are you trying to accomplish?  Removal of the tech limits entirely, moving them around, ??

The proper steps needed will be different for each...

[Akira_R]

43 minutes ago, Shadowmage said:

If you want to remove the upgrades completely, it is a slightly more complex setup.  What exactly are you trying to accomplish?  Removal of the tech limits entirely, moving them around, ??

The proper steps needed will be different for each...

I am only trying to hide that one in particular, as I have set the min diameter for tanks to 0.3125. Removing the techRequired to hide the upgrade should work just fine, doing it manually works, it removes the upgrade from that tech node so it never gets applied.

I am also using MM to try and move some of the other upgrades to different nodes with essentially the same patch:

Spoiler

@PARTUPGRADE[SSTU-MFT-D1]:FIRST
{
    @techRequired = generalRocketry
}

But it doesn't work, if I manually change the techRequired field in the upgrade cfg it works just fine.

11 hours ago, Jimbodiah said:

What are you trying to do there? You are removing the techrequired before the mm patch is applied. If you want to change it do it like this:

@PARTUPGRADE[SSTU-MFT-M1]:AFTER[SSTU]
{
    techRequired = start
}

Yes because I want to hide that upgrade as I have already set the min diameter lower than what that upgrade does. I have tried :FIRST :AFTER[SSTU] and :FINAL and it doesn't change, none of the MM patches an the @PARTUPGRADE's have any effect.

 

EDIT:

FYI the only reason those patches show :FIRST is because when I was using :FINAL nothing was happening, so I wanted to see if maybe that would change something, and it didn't

The MM patch is working as designed, the config that is output in MMs config cache reflects the change, however it has no change on the actual upgrade nodes in the tech tree. If I change values in the .cfg manually the changes do take effect in the tech tree in game. Which is why I suspected that either your plugin is grabbing the data from the config before MM has a chance to do anything to it, or your plugin is pulling the data straight from the file and not from the loaded config that has been changed by MM.

Edited November 9, 2016 by Akira_R

[Jimbodiah]

...

Edited November 9, 2016 by Jimbodiah

[Shadowmage]

20 minutes ago, Akira_R said:

I am only trying to hide that one in particular, as I have set the min diameter for tanks to 0.3125. Removing the techRequired to hide the upgrade should work just fine, doing it manually works, it removes the upgrade from that tech node so it never gets applied.

I am also using MM to try and move some of the other upgrades to different nodes with essentially the same patch:

  Reveal hidden contents

@PARTUPGRADE[SSTU-MFT-D1]:FIRST
{
    @techRequired = generalRocketry
}

But it doesn't work, if I manually change the techRequired field in the upgrade cfg it works just fine.

Yes because I want to hide that upgrade as I have already set the min diameter lower than what that upgrade does. I have tried :FIRST :AFTER[SSTU] and :FINAL and it doesn't change, none of the MM patches an the @PARTUPGRADE's have any effect.

 

EDIT:

FYI the only reason those patches show :FIRST is because when I was using :FINAL nothing was happening, so I wanted to see if maybe that would change something, and it didn't

The MM patch is working as designed, the config that is output in MMs config cache reflects the change, however it has no change on the actual upgrade nodes in the tech tree. If I change values in the .cfg manually the changes do take effect in the tech tree in game. Which is why I suspected that either your plugin is grabbing the data from the config before MM has a chance to do anything to it, or your plugin is pulling the data straight from the file and not from the loaded config that has been changed by MM.

What you might be seeing is the stock part caching mechanism at play.

When you first start a career game all of the parts in the tech tree, and their positions, are written into the persistence file.  When you reload that save game it uses teh data from the persistence file rather than the actual 'live' data from the tech tree.

 

Try keeping your patches in place that you say are working, but starting a -new- career game.

[Akira_R]

11 minutes ago, Jimbodiah said:

Don't use either, use AFTER[SSTU].

Is there a reason that :AFTER[SSTU] and :FINAL would have a different effect?

Not necessarily doubting you lol, but from my understanding of how MM works it shouldn't, using :FINAL just makes it apply after all other patches have been applied. I will have to wait until I get home from work and class but I will give it another shot to see.

5 minutes ago, Shadowmage said:

What you might be seeing is the stock part caching mechanism at play.

When you first start a career game all of the parts in the tech tree, and their positions, are written into the persistence file.  When you reload that save game it uses teh data from the persistence file rather than the actual 'live' data from the tech tree.

 

Try keeping your patches in place that you say are working, but starting a -new- career game.

Yeah I know about the tech tree persistence thing, I have been starting new saves every time to verify my parts are moving to the nodes I want, and all the parts have, it's only the PARTUPGRADE things that aren't moving when I use MM.

Edited November 9, 2016 by Akira_R

[Shadowmage]

8 minutes ago, Akira_R said:

Is there a reason that :AFTER[SSTU] and :FINAL would have a different effect?

Not necessarily doubting you lol, but from my understanding of how MM works it shouldn't, using :FINAL just makes it apply after all other patches have been applied. I will have to wait until I get home from work and class but I will give it another shot to see.

Yeah I know about the tech tree persistence thing, I have been starting new saves every time to verify my parts are moving to the nodes I want, and all the parts have, it's only the PARTUPGRADE things that aren't moving when I use MM.

Sounds like it might be time to hit up the ModuleManager thread then; if there are problems with MM, that would be the place to ask, and where the people with the knowledge on it will be found.

[Akira_R]

4 minutes ago, Shadowmage said:

Sounds like it might be time to hit up the ModuleManager thread then; if there are problems with MM, that would be the place to ask, and where the people with the knowledge on it will be found.

Is PARTUPGRADE a stock thing or is it something that you implemented?

I guess I will, the only reason I asked here first is because according to the output_log and the MM config cache MM is doing it's job properly.

I don't really know anything about c# nor do I know how KSP handles things, but I have written just barely enough c++ to suspect that it would be a fairly easy mistake to make to have a class pulling it's variables from a file location instead of from a cached copy of the file, or maybe having the plugin grab it's data from a file when it is initialized which from my understanding plugins are initialized prior to MM doing it's thing, now maybe with something like KSP or c# that is not at all an easy mistake to make, that was just what made sense to me given that based on all the diagnostic info available to me at this time indicates that MM is working as intended. The cached config loaded by the game has changed, but something doesn't seam to be respecting that change.

[Shadowmage]

1 minute ago, Akira_R said:

Is PARTUPGRADE a stock thing or is it something that you implemented?

I guess I will, the only reason I asked here first is because according to the output_log and the MM config cache MM is doing it's job properly.

I don't really know anything about c# nor do I know how KSP handles things, but I have written just barely enough c++ to suspect that it would be a fairly easy mistake to make to have a class pulling it's variables from a file location instead of from a cached copy of the file, or maybe having the plugin grab it's data from a file when it is initialized which from my understanding plugins are initialized prior to MM doing it's thing, now maybe with something like KSP or c# that is not at all an easy mistake to make, that was just what made sense to me given that based on all the diagnostic info available to me at this time indicates that MM is working as intended. The cached config loaded by the game has changed, but something doesn't seam to be respecting that change.

The entire PARTUPGRADE system is stock code, and a stock system.  I don't do anything with it aside from what you see in the configs (e.g. there is nothing in my plugins that is messing with things).

I'll see about testing some of this when I get a free moment at my home computer.  Your patches looked like they should have been working (mostly, at least the recent ones posted); and if the MM cache looks correct, it would point towards the error being somewhere in the stock code.

However that doesn't really make too much sense, as the stock code is merely loading from those config nodes, which have already been adjusted by MM by the time the stock code sees the data.  Unless for some reason the stock code is skipping the ModuleManager altered configs and loading the files directly from disk.  Which is why I had suggested asking in the MM thread -- if there is a conflict with MM and stock code, they will be the ones who would know about it.

One other suggestion would be to clear out the ModuleManager cache files (physics, tech-tree, configs);  who knows, maybe its patching the configs correctly, but loading an old unaltered tech-tree file.

 

 

 

One more, probably final, attempt at bracing geometry/animations for the inflatable-torus-centrifuge parts.  Two bracing/reinforcement variants; wide, or skinny.  I really like the look of the 'wide' one when deployed, but sadly there is no good way to animate it; it will always distort when retracted, which makes the bracing look bad.  The skinny variant I think looks acceptable; it keeps the same width in both stowed and deployed states, and has minimal distortion during the animation; it also keeps the bracing setup simple and workable.

Looks like keeping things simple is the only way these will work out (for me anyway).  Someone with more time (and patience, and who actually likes doing modeling) could come up with something better; but I've already spent far more time than I had set aside for figuring out the animations (spent the last 2 1/2 days working on it, with close to zero progress, which is about the extent of my patience).

Going to work on unwrapping the rest of the larger torus, and begin working on the central pillar geometry, crew tube, and truss geometries.

[Akira_R]

3 minutes ago, Shadowmage said:

The entire PARTUPGRADE system is stock code, and a stock system.  I don't do anything with it aside from what you see in the configs (e.g. there is nothing in my plugins that is messing with things).

I'll see about testing some of this when I get a free moment at my home computer.  Your patches looked like they should have been working (mostly, at least the recent ones posted); and if the MM cache looks correct, it would point towards the error being somewhere in the stock code.

However that doesn't really make too much sense, as the stock code is merely loading from those config nodes, which have already been adjusted by MM by the time the stock code sees the data.  Unless for some reason the stock code is skipping the ModuleManager altered configs and loading the files directly from disk.  Which is why I had suggested asking in the MM thread -- if there is a conflict with MM and stock code, they will be the ones who would know about it.

One other suggestion would be to clear out the ModuleManager cache files (physics, tech-tree, configs);  who knows, maybe its patching the configs correctly, but loading an old unaltered tech-tree file.

*snip*

Ok good to know! Yeah I was deleting all of the MM cache files every time I reloaded the game just to make sure that wasn't happening, it does look like it is loading them straight from the disk which is weird. This is the first time I've seen the PARTUPGRADE stuff so I thought it was something you had implemented, I'll take it over to the MM thread and see what they have to say, if it's stock code then it's got nothing to do with you lol. Thank you!

I like the look of the thinner ones personally 

[tater]

What about something just in between? The widest the "brace" can go without distorting much, or is that what the skinny version is right now?

Whatever you do will be awesome, though. No worries.

[Jimbodiah]

Also try deleting the PartDatabase.cfg. Mage tipped me on that a while back when I was having some issues with the game.

[Akira_R]

36 minutes ago, Jimbodiah said:

Also try deleting the PartDatabase.cfg. Mage tipped me on that a while back when I was having some issues with the game.

Where is that found?

[Jimbodiah]

KSP directory, same level as the GameData folder.

[RedParadize]

1 hour ago, Shadowmage said:

Looks like keeping things simple is the only way these will work out (for me anyway).  Someone with more time (and patience, and who actually likes doing modeling) could come up with something better; but I've already spent far more time than I had set aside for figuring out the animations (spent the last 2 1/2 days working on it, with close to zero progress, which is about the extent of my patience).

Going to work on unwrapping the rest of the larger torus, and begin working on the central pillar geometry, crew tube, and truss geometries.

 

Sure, there could be much more cable and stuff. But the goal is not to spend hours in awe looking at the most fashionable torus ever. It suppose to have been designed my engineer, who are known to have no sense of taste whatsoever...

So, let me say its the nicest torus shaped thing that have ever flown in kerbal space.

Edited November 9, 2016 by RedParadize

[Shadowmage]

Settled on using the skinny bracing; any wider and it creates problems with distortion and things not lining up correctly.  Even with the skinny geometry I have to bash things around a bit at the mesh level to keep things from clipping or showing back-faces.

Working on how to best do the windows.  Or even -if- to do windows.  Seems like I have two choices there: windows that get distorted with the mesh scaling, or using a method similar to the HAB parts and keeping the window mesh the same size while manipulating the surrounding geometry / beveling.  So, here are a couple different window concepts.  Top of image = HAB styled window.  Left = very large window panel (distorted in animation), right = circular window (distorted in animation)(e.g. similar to DOS), bottom = smaller window panel (distorted in animation).

I'm leaning towards either the top or bottom options, probably more towards the bottom.  Yes the bottom one gets distorted in the stowed state, but I think it looks the best while deployed.  The top option offers the least distortion during animation, but looks kind of bad in both the stowed and deployed states.

So I guess the question for today comes down to -- windows, or no windows? 

If they are included I'll likely go with the option on the bottom (smaller inset panel, scaled with the rest of the mesh).  It is simpler to model and looks fairly nice when in the deployed state.  For this smallest torus I would likely include one or two per quarter (so 4-8 total on each side).  Larger torus would have more windows, keeping about the same spacing between them as on the small torus.

I'm also okay with not having windows.  It goes against the 'deluxe habitation' concept a bit, is much simper to model, animate, and texture, but makes for a bit of a 'plain' looking part.

[tater]

Windows. Bottom is fine. I think, as you say, it makes it more visually interesting.

If anyone ever steps up and offers to do an IVA, it will be fun to watch the universe spin by  .

[Jimbodiah]

I like the bottom window. The large one is too big, the round one is so cliche and the beveled one is too kerbal

[RedParadize]

Top window look good, the bevel could be smaller I guess. The shape of the bottom one is better. You could definitively go without windows, the ISS don't have windows all over the place. If tourist want view they can go to the observatory. ( they would probably be sick anyway.)

[tater]

The number of windows can be small, however.

[Vrana]

No window. But some window isn't horrible either. Just do your thing, Shadowmage, you are the talent behind this.

Edited November 9, 2016 by Vrana

[Shadowmage]

One more render; includes speculative window geometry, more bracing (mostly mimicking PJ's parts at this stage), and a bit more work on the central pillar (cleans up all of clipping when in the stowed state).

I think it is looking fairly good, and can easily be split into smaller segments for texturing (reducing texture size / increasing texture resolution).  Will look much better after I get some more detailed texturing on it (proper normals) and finish up the central pillar geometry. 

Pillar is currently 1.25m at the top/botom, tapering down to ~0.8m in the middle, with the crew tube being ~0.7m in diameter (should be big enough for a non-helmeted kerbal to fit through).  Really not sure of how much more it could be improved given the limitations imposed by the animation.

Still a bit torn on the windows.  As was pointed out, having windows in a rotating habitat is just asking for some dizzy astronauts (is that a thing?).  Would make more sense with the slower rotation speed on larger parts.  But I also think they add a nice bit of detailing to an otherwise simple model.  Eight might be too many though (rather 16, as they are on the back side as well); may cut it down to half of that number for this particular part.

Contemplating counterweights for the rotation; certainly doable, and a nice bit of easy to add detail.

Most of the style/concepts/methods can easily be applied to the larger torus parts, and I'll likely start doing the rough geometry work on them for the bracing/etc.  The largest ones are going to be a bit more detailed / have more bracing on them, probably with alternating windowed / non-windowed segments.

[Jimbodiah]

Wow!!!