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

[davidy12]

@tater: I've asked this before. Most likely, it'll be when 1.1 comes out then Mage may get back to the IVAs. And even then you'll have to wait until most of the pack is completed. Plus, he's remaking the landers.

EDIT: @Shadowmage: YOU'VE HIT 90 PAGES!!!!

Edited March 1, 2016 by davidy12

[Shadowmage]

10 minutes ago, sp1989 said:

Ok so the problem keeps persisting. Just tested it again a few minutes ago. I put just the soyuz together and I wanted to test the LES. I pressed launch and boom the game crashed. So here is my log for that https://www.dropbox.com/s/pcybc65bdg6owx6/KSP.log?dl=0 I fully acknowledge it could be my computer. It just seems interesting to me that the game is fine before I install SSTU and then after it just crashes. 

 

Also here is my Unity player.log maybe there is something in there. https://www.dropbox.com/s/j9pm1i59c04ycoi/Player.log?dl=0

 

As had been asked, we need to know how your memory use looks when you are loading the game.  This -really- sounds like a memory related crash (which there is nothing I can do about).  If you are launching the game with it using more than ~2.6gb, it -will- crash within a few scene changes; that is just KSP being memory limited and the stock memory leaks having fits.

An easy way to test this -- setup a just stock+SSTU (and dependencies) install, and see if it -still- crashes.  Or, you could post the screenshots while using GCMonitor as blowfish had asked.  Either method should give enough information to tell if it is a memory problem or other.  I'm betting it is a memory problem though; SSTU is a -large- mod-pack, and will nearly overload a stock DX9 install all by itself (fine with openGL).

 

Edit/further info:

From your player.log file:

[ ALLOC_PROFILER ] used: 110664B | peak: 0B | reserved: 4194304B
Could not allocate memory: System out of memory!
Trying to allocate: 2539968B with 16 alignment. MemoryLabel: Default
Allocation happend at: Line:334 in
Memory overview

 

This -is- an out memory error/problem.

Try removing some mods, using ATM, switching to OpenGL mode (not sure on a mac, thought openGL was the default), and/or manually compressing some textures to save some memory.

Edited March 1, 2016 by Shadowmage

[blowfish]

9 minutes ago, sp1989 said:

Ok so the problem keeps persisting. Just tested it again a few minutes ago. I put just the soyuz together and I wanted to test the LES. I pressed launch and boom the game crashed. So here is my log for that https://www.dropbox.com/s/pcybc65bdg6owx6/KSP.log?dl=0 I fully acknowledge it could be my computer. It just seems interesting to me that the game is fine before I install SSTU and then after it just crashes. 

 

Also here is my Unity player.log maybe there is something in there. https://www.dropbox.com/s/j9pm1i59c04ycoi/Player.log?dl=0

That did it, thanks.  And yeah, looks like you're out of memory.  You might try Dynamic Texture Loader or try to get rid of a few mods or just wait until 1.1.

[Charlie the Kerbal]

Amazing work ! Especially liking the new radial SRB separator/mount. Thank you Shadowmage.

A comment, having a beginner knowledge of KSP mods.

It seems like SSTU configuration files are spread under several directories. This makes selective installation of the parts very difficult. Would it be a good idea to follow the format of other part mods where dds, mu, cfg files for an engine sits under that engine's directory. Then all engine directories under a common directory ? So that if someone wants to install just the engines, it would be a single copy/paste.

Second question, perhaps an irrelevant one, would it be very difficult to develop new engines RO-ready ? Seems like you develop quite fast and RO always needs to catch-up and we end up with several unsupported parts. Just a wish really.

Charlie

[blowfish]

2 minutes ago, Charlie the Kerbal said:

Amazing work ! Especially liking the new radial SRB separator/mount. Thank you Shadowmage.

A comment, having a beginner knowledge of KSP mods.

It seems like SSTU configuration files are spread under several directories. This makes selective installation of the parts very difficult. Would it be a good idea to follow the format of other part mods where dds, mu, cfg files for an engine sits under that engine's directory. Then all engine directories under a common directory ? So that if someone wants to install just the engines, it would be a single copy/paste.

