Jump to content

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


Shadowmage

Recommended Posts

I vote for the rest of Saturn V, and Apollo to make a come back...

You don't even need to make the Saturn Ib first stage, we have the parts for a Saturn Ic from ETS already, we just need an S-IVB! And with the orange texture switch and such we could probably make a Saturn Multibody as well. Horray for things that didn't actually happen!

Link to comment
Share on other sites

hey Shadow,

Sorry, can't give you good feedback for engines, don't know much of them, I can only judge spreadsheet if I have thrust values as well. (So will just sort by thrust -> ascending and observe whether ISP has more or less descending values without 'big' outliers (something like in stock rebalance http://i.imgur.com/WmNB4D9.jpg ;))

Concerning setting minimum thrust values for various engines - personally I wouldn't go for it. As much as this is not realistic it allows for more sandbox scenarios (for example landing on bodies with low gravity, assist in initial docking positioning :P or spent reusable stages that can precision-land using minimal thrust). This would probably allow for better automatic mechjeb flying I guess.

And last thing - just letting you know. I've been conducting some performance tests on my mod parts with multiple colliders (frame with doors - about 18 different type of colliders for one animated part). I've observed fps jumps issue similar to the one with docking ports (running animation increased fps from 22 to 59). So the issue might be embedded deeper than just docking ports themselves :/

Link to comment
Share on other sites

I vote for the rest of Saturn V, and Apollo to make a come back...

You don't even need to make the Saturn Ib first stage, we have the parts for a Saturn Ic from ETS already, we just need an S-IVB! And with the orange texture switch and such we could probably make a Saturn Multibody as well. Horray for things that didn't actually happen!

also, DECQ is planning to release his Saturn IC tomorrow

alternativelly Saturn IC stage could be easily made with the current version of SSTU, just use a F-1 with a Generic mount, a 3.75m tank and voila

to be fair, not only Saturn IC first stage can be made right now, but so can the monstruous Saturn V-23/24(L) :D in fact I submitted a PR on the RO github a few hours ago that covers all S-IC stage variants of the Saturn MLV study and the LRB aswell (well, Shadowmage already had it for stock, I just RO-fied it :P the only really new thing is a MS-IC-1A 6xF1 mount)

on top of that, I also vote for Saturn parts to be finished next :D

Link to comment
Share on other sites

Unsure what is happening here, but with the latest version, the LC-ISA goes wonky after saving and reloading.

This is what this setup should look like:

F6Dp1MEl.png

After reloading, it goes like this:

63lxw1nl.png

It's reversable, and works fine in the flight scene when corrected, but I have to do this every time I do a launch. Luckily, it's as simple as detaching the LC-ISA from where it has attached itself halfway up the lander and putting it back under the descent motor, and then taking the ICPS and re-placing that as well.

For the record, this is a craft that I made after the latest update. Is there anything else I can send your way regarding this Shadow? There's no nullrefs or anything.

Link to comment
Share on other sites

I think the new RS-25s could use quite a bit more engine power, but I like the models!

Thanks, and noted.

How does the thrust feel for the F1/F1b?

I'm personally leaning towards another decent bump all around; probably another 5-10% increase on the global multiplier. Currently they are based on exact squared scale thrust of the real engine (e.g. 0.64 * 0.64 = 41%), though judging by the physical size of the engines compared to KSP, this could likely be increased a bit.

hey Shadow,

Sorry, can't give you good feedback for engines, don't know much of them, I can only judge spreadsheet if I have thrust values as well. (So will just sort by thrust -> ascending and observe whether ISP has more or less descending values without 'big' outliers (something like in stock rebalance http://i.imgur.com/WmNB4D9.jpg ;))

Concerning setting minimum thrust values for various engines - personally I wouldn't go for it. As much as this is not realistic it allows for more sandbox scenarios (for example landing on bodies with low gravity, assist in initial docking positioning :P or spent reusable stages that can precision-land using minimal thrust). This would probably allow for better automatic mechjeb flying I guess.

And last thing - just letting you know. I've been conducting some performance tests on my mod parts with multiple colliders (frame with doors - about 18 different type of colliders for one animated part). I've observed fps jumps issue similar to the one with docking ports (running animation increased fps from 22 to 59). So the issue might be embedded deeper than just docking ports themselves :/

Spreadsheet - have updated the sheet a few times since then, it now includes the thrust values for the engines. Though, I don't think that I will be following that type of balance. Bigger is not necessarily less efficient (isp wise), and one of the biggest RL engines is -also- one of the most efficient engines ever made (RS-25; not many engines are larger; and very few are higher efficiency in vacuum). Though their general TWR will fall on that type of curve (lifters generally have higher TWR than upper stage engines).

Minimum thrust - noted. I'll probably leave the engines as-per stock with no minumum thrust / 100% throttle-able. Easy enough for others to change that setting through patches if they want.

Docking Ports / Animations - I've noticed that the stock animation code has a 'bug' where it constantly replays the last frame of the animation (or rather, the last couple miliseconds) (as opposed to actually -stopping- the animation); and as I understand it with Unity/phyiscs that whenever you manually move a collider it causes a full-tree update of all physics objects. Combine these issues with a part with an animated collider; and you can probably see the problem. When open/deployed, the animation is always playing, collider is always being moved by animation, and physics tree is fully updated every tick. And to complicate things more (on trying to solve them), the stock animation modules are extremely inconsistent in how it handles state update and reloading.

So.. it might be worth it to try a 'fixed' animation module on the stock shielded docking ports to see if that cleans up some of their performance problems (as I believe they have colliders that are moved as part of the animation).

Unsure what is happening here, but with the latest version, the LC-ISA goes wonky after saving and reloading.

This is what this setup should look like:

After reloading, it goes like this:

It's reversable, and works fine in the flight scene when corrected, but I have to do this every time I do a launch. Luckily, it's as simple as detaching the LC-ISA from where it has attached itself halfway up the lander and putting it back under the descent motor, and then taking the ICPS and re-placing that as well.

For the record, this is a craft that I made after the latest update. Is there anything else I can send your way regarding this Shadow? There's no nullrefs or anything.

Hmm... looks like a bug to me :) Open up an issue ticket and I'll see about getting this fixed up for the next update (ticket is just so that I don't forget about it). Likely something I changed in one of the recent releases (unified node-offset positioning) that is not playing nicely with the ISA code, probably pretty simple to get fixed.

Sadly, as the mod gets bigger and bigger it becomes harder/unrealistic for me to be able to test 'everything' prior to each release, and bugs such as this are more and more likely to make it into releases. So, here in the next week or two, I'm going to start moving the 'finished' stuff over to a public release thread. Those releases will be updated far less often (likely only once a month or so), will only contain features or parts from the dev branch (the current release branch/this thread) that are finished, and releases will have extensive testing before being moved over to the public release branch/thread.

Plans this week:

RL-10(A3/A4/B2) - Three separate engines - UV unwrap done, layout and texture WIP

J-2 - maybe, if I have time. Seems possible, as I aim to wrap up the RL10s today/tonight.

Fallout 4 - Yep, will be taking some 'time off' to play some games as an official part of my todo list this week; namely the newest game in one of my favorite series, from one of the few developers that I have any remaining faith in. Can't just work all the time :)

Link to comment
Share on other sites

Hehe, I won't be 'gone' as it were; quite a bit of my dev time happens during downtime at work, so even though I'm taking some nights/evenings off, I should still have plenty of time to get modding things done.

'Finalized' geometry for RL10(A-3/A-4/B-2) (RL10A-3 shown), with initial AO only diffuse texture.

mFml0Li.png

Will be working on texturing for the rest of the night (until F4 is unlocked :) ). Any particular color schemes you guys would like to see implemented? Most of the pics for this engine are all metal/gray/silver, so that is likely how I will be doing this one as well.

Have settled on a 128px/m minimum texture scale for these engines (and is what I try to get for texture resolution in general for all parts). This should allow for a decent level of detail at the default resolution while still allowing for 'decent' detail if the textures are downscaled to half-size. I will be using whatever texture size is needed to get the necessary minimum texture scale for these engines. As the F1 is the 'largest' engine, and only required a 1024x, this means that most other engines should use less (far less) texture space.

Edit: And just because it is so 'cool' : (RL-10 engine during testing, forming icicles along the edge of the bell)

Edited by Shadowmage
Link to comment
Share on other sites

Icicles... someone please explain to me how a cryogenic engine works. Does it get cold rather than hot??

Also, you'd better get that distinct engine bell texture down! ;3

There's cryogenic fuel flowing through many of the pipes and the nozzle. So while the inner surface of many of the parts might be quite hot, the outer surface might be very cold. I'm not sure if icicles would form in a vacuum (though the exhaust is mostly water vapor so it's possible).

Link to comment
Share on other sites

one last thing Shadow, maybe it's usefule if you didn't find it already ;)

upper stage comparison:

kn09z6W.png

source: Cryogenic propulsion stage by david jones (pdf)

From what I see another interesting upper stage engine would be Vinci, I don't know whether you have it on your list; it has 60% better thrust than RL10-B-2 with other similar stats. On the con side it's still in development so it's hard to get good modelling reference images and then the piping is... dreadful :P

3GACPga.pngvinci.jpg

bigger picture from the bottom

Link to comment
Share on other sites

cool stuff:)

