Krzeszny

Stockalike Station Parts Expansion Redux adds 5 new station core parts: 1.25m station core 1.875m station core 2.5m station core 3.75m station core 5m station core Do you think the "Launch the Space Station!" contract should require a station core if at least one of those parts is researched? If not, how much should including a station core part pay?

Hi again. I'm still working on a pull request that would make this mod compatible with SSPXR and USI. Among other new mod-specific parameters, I added this under the vanilla science lab: PARAMETER:NEEDS[StationPartsExpansionRedux] { name = PartValidation type = PartValidation title = Include an SDV-X 'Cronus' Extensible Centrifuge rewardFunds = 181000.0 hideChildren = true part = sspx-expandable-centrifuge-5-1 } After uninstalling Stockalike Station Parts Expansion Redux and making sure a folder named StationPartsExpansionRedux isn't in GameData, I'm getting this in my career save: Fulll error: Why and how?

What would a contract look like if it had 2 parameters: Parameter 1 would check for module x (unspecified part) and gave a specific reward (multiple parts have that module) Parameter 2 would check for one specific part (which has module x in it) but gave a different reward? I know how to check for errors (the Ctrl+Alt+F10 menu) but not how to "spawn" a contract if not all requirements have been met, so testing it isn't that easy.

I've noticed that SSPXR has patches that seemingly add its cupolas, science labs, etc. to contracts. However, the contract pack Bases and Stations Reborn don't accept those parts (or at least doesn't list them as options in the contract). Why? Example from SSPXR: // SSPXr contract patches // New cupolas count for contracts @Contracts { @Base { @PART_REQUEST:HAS[#Part[cupola]] { Part = sspx-cupola-125-1 Part = sspx-cupola-1875-1 Part = sspx-cupola-375-1 Part = sspx-observation-25-1 Part = sspx-dome-5-1 Part = sspx-dome-observation-5-1 } } @Station { @PART_REQUEST:HAS[#Part[cupola]] { Part = sspx-cupola-125-1 Part = sspx-cupola-1875-1 Part = sspx-cupola-375-1 Part = sspx-observation-25-1 Part = sspx-dome-5-1 } }

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

Thank you. I did the modifications you suggested but I'd like to also include a universal patch (but I can't code). Can you give me one that accepts any parts with ModuleScienceLab that arent't included in the list (so they don't duplicate)? I'd like it to say "Include X" that uses the part's name and the reward to be Y times the cost of that part. If I patched it with a part from a mod that isn't installed, would it cause errors? And lastly, I wanted to make a new mission but it's getting more and more complicated. I'm not sure if it's worth doing, as I can't code so I can only ask others to code for me (well, to be specifically, to code a patch that hopefully gets added to this contract pack). The simplified version is as follows. Modify this to check for ModuleScienceLab instead of that part: targetVessel1 = AllVessels().Where(v => v.Parts().Contains(Large_Crewed_Lab) == false && v.VesselType() == Station && v.CrewCount() > 0).Random() and make the contract scale the rewards based on the mass and costs of the science lab you choose to haul to the station. And here's a more complex idea, probably too complex: Contract Configurator would choose a random station without ModuleScienceLab. Then it checks for the radial size of the biggest part. It then gives the mission to dock a science lab of matching size, which it also checks for from the available parts. However, since there are sometimes multiple science labs of the same size, it gives you the option to bring any of those with different rewards scaling with mass, and refunds the cost of the part, too. It also checks whether the station has a centrifuge. If it doesn't have one and the appropriate size has a science lab with a centrifuge, it asks you to bring the centrifuge lab specifically. If there's already a centrifuge, it asks you to bring a non-centrifuge lab of the appropriate size.

@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

@linuxgurugamer Or maybe it's not a problem with all contracts but just ones from Duna One (which I'd still like to change):

Cool, I didn't know that mod. If it still works, it seems like a better alternative to ScienceAlert (but [x] Science is still useful with its experiment finder).

-

Noted

So you never watch my bug report videos... is it because of the buzzing microphone?

