d4harp

The art assets are All Rights Reserved, so you won't be able to. It would have been an awesome option to have though. Edit: ignore this, I misunderstood "include" to mean "redistribute"

Will you be updating each mod independently (i.e focus on propulsion and release, then move on to electrical etc.) or will they be getting released as a single collective update? I don't mind either way, I'm just curious how you would approach a mod suite of this scale.

I feel like this logic is backwards. If the restock+ textures/models already exist, why revert back to the making history version? In a making history install, the vanilla styled 1.8m decoupler stands out like a sore thumb amongst all the restock decouplers.

@Poodmund is trying to help, not criticise. Following the advice will really improve the performance of this mod.

Whoever is in charge of screenshots/promo pictures, do you mind listing which visual mods you have installed? (Assuming it's not a custom private config) These pictures look beautiful!

@_Zee I actually looked into this and reported it in the mod's release thread. It's caused by a hardcoded lookup which only contains a few of the possible values (12 is not one of them)

@linuxgurugamer Apologies if you have a preferred platform for bug reports, but the github issue tracker is disabled for this mod so I will report here. In the SituationHelper class, a list of possible values is defined for usageReqMaskInternal & usageReqMaskExternal. However, this list does not contain every possible value and can cause an NRE on a value not explicitly defined (as discovered by @4x4cheesecake in the Probes Before Crew thread)

That's because it is a bitwise mask. The value 12 is a combination of 8 (ExperimentUsageReqs.ScientistCrew) and 4 (ExperimentUsageReqs.CrewInPart) Regarding the significance of changing the values: usageReqMaskInternal defines the state needed to trigger the experiment from the vessel. usageReqMaskExternal defines the state required to trigger the experiment via EVA. So in this case, the experiment can be either triggered by a scientist inside the aquaculture lab, or by a scientist on eva just outside the lab.

In your DMagic patch, there is a section at the bottom with the comment "Deprecated Parts??". These parts are for Universal storage I and are incompatible with Universal Storage II. That is why they are defined as "Unresearchable" in the original DMagic files. So you should probably remove that part of the patch (unless you plan to add support for the old Universal Storage)

@emirkustirika Generally, asking for support with this little information will rarely get a response. Instead, try to reproduce the issue with the minimum number of mods installed as possible. If the issue happens with a single mod installed, it's an issue with that mod. If it only happens with a specific combination of mods, then its an incompatibility between those mods. (you have already started this step by confirming that waypoint manager doesn't reproduce the issue independently) Once you have found which mod(s) causes the issue, report it to the relevant mod author(s) following the steps in the following topic:

IIRC kerbalism uses a psudo-mod called zzzKerbalism (or something along those lines) to force some changes to load after all other mods. If science values are one of these, you would have to load your patches `:AFTER` that psudo-mod rather than relying on alphabetical ordering. Otherwise, I support your suggested solution of override by default. If people are downloading a techtree mod, they most likely want the science balance to be well tuned with the progression balance Edit: Ignore what I said about zzzKerbalism. I just verified by looking at the files. The only relevent change with the psudo-mod is `xmitDataScalar` which probably shouldn't be reverted anyway

By "enormous" file, do you mean the 262MB zip? It would take 1.7 minutes to download at 20Mbps (which is a below average download speed)

May I throw in a request for an AirplanePlus patch?

Kerbalism also adjusts science values (and completely overhauls the way science is handled) so adding optional support without messing up the balance of this mod would be quite difficult That being said, if a kerbalism patch does happen to be possible, I would appreciate the hell out of it

While many of us admire your designs, don't give yourself the stress of us being dependent on you. Ksp is a game, not a responsibility. The whole point of a game is to have fun. If you feel like playing is bringing more frustration than satisfaction, then take as much of a break as you need. Go and play something new/different that doesn't require too much creativity. And when/if you return, do your thing at whatever pace you feel like. We will always accept your art with open arms regardless of when it is released.

The following patch will add a kOS computer to all controllable parts without a crew requirement (i.e. probe cores). If you use this patch, you can play your game with kOS using nothing but stock parts. (I'm not at my gaming pc right now so can't test, but I am using a similar patch in my game and it works) @PART[*]:HAS[@MODULE[ModuleCommand]:HAS[#minimumCrew[0]],!Module[kOSProcessor]]:FINAL { MODULE { name = kOSProcessor diskSpace = 5000 ECPerBytePerSecond = 0 ECPerInstruction = 0.000004 } } Using this as a template, you can add other modules (like MechJeb). However, I think it should be left to the individual user to patch their game like this. If every computer-like mod added it's module to stock probe cores, then the part action windows would get very messy for those parts.

The following page shows all of the forks of this mod: https://github.com/VenVen/Stock-Revamp/network I assume that Kerbas_ad_astra's "KSP_1.4" branch is the active development version. But someone please correct me if I'm wrong. Here's a direct link to the above-mentioned branch (because GitHub can be confusing to navigate if you aren't used to it): https://github.com/Kerbas-ad-astra/Stock-Revamp/tree/KSP_1.4

I think Olympus would be an appropriate name for the 5m rocket lineup. That way, each manufacturer has their own naming scheme: Junkyard = Projectiles, Rockomax = Weather, Kerbodyne = Greek mythology

Has this been tested in 1.4.1 because it included a bug fix for the decouplers' drag cubes which might affect the vessel simulation. (Assuming the issue is aerodynamic related)

I think it might be to do with inverted normal maps. I have very little experience with graphics though, so I don't know how it could be fixed.