Second question, perhaps an irrelevant one, would it be very difficult to develop new engines RO-ready ? Seems like you develop quite fast and RO always needs to catch-up and we end up with several unsupported parts. Just a wish really.

Charlie

A lot of parts share textures so it's not possible to split it all up.  Some degree of segmentation might be possible, not exactly sure how much.  Even if that were to happen, installing just part would be more like "install then remove the parts you don't want" rather than "just install the parts you want," as there are things (like the plugin) that everything depends on.

RO - Shadowmage has been submitting some pull requests to RO, so if you feel up to learning a little git you could probably get more up-to-date version than the current release version.  But the RO patches are quite complicated and by convention they're all kept in RO - so I don't think moving those patches out of RO is reasonable.

[Shadowmage]

40 minutes ago, blowfish said:

A lot of parts share textures so it's not possible to split it all up.  Some degree of segmentation might be possible, not exactly sure how much.  Even if that were to happen, installing just part would be more like "install then remove the parts you don't want" rather than "just install the parts you want," as there are things (like the plugin) that everything depends on.

RO - Shadowmage has been submitting some pull requests to RO, so if you feel up to learning a little git you could probably get more up-to-date version than the current release version.  But the RO patches are quite complicated and by convention they're all kept in RO - so I don't think moving those patches out of RO is reasonable.

 

45 minutes ago, Charlie the Kerbal said:

Amazing work ! Especially liking the new radial SRB separator/mount. Thank you Shadowmage.

A comment, having a beginner knowledge of KSP mods.

It seems like SSTU configuration files are spread under several directories. This makes selective installation of the parts very difficult. Would it be a good idea to follow the format of other part mods where dds, mu, cfg files for an engine sits under that engine's directory. Then all engine directories under a common directory ? So that if someone wants to install just the engines, it would be a single copy/paste.

Second question, perhaps an irrelevant one, would it be very difficult to develop new engines RO-ready ? Seems like you develop quite fast and RO always needs to catch-up and we end up with several unsupported parts. Just a wish really.

Charlie

Glad you are enjoying the mod in its current unfinished state

In addition to what blowfish wrote (which is all spot-on, esp. regarding the folder setup) -- I don't use RO, nor is the mod being developed specifically for RO, so the fact that I'm supporting it at all and helping with the patches is... going way out of my way.  Don't expect more than that.  Also the fact that I don't use RO means that I am -not- the best person to write the patches; I have no personal interest or investment in it, and the work is going to be rough at best.  Additionally the mod is in active development -- Things change / break so often that there is no realistic way to keep the patches up to date (unless I had a full-time personal assistant who did nothing but update RO patches).  Perhaps after the mod becomes more stable this might change; but don't expect that until a while after 1.1 is released and the mod fully updated.

In short -- don't expect -any- RO support from me.  If you do happen to get some, then be happy, it is a bonus.

 

And, on a more positive note: got some of the AO bake done for the SC-E parts (fuselage, tail, wings) (render actually has double AO; once from the texture, once from the render... it won't be as noticeable on parts):

 

Edited March 1, 2016 by Shadowmage

[tater]

I have to say, this is one of the coolest part mods I've messed with, I really like the lander parts. I noticed on the 2-man lander (haven't tested the 3 yet) then when mated to the tank framework that is the same size as the pod, the built-in ladder works fine, but when you egress the lander, you cannot climb down to the ground, they are just a little different in radius maybe? You have to let go, and fall to the ground, though it works fine claiming up, then boarding.

 

[Jimbodiah]

There is a small dianeter difference, you gave to jump down. Up should work fine though. No doubt it will be adressed when Mage gets around to the landers. The two decouplers are broken as well as per 1.0.5.

[Shadowmage]

16 minutes ago, Jimbodiah said:

There is a small dianeter difference, you gave to jump down. Up should work fine though. No doubt it will be adressed when Mage gets around to the landers. The two decouplers are broken as well as per 1.0.5.

