[1.4] SpaceY Expanded, v1.5 (2018-04-02)

[NecroBones]

I'm going to increase the joint strength a bit, but those settings determine at what point the joint breaks, and doesn't seem to have much impact on how bendy things are. There aren't any exposed variables we can use to influence the stiffness. I REALLY would like for Squad to add a "stiffness multiplier" for the part CFGs. That would help us immensely. But for now, the best bet is KJR.

[maculator]

Well I guess its KJR then. Anyways great mod/mods those packs really add to the games variety.

[NecroBones]

Posted:

0.6 (2015-10-01) - Beta.
 - Adjusted P-series (Penguin) engines back to 400 ISP by default.
 - Added MM config for Penguin engines to detect CryoEngines and make the following tweaks:
    - Reduces Liquid-Fuel ISP to 360.
    - Adds mode switching, with alternate Liquid-Hydrogen mode, with slightly better ISP but slightly worse thrust.
 - Added a minuscule gimbal range to Penguin engines (previously they were non-vectoring). 
 - Significantly increased connection breaking strength on most parts (including all 7.5m parts).

[Kerbas_ad_astra]

Posted:

0.6 (2015-10-01) - Beta.
 - Adjusted P-series (Penguin) engines back to 400 ISP by default.
 - Added MM config for Penguin engines to detect CryoEngines and make the following tweaks:
    - Reduces Liquid-Fuel ISP to 360.
    - Adds mode switching, with alternate Liquid-Hydrogen mode, with slightly better ISP but slightly worse thrust.
 - Added a minuscule gimbal range to Penguin engines (previously they were non-vectoring). 
 - Significantly increased connection breaking strength on most parts (including all 7.5m parts).

You've got a lot of parts that have mod-specific patches in their individual configs (e.g. for CryoEngines and ModuleEngineIgnitor on your engines), rather than broken out into patch files like you've done for HotRockets, ConnectedLivingSpace, etc., which I think is a better pattern.

In particular, the ModuleEngineIgnitor stuff will cause KSP to hang on loading because it doesn't know what HypergolicFluid is. I'd also rather have the Cryogenic Engines stuff on its own because I use a patch that Nertea includes with Cryo Engines that converts his engines to use LFO (reducing Isp to the 375-425 seconds range, as the Penguin is by default), so having your engines give themselves an LH2 mode won't do me any good. I'd like to be able to delete one patch file to leave your engines with their "stock" performance values, rather than have to hunt through each engine's config.

[maculator]

So this one got updated in strength too. Good to hear. I have 2 questions:

1. If I update via ckan, do i have to delete the folders first or will it work without doing anything?

2. Those massive boosters, the biggest ones (I looked carefully through the parts this time!) they dont seem to have a fitting nose cone. I always the modular interstage adapter and then the biggest nose cone i can find on top. Did I miss something, or isnt there one that fits? And will you be making one in the future?

3. Suprise question: That texture changing wich works for almost all the tanks will it be implemented in SpaceY Expanded and the other few tanks that are missing it? I really love the feature.

4. The procedual parts have a lot of texture packs does anybody know a way to get those textures `to work for the Necrobones packs aswell?

And again a big thanks for your packs the more I play with them the more i concider them "stock+"

[qm3ster]

- Adjusted P-series (Penguin) engines back to 400 ISP by default.

- Added MM config for Penguin engines to detect CryoEngines and make the following tweaks:

- Reduces Liquid-Fuel ISP to 360.

- Adds mode switching, with alternate Liquid-Hydrogen mode, with slightly better ISP but slightly worse thrust.

Isn't this way too low, especially considering the norm is now 400 not 390? (Even if the config exists, should be higher than 360)

Why do you want to give more incentive to use Cryo Engines in more cases?

Finally, I agree with Kerbas, although I'd go further. I think it would be best to have them as a separate CKAN release, the mm config. For current and future compatibility sake. (Can even recommend CE instead of depending on it)

Edited October 2, 2015 by qm3ster

[Kerbas_ad_astra]

I may have been hasty in warning about the ModuleEngineIgnitor stuff -- since HypergolicFluid is only used in ModuleEngineIgnitor, KSP may ignore both without complaint, as it seems to have done on my install. I'm still suspicious, since I'd expect to see a notice about that module or resource not being recognized in the log, and I don't, so I'd still suggest breaking it out into a discrete patch.

[Michaelo90]

Am I blind or is there no 7.5m stack separator? Not sure if I would use it but when there's docking ports there should be separators

Also, a bigger conical payload bay would be nice, a 3.75m - 5m one, for using with 3.75m capsules.

[NecroBones]

You've got a lot of parts that have mod-specific patches in their individual configs (e.g. for CryoEngines and ModuleEngineIgnitor on your engines), rather than broken out into patch files like you've done for HotRockets, ConnectedLivingSpace, etc., which I think is a better pattern.

In particular, the ModuleEngineIgnitor stuff will cause KSP to hang on loading because it doesn't know what HypergolicFluid is. I'd also rather have the Cryogenic Engines stuff on its own because I use a patch that Nertea includes with Cryo Engines that converts his engines to use LFO (reducing Isp to the 375-425 seconds range, as the Penguin is by default), so having your engines give themselves an LH2 mode won't do me any good. I'd like to be able to delete one patch file to leave your engines with their "stock" performance values, rather than have to hunt through each engine's config.

I may have been hasty in warning about the ModuleEngineIgnitor stuff -- since HypergolicFluid is only used in ModuleEngineIgnitor, KSP may ignore both without complaint, as it seems to have done on my install. I'm still suspicious, since I'd expect to see a notice about that module or resource not being recognized in the log, and I don't, so I'd still suggest breaking it out into a discrete patch.

Right, KSP does just ignore those when they're not present, so it doesn't break anything. Mostly they're there because I started out doing it that way a long time ago, and just never moved them. I'll break them out, since I agree it's a better methodology since it lets people just delete the file if they're having compatibility problems or don't want those features.

The only reason I added the CryoEngine configs in the individual files was so all the ISP settings would be in the same place, but I agree, that's probably not a good enough reason.

So this one got updated in strength too. Good to hear. I have 2 questions:

1. If I update via ckan, do i have to delete the folders first or will it work without doing anything?

2. Those massive boosters, the biggest ones (I looked carefully through the parts this time!) they dont seem to have a fitting nose cone. I always the modular interstage adapter and then the biggest nose cone i can find on top. Did I miss something, or isnt there one that fits? And will you be making one in the future?

3. Suprise question: That texture changing wich works for almost all the tanks will it be implemented in SpaceY Expanded and the other few tanks that are missing it? I really love the feature.

4. The procedual parts have a lot of texture packs does anybody know a way to get those textures `to work for the Necrobones packs aswell?

And again a big thanks for your packs the more I play with them the more i concider them "stock+"

Sure thing, glad you like it! Answers below:

1. CKAN automatically does this for you. It deletes the folder and then re-adds it, so that you always have a clean install.

2. That's true, I hadn't thought about that. I usually add fueled nose cones these days, since an empty one is "wasted space", but on SRBs you just want something lightweight. So this makes sense.

3. Possibly. I could do what I did in CCC, and add all the extra model information so that it case use FTPs texture sets when FTP is installed. Using FTP as a dependency means that no additional textures need to be made, just the additional mesh data that uses them.

4. The problem with those is that they're tiled material textures, rather than UV mapped "altas" textures. I'd have to completely change the design of the tanks for those to be usable.

- - - Updated - - -

Isn't this way too low, especially considering the norm is now 400 not 390? (Even if the config exists, should be higher than 360)

Why do you want to give more incentive to use Cryo Engines in more cases?

Yeah, it's totally a work in progress. I think I overshot the mark, so I'll definitely take another look at this. I'm thinking maybe around 380 or 390 for LF, and 400 or 420 for LH, depending on how the Cryo Engines compare after a more careful look at them. I might push out an update fairly quickly.

Am I blind or is there no 7.5m stack separator? Not sure if I would use it but when there's docking ports there should be separators

Also, a bigger conical payload bay would be nice, a 3.75m - 5m one, for using with 3.75m capsules.

Cool, yeah the conical bay might be a nice thing to have. And you're right, there's no separator. I'll put that on the list.

[More Boosters]

Yep, I think it's great when mods can cooperate and balance against each other where appropriate.

So here's what I have in the next update so far (though it's not ready yet):

 - Adjusted P-series (Penguin) engines back to 400 ISP by default.
 - Added MM config for Penguin engines to detect CryoEngines and make the following tweaks:
    - Reduces Liquid-Fuel ISP to 360.
    - Adds mode switching, with alternate Liquid-Hydrogen mode, with slightly better ISP but slightly worse thrust.
 - Added a miniscule gimbal range to Penguin engines (previously they were non-vectoring). 

Don't want to be an asshat but cryo engines need at least like 430 ISP to work properly. How much better is slightly better? Anyway, 360 sounds good enough for this engine, I didn't download the new version but it's quite a way off on my career anyway.

[NecroBones]

Isn't this way too low, especially considering the norm is now 400 not 390? (Even if the config exists, should be higher than 360)

Why do you want to give more incentive to use Cryo Engines in more cases?

Yeah, it's totally a work in progress. I think I overshot the mark, so I'll definitely take another look at this. I'm thinking maybe around 380 or 390 for LF, and 400 or 420 for LH, depending on how the Cryo Engines compare after a more careful look at them. I might push out an update fairly quickly.

OK, so here's what I think we'll try. Defaults to 400 as it does now. With CryoEngines installed, they drop the LF ISP to 390 (just to help give some gap versus the LH mode), and add the LH mode with an ISP of 425. This puts the LH mode at sort of in the middle of the CryoEngines range.

I'm wishing that Nertea had added some "FOR" statements in the LFO patch, so that its presence can be detected. I'd use that to skip applying the LH patches.

Finally, I agree with Kerbas, although I'd go further. I think it would be best to have them as a separate CKAN release, the mm config. For current and future compatibility sake. (Can even recommend CE instead of depending on it)

I'll keep it in mind, but for now it'll be included, and can easily be deleted since it'll now be in its own file. Though admittedly, this would help with the above scenario.

[blowfish]

CryoEngines gives its engines pretty realistic Isp for hydrolox engines. For an upper/vacuum stage like the Penguin, this would be somewhere in the 440-460s range.

[NecroBones]

CryoEngines gives its engines pretty realistic Isp for hydrolox engines. For an upper/vacuum stage like the Penguin, this would be somewhere in the 440-460s range.

For pure realism, I agree. Though I'm aiming more for stock-like balance. But it's always a work in progress in any case.

[NecroBones]

Update posted. Once again, the ISPs are considered experimental for now. But This should be more reasonable. I wanted to push it quickly before too many people built ships around yesterday's stats.

0.6.1 (2015-10-02) - Tweaks.
 - Moved some engine mod-support to their own MM config files:
    - CryoEngines
    - EngineIgnitor
 - Adjusted the Penguin engines' CryoEngines-triggered ISPs upward for both fuel modes.
 - Added 7.5m stack separator.

[blowfish]

For pure realism, I agree. Though I'm aiming more for stock-like balance. But it's always a work in progress in any case.

Of course, but a major point to consider here is that CryoEngines has pretty definite lower/upper stage segregation, so I don't think averaging the Isp of all the engines is valid for an engine like the Penguin which is clearly not designed to be used at sea level. CryoEngines seems pretty well balanced against stock given the tank volume and TWR trade off, so I don't think it's necessary to try and re-do that balance.

[qm3ster]

Yay, more updates!

Yay, more ISP in all cases

[Damminh Khoi]

Kottabos done a review of your mod.

[NecroBones]

Kottabos done a review of your mod.

Yep, and he deleted a bunch of the textures that the mod expects, so lots of parts look wrong.

[Kuansenhama]

The 7.5M Decoupler and 7.5M Seperator classify as 5M parts when you filter by cross section profile.

The Dual emu and quad emu engines class as 3.75M parts.

[NecroBones]

The 7.5M Decoupler and 7.5M Seperator classify as 5M parts when you filter by cross section profile.

The Dual emu and quad emu engines class as 3.75M parts.

Doh! This is fixed for the next update. Thanks!

[maculator]

Hey i got a quick question. Fuel Tanks Plus demands the interstellar Fuelswitch Core, and SpaceY Expanded suggest to get the full mod. Why? Is there a benefit in taking the full Interstellar Fuelswitch or am I fine with just the core?

[NecroBones]

Hey i got a quick question. Fuel Tanks Plus demands the interstellar Fuelswitch Core, and SpaceY Expanded suggest to get the full mod. Why? Is there a benefit in taking the full Interstellar Fuelswitch or am I fine with just the core?

The core is fine. In fact, Expanded only suggests the core. The suggestion for the full version was only in CKAN for about a day, so you might have outdated data in your copy.

[qm3ster]

The core is fine. In fact, Expanded only suggests the core. The suggestion for the full version was only in CKAN for about a day, so you might have outdated data in your copy.

What's the difference between the whole mod and core, anyway? I wasn't able to quickly find the information, and since you use it and are currently an active mod dev, you would probably explain better anyway.

( Partially wondering if I should suggest Mk2 Stock-a-like Expansion to require core. It's the only 1 out of 5 IFS mods that I have that requires the full thing )

[NecroBones]

What's the difference between the whole mod and core, anyway? I wasn't able to quickly find the information, and since you use it and are currently an active mod dev, you would probably explain better anyway.

( Partially wondering if I should suggest Mk2 Stock-a-like Expansion to require core. It's the only 1 out of 5 IFS mods that I have that requires the full thing )

I thought the difference would be a config that adds fuel switching to stock tanks, but looking at the file structure, I don't see that at all. What I do see is that the full version adds a couple of example fuel tanks that use the stock artwork from the xenon tanks.

Basically the "core" is the DLL/plugin portion of the mod, and since it's a dependency for the "full" version anyway, and it's the only part that's needed if you're using the functionality that the plugin provides (fuel switching, mesh switching, or texture switching), it's really the better one to use as a real dependency (even if it's a "soft" dependency via suggestion/recommendation). But it doesn't look to me like it would hurt anything to suggest the full mod. It's just that some users might not want those additional fuel tanks, especially since they'll look identical to the xenon tanks.

[qm3ster]

I thought the difference would be a config that adds fuel switching to stock tanks, but looking at the file structure, I don't see that at all. What I do see is that the full version adds a couple of example fuel tanks that use the stock artwork from the xenon tanks.

Basically the "core" is the DLL/plugin portion of the mod, and since it's a dependency for the "full" version anyway, and it's the only part that's needed if you're using the functionality that the plugin provides (fuel switching, mesh switching, or texture switching), it's really the better one to use as a real dependency (even if it's a "soft" dependency via suggestion/recommendation). But it doesn't look to me like it would hurt anything to suggest the full mod. It's just that some users might not want those additional fuel tanks, especially since they'll look identical to the xenon tanks.

So, if some bandit swapped out the dependency (A hard dependency btw) in CKAN for the core mod, there's realistically no chance of breaking the mod?