shadowmage45 / SSTULabs

Dev repository for testing/unfinished KSP parts/plugins/etc.
Other
62 stars 41 forks source link

More minor part issues #633

Closed vossiewulf closed 6 years ago

vossiewulf commented 6 years ago

SC-TANK - MFT-S - checker and stripe patterns don't work, show plain white. texture sets work, just need to recolor them DOS-LAB:

Actual problems to solve:

vossiewulf commented 6 years ago

Also all of the DOS parts are difficult to control under RCS, as both pitch and yaw inputs generate roll components as well, I normally like doing my own docking but I had to let MJ handle these.

shadowmage45 commented 6 years ago

SC-TANK - MFT-S - checker and stripe patterns don't work, show plain white.

It is because you need to select a color pattern for them from the recoloring GUI. By default they are white/white, intentionally.

Has same lack of seat 0 inventory, all of these parts have that issue

Part of the same MFT-KIS integration problem that is fixed in #630

Also all of the DOS parts are difficult to control under RCS, as both pitch and yaw inputs generate roll components as well, I normally like doing my own docking but I had to let MJ handle these.

Stock problem nothing I can do about it. I put the RCS ports where they need to be -- if stock code can't figure out how to use them without inducing roll... that is a problem that should be filed as a stock bug report. (there is zero reason why there should be pitch/yaw -> roll coupling on these parts, except crappy stock code)

When you loop through all the options for nose or bottom and roll over to the first one again, the texture changes to S1. Rolling over again doesn't change it again.

Not quite sure what you are referring to on that one? Have any screenshots for examples?

vossiewulf commented 6 years ago

Not quite sure what you are referring to on that one? Have any screenshots for examples?

I've now seen variations of this with several parts, basically you're losing track sometimes of the current texture choices. With a DOS part, just instance one in the VAB, it will be all off-white. Then cycle through all the Top/Nose choices for the part, keep going at the end so you roll over to the beginning of the choices again. When you do this the nose's texture will change from plain white to the S1 texture.

In other cases a sub-part ceases to exist, and you forget what the texture choice had been if that sub-part is reinstanced. Good way to reproduce this is take the tank that is a series of pressure vessels, set its body length to four so there are four pressure spheres, set a center texture of silver on it. Then shorten the body length down to 2 or 1 and then back to four, the center texture will be back to default gold. This is only a problem because of your recoloring options, someone can spend time getting color choices right and then one wrong click on the body length and it has to be redone.

I'm sure there are other examples besides the pressure tank as well.

shadowmage45 commented 6 years ago

Not sure of a way to 'fix' what you are seeing, and it sounds like the proper handling for those parts.

If you select a variant that no longer has a texture set, it is going to lose any existing selection (such as the length = 1 on the MFT-S part, which means there is NO central model, only the adapters).


Basically it will try and keep whatever texture set you currently have selected -IF- the new model also has that texture set. Otherwise it will default to whatever the 'default' texture set is for the newly selected model.

If the newly selected model has no texture sets (empty model), then the 'current' texture set selection for that segment is set to 'none. If you then switch over to a new model for that segment, it will see that it currently has 'none' assigned for texture set, and correctly use the 'default' texture set for the newly selected model.


MFT-S-texture assignment workflow

taterkerman commented 6 years ago

The Hub-COS and DOS have "Recolorable" for both elements in the recoloring GUI, instead of whatever labels they need.

This is in the latest dev version I just installed, BTW.

taterkerman commented 6 years ago

CFG parts need rocket parts, right?

I was making some screen shots for a step-by-step, and came across this:

cfg issue The VAB says the same thing, materials kits, but the fuel type is RocketParts in the cfg file.

This is the version of the dev build I DLed last night, BTW.

shadowmage45 commented 6 years ago

There is a patch in the 'optional patches' and/or in the mod-integration folders that changes it to material kits if one of the USI mods is installed. It should only activate if MKS/UKS is present, but perhaps that portion of it is broken. (unless you have MKS, in which case, that is correct and intended)

taterkerman commented 6 years ago

On the dev version I threw in the optional patches, but don't have MKS, this is SSTU clean with EVE (and just today that cool LM lander).

taterkerman commented 6 years ago

I was worried I was telling him something wrong all of a sudden, even though I had just built an inflatable---but that was before I tested the dev version and left the optional patches in (I was just wanting stock crap to go away, lol).

Regardless, I'll take some nice, SSTU only screen shots in the VAB and orbit and show inflation for the station core wiki.

taterkerman commented 6 years ago

The Modular Upper Stage, and MFT-SM parts' RCS have no visual effect, though the included MP/hypergolic drains.

Jimbodiah commented 6 years ago

Yeah, I hate that about MKS and always remove the EPL patch from MKS. It's a serious PITA as everything in EPL is changed out for those resources.

shadowmage45 commented 6 years ago

The Modular Upper Stage, and MFT-SM parts' RCS have no visual effect, though the included MP/hypergolic drains.

Is this in the dev branch, or current full release? Edit: NVM, silly question; obviously the dev-branch, as the MSM isn't in live releases.

Investigating now -- I did some changes to the RCS-updating code used throughout, but it shouldn't have broken things to that extent.

And, fixed. Had some incorrect thrust transform names. Also cleaned up some of the other MUS-rcs code, as it was a bit... ugly...

taterkerman commented 6 years ago

RCS structures don't attach to all the *-V RCS parts (except the 1F-V), and float as the scale value is decreased. Shown below are parts scaled to 0.25.

rcs

It would seem desirable for the RCS stand-off structures to sink a little into the parts as the new docking port backplates do, though perhaps no so much. The use case I am thinking of is as pictured with the awesome new MFT-L part, as this could allow attachment to such parts without too much kooky clipping required (easy enough to do until you need to move something).