I actually ninja'd in a fix for the decouplers with last nights update -- they should now properly have compound colliders (8 box colliders ).  Have not tested if they get stuck or not (due to clearance), but they should be working again.

Aye, there is a planned refresh of the LanderCore parts -- after all other parts/series have had at least initial work done on them (stations, bases, rovers, probes/satellites, interplanetary).  Might get back to them sooner if I can find some good concept stuff to work from.

[tater]

The integrated, collapsing stuff you have, like the gear and solar panels might be something to look at for rover use with an eye towards a carried rover that doesn't require some ridiculous sky crane. Imagine one of the smaller LC tanks, where the variant is no tanks, 4x retracted wheels, and a couple integrated command seats sort of where the tanks would be (the kerbal's head would still up, but the seat back would be flush for stacking). A tiny rover  

[Jimbodiah]

I'll test them out.

 

The lander concept is good, I would not change much, but some suggestions:
- gold foil (or gold/yellow looking at least vs the current orange)
- Modular tanks for width (4 steps like right now?) and if ppossible height
- Integrated docking ports, 1.25m for LC3/LC5, 0.625m for the LC2, but I think that is already what you had in mind?
- fuel switch on the tanks for LF/Ox, LH2/Ox, LF, LH2, MP as per the MFTs. This would allow us to use the RL10/etc on the landers
- gold foil on the tanks
- standard small built-in monoprop (50-ish) in the tank sections as 50 from the LC is just not enough sometimes and an extra tank section to enable monoprop is overkill
- possibility to add LS supplies through a patch, as something is blocking these resources from being added.
- did I mention gold foil? hahaha 
- built in antenna like on the Apollo SM perhaps?

 

Yeah, I know: once I get started...

Edited March 1, 2016 by Jimbodiah

[Jimbodiah]

Re the LC decouplers...

They will only attach to the bottom node of a tank (not the center as before) where the engine rack goes, but then the engine does not see the fuel tank anymore: 0 fuel is shown.
- Place tank
- place decoupler
- place engine

If you place the engine first, the decoupler will not attach at all.

Edited March 1, 2016 by Jimbodiah

[Jimbodiah]

BTW: Awesomeness....  Kerbal 365 (3.2) means I now actually need an SLS to send the Orion+SM+lander to the Mun. The HUS is juuuuusst powerful enough to get into a circular orbit and have enough to do the munar (lol) injection of around 1600dV. All with stock engines and realistic looking proportions. Pretty cool.

[Shadowmage]

Updated testing release is available:

https://github.com/shadowmage45/SSTULabs/releases/tag/0.3.29-pre8

Mostly updates to SC-E parts and functionality; see the link for full change-log and downloads.

[ComatoseJedi]

The shuttle works great. A little bit more tweaking on my entry so I won't overheat as bad. I did notice, however tiny of a detail this is. The IVA is facing the cargo bay. I mean, I love how it looks and everything, too, but I use instrumentation and cockpit visualizations to land V.I.A. the ASET mk3 cockpit and it's kinda hard to line up for an approach, however much like a brick it's supposed to be on approach (which yours handles very smoothly, I might add) while facing an empty cargo bay. But, other than that detail, wonderful work. It's definitely going to replace a lot of shuttle mod packs out there. And it's looking beautiful, too. Needless to say, I did make a landing, but I was off by  50 feet to the left of the runway, which is the closest I've ever came to landing a shuttle without crashing into the side of the mountain. 

 

[tater]

The ablator on the 2.5m reentry pod is set to 450. The stock 2.5m pod's heatshield is rated at 800. 800 is overkill for stock, but on a larger kebin, 450 is not nearly enough for even a Mun direct reentry based on some testing I just did (entry at ~5200 m/s). It;s easy enough of me to change it, but the stock mk1-2 is just fine, even with a 3.2X kerbin and a 6.4x distance setting. Perhaps with rescales being a common thing, the ablator could default to 450, but you could add it up to 800 (with a mass penalty) in the VAB?

[Jimbodiah]

