Jump to content

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


Shadowmage

Recommended Posts

19 hours ago, Shadowmage said:

Not really interested at this time.  Unless you can show how those engines would fill a particular gap in the engine lineup;  I do not have stats on-hand though, so could not say from memory.

I could see use for a RD-0124 by being a upper stage engine with 294kN thrust, but at the same time, I don't think it fits the mod, as it has multiple chambers (plus, three RL-10A-4 or four to five RL-10A-3 could do the same work)

same goes for RD-170, a bit more powerfull than the F-1, but other than the RD-191 I don't see how it could fit in the mod, as RD-170 has four chambers and RD-180 two, with RD-191 being the only single chamber version

however this was more of a question than a request, current set of engines is awesome already :) (and I think Bobcat's Soviet Engines could be fixed...)

Link to comment
Share on other sites

Downloaded the newest release, but keep encountering a problem - KSP wont load past the SSTU-SC-ENG-SRB-A file.

Is anyone else getting this?

Edit: Have tested the mod on a completely fresh install of KSP just to check it wasn't conflicting with other mods. No luck.

Edit2: Deleted the SRB-A config file,   game won't load past SRB-B. Deleted all SRB config files, now the game won't load past SSTU-SC-GEN-ISDC.... Am i missing something here?

Edited by Qwarkk
Link to comment
Share on other sites

Wasn't there a change to no longer be dependant on CRP? Mage?

Maybe bundle MM/CRP/Textures with future versions as I see more new people starting to install this mod.

@Qwarkk  here is a link to the textures pack, place in the GameData folder next to SSTU (not inside it). https://github.com/shadowmage45/SSTULabs/releases/download/0.3.28-pre1/SSTU-TextureSets-1.5.zip

Link to comment
Share on other sites

No, he said on the curse thread that you'll need CRP and MM. Textures, I'm not to sure, but it's not mentioned as a dependency. I have all three on my test build and it works just fine. 

Links:

CRP: 

Textures: https://github.com/shadowmage45/SSTULabs/releases/download/0.3.28-pre1/SSTU-TextureSets-1.5.zip

Edited by ComatoseJedi
Link to comment
Share on other sites

21 minutes ago, ComatoseJedi said:

No, he said on the curse thread that you'll need CRP and MM. Textures, I'm not to sure, but it's not mentioned as a dependency. I have all three on my test build and it works just fine. 

Turns out I'm an idiot. Removed CRP a few days ago thinking i wasn't using it... Have reinstalled and everything works fine.

Thanks :)

Link to comment
Share on other sites

Strange, as I -thought- I had fixed the CRP dependencies for Sat/Sundays releases (I even tested it without CRP installed...).  Ohwell..  If I hear of any more problems I'll just start bundling it and moving the LH2 patch stats into the part configs.  One less thing I'll have to swap around for the 1.1 update.

Spent a bit of time yesterday working on shuttle landing gear.  And then I remembered what a PITA the stock modules were to use/set things up for (ModuleLandingGear does not support suspension or built-in steering; ModuleWheel does not support animations; I need both)... so spent the remainder of my modding time yesterday writing up the preliminaries of a custom wheel module (which should be usable for wheels, landing gear, or landing legs, of fixed/extensible/animated/non-animated varieties; with support for multiple independent wheel colliders being managed by a single module).

Sadly, this module will be short lived, as I'm 100% certain that it will break with 1.1 and need to be rewritten.  I can only hope that whatever wheel package Squad picked up is usable by modders without having to pay for another license.  Can also hope (but do not anticipate) the stock ModuleWheel is usable, useful, and easy to setup, and that I do not need to (re)write a custom solution; only time will tell.

 

And spending a bit of time today writing up a module to manipulate the GUI fields of other modules. This will be capable of renaming or hiding any GUI field/action/event for any other part-module, based on some simple syntax/nodes added to their configs.  Ideally this will work for nearly any module / field / event / action, though there might be a few cases where there are some things it cannot override (due to the module itself constantly changing the name/status).

The reasoning behind this is to cleanup some of the extraneous right-click menu options for some of the parts -- such as removing all of the RCS 'thrust limiter' and 'enable/disable' buttons from the SC-E parts; or renaming or hiding/removing the 'Control From Here' options ('Control From Cockpit', 'Control From Docking Port', 'Control From Outhouse', etc).  Will see how useful this module is... it should work for many cases, but I know there are going to be a couple that it just won't work appropriately for (would need someway to hook into the modules own code / use logic to determine naming/status etc).

