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

[ComatoseJedi]

18 hours ago, Shadowmage said:

As far as I know this is an issue in KJR that has been fixed in the most recent dev-versions but is not yet publicly available.

Edited April 29, 2016 by ComatoseJedi
Reason why we don't have the Dev version, it's not available for public, yet.

[blowfish]

@ComatoseJedi KJR keeps compiled DLLs in the repository.  The change has in fact been committed.

[MacLuky]

1 hour ago, Shadowmage said:

Indeed, same issue as reported here: https://github.com/shadowmage45/SSTULabs/issues/298

As far as I know this is an issue in KJR that has been fixed in the most recent dev-versions but is not yet publicly available.  Will be doing some testing over the next few days to see if it is fixed with the new KJR.

Sorry i didn't check your issue tracker. Can I just take the https://github.com/ferram4/Kerbal-Joint-Reinforcement master to test or is the dev branch in a separate repo?

[blowfish]

5 minutes ago, MacLuky said:

Sorry i didn't check your issue tracker. Can I just take the https://github.com/ferram4/Kerbal-Joint-Reinforcement master to test or is the dev branch in a separate repo?

The relevant commit is in master.

[Shadowmage]

Yep -- that was pretty much how I was intending to do testing with it; just grab the .dll straight from the repo and replace the existing one; was how I had KJR for the pre-releases on day one.

If you guys get to testing it before I do, please let me know how it goes

 

[blowfish]

2 minutes ago, Shadowmage said:

Yep -- that was pretty much how I was intending to do testing with it; just grab the .dll straight from the repo and replace the existing one; was how I had KJR for the pre-releases on day one.

If you guys get to testing it before I do, please let me know how it goes

 

I usually like to replace the whole KerbalJointReinforcement folder in GameData, since there might be config changes too, but yeah, that's the idea.

[MacLuky]

Thats what I did, Jeb and Val are exchanging war stories while docked. Thanks for pointing me in the right direction. Works like a charm

Edited April 29, 2016 by MacLuky

[Shadowmage]

I can confirm that the docking / petal-adapter bug has been fixed in the dev versions of KJR; or at least I cannot duplicate it with the test-cases I was using previously.

Will need to wait for Ferram to publish a public release, and/or just point people towards the dev stuff temporarily.

 

[ComatoseJedi]

1 minute ago, Shadowmage said:

I can confirm that the docking / petal-adapter bug has been fixed in the dev versions of KJR; or at least I cannot duplicate it with the test-cases I was using previously.

Will need to wait for Ferram to publish a public release, and/or just point people towards the dev stuff temporarily.

 

Did you try to undock?

 

[Shadowmage]

21 minutes ago, ComatoseJedi said:

Did you try to undock?

 

No, but I didn't previously have any problems with undocking; only the initial docking was causing errors.  Will test that out shortly

Edit:

Undocking works fine.  Redocking after undocking works fine

 

Edited April 29, 2016 by Shadowmage

[Shadowmage]

Updated testing release is available, compiled for KSP 1.1.2; includes updated ModuleManager and CRP:

https://github.com/shadowmage45/SSTULabs/releases/tag/0.4.31-pre7

Bugfixes; lots and lots of bugfixes; every known outstanding bug has been squashed.  Not much else in this update; though the LC-POD parts have been re-exported and should be back to usable state.

[Shadowmage]

Did a bunch more post-release cleanup of various things on my TODO list; added transmitters to all crewed pods and service modules, cleaned up some engine mount stuff, and some misc. texture cleanups.

All that is left on the pre-balancing TODO list is all SC-E related; and most of that is all in regards to the wheels.  Still working on the replacement WheelCollider, and it seems like it might still be a few weeks out... so I may well start on the balancing stuff for all other parts this next week.  I anticipate it will likely take a couple weeks to get all of the balance sorted out; but that means the first 'stable' releases are only a couple weeks away now (may or may not have SC-E in those initial releases, depending on if I can get the wheel stuff sorted out).

[Theysen]

@Shadowmage: Will you be able to bring in the "Right Click Menu" stays in position mechanic again? I remember you introduced this feature in a 1.0.5 release and personally I think it's quite convenient to have and saves a bit of frustration

 

 

[JoseEduardo]

isn't 1.1 supposed to have a fixed right click menu already?

[Cheesecake]

Theysen means the right click menu in the VAB not in flight. The right click menu in flight is fixed with 1.1.

[JoseEduardo]

I remember having a fixed right click menu in the VAB during the pre-release, did they remove that after the pre-release?

Edited May 1, 2016 by JoseEduardo

[Shadowmage]

3 hours ago, Theysen said:

@Shadowmage: Will you be able to bring in the "Right Click Menu" stays in position mechanic again? I remember you introduced this feature in a 1.0.5 release and personally I think it's quite convenient to have and saves a bit of frustration

 

 

Nothing I can do about it this time; the menu already -is- staying in position, they've merely changed it to be pinned by the bottom rather than the top, which is where the problems come from.  There was at least one bug report/feedback issue on it during the pre-release but nothing was done about it.

Edit:  But yes, I understand the frustration; is quite annoying to have the button you need to press moving up/down in the window.

