Jump to content

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

Shadowmage

By Shadowmage
in KSP1 Mod Development

 Share

Recommended Posts

Shadowmage

Shadowmage

Posted
  • Author
Posted

Ahh, the fun of strong encapsulation....  This is (part of) the public interface of the (partially rewritten) 'ModelModule' -- the collection of code that handles the positioning and scaling of models, texture set and recoloring handling, and the in-editor model selection bits (model selection, texture selection, etc).

RwuFaHo.png

Lots of generic boilerplate stuff.  Pretty boring.  Makes for code that is more pleasant to use (for the developer), faster to develop with, and if done properly leaves fewer possibilities for mistakes ( = fewer bugs, and easier to track down).

 

But then once in awhile, you get into the actual fun(ctional) bits of the code:
(nothing special, just one of the random model setup related methods... this method takes an input model from the GameDatabase, keeps any transforms specified in the model definition config, examines for and also keeps the parents of the desired transforms, and finally destroys any transforms that were not kept)

M2qs3fE.png

If you ever wondered how much 'fun' programming is... ^^^ that is about it it.  Lots of writing, lots of structure, and lots of waiting on KSP to start up so you can test changes.

Link to comment
Share on other sites
Akira_R

Akira_R

Posted
Posted (edited)

I find coding to be quite enjoyable as a hobby, I write some basic Python and MatLab, I learned C++ back in the stone age when I was in high school, but have pretty much forgotten everything syntax wise about it, the main thing I held onto is the thought/problem-solving process when writing/de-bugging, and general design theory. Have wanted to take the plunge into C# for a while now so that I could help contribute to mods but just haven't gotten around to it.

I like it because it gives my ADD addled brain something to chew on, it thoroughly enjoys the problem solving process.

Edited by Akira_R
Link to comment
Share on other sites
Nightside

Nightside

Posted
Posted (edited)

@RaiderMan, yes to both Soyuz spacecraft and launcher, the Soyuz stuff is among my favorite parts of this mod.

The spacecraft bits are called SC-A.

For the launcher use MFT-A with Soyuz caps and MFT-D tanks for boosters. 

SSTU uses real names for engines, so a quick trip to Wikipedia can help you find those.

Edited by Nightside
Link to comment
Share on other sites
Shadowmage

Shadowmage

Posted
  • Author
Posted
4 hours ago, Akira_R said:

the main thing I held onto is the thought/problem-solving process when writing/de-bugging,

Those are the important bits, as they transfer well to nearly all other languages.  Flow control (if/for/while), and boolean operations (&& / ||) are probably the most vital bits to understanding programming.  Past that it is mostly just language syntax and special features.

46 minutes ago, Nightside said:

SSTU uses real names for engines, so a quick trip to Wikipedia can help you find those.

@RaiderMan

Use an MFT-A for the central core, sized at 1.4375m diameter (set to 1.25m and then use the slider to adjust), and select the 'Soyuz' nose adapter (4 variants available if I remember correctly).  Engine is RD-108A for the central core (if the fuel tank is sized correctly, the mount should line up very precisely with the fuel tank diameter).

The radial boosters should use the MFT-D tank (has integrated decouplers for surface attached use), and the RD-107A engines.

 

3 hours ago, Jimbodiah said:

You means lots of coffee and loads of swearing?

Yep, sometimes more of one than the other.  The precise mixture varies from day to day.

 

20 hours ago, Jimbodiah said:

I do programming of different sorts (motion control), but find it quite enjoyable actually.

Nice; I've had a little bit of experience at that -- programming servo controls for RC use (complex scratch-built RC aircraft).  I'm guessing yours is probably more robotics or automation oriented though.

Same stuff with KSP, only the results are less real-world physical.  Still very neat the first time you program something and see it actually work in-game.

 

General Development News:

Progress is coming along nicely on work for the ModelDefinition / ModelModule systems rewrite.  Just got the code back to a state where there are no more compiler errors, so I might be able to start working on adapting configs and doing some actual testing -- making sure the existing part-module still function, and that all of their configs have been adapted correctly (ModularEngineCluster, solar panels, ISDC).  The new 'SSTUModularPart' code is still only about halfway done, but with all the back-end support worked out, the rest of the work on it should go a lot faster/smoother.