Quickly googled subject; an idea how to differentiate RL10-A-3 and A-4:

standard colors for A-3:

http://www.b14643.de/Spacerockets/Diverse/P&W_RL10_engine/RL-10A-3-3A_2.jpg

blue strip for A-4:

http://i.imgur.com/OcY0xr0.jpg

no idea / preference for B-2 :P

Good thing I mapped the UVs for the lower portion of the different bells to unique islands then, eh?

I'm not sure, but I think the blue wrap on the A4 in that picture is some pre-flight protective covering. I've seen it in a few of the images for that engine...but not in all of them.

Such as: RL-10A-4-2.jpg

Same engine (afaik), one with protective covering, one without.

And : rl10a4.jpg

Without protective covering.

I have however added a bit of yellow/green to the tubed portions of the engine bell (as can be seen in many of the images of the engine; I personally think it is just tarnish/dirt though), should add a bit of contrast vs. the straight silver portions/reinforcement bands.

Well, 1.0.5 is now released.

Yes. This makes me both happy and sad. Of course they would release it on the day that I have too much stuff to do, in the week where my time is already all spoken for. I was hoping to do a quick post-1.05-release update/check on my parts on release day; unfortunately it will have to wait for this weekends normal update.

Is anyone aware if the IPartMassModifier bugs were fixed in this release? I have not been able to locate anything in the patch notes in regard to this, but it might have been disguised under another description unrelated to the modding API. If they have fixed it, it means I have quite a bit of code-updating to do on my side.