You replied to the wrong post but I get your point. My second post was supposed to be a bug report but it turned out to be not connected with MOLE.

-

I was expecting this mod to either not show resting Kerbonauts on the crew list or display any kind of text message that a particular Kerbal is resting when trying to put them in a command pod. I wasn't expecting any windows or any other UI nor was I expecting having to go to the Astronaut Complex each time before launching a mission or a simulation, simply because it was never required in stock KSP. One does not simply expect users to report bugs. Remember the white icon that nobody reported before I did? Anyway, Crew tab shows 6 Kebals > you try to put someone in a comand pod > everyone in the crew tab literally disappears. Ok, I was somewhat unlucky that all my Kerbonauts are on a break at the same time, for the first time (I didn't use this mod before), but still, it looks like a bug, considering how many mods I have installed. I'm not expecting you to fix it if it 's intended but is it really intended? Do you see no problem here? "My crew disappears when I try to put them in a command pod. I don't know how to fix it and can't play KSP. This is fine "

After spending more than an hour wondering why my crew disappears, copying KSP instances, and finding out that it only happens in career mode I got the idea to visit the Astronaut Complex and only there did I notice that the crew needs 18 more minutes to recover. The problem with this mod is that it doesn't tell you that the crew is recovering. When your crew straight-up poofs and it's gone when you try to assign them to a vessel, that's... a really bad user experience, I guess. Player.log https://drive.google.com/file/d/1-Gi-KZ6w_1zjhSac9JaBkUa3ajB9DS-v/view?usp=sharing (Best regards, S.A.V.E. Resaved 1.11.0.1) Also, there's a typo. This mod is called "Crew R&&R" on CKAN.

