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

[Nightside]

On 12/11/2018 at 5:54 AM, eagle92lightning said:

Thanks, the only problem is I need them to work with SSTU because I am working on a Deep Space Launch Vehicle or DSLV for short.

Nertea has a great looking one in CryoEngines. I believe it uses the same fuel ratio as sstu H2 engines.

[Sudragon]

Is anyone else having problems with the modular heat shield upgrade nodes?

[tater]

3 hours ago, Sudragon said:

Is anyone else having problems with the modular heat shield upgrade nodes?

I had an issue, yes. Career was borked, and not by SSTU. I set up a career with tech tree set to pay funds, and then I stopped getting upgrades, even when paid for.

[Sudragon]

13 hours ago, tater said:

I had an issue, yes. Career was borked, and not by SSTU. I set up a career with tech tree set to pay funds, and then I stopped getting upgrades, even when paid for.

Everything else works fine, just no size upgrades for the heat shield.

[tater]

Mine all updated when I unlocked that 10m inflatable heat shield.

[pap1723]

Hi @Shadowmage,

I have been looking through the code for SSTUModularEngineCluster to try and determine how you are setting up the clusters. We love your models and the lower part count is great, but we use TestFlight and it treats each cluster as a single engine. In looking at the code, is there a way that we could hook into it and eseentailly see each engine model as it's own engine? We want to allow one engine in a cluster to fail and if it does, it would obviously provide off-centered thrust. Any help you can give us would be great!

[Starwaster]

24 minutes ago, pap1723 said:

Hi @Shadowmage,

I have been looking through the code for SSTUModularEngineCluster to try and determine how you are setting up the clusters. We love your models and the lower part count is great, but we use TestFlight and it treats each cluster as a single engine. In looking at the code, is there a way that we could hook into it and eseentailly see each engine model as it's own engine? We want to allow one engine in a cluster to fail and if it does, it would obviously provide off-centered thrust. Any help you can give us would be great!

I brought up this issue a long time ago because of Stage Recovery asking for a publicly accessible field but he declined. He posted an alternate solution here to be implemented in whatever mod might need to know correct engine thrust in the module

There were TWO suggestions; I recall having an issue with one of them as being likely to be unworkable. The other one probably would work. I didn't pursue either of them as I was a bit bummed out at mod inter-compatibility in general at the time (and trying to get those issues corrected with other modders) and decided not pursue the issue further as it involved two separate modders for two mods that were not my own.

 

[pap1723]

14 minutes ago, Starwaster said:

I brought up this issue a long time ago because of Stage Recovery asking for a publicly accessible field but he declined. He posted an alternate solution here to be implemented in whatever mod might need to know correct engine thrust in the module

There were TWO suggestions; I recall having an issue with one of them as being likely to be unworkable. The other one probably would work. I didn't pursue either of them as I was a bit bummed out at mod inter-compatibility in general at the time (and trying to get those issues corrected with other modders) and decided not pursue the issue further as it involved two separate modders for two mods that were not my own.

Thank you for pointing me there.

[Cheesecake]

@Shadowmage I have an issue with the F-1 and the J-2. There is only a black texture.

It`s only this two engines. All others are fine.
KSP 1.5.1, no -force-d3d11 or -force-glcore because I use a rescaled version of the Kerbol-System and DX11 or GL-Core have issues with rescaling (black ground textures and other issues).

Log:
https://www.file-upload.net/download-13438441/KSP.log.html

[Theysen]

1 hour ago, Cheesecake said:

@Shadowmage I have an issue with the F-1 and the J-2. There is only a black texture.

It`s only this two engines. All others are fine.
KSP 1.5.1, no -force-d3d11 or -force-glcore because I use a rescaled version of the Kerbol-System and DX11 or GL-Core have issues with rescaling (black ground textures and other issues).

Log:
https://www.file-upload.net/download-13438441/KSP.log.html

Quote

Requirements:

TexturesUnlimited currently requires the use of the either the DirectX11 or OpenGL-Core graphics API.  This may be activated by using the '-force-glcore' command line option to launch KSP.

Other graphics APIs will 'work' (DX9, legacy GL), but will have rendering errors.

^ From the TexturesUnlimited thread op, which you most likely installed during SSTU installation.

 

You have to use DX11 or GL, unfortunately. 

[Cheesecake]

11 hours ago, Theysen said:

^ From the TexturesUnlimited thread op, which you most likely installed during SSTU installation.

 

You have to use DX11 or GL, unfortunately. 

I know this. But: there are only issues with this two engines. all others works fine. Also Tanks and Pods and all the other parts works.

[Starwaster]

5 hours ago, Cheesecake said:

I know this. But: there are only issues with this two engines. all others works fine. Also Tanks and Pods and all the other parts works.

