totm sep 2021 [1.12] Stockalike Station Parts Redux (August 14, 2024)

[modus]

1 hour ago, Spaceman.Spiff said:

I believe it's now included by default.

indeed it is.

Edited September 8, 2021 by modus

[modus]

19 hours ago, danfarnsy said:

Whoa, okay, so now I have reviewed @ProgorMatic's patch. This is a huge departure and overhaul from what was previously here, adjusting part masses to simple integer tons, adding recyclers to habs, flattening habs categories into the same 1-ton, 2-ton hab, and 4-ton options across the variety. I'm not saying that's wrong, but it is aggressive in how it touches everything. It will definitely change ships in flight that are using the previously existing patch, which I left untouched, only adjusting the new parts to be similar to the old parts.

I think we ought to get feedback from other users as to what they want. Do you want a patch that wholly brings SSPXR up to the way MKS habs operate? Or do you want an extension of the previous patch that leaves the old things in place and only brings new parts in line with them? I'd prefer my option, but I'm just a creature of habit. ProgorMatic's patch is definitely streamlined and easy for planning missions. There are aspects of it I like. Overall, I'm uncomfortable with it. Sorry to change my answer to you so quickly, but I didn't realize you were essentially providing an entirely new patch instead of a simple update to accommodate the new parts. But I'm just one voice in the crowd. Can others please reply and say what you'd prefer? Maybe test them both out?

Edit: Also just want to add an apology to ProgorMatic for not seeing that you'd posted a week before I did that you were looking at adding a USILS patch. Whatever concerns I have with it, it would have been more productive to discuss them back when you were very clear about how you were planning to overhaul things.

I have a bit of mixed feelings.

On the one hand, I like wat ProgorMatic has done, really bringing SSPXR in line whith USI/MKS. Since MKS really is an overall gameplay mod rather than 'just' a parts mod that totally makes sense.

On the other hand, there's the 'problem' (and I'm using quotes because everything is relative ofcourse) of using Progor's patch in an existing save. I've been using my main save since 1.7, dropping this patch in there really changes stuff. In that sense I will probably end up using danfarnsy's patch.

So yeah, imho it all depends on when you want to implement things. In a new save where you want to use MKS/USI and have some extra cool space station parts, I'd say Progors patch is the way to go.
When using it in an existing save, I'd say bringing MKS in line with SSPXR, instead of the other way around, is better.

[Nertea]

:| well yall gotta tell me which one you want...

[modus]

Uh yeah I hope the 'user feedback' won't be just me 

[Nertea]

Well I am generally waiting for the TAC patch PR before getting antsy about a release, so there's at least until then.

[danfarnsy]

@NerteaReluctantly, I think you should go with my patch. I know I'm coming in like a wrecking ball after ProgorMatic did a lot of work. I wish I'd seen his earlier posts.

I fully agree with this:

On 8/24/2021 at 10:07 AM, Nertea said:

I'd prefer not to mess with the mass and cost of parts. Stuff changing in the presence of MKS is one thing, as it is a massive change to how the game works, but USI-LS seems to be something you could drop into a save halfway through and messing with masses of stuff in flight is bad. 

I don't particularly have a stake in how MKS works, but in my opinion full switchability of functions isn't desirable because it removes all gameplay uniqueness from parts. I would suggest more limited switching based on roles, but above all else the patch should function in terms of how MKS works, if a user installs SSPX alongside MKS they shouldn't have to learn new mechanics and concepts. 

I've only updated the existing patch to add new parts, kept functions separate, consistently with what they were before, and still do not touch dry masses. I use MKS, but I prefer to have this patch merely enable SSPXR to play with it in a reasonable way, rather than have the presence of MKS override the character of SSPXR parts. There is also already an MKS patch which modifies extensible/inflatables to use material kits, still leaving total deployment mass unchanged. Altogether, the lighter footprint of the old patch is preferable.

It's true that the balance for the old patch isn't self-consistent, and I haven't fixed that balance. I'm open to a balance pass and changing the performance of individual parts, but without changing dry masses, crew capacities, or roles of the parts .

Again, @ProgorMatic, I'm sorry for not having this conversation more than two weeks ago.

[modus]

I reluctantly agree, having played some more yesterday with both patches.

I totally acknowledge the hard work ProgorMatic has put in his patch, and at first I agreed with this approach, but after some playing time I find it a bit too much of a change.

What Nertea could do, but I know he won't (I wouldn't if I was the author cuz it's an ugly solution), is offer both patches in one file and put everything in comments. That way you could uncomment the patch you want. 

[SiCaRiO31]

Ideally, both patches should be avaliable, 1 for new saves and 1 for existing ones. But im not sure that can be done on the fly, at least not without more tons of coding.

[_Zee]

Hi Nertea! I've just updated Probes Before Crew with your 38 (!!) new parts and wanted to let you know I spotted a typo while updating my support patch for your mod. 