Going to be a slew of new features coming with this code update.  The basic system that handles how engine layouts position the engine models is being brought over to the rest of the model-definition system -- so any use of a 'model definition' will consist of the definition to use, and the layout data to use for it (default layout is a single model positioned at origin).  This is mostly so that things like RCS and solar panels can have 'built in' support for different layouts... but it might also be adapted for other uses -- e.g. multiple ascent-tank layout options on the LC pod parts, or multiple engine layout options on the ISDC, or multiple landing strut layouts on a fuel tank (rigid, no suspension).

 

Still (slowly) working on geometry for the landing legs.  Have the first set mostly worked out (light legs), and some early WIP geometry for another set (heavy legs for paneled tanks).  Still going to be at least a few weeks before there is anything usable on them.  Mostly I'm finding it difficult to create realistic looking (and functioning) legs that are generic enough to be used for more than one fuel tank.  Really not easy; stock models simply ignored all of that, which is why you have the single-piston leg setups that exist in stock (that in real life would suffer from all sorts of stability problems due to lack of lateral bracing).

I've got some good concept stuff from @tater and @Jimbodiah already, and I would welcome anyone else to drop by the thread and submit ideas/concepts -- https://github.com/shadowmage45/SSTULabs/issues/652

Link to comment
Share on other sites
tater

tater

Posted
Posted

Yeah, the single stick legs look odd compared to RL solutions. I think you have chosen well with the light legs in terms of embracing some clipping, and that can play out with other choices as well (or something like the "backplate" on the docking ports?)

Link to comment
Share on other sites
Agustin

Agustin

Posted
Posted (edited)

Engines are not done yet, right? or is there something wrong with my install? I mean the pbr shaders.. There are some with no textures it seems.... like boring grey. Mounts do have textures but not the engines themselves at least in my install.

example: merlin 1A

Edited by Agustin
Link to comment
Share on other sites
tater

tater

Posted
Posted
1 hour ago, Agustin said:

Engines are not done yet, right? or is there something wrong with my install? I mean the pbr shaders.. There are some with no textures it seems.... like boring grey. Mounts do have textures but not the engines themselves at least in my install.

example: merlin 1A

Sounds like an install problem. I’ll check at some point later for you.

Assuming you mean no textures at all.

Link to comment
Share on other sites
Agustin

Agustin

Posted
Posted (edited)
Just now, tater said:

What does your game data folder look like?

eMsiDMg.png

Inside Textures Unlimited Stock I have thee 3 files:

TU_PorkjetStock

TU_PartOverhauls

TU_VenStockRevamp

I think the file DefaultShaderAssignments-Engines - PBR is only patching the F1 and J2, and also there the textures of example merlin 1 in SSTU PBR assets folder...
I just created some  totally grey png's there and added some CFG and then the engines have reflections (although I can't make any changes) like this:

Spoiler

KSP_MODEL_SHADER
{
 name = SSTU/Assets/SC-ENG-Merlin-1A
 model = SSTU/Assets/SC-ENG-Merlin-1A
 TEXTURE
 {
  shader = SSTU/PBR/Metallic
  texture = _MainTex, SSTU-PBR/Assets/SC-ENG-Merlin-DIFF
  texture = _BumpMap, SSTU-PBR/Assets/SC-ENG-Merlin-NRM
  texture = _MetallicGlossMap, SSTU-PBR/Assets/SC-ENG-Merlin-MET
  texture = _AOMap, SSTU-PBR/Assets/SC-ENG-Merlin-AO
 }
}

and added the totaally grey textures in the SSTU-PBR/assets folder to test (i am not modder or anything)

Edited by Agustin
Link to comment
Share on other sites
Agustin

Agustin

Posted
Posted
Just now, Jimbodiah said:

A screenshot might help. I know the merlins don't have a lot of detail to begin with.