There's cryogenic fuel flowing through many of the pipes and the nozzle. So while the inner surface of many of the parts might be quite hot, the outer surface might be very cold. I'm not sure if icicles would form in a vacuum (though the exhaust is mostly water vapor so it's possible).

I'm still trying to determine how I should do the RL10 emissive textures after seeing this / similar images. How much would the engine bell glow if it is normally running 'cool' such as this? And is this the normal mode of operation for these engines in vacuum (e.g. running cool, no heat output)? Heh, lots of questions.

Link to comment
Share on other sites

Is anyone aware if the IPartMassModifier bugs were fixed in this release? I have not been able to locate anything in the patch notes in regard to this, but it might have been disguised under another description unrelated to the modding API. If they have fixed it, it means I have quite a bit of code-updating to do on my side.

My understanding is that this was planned for 1.1. If it didn't show up in the release notes then that's probably the case. If you need multiple modules modifying mass (say that 5 times fast! :P) before then, I have a workaround I could show you :)

Link to comment
Share on other sites

My understanding is that this was planned for 1.1. If it didn't show up in the release notes then that's probably the case. If you need multiple modules modifying mass (say that 5 times fast! :P) before then, I have a workaround I could show you :)

Ahh good to know, likely not too much to update on my end code-side then.

For the time being, where I have multiple modules modifying mass (LC parts that use both resource and mesh-switch), I've manually inter-linked them in the plugin code to check for the existence of the other module and add their modified mass together if multiple modules are present. Definitely -not- a clean solution, but was the only one I could find.

If anyone has time to try out SSTU in 1.05, please let me know how it goes / what is broken / how broken things are :) If it is bad, I'll take some time out this week in the evenings to get things fixed up / cleaned up / not quite so broken.

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