The ablator was balanced for stock use, so anything needed for other mods would need to be made by yourself. The stock values kind of make having an ablator resource a moot point as you never run any risk of using it all up anyway. Kind of makes no sense to even have the mechanic if they use cheat values.

At 3.2 Kerbal there is not enough ablator on any of the pods, but you can patch that yourself in the cfg or with a MM config. I have the same issues now with my own 3.2x game where I am coming in at 5500m/s (mun return) and the Orion's ablator is gone about half way through the atmosphere. On stock Kerbin it is more than enough though unless you need two aerobraking passes, but even then it should still survive the heat. I will probably make a MM patch to check if 365 is running and then multiply ablator on the pods by 1.5 or something, might upgrade engine thrusts a little as well but have no idea about a balanced ratio for 3.2

 

[tater]

I was planning on running some tests (I'm also playing 365, my 5200 figure was because I had enough propellant in the tanks to brake some before entry (periapsis was set to around 20). Yeah, I'll make a patch for it, too, I guess. It'll give me a rationale in career for some "boilerplate" tests

[Jimbodiah]

I have a patch that doubles the ablator on the A/B/C pods if you want. Just trying to figure out how to auto-detect 365 as it's just two Kopernicus cfg files. Does anyone know how to check if a directory exists?

current patch: http://kerbal.nl/sstu/K365.cfg

I've also made a PR for updated USI and TAC LS files that adds the shuttle at 7 kerbals x 12 days (average mission length of all the real shuttles).

@Mage/Jose: Do you know the ratio for thrust/isp change on the RO patches? I want to see if I can alter the thrust for the 3.2x version, don't think they change much though.

Edited March 2, 2016 by Jimbodiah

[ComatoseJedi]

18 minutes ago, Jimbodiah said:

I've also made a PR for updated USI and TAC LS files that adds the shuttle at 7 kerbals x 12 days (average mission length of all the real shuttles).

 

Is there a mod that changes the crew capacity to 7? I thought the highest was 6?

[JoseEduardo]

it's not a fixed ratio, two engines running on the same fuel can have different iSP, Thrust and ratio... (RD-170 and F-1 for example)

you can check it here: http://www.b14643.de/Spacerockets/Diverse/U.S._Rocket_engines/engines.htm

I would suggest you to take a look at RF and maybe make a RF patch for K365... either that or SMURFF

Edited March 2, 2016 by JoseEduardo

[Jimbodiah]

@ComatoseJedi  Ah, I took 7 as the shuttle had 7 people on board most of the time. It only has 6 in SSTU? Didn't even notice. Will it stay at 6 Mage? Else I need to change the LS patches. I also took 3 as the number for the Soyuz at the time looking at the current missions   "Assumption is the mother of all f_ck-ups".

@JoseEduardo I don't want to change the fuel types or their ratios, I'm not aiming for an RO-style patch, just a minor tweak on thrusts/isp.

 

Testing a nicer patch for the ablators right now that checks for the directory and just mulitplies the stock values instead of setting an absolute value, this way they will scale up with whatever Mage uses in stock.

I see the shuttle does not use the ablator mechanic at this point, will add it later.

Edited March 2, 2016 by Jimbodiah

[JoseEduardo]

IIRC KSP stock isp are weaker than the RW values... you could tweak them to match the RW values and leave the thrust as it is?

[Jimbodiah]

I just made an excel sheet with the values from the link you sent me and what Mage uses. The thrusts are around 0.4x real-world values, but ISP is the same as real-world.

Kerbal is Earth/9.66

Mage uses 0.4x RL values (1/2.5)

Earth = 0.4 * 9.66 = 3.864

K365:   3.864/(9.66/3.2) =  = 1,27x stock thrust or 0.79xRL 

 

Please check my math, as I may just be having a brain fart. If it checks out I will patch the engines later today for K365.

Edited March 2, 2016 by Jimbodiah

[JoseEduardo]

64%² = 40.96%

I remember mage saying a long time ago (in a galaxy far far away) he would do this math for it

I just wasn't sure if he also scaled the isp at 40.96% or if he used a "standard" isp value for a given use/fuel

Edited March 2, 2016 by JoseEduardo