Some of these have better textures, but not recoloring and metallic properties, and some other seem to have no textures at all. The upper one is the one that I added the patch to make it mettalic, but it looks too homogeneous... 

T92qr4f.png

Link to comment
Share on other sites
Agustin

Agustin

Posted
Posted
44 minutes ago, Delta_6 said:

What the BLEEPING BLEEP is the SSTU Reflection probe, why the BLEEP is it destroying my craft and how the BLEEPING BLEEP do I disable it?

provide more information.

specs, performance during playing the game (see how much ram are you using). image of your gamedata folder as well as a link to your ksp.log file

maybe someone can help you but you have to provide something.

Link to comment
Share on other sites
Shadowmage

Shadowmage

Posted
  • Author
Posted
9 hours ago, Delta_6 said:

What the BLEEPING BLEEP is the SSTU Reflection probe, why the BLEEP is it destroying my craft and how the BLEEPING BLEEP do I disable it?

Try updating your TexturesUnlimited -- there were some issues in the early versions that could cause explosions on decoupling.

Otherwise, going to need more info -- logs, screenshots, you know... the usual stuff that should be posted with each and every support request.

Link to comment
Share on other sites
Nightside

Nightside

Posted
Posted
12 hours ago, Delta_6 said:

What the BLEEPING BLEEP is the SSTU Reflection probe, why the BLEEP is it destroying my craft and how the BLEEPING BLEEP do I disable it?

I can’t tell if you are just complaining or if you actually have a question. 

The reflection probe is part of the PBR system that makes reflections possible. I believe you can get rid of it by not installing the PBR pack, is that right @Shadowmage?

Link to comment
Share on other sites
Sudragon

Sudragon

Posted
Posted (edited)

Could i get a sanity check on this? Code for Xenon gas into SSTU tanks 
  

SSTU_FUELTYPE:NEEDS[Bluedog_DB]
{
    name = XenonGas
    RESOURCE
    {
	    resource = XenonGas
	    ratio = 1
    }
}    




SSTU_RESOURCEVOLUME:NEEDS[Bluedog_DB]
{
	name = XenonGas
	volume = 0.003049
}


@PART[SSTU-SC-TANK-MFT-A|SSTU-SC-TANK-MFT-S|SSTU-SC-TANK-MFT-R|SSTU-SC-TANK-MFT-LV|SSTU-SC-TANK-MUS|SSTU-SC-TANK-MFT-D]:NEEDS[Bluedog_DB]
{
	@MODULE[SSTUVolumeContainer]
	{
		@CONTAINER,0
		{
			resource = XenonGas

		}
	}
}

 

Edited by Sudragon
Link to comment
Share on other sites
Jimbodiah

Jimbodiah

Posted
Posted (edited)

Xenon already has it's volume defined in SSTU, so no need to add it again. Also xenon does not "needs bdb" as it is a stock fuel type and has already been defined in the base sstu install.

 

I take it you are trying to add the sstu container to BDB parts?  All you need to do is add the SSTU_VolumeContainer module to the BDB part like so: 

    MODULE
    {
	    name = SSTUVolumeContainer
	    volume = 1000
	    baseContainerIndex = 0
	    subtractMass = false
	    subtractCost = false
	    enableContainerEdit = true
	    enableFuelTypeChange = true
	    CONTAINER
	    {
		    name = Battery
		    percent = 100
		    tankageVolume = 0
		    tankageMass = 0
		    ecHasCost = false
		    defaultModifier = standard
		    defaultResources = ElectricCharge,1
		    resource = LiquidFuel
		    resource = LqdHydrogen
		    resource = Oxidizer
		    resource = MonoPropellant
		    resource = Aerozine50
		    resource = NTO
		    resource = ElectricCharge
		    resource = RocketParts
		    resource = Ore
		    resource = XenonGas
		    modifier = standard
	    }
    }

 

Check my patches for examples, as I've already added the VolumeContainer to the BDB Aardvark part.

 

Edited by Jimbodiah
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.

×
 Share
Go to topic listing
×
×
  • Create New...