They might look like they render fine to you (and obviously things like cube maps and reflections are working for you) but those look a lot shinier than they would be under DX11.  In fact, I find that it's impossible to get specularity right when using the recolor option because everything has a plasticky sheen to it. You're really better switching to DX11 or OGL

[tater]

The 2 engines is a known issue, there are lots of parts, and he thinks those 2 got missed merging PBR with the new DL.

[Shadowmage]

18 hours ago, Cheesecake said:

@Shadowmage I have an issue with the F-1 and the J-2. There is only a black texture.

 

It`s only this two engines. All others are fine.
KSP 1.5.1, no -force-d3d11 or -force-glcore because I use a rescaled version of the Kerbol-System and DX11 or GL-Core have issues with rescaling (black ground textures and other issues).

Log:
https://www.file-upload.net/download-13438441/KSP.log.html

As others have pointed out, it is a known issue;  I missed a couple of patches for those engines in the last update.

Thanks for including the log file though; wish more people took the time to do that when posting about issues

 

21 hours ago, pap1723 said:

Hi @Shadowmage,

I have been looking through the code for SSTUModularEngineCluster to try and determine how you are setting up the clusters. We love your models and the lower part count is great, but we use TestFlight and it treats each cluster as a single engine. In looking at the code, is there a way that we could hook into it and eseentailly see each engine model as it's own engine? We want to allow one engine in a cluster to fail and if it does, it would obviously provide off-centered thrust. Any help you can give us would be great!

As @Starwaster mentioned, it has been brought up before.  Its not so much that 'I declined' adding such a feature... but that such a feature would be extremely difficult to add, likely taking weeks of development time, and is not a feature that I would ever use.  Weighing that against the features that I will use, and the outstanding bugs that need fixing, and it wasn't hard to see where best I should spend my time.

If someone would like to submit a PR for such a feature/addition, I would more than likely include it.  But it is not something that I will be spending my (extremely limited) modding time on in the foreseeable future.  The difficulty isn't necessarily with SSTU's engine-clustering code -- the difficulty is with the stock engine module (and the fact that you can only effectively have one engine module per part).  In theory you shouldn't need to touch SSTUs code to do what you are requesting;  hook into the engine module and manipulate its internals.

[Starwaster]

@pap1723 is everything you need to do ONLY in-flight? (I wasn't clear on that and maybe misunderstood) If so then maybe what you really need to look at is the engine's thrustTransformMultipliers; it's a list that is as long as the number of thrust tranforms and by default each one's value is (1/number of thrust transforms). One caveat there is that the engine's thrust transform multipliers can be changed via config. Not many mods make use of that feature but SSTU does for a few engines. (I think to simulate open cycle gas generator engines?)

If you zero out one of the thrustTransformMultipliers elements that would have the effect of that engine failing. Or you could set it to some arbitrarily low value depending on what sort of failure you want. As I mentioned above, some of SSTU's engines do change the transform multipliers so each 'individual' engine might have multiplies and you'd have to zero all of them as a set. (so you'd have to figure out which elements of the thrustTransformMultipliers list constituted an entire engine)

[Shadowmage]

38 minutes ago, Starwaster said:

@pap1723 is everything you need to do ONLY in-flight? (I wasn't clear on that and maybe misunderstood) If so then maybe what you really need to look at is the engine's thrustTransformMultipliers; it's a list that is as long as the number of thrust tranforms and by default each one's value is (1/number of thrust transforms). One caveat there is that the engine's thrust transform multipliers can be changed via config. Not many mods make use of that feature but SSTU does for a few engines. (I think to simulate open cycle gas generator engines?)

If you zero out one of the thrustTransformMultipliers elements that would have the effect of that engine failing. Or you could set it to some arbitrarily low value depending on what sort of failure you want. As I mentioned above, some of SSTU's engines do change the transform multipliers so each 'individual' engine might have multiplies and you'd have to zero all of them as a set. (so you'd have to figure out which elements of the thrustTransformMultipliers list constituted an entire engine)

Pretty much this ^^

SSTU doesn't touch the thrust-transform multipliers after it has set up the model and engine-module initially (when vessel/parts are first loaded).  It should be safe to manually adjust these values to simulate engine failure modes.  As noted though -- some of SSTU's engines have multiple thrust transforms in a single engine (notably the multi-nozzle engines and those with pump-exhaust roll control), so some special handling would be needed for those.

[Starwaster]

37 minutes ago, Shadowmage said:

Pretty much this ^^

SSTU doesn't touch the thrust-transform multipliers after it has set up the model and engine-module initially (when vessel/parts are first loaded).  It should be safe to manually adjust these values to simulate engine failure modes.  As noted though -- some of SSTU's engines have multiple thrust transforms in a single engine (notably the multi-nozzle engines and those with pump-exhaust roll control), so some special handling would be needed for those.

I haven't looked at how you handle that but unless you're doing anything weird it should be easy to extract the groups... it would probably end up internally as something like transform0, transform1, transform0, transform1, wouldn't it? (where transform0 would be the main thrust transform and transform1 being the pump exhaust?)

[Shadowmage]

1 minute ago, Starwaster said:

I haven't looked at how you handle that but unless you're doing anything weird it should be easy to extract the groups... it would probably end up internally as something like transform0, transform1, transform0, transform1, wouldn't it? (where transform0 would be the main thrust transform and transform1 being the pump exhaust?)

Pretty much yes - they are grouped by the 'engine'.  So if an engine has 3 transforms, and you have 4 engines in the cluster, the transform mult. list should look like.  But in order to process it correctly you will need to know the layout of the original engine (how many tr's there are, which one is the 'main' transform).

tr[0] = engine[0]:tr[0]
tr[1] = engine[0]:tr[1]
tr[2] = engine[0]:tr[2]
tr[3] = engine[1]:tr[0]
tr[4] = engine[1]:tr[1]
tr[5] = engine[1]:tr[2]
tr[6] = engine[2]:tr[0]
tr[7] = engine[2]:tr[1]
tr[8] = engine[2]:tr[2]
tr[9] = engine[3]:tr[0]
tr[10] = engine[3]:tr[1]
tr[11] = engine[3]:tr[2]

[Shadowmage]

Huh, well apparently SQUAD did another un-announced / un-scheduled game update.

In short -- I have no idea if/when I'll be able to get SSTU updated for 1.6.  It will be awhile.  I have things planned and in the works from now up until midway through January, which is when this updated was supposed to be released.  Will be at least until then before I will be able to do even a basic recompile of SSTU or any of my other mods. 

So sick of the inconsistent update schedules, and lack of any actual schedule.  Why announce a 3-month update timing pattern... and then not stick to it for even the first update?  Like what?  How am I supposed to schedule my work if I can't rely on their announced schedules being followed?

[Damon]

1 hour ago, Shadowmage said:

Huh, well apparently SQUAD did another un-announced / un-scheduled game update.

In short -- I have no idea if/when I'll be able to get SSTU updated for 1.6.  It will be awhile.  I have things planned and in the works from now up until midway through January, which is when this updated was supposed to be released.  Will be at least until then before I will be able to do even a basic recompile of SSTU or any of my other mods. 

So sick of the inconsistent update schedules, and lack of any actual schedule.  Why announce a 3-month update timing pattern... and then not stick to it for even the first update?  Like what?  How am I supposed to schedule my work if I can't rely on their announced schedules being followed?

I totally agree. Even more annoying is that I found 5 new bugs within the first 5 min of playing the new update.. I'm actually just pretty sissed about it. 

Edited December 20, 2018 by damonvv

[Sudragon]

1 hour ago, damonvv said:

I totally agree. Even more annoying is that I found 5 new bugs within the first 5 min of playing the new update.. I'm actually just pretty sissed about it. 

I'm so glad I don't play on the Steam directory version of the game.

[Dermeister]

Using KSP 1.3.1 with the SSTU-0.7.39.149 mod when I go to connect the Habitat parts any of them to my ship the part disappears and makes the node disappear then the part reappears  floating in the VAB not attached. IS it a known bug? what would I have to do to get help to fix this?

[Cheesecake]

5 hours ago, Dermeister said:

Using KSP 1.3.1 with the SSTU-0.7.39.149 mod when I go to connect the Habitat parts any of them to my ship the part disappears and makes the node disappear then the part reappears  floating in the VAB not attached. IS it a known bug? what would I have to do to get help to fix this?

I had this issue too yesterday in KSP 1.5.1. After reinstalling SSTU it worked fine.

[tater]

Hey, @Shadowmage

This is in 1.6. Seems to work fine. Maybe something is broken, someplace that I didn't notice... the stock dv readout was certainly off (said the SM had 55m/s, and it's full of hypergolic), but past that... works as far as I could quickly tell.

Edited December 21, 2018 by tater

[Shadowmage]

9 hours ago, tater said:

Hey, @Shadowmage

This is in 1.6. Seems to work fine. Maybe something is broken, someplace that I didn't notice... the stock dv readout was certainly off (said the SM had 55m/s, and it's full of hypergolic), but past that... works as far as I could quickly tell.

Good to know -- thanks for the info.  I figured there likely wasn't going to be much breakage with the new update with SSTU -- I'm more concerned with the stock 'in flight reflection updates' and how much pain that is going to cause for TU.  Every time stock touches their shaders/rendering, I end up spending two months cleaning up their mess.

Judging by your screenshots it looks like it didn't break anything in TU, which is great news.  At least I (hopefully) won't have to spend a ton of time cleaning up the stock issues, though I'll certainly have to play around with the stock reflection update stuff to see if/how it works (and how broken it is with mods in play, and if it even does convolution correctly).