sspx-greenhouse-5-1   is looking for "experimentalScienceTech" for its tech node, which doesn't exist. I'm assuming you meant to use "experimentalScience". 

Apologies if its already been reported. Cheers!

[Nertea]

1 hour ago, _Zee said:

sspx-greenhouse-5-1   is looking for "experimentalScienceTech" for its tech node, which doesn't exist. I'm assuming you meant to use "experimentalScience". 

Thanks, no I did not know, I will sort out for the next update.

[AtomicRocketBooster]

So I really like the idea of @ProgorMatic's patch. As someone who both uses SSPX and USI and starts new games all the time, it's basically perfect for me. 

I think even if we go with the other one, a full refresh bringing everything into the same balance scheme is awesome - it could maybe live on as an extra or something?

(Similar to the optional LFO patches)

I think the main problem with ProgorMatic's patch, as I think about it more, is that anyone who's already using both USI and SSPX either can't update, or will see the life support and performance characteristics of their crafts in flight change dramatically. Maybe it's too conservative, but we're really late in the game maturity cycle for breaking changes. 

Maybe ProgorMatic's could be the default experience, with an optional patch if you need backwards compatibility?

The total overhaul patch is just too good to not release in some way, but compatibility is also important and we're so late in the game, you have to give people the option to stick with the existing system. 

Edited September 12, 2021 by AtomicRocketBooster

[modus]

Yeah, kinda feel the same. Because I'm playing a longtime career save progors patch is just too much of a change, so I'm going with the other one.

But, as I already stated, progors patch is really good, and for a new game it is perfect.

[DStaal]

An addition for either patch:

@PART[sspx-adjusting-base*]:NEEDS[KolonyTools]
{
	MODULE
	{
		name = USI_InertialDampener
	}
}

Enables the USI ground-tethers on the cradles/bases.