I'm getting a B9 error that opens a window which asks me to close KSP. A similar error was mentioned on page 2 of this thread. It started happening when I copied an instance of KSP and uninstalled some mods. It only happens when either the Fuselage or SphericalTanks part pack (or both) are/is installed. [LOG 00:04:11.403] PartLoader: Compiling Part 'DaMichel/SphericalTanks/Parts/c125-r88-SphericalTank/DM-SphericalTank-125-88' [ERR 00:04:11.403] PartCompiler: Cannot replace texture 'c125-colormap' as cannot find texture 'DaMichel/SphericalTanks/Parts/c125-colormap' to replace with [ERR 00:04:11.404] PartCompiler: Cannot replace texture as cannot find texture 'c125-normalmap_NRM' to replace [WRN 00:04:11.406] PartLoader Warning: Variable tankVolume not found in Part [WRN 00:04:11.406] PartLoader Warning: Variable B9Volume not found in Part [ERR 00:04:11.411] Module ModuleB9PartSwitch threw during OnLoad: System.Exception: Fatal exception while loading fields on module ModuleB9PartSwitch on part ---> System.Exception: Exception while loading field subtypes on type B9PartSwitch.ModuleB9PartSwitch ---> System.Exception: Exception while loading fields on subtype PartSubtype EC+MP ---> System.Exception: Exception while loading field tankType on type B9PartSwitch.PartSubtype ---> System.Collections.Generic.KeyNotFoundException: No tank type named 'KGExSupport' exists at B9PartSwitch.B9TankSettings.GetTankType (System.String name) [0x00030] in <2aacd5f344de4b4cbd0690767697fdd6>:0 at B9PartSwitch.TankTypeValueParser.Parse (System.String value) [0x0000b] in <2aacd5f344de4b4cbd0690767697fdd6>:0 at B9PartSwitch.Fishbones.NodeDataMappers.ValueScalarMapper.Load (System.Object& fieldValue, ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00022] in <2aacd5f344de4b4cbd0690767697fdd6>:0 at B9PartSwitch.Fishbones.NodeDataField.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00043] in <2aacd5f344de4b4cbd0690767697fdd6>:0 at B9PartSwitch.Fishbones.NodeDataList.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00025] in <2aacd5f344de4b4cbd0690767697fdd6>:0 --- End of inner exception stack trace --- at B9PartSwitch.Fishbones.NodeDataList.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00058] in <2aacd5f344de4b4cbd0690767697fdd6>:0 at B9PartSwitch.Fishbones.NodeDataObjectExtensions.LoadFields (System.Object obj, ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00033] in <2aacd5f344de4b4cbd0690767697fdd6>:0 at B9PartSwitch.PartSubtype.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00000] in <2aacd5f344de4b4cbd0690767697fdd6>:0 --- End of inner exception stack trace --- at B9PartSwitch.PartSubtype.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x0001d] in <2aacd5f344de4b4cbd0690767697fdd6>:0 at B9PartSwitch.Fishbones.Parsers.NodeObjectWrapperIContextualNode.Load (System.Object& obj, ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00038] in <2aacd5f344de4b4cbd0690767697fdd6>:0 at B9PartSwitch.Fishbones.NodeDataMappers.NodeListMapper.Load (System.Object& fieldValue, ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x0009e] in <2aacd5f344de4b4cbd0690767697fdd6>:0 at B9PartSwitch.Fishbones.NodeDataField.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00043] in <2aacd5f344de4b4cbd0690767697fdd6>:0 at B9PartSwitch.Fishbones.NodeDataList.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00025] in <2aacd5f344de4b4cbd0690767697fdd6>:0 --- End of inner exception stack trace --- at B9PartSwitch.Fishbones.NodeDataList.Load (ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00058] in <2aacd5f344de4b4cbd0690767697fdd6>:0 at B9PartSwitch.Fishbones.NodeDataObjectExtensions.LoadFields (System.Object obj, ConfigNode node, B9PartSwitch.Fishbones.Context.OperationContext context) [0x00033] in <2aacd5f344de4b4cbd0690767697fdd6>:0 at B9PartSwitch.CustomPartModule.OnLoad (ConfigNode node) [0x000ea] in <2aacd5f344de4b4cbd0690767697fdd6>:0 --- End of inner exception stack trace --- at B9PartSwitch.CustomPartModule.OnLoad (ConfigNode node) [0x0010f] in <2aacd5f344de4b4cbd0690767697fdd6>:0 at PartModule.Load (ConfigNode node) [0x001ab] in <cd473063d3a2482f8d93d388d0c95035>:0 tankType = KGExSupport can be found in Fuselage and in SphericalTanks patches KSP.log https://drive.google.com/file/d/1-6bLg6mTrMS7DtzWWiKTAbHDRMo6YXG6/view?usp=sharing Player.log https://drive.google.com/file/d/1-CYkZzLbsH2OVJNyB6Hxych5i9WOsJaR/view?usp=sharing