Link to comment
Share on other sites

@Shadowmage Please don't spend too much time on a short-lived module.  We don't have a clear idea how far 1.1 is, but based on past releases it won't be more than a month.  If it took that long to get landing gear integrated, I personally would have no issues.

Now that you have single-axis gimbaling working, would it be possible to get the larger exhaust nozzle to provide roll control on the RS-68?  I do see that the nozzle is currently not its own object, so it would require a bit of texture work to separate it.  But as far as I understand, the rest of the setup would be relatively simple.

Link to comment
Share on other sites

1 hour ago, blowfish said:

@Shadowmage Please don't spend too much time on a short-lived module.  We don't have a clear idea how far 1.1 is, but based on past releases it won't be more than a month.  If it took that long to get landing gear integrated, I personally would have no issues.

Now that you have single-axis gimbaling working, would it be possible to get the larger exhaust nozzle to provide roll control on the RS-68?  I do see that the nozzle is currently not its own object, so it would require a bit of texture work to separate it.  But as far as I understand, the rest of the setup would be relatively simple.

Thankfully I have a good portion of the code already written for the existing custom landing-leg module; mostly I need to add support for steering, brakes, and optionally motors (though, that may wait until 1.1/rewrite of the module).  I need the landing gear working and integrated in order to complete the model; or at least I need to model the landing gear/etc before I can start texturing, and it is helpful if they are rigged properly from the start.

Pretty sure I already have the module to a mostly workable state for what I need for the shuttle parts, may take a few more hours of work to add in the steering and brakes code, and probably a few more hours after that in order to get it balanced and working smoothly.  Should likely have it done and working by the end of the day.

 

RS-68 -- possible, sure, but not really anything I want to mess with at the moment. If you want to open an issue ticket to make sure it doesn't get forgotten about, I can look into it next time I'm feeling like I want to work on something different.  Will try and at least get it cleaned up for the 1.1 update.  Also not sure how handle the thrust differential for the exhaust nozzles;  If I add a thrust transform for the roll nozzle, I'll need to add an identical/symmetrical one for the other exhaust nozzle, or the entire thing will be off-balance all the time (and I'm not sure if this is possible with the existing geometry, as the nozzle exits may be in different non-symmetrical positions compared to the part origin).

Edit:  Also not really sure I want to do it at all, given how unstable the single-axis gimbal setup made the RD-107/8 engines.

Edited by Shadowmage
Link to comment
Share on other sites

2 hours ago, Shadowmage said:

RS-68 -- possible, sure, but not really anything I want to mess with at the moment. If you want to open an issue ticket to make sure it doesn't get forgotten about, I can look into it next time I'm feeling like I want to work on something different.  Will try and at least get it cleaned up for the 1.1 update.  Also not sure how handle the thrust differential for the exhaust nozzles;  If I add a thrust transform for the roll nozzle, I'll need to add an identical/symmetrical one for the other exhaust nozzle, or the entire thing will be off-balance all the time (and I'm not sure if this is possible with the existing geometry, as the nozzle exits may be in different non-symmetrical positions compared to the part origin).

Edit:  Also not really sure I want to do it at all, given how unstable the single-axis gimbal setup made the RD-107/8 engines.

Well thanks for looking at it regardless.  Looking at the exhaust ports, it looks like thrust might be ever so slightly asymmetric, but it's definitely nothing SAS couldn't handle.  I'll create an issue, of course you can decide to do it or not :D

I think is a lot less issue-oprone than on the RD-107/8 engines, where all the thrust vectoring is provided by the verniers.  In this case, the main bell still provides the pitch/yaw vectoring, with the exhaust port only providing roll (which you usually need very little of anyway).  The  gimbal module could (and should) be configured so that it only responds to roll input. EDIT: I think I was confusing it with RCS and that limiting the control inputs isn't possible.  Not 100% sure though.

Edited by blowfish
Link to comment
Share on other sites

58 minutes ago, blowfish said:

Well thanks for looking at it regardless.  Looking at the exhaust ports, it looks like thrust might be ever so slightly asymmetric, but it's definitely nothing SAS couldn't handle.  I'll create an issue, of course you can decide to do it or not :D

