Jump to content

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


Recommended Posts

19 hours ago, RaiderMan said:

...thats where the problem is occurring...just cant seem to make the patch work.

 

I dont mind a docking port free version being a separate part. on that basis, would using the pods.cfg as is be safe?

So... here is the extracted patch that you are needing.  Note the index on the !MODEL node -- it tells it to remove the 2'nd occurrence of that node.  Taken directly out of the repo/patches that someone linked for you earlier ( https://github.com/FFCJoseEduardo/SSTU-Expansion/blob/master/GameData/SSTU-Expansion/Parts/ShipCore/Pods.cfg#L274-L286 )

+PART[SSTU-SC-C-CM]:FINAL
{
	@name = SSTU-SC-C-CM-NDP
	@title = SSTU - SC-C - CM - Re-Entry Module - No Docking Port
	!MODEL,1
	{
	}
	@node_stack_top = 0,1.5957,0,0,1,0,1
	%node_stack_BPC = 0,1.3957,0,0,-1,0,2
	!MODULE[ModuleDockingNode]
	{
	}
}

 

(very soon I'm going to stop doing all this work for other people; I have not the time to be writing patches and doing research for other people, when they should full well be capable of doing the research and writing it themselves; every time I do this it only takes away from actual development time.... you guys do actually want me to update SSTU sometime this century, right?  So, expect in the future that I will simply ignore support requests for trivial stuff like this.  Nothing personal, but I've got things to get done, and nobody else is going to do them.)

 

 

In general development news:

Yes, I'm still working on SSTU.  Unfortunately my real life schedule has not opened up much, and sounds like it will actually be getting busier over the next few months, including a trip to Dallas in the next couple of weeks to help with some setup and training on the systems that I'm responsible for.

But I'm still working on things.  Recent efforts have been towards getting TU and KSPWheel to be usable and stable, and are nearly there.  I have a couple small issues to clean up in TU regarding transparent materials/shaders/flags-on-parts, and need to fix the dust-effects in KSPWheel (started/WIP/no rush on it).

I've also been spending time cleaning up some UI and other odd issues with the new SSTUModularPart module, and have been making pretty good progress on that as well.  I've actually made it far enough that the part loads, the models load, and the texture sets work.  Most of the model-switching functionality is working, but I've got some config and/or code-side issues regarding model positioning to cleanup.  Progress.  Slow, but undeniable.

Current state of the UI, and general look at how many things are working/broken (note all of the broken pods in the editor part selection window.... still a lot to fix).

JcyZ5dU.png

 

 

Link to post
Share on other sites
14 hours ago, Shadowmage said:

Yes, I'm still working on SSTU.  Unfortunately my real life schedule has not opened up much, and sounds like it will actually be getting busier over the next few months, including a trip to Dallas in the next couple of weeks to help with some setup and training on the systems that I'm responsible for.

Hahaha! told you! People don't get promoted to work less! Glad for you, and be a poodle when the salary negotiation time will come!

Link to post
Share on other sites
4 minutes ago, Norcalplanner said:

That is a gloriously cluttered UI that makes me giddy with anticipation.

Indeed, it is a bit busy.  Many of those buttons will be removed/disabled unless their corresponding functions are present on the part -- e.g. the solar and RCS model, parent, and layout buttons won't be present on the standard MFT tanks (but will be available on the MUS, MSM, and most StationCore parts).

Standard tanks should have the following model/texture controls:

  • Diameter
  • Nose Model
  • Upper Model
  • Core Model
  • Lower Model
  • Mount Model
  • One texture-set slider for each currently active model slot (slots with no models, or with a model with no texture selections, will not show any UI controls for that slot)

So 11 controls on a standard fuel tank regarding model and texture control.  One more for fuel type selection, plus a few buttons for other misc features (toggle flag, customize fuel type, recoloring GUI, toggle interstage nodes).  Still going to be quite busy, but not quite as cluttered as the screenshot above.  Perhaps at some point in the future I'll return to my dreams of making a custom UI for these parts... but for now I think the stock PAW-UI will be sufficient.

Link to post
Share on other sites

Bit of a showcase of just how...configurable... the new fuel tanks will be (and the part-module in general).  This is all a single part:

7rYsghI.png

Apparently my model positioning issues were just configs that hadn't been updated/fixed yet.  A few edits later, and everything just 'fell into place' as it were.  One step closer... (but still many more to go).

 

Link to post
Share on other sites
8 minutes ago, Jimbodiah said:

Will there be a possibility for a vertical offset for the panels?

Possibly, though I don't think I currently have any UI controls or code in place for it.  The main problem with it would be defining the range in which the model could be offset.... but I might be able to borrow he validation that I've setup for the RCS positioning (the valid range of movement is defined in the model definition of whatever model the solar/rcs would be mounted to; including an 'angle' parameter for conic parts).  The second (and probably larger) problem would be ensuring that the position specification is valid for every solar panel model; some solar panel models extend down from their mounting point, some upwards; likely to cause problems with mesh clipping.

The current solar panel support was based on the existing needs of the StationCore parts -- which only require static placement of the solar panels; though I could certainly see the use of positional controls for part setups like the MSM.

They will have 'parent slot' controls at the very least.  So you'll be able to specify that the solar (or rcs) should be mounted on the CORE, NOSE, etc. slots, and the models will be moved and positioned appropriately for the model and slot they are mounted on.  I'll know more about the specifics of these features after I start working on the MUS and MSM parts.

Link to post
Share on other sites
2 hours ago, Shadowmage said:

Bit of a showcase of just how...configurable... the new fuel tanks will be (and the part-module in general).  This is all a single part:

7rYsghI.png

Apparently my model positioning issues were just configs that hadn't been updated/fixed yet.  A few edits later, and everything just 'fell into place' as it were.  One step closer... (but still many more to go).

 

Holy crap.

Link to post
Share on other sites
On 3/28/2018 at 7:52 PM, tater said:

Holy crap.

Hehe, yeah.  Might be a bit...overkill. :)

 

On 3/28/2018 at 9:45 PM, T-10a said:

So I take it we may not need to tank stack in the future with this new feature? :D


For most uses a single part should be sufficient.

Specifically, I will be including 'tank extension' models in the adapter selection lists for the UPPER and LOWER slots; so a single part could be Nosecone, upper-tank, central tank, lower tank, mount/adapter.

 


Yes, still making progress on the SSTU update.  Slow, but definite progress.  I -think- I have all of the basic model setup, positioning, and validation code working, and the next bit to work on is attach node updating/part re-positioning (which is already written, just needs to be adapted/cleaned up to match the rest of the system).

Link to post
Share on other sites

@Shadowmage I noticed that there's no height slider in the photos you posted. Will that still be there in the newer version?

Also, has there been any discussion about integrating more USI or CRP resources into the  tanks? I really enjoy the USI-LS integration right now, and will frequently make a single tank with LF, O, EC, MP, Supplies, Mulch, and Fertilizer. Being able to add things like Karbonite or Water would be appreciated in a SSTU tank. And if I should be asking RoverDude about this instead, please accept my apologies for the social faux pas.

Link to post
Share on other sites
1 hour ago, Norcalplanner said:

I noticed that there's no height slider in the photos you posted. Will that still be there in the newer version?

It is still there; that is what the 'CORE' slider will adjust.

There never was a 'length' adjust option (even if it might have been labeled as such).  It simply switched between pre-compiled models of different lengths.  The 'core' control will do the same.

Link to post
Share on other sites

More info or you will not get suport I think.  KSP version, log files.... Also, if you are running RO then I think Mage will point you to ask RO about that as SSTU does not support RO.

Edited by Jimbodiah
Link to post
Share on other sites
13 hours ago, Russekof71 said:
hello, I play with SSTU RSS / RO but the capsule Orion does not work

what do u mean by does not work...try install RSS/RO Via CKAN. usally the installation of those two are screwed up. CKAN fixes that.

 

to install that put all of the stuff that comes with CKAN in the main KSP folder (the folder out of the gamedata folder) also if the problem is SSTU go to here.

where it shows compatibility it says SSTU and use this version.

Link to post
Share on other sites

Had a few moments finally to do some comparisons of the new stock engines vs SSTU's parts, seeing if it would be worth it to replace my models with the stock ones.  The new MH-stock engines are pretty good geometry wise, comparable detail to SSTU.  Most are fairly close dimensions wise as well (for 64% of real scale).  Textures... are fairly well done as well, though certainly in the stock-alike aesthetic.

F-1 -- The SSTU engine is quite a bit larger, both in length and in diameter.  I think it is because the stock version is scaled down further to enable a Saturn-V setup at 5m diameter (SSTU would use 6.25m+ diameter for the same replica)

GxUAifd.png

 

RD-107 is very similar, both geometry and dimensions wise.

CEdS8Mn.png

Stock J-2 looks good from the front.  Texture is well done with plenty of contrast to make the engine interesting, though it is lacking of the full-length cooling tubes that were quite apparent on this engine.  Obviously the stock version is also lacking the PBR based metallic reflections, but still not bad for legacy texturing.

S7Oc0Qj.png

Geometry was good in the front, but lacks some details on the rear.

QPog9Kq.png

 

Overall I think the new stock models are pretty good.  I'll still be keeping the current ones around in SSTU though, if for no other reason than to make sure the models are still around even when the DLC is not installed.

 

Hoping to get a few hours this week to do more cleanup on SSTU configs (and code).  Progress has been slow, but steady -- an hour here, two there.  I think TU and KSPWheel are finally in a 'stable' state, and so I can finally concentrate on cleaning up the remaining problems in SSTU.

Link to post
Share on other sites

Shadowmage, I think your models are fantastic.  Your mod is one of my favorites.  Thanks so much!  Keep up the great work!  I was admiring the J-2 last night...

nXr6uhF.pngDnFJix9.png

Edited by Joker58th
Wasn't sure how to insert an image.
Link to post
Share on other sites

@Shadowmage Thank you for keeping us updated. Just wanted to know if, and I know you'll say "when it's ready", and I know you are a busy guy as I am, but...

I miss SSTU in my 1.4.2 KSP installation :wink: 

Sorry for pestering you but anyway those models of yours are still better than those of the DLC I think :wink: Any release "window" ?

Edited by FrancoisH
Link to post
Share on other sites

I'm trying to have the stock launch clamps pump LH2 into the tanks using the stock Generator module. It seems to work for USI-LS Supplies, but LqdHydrogen does not seem to flow. I checked the resource definition for LH2 but there is no pump restriction that I can find. Has anyone gotten this to work for LH2?

 

@PART[launchClamp1]
{
    -MODULE[ModuleTestSubject] {}

	@MODULE[ModuleGenerator]
	{

		OUTPUT_RESOURCE   // no NEEDS[SSTU] as I don't play without it ;)
		{
			name = LqdHydrogen
			rate = 20
		}

		OUTPUT_RESOURCE:NEEDS[USILifeSupport]
		{
			name = Supplies
			rate = 1
		}
	}
    
}

 

Edited by Jimbodiah
Link to post
Share on other sites

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