Regarding my previous post I tested all command pods (that aren't spaceplane cockpits) from NF Spacecraft and stock KSP to see whether their exits were correctly defined. I didn't even find any problems with Nereid (I don't know why it's blocked in my previous screenshot). The only problematic pod is Proteus. The real hatch area that can't be obstructed is shown in the screenshot below, and as you can see, it's misaligned by a lot. Fun fact: Nereid is pronounced nee-rid.

You're a science mode player. I play in career mode and can't afford to upgrade the VAB to get action groups yet.

The easiest solution that's not a solution is adding this bug which is not a bug to the list of known bugs in the OP

The video I added at the bottom. You probably missed it. In the video I comment what makes it different. To be clear, I'm trying to make 4 points in the video: No new experiment: Spam from ReAlerted's Collect All took 17 seconds Spam from Experiment Storage Container's Collect All took less than 3 seconds New experiment: There was no spam from Experiment Storage Container ReAlerted spammed for 19 seconds IMO it proves that there's something wrong with ReAlerted. 1.11.0 I always check for updates before launching KSP I updated SAVE to 1.11.0.1 just now and the console is stil getting spammed, by the way.

The Harvester configuration addon from SystemHeat is broken. 8 days ago I reported it in the Stockalike Mining Expansion thread thinking that it's that mod's fault but it's not. Baha EPL augers break in the same way with the Harvester configuration. All unconfigured drills (SME and Baha) have broken Load (drilling speed) with SystemHeat + Harvester configuration addon installed. While stock drills usually have 125% Load with a 5-star engineer and 5% Load without any engineer, drills from SME have completely random Load values even at optimal temperatures, and they're always hugely lower than expected, making mining very slow. Load, per KSP wiki, is "T" times "m" where "T" is thermal efficiency (between 0 and 1) and "m" is the engineer multiplier (normally between 5% and 125% where 5% is no engineer and 125% is a 5-star engi). (The exception is that Drill-o-matic Jr in vanilla KSP, without SystemHeat has 7.5% Load w/o an engineer but with SystemHeat 5% w/o an engineer. It definitely should have 5%.) Note that with SystemHeat and its addon, custom drill Load (drilling speed) very slightly decreases (only by 0.02% to 0.20% from cold to optimal temperature) as thermal efficiency increases (or is it because of time?), and it should be the opposite. When the optimal Loop Temperature is reached, Load still keeps decreasing seemingly for no reason, but not with all drills, only with some. Also note that if you stop drilling and start again, the PAW won't show the load most of the time, you'll only see "Operational" until you restart try slowly toggling it on and off. In vanilla KSP, Efficiency (whatever that is) first starts above 100%, increases a bit as the temperature rises and then with stock drills it comes back to 100% at optimal temperature. However, with SystemHeat and unconfigured drills (SME/Baha EPL) Efficiency starts above 100%, increases a bit and decreases a bit while still staying above 100% at optimal temperature - it shouldn't. Here's a list of tests I made for drills auto-configured with the Harvester configuration addon. The format for the Load of each drill is X / Y where X is with a 5-star engineer (the maximum possible speed) and Y is without an engineer. Y is normally equal to X/25 but in a few cases it wasn't, those are in red. I tested it using KRASH to teleport my mining rig to the same coordinates on Minmus each time (13 lat 80 long). The Load values of unconfigured drills change each time I open KSP, which is why second and third tests were different. Stock: Always 125% / 5% base efficiency SME: Trowel: 4.72% / 0.19% | second test (next day) 83.02% / 3.32% Prospector: 11% / 0.17% (should be 0.44%) | second test 4.17% / unmeasured% Wildcat vertical: first test 28% / 1% | second test 4.20% / unmeasured% Wildcat horizontal: 83.44% / 3.34% Tremor: 11.21% / 3.32% (should be 0.45%) | second test 82.96% / unmeasured% | third test 36.28% / 1.53% (should be 1.45%) | fourth test 39.99% / 1.52% (should be 1.60%) Terravore: 83.23% / 3.33% Lithoquake: 106.12% / 4.24% | second test 80.36% / 3% or 3.21% Baha EPL: DRL-0R1: 38.26% / 1.53% As you see, the X values are seemingly random and Y most of the time equals X/25 but sometimes not (???) Here's the log https://drive.google.com/file/d/1eDJU0oZmCe5KH1JF6Vj6uFmMUeaw1vvg/view?usp=sharing And here's the test vessel I use (requires SME and Baha EPL Redrilled) https://drive.google.com/file/d/1jzProEYtgaZ8LnajTUmwT7HazhHlILMc/view?usp=sharing

While the Landed tab allows inputting an altitude, the real spawn altitude is never below a predetermined minimum (the default value) connected with the vessel's size and the minimum altitude is always too high. For examply, my test lander is landed at 3 meters AGL but it spawns at 19 meters AGL (even if I choose 4 meters) and keeps falling for 15 seconds (Minmus). Just so you don't say "no logs no support" https://drive.google.com/file/d/1eDJU0oZmCe5KH1JF6Vj6uFmMUeaw1vvg/view?usp=sharing

It's not the same. Here's the log from the examples recorded below: https://drive.google.com/file/d/1eI6ZnOgaCFzGAZT6wU2leQlv47yPqS1M/view?usp=sharing

@Nertea is it normal that this hatch is obstructed while it visibly isn't? I suspect other pods might have the same problem.