I think is a lot less issue-oprone than on the RD-107/8 engines, where all the thrust vectoring is provided by the verniers.  In this case, the main bell still provides the pitch/yaw vectoring, with the exhaust port only providing roll (which you usually need very little of anyway).  The  gimbal module could (and should) be configured so that it only responds to roll input. EDIT: I think I was confusing it with RCS and that limiting the control inputs isn't possible.  Not 100% sure though.


Stock gimbal is not able to be limited on axis (input or rotation) -- I had to 'cheat' with the RD-10X engines using a custom look-constraint module to lock it to a single axis of rotation (the actual gimbal merely rotates a target; the constraint module rotates the thrust transform/geometry along a single axis to line up as close as it can with the rotated target transforms position).

Aye, hopefully the effect won't be as bad with it only being roll control.... suppose we'll find out though.

Link to comment
Share on other sites

Well, the field-hiding/renaming module mostly works.  A few bits to sort out on it as i was sure there would be (some modules update their fields during Update/etc ticks, and will need to overwrite those values per-tick).  But, at least it cleans up all the extra RCS thrust/isp/enable/disable buttons from the SC-E fuselage, making the right-click menu of reasonable length.  Can always improve on it in the future.

RS-68 will be receiving vectored roll-exhaust (and thrust) with the next update.  It does mean that the engine is no longer perfectly balanced, but even with the slight thrust offset/differential it is still very flyable, and actually has some roll-control now with single engine setups.  Still doing tweaking and testing on it, but should be available with the next update.

Wheel module is... coming along.  Deployment/retract works, suspension follows the wheel collider appropriately.  Wheel properly collides.  Have some wheel-collider setting based stuff to clean up (target position and spring force I believe).  Still need to implement steering, brakes, and motors.... but those shouldn't be too difficult to get working after I get the basics online.

And the wheels are coming along as well.  Will probably take me longer to model the wheels fully than it will to get the module working.

Here is the current geometry for the nose-wheel (front is to the left); fully a WIP, still working on overall shape and rigging of the various bits.  Rigging works including suspension, deployment-actuator piston, drag-brace, and steering/torque arm

 

 

YjWO91c.png

Link to comment
Share on other sites

1 hour ago, ComatoseJedi said:

Wheels are by far one of the buggiest things in the KSP universe. Landing gear is just as worse. I do not envy you on your journey to make this work. 

 

46 minutes ago, Jimbodiah said:

I found Kerbal Foundries to have an excellent selection of wheels and track (love tracks!). The stock wheel explode when you look at them, and they all behave like they are on ice; zero grip anywhere, just sliding down hills with your brakes on.

 

Indeed :)

Thankfully I have an advantage that most others don't -- I'm writing my own wheel module, so I know exactly how things need to be setup, and can do custom work to fix many of the other annoying issues (such as slippage/flippage).
Going to be a very simple wheel module in its initial incarnation, but will expand on the functionality with 1.1 and its forced rewrite.

 

Link to comment
Share on other sites

16 minutes ago, Shadowmage said:

I'm writing my own wheel module, so I know exactly how things need to be setup, and can do custom work to fix many of the other annoying issues (such as slippage/flippage).

Will you be releasing that module as a API for others to use? With a Rover pack planned, I'd love to not have to work with buggy wheels :)

Link to comment
Share on other sites

40 minutes ago, akron said:

Will you be releasing that module as a API for others to use? With a Rover pack planned, I'd love to not have to work with buggy wheels :)

It will be usable just as any other part of the SSTUTools.dll plugin is;  yes, you can use these custom modules for your own parts.  No guarantee if you can adapt existing parts to them, as some have quite special setups; but many of the modules are highly configurable, so the chances are good.

Will I release it as a stand-alone plugin?  No, I have no reason to do so.  But the entire plugin is quite small (a few hundred kilobytes), so is easy enough to bundle into other distributions if needed.

13 minutes ago, RedParadize said:

Soon, Shadowmage will rewrite KSP.

Don't think I haven't been tempted, more than once :)

And then I remember what a PITA Unity is.... and my aspirations quickly vanish.  I would have to port things to another engine entirely;  I also don't have source-access, so would have to completely re-implement everything from scratch.  And that's not touching on copyright issues...

 

But soon I will have a good enough list of parts that you could mostly delete the stock ones and never even notice they were missing :)  That is almost as good as rewriting the game :)

 

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...