Edited May 1, 2016 by Shadowmage

[DasBananenbrot]

Looks promising  Some real nice work already. Will probably test it soon. One quesiton: What about RealChute compability? If you didn't made any configs so far, I think I  maybe could make some MM configs for the parts who have integrated parachutes (probably only the capsules I guess)

[Theysen]

4 minutes ago, Shadowmage said:

Nothing I can do about it this time; the menu already -is- staying in position, they've merely changed it to be pinned by the bottom rather than the top, which is where the problems come from.  There was at least one bug report/feedback issue on it during the pre-release but nothing was done about it.

Edit:  But yes, I understand the frustration; is quite annoying to have the button you need to press moving up/down in the window.

Hm well, thanks for the answer anyways. If there's no workaround then for the VAB editor windows - would it be inconvenient to handle all the current options in a window like your latest resource manager? Just an idea, which is - I guess - not that easy and not on your scope right now.

[Shadowmage]

1 minute ago, DasBananenbrot said:

Looks promising  Some real nice work already. Will probably test it soon. One quesiton: What about RealChute compability? If you didn't made any configs so far, I think I  maybe could make some MM configs for the parts who have integrated parachutes (probably only the capsules I guess)

They will not work with RealChutes due to differences in how the parts are setup; these parachutes are not part of the part models, and do not use standard animations at all.  The SSTU parachute module is already physics/force based and will work fine in FAR/etc; more than adequate for its intended purpose; as such Real-Chutes is simply not needed and of zero benefit.

6 minutes ago, Theysen said:

Hm well, thanks for the answer anyways. If there's no workaround then for the VAB editor windows - would it be inconvenient to handle all the current options in a window like your latest resource manager? Just an idea, which is - I guess - not that easy and not on your scope right now.

I was originally intending on doing such; complete with preview icons for the different model options.  But then the 'New Unity GUI' system turned out to be so obtuse and painful to actually use in game that I scrapped the idea.

I might look into it again in the future if someone figures out a way to use the Unity prefab GUIs in game without thousands of lines of supporting code.

[DasBananenbrot]

11 minutes ago, Shadowmage said:

They will not work with RealChutes due to differences in how the parts are setup; these parachutes are not part of the part models, and do not use standard animations at all.  The SSTU parachute module is already physics/force based and will work fine in FAR/etc; more than adequate for its intended purpose; as such Real-Chutes is simply not needed and of zero benefit.

 

Okay, good to know. 

[tater]

If you option-click to move a tank, the copied tank looks OK in VAB until you mouse over it, then the flag (if small) stays, but the rest of the decal goes transparent... I'll test it some more. 

[Shadowmage]

42 minutes ago, tater said:

If you option-click to move a tank, the copied tank looks OK in VAB until you mouse over it, then the flag (if small) stays, but the rest of the decal goes transparent... I'll test it some more. 

Known issue; is actually a stock bug regarding shaders with transparency.

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

If I remember correctly, this is due to the way the KSP shaders are implemented on top of the Unity5 standard shader/rendering system.

[tater]

Gotcha. I only happened to notice because I decided to test SSTU for 1.1.2, and picked that "badge" flag randomly, which I had not picked in stock tests.

Edited May 1, 2016 by tater

[Shadowmage]

So.. the theme for this week is balance and cleanup.

Did a pass over the career-mode costs for most of the command pods and service modules yesterday, bringing them inline with what a similar setup would cost if using stock parts.  Will be looking into the rest of the ShipCore series parts next (ICPS, HUS, BPCs) to bring them in-line with stock-built equivalents; after that will be all of the 'general' parts (decouplers, fairings, etc).

Also swapped over all of the service modules and command pods to use the 'Hypergolic' fuel type for their engine and RCS.  The only things still using monopropellant for RCS are the ICPS and HUS... because if I understand correctly the actually did/would use a cold-gas thruster for attitude control (not technically 'monopropellant' but close enough...).  So mostly appropriate.

Have been debating on if I should add VolumeContainer support to the command modules and service modules; does anyone see a need for swappable/alterable resources for those parts?  E.G. removing some propellant to add KIS storage, or include some different resources (no clue why on that one).  Could also potentially make adding Life-Support supplies a bit easier as they could be added as a second sub-container that would allow for the player to adjust the amounts/ratios of the various LS supplies (or remove some in favor of more KIS storage or otherwise).  Thoughts?

On the note of cleanup (sort of) - am working on implementing a thrust-curve editor for the MSRB parts;  this will be an in-editor tool where you can either use some pre-made thrust curves, adjust the premade ones to your liking, or come up with completely new thrust curves of your own.  About the only thing I haven't figured out is how I'm going to 'save' the custom thrust curves into the part; there is very limited / no support for saving complex config-node data and I may have to hack it all into a single String variable to save it into the persistence file for that craft/part.  Might also offer a 'save as premade curve' option so that you can easily add additional premade thrust curves (will need to learn/figure out c# disk IO for this one).

Will be continuing the balancing and cleanup throughout the week, with the next testing release likely put together on Saturday; should give time for a reasonable amount of balancing and updating things.