(And I agree with others that I like the idea of ProgorMatic's patch, but it's too disruptive to be the default.  As an option in an Extras folder, or a PatchManager alternate, it'd be good.)

[ProgorMatic]

I am totally on board with using danfarnsey's patch as the default.  Then I'll look at releasing mine as a separate, optional compatibility patch.  I knew it was a big change when I made it.

Can CKAN be told to overwrite an existing file, or would I need to add some lines to delete the existing modules and make sure mine gets loaded last?

[Rakete]

Very minor bugreport on SSPXr.

The hatch of the new telescope does not close airtight. There is a gap in the hatch, if you close it. So the kerbals can't do internal telescope maintenance without eva-suit. 

 

Also: the telescope (and also the greenhouses and aquariums) can't be cleaned up after usage by an eva-Scientist. Only an installed research lab will do.

Edited September 12, 2021 by Rakete

[modus]

7 hours ago, Rakete said:

Also: the telescope (and also the greenhouses and aquariums) can't be cleaned up after usage by an eva-Scientist.

Hmm I think I resetted a telescope on eva the other day. Will have to check again. 

[NHunter]

8 hours ago, Rakete said:

Also: the telescope (and also the greenhouses and aquariums) can't be cleaned up after usage by an eva-Scientist. Only an installed research lab will do.

Pretty sure the greenhouses (don't remember about aquariums) couldn't be manually reset in the past. You need to use processing lab functionality to reset them (which, conveniently, cleans all other used experiments on the ship in one click).

[Rakete]

50 minutes ago, NHunter said:

Pretty sure the greenhouses (don't remember about aquariums) couldn't be manually reset in the past. You need to use processing lab functionality to reset them (which, conveniently, cleans all other used experiments on the ship in one click).

Yeah, but can‘t a kerbal inside clean them up? Would make sense, wouldn‘t it? Otherwise a research ship, that enters multiple bioms/SOIs would have to carry a lab instead of returning to a station with lab after its journey to deliver the data to be processed there by the experts…

and for the new telescope: since no kerbal can sit in there, the only clean-up is by using a lab. Somehow I wonder why it needs cleaning after looking through? Do the kerbals clutter the sensors with snacks, while watching and munching sweets?

 

I usually deliver my data to a science station and deorbit the science collector ship or refuel it for a new mission with crew exchange. In many cases i sent the old ship to the ground for recycling as even kerbals love the smell of a new car …. Vessel…  the data is then processed in my huge fancy shiny sspxr science station near kerbin or duna, where the experts work through the pile of data…

Edited September 13, 2021 by Rakete

[Krzeszny]

@Nertea Can you do something to prevent uninformed users from installing the SSPXR Metal Surfaces addon in KSP 1.12? The problem is that CKAN users can easily assume that Metal Surfaces improves SSPXR and install it without realizing that it forces them to use SSPXR 1.4.0.

(For those who don't know, Metal Surfaces was covertly deprecated with the KSP 1.12 release of SSPXR, and by covertly I mean it's not marked as deprecated so how would you know?)

@HebaruSan had the idea to just mark it as deprecated but it's needed for SSPXR 1.4.0 and lower, so for users of KSP 1.11 or lower. For the same reason, it can't be removed from CKAN.

Because of it, many users must have missed the recent updates of SSPXR (if you have the MS addon installed, CKAN won't tell you to update SSPXR).

Here's its metadata:

https://github.com/KSP-CKAN/CKAN-meta/blob/master/StationPartsExpansionRedux-Metal/StationPartsExpansionRedux-Metal-1.4.0.ckan

Edited September 17, 2021 by Krzeszny

[Nertea]

7 hours ago, Krzeszny said:

@Nertea Can you do something to prevent uninformed users from installing the SSPXR Metal Surfaces addon in KSP 1.12? The problem is that CKAN users can easily assume that Metal Surfaces improves SSPXR and install it without realizing that it forces them to use SSPXR 1.4.0.

(For those who don't know, Metal Surfaces was covertly deprecated with the KSP 1.12 release of SSPXR, and by covertly I mean it's not marked as deprecated so how would you know?)

@HebaruSan had the idea to just mark it as deprecated but it's needed for SSPXR 1.4.0 and lower, so for users of KSP 1.11 or lower. For the same reason, it can't be removed from CKAN.

Because of it, many users must have missed the recent updates of SSPXR (if you have the MS addon installed, CKAN won't tell you to update SSPXR).

Here's its metadata:

https://github.com/KSP-CKAN/CKAN-meta/blob/master/StationPartsExpansionRedux-Metal/StationPartsExpansionRedux-Metal-1.4.0.ckan

I don't know everything about CKAN so I am not the person to ask about this. You have described the problem well and I"m not aware of a good solution.

 

[Spaceman.Spiff]

7 hours ago, Krzeszny said:

@Nertea Can you do something to prevent uninformed users from installing the SSPXR Metal Surfaces addon in KSP 1.12? The problem is that CKAN users can easily assume that Metal Surfaces improves SSPXR and install it without realizing that it forces them to use SSPXR 1.4.0.

(For those who don't know, Metal Surfaces was covertly deprecated with the KSP 1.12 release of SSPXR, and by covertly I mean it's not marked as deprecated so how would you know?)

@HebaruSan had the idea to just mark it as deprecated but it's needed for SSPXR 1.4.0 and lower, so for users of KSP 1.11 or lower. For the same reason, it can't be removed from CKAN.

Because of it, many users must have missed the recent updates of SSPXR (if you have the MS addon installed, CKAN won't tell you to update SSPXR).

Here's its metadata:

https://github.com/KSP-CKAN/CKAN-meta/blob/master/StationPartsExpansionRedux-Metal/StationPartsExpansionRedux-Metal-1.4.0.ckan

@HebaruSanit could be marked as compatible with 1.11.2 and below. Or incompatible with 1.12

[jefferyharrell]

1 minute ago, Spaceman.Spiff said:

@HebaruSanit could be marked as compatible with 1.11.2 and below. Or incompatible with 1.12

It already is. Its max version is listed as 1.11.9 while SSPX 2.0.3 is compatible with 1.12.9.

[Krzeszny]

TBH, the addon shouldn't have been merged 

I'd suggest renaming it to

[Deprecated in 1.12] Metal Surfaces for Stockalike Station Parts Expansion Redux

or

[Not for 1.12] Metal Surfaces for Stockalike Station Parts Expansion Redux

While it won't solve the problem for 1.12 players who still have it installed and have KSP 1.11 marked as compatible in CKAN, I don't think there could be a better solution.

(Except for all mod authors updating the metadata of 1.12-compatible mods that aren't marked as 1.12-compatible,  so we don't have to install mods for older KSP versions, but I know it's too much to ask for).

Edited September 19, 2021 by Krzeszny
Descriptive tags

[Rakete]

Little showcase how much fun the SSPXr mod can give: A little Munar Station. Some Iondrives are installed for Ap/Pe-Corrections after serveral dockings. This thing is powered by a nice 400kW (electrical usable power) Reactor on the bottom, which generates up to 800kW Waste heat on highest settings - enough power to run all 24 Ion-engines for height control. Some nice cupolas from SSPXr and a long docking arm for my SSTOs to dock.

The centrifuge on the left hand side is not yet deployed, since there are not enough engineers on board right now. This will change in the next mission...

 

Little hint at @Nertea: Don't know if the octagonal (not rounded) docking ports, which snap in 90 degree increments, belong to NFC or SSPXr: If two of them are docked to each other, there is a gap between them. So if you touch the things some day you might adjust the colliders slightly. But it's not worth mentioning or writing a bug report on it :-)

Edited September 19, 2021 by Rakete

[Starseeker]

5 hours ago, Rakete said:

Little hint at @Nertea: Don't know if the octagonal (not rounded) docking ports, which snap in 90 degree increments, belong to NFC or SSPXr: If two of them are docked to each other, there is a gap between them. So if you touch the things some day you might adjust the colliders slightly. But it's not worth mentioning or writing a bug report on it :-)

They're NFC, part of the octo-girder set!