Psycho_zs

The stockiest and quite rich set of RCS blocks can be found in MandatoryRCS Part Pack But "stockiest" is going to be meaning nothing but "dull and obsolete" thanks to ReStock team )

New RCS blocks are awesome! Special thank you for 3-way configurations! (and I see what you did there with RV-103 description ) Regarding RCS plumes, they seem to be rather short and slow. Nothing like those flashy fountains, is that something stock FX engine can be crudely beaten into? Speaking of plumes, what is the difference between fxTransformCore and fxTransformPlume in engines? And which one should I target with the RealPlume patch?

You'll probably never dare to not use them

That's perfectly understandable. I'm just querying for information that would help me get everything working on my end. OK, no warnings, but now ReStock plume is still visible. How do I treat all these transforms properly? Or did I wrongly diagnosed the problem? I see that in most RealPlume patches thrustTransform is used, including patches for KerbalAtomics and CryoEngines.

tried adding :AFTER[ReStock] to Squad selectors in RealPlume-Stock, but MM doesn't like that: more than one pass specifier detected, ignoring all but the first: RealPlume-Stock/Squad/liquidEngine1-2/@PART[liquidEngine1-2]:FOR[RealPlume]:NEEDS[SmokeScreen]:AFTER[ReStock] The problem, specifically for Mainsail for example, is that plume originates tens of meters below the engine. My suspicion is that RPS patch assigns plume to 'thrustTransform', and ReStock model does not have that, but has smokePoint, fxTransformCore, fxTransformPlume. I tried to change it to fxTransformPlume, but plume now literally goes sideways Edit: @Kradgger , well, that is synchronicity. Hehehe

Well, there is (very roughly) 100MB difference in KSP process memory (when loaded to main menu) with and without restockblacklist. This is in the ballpark of file size of the listed content (~170MB). I don't know what kind of inflation would the data have (especially textures) when being actually actively used in the game, but the difference is there. We seem to have an honest blacklist mechanism now! YAY! Having a list just sitting in GameData is much more handy that removing stuff by hand after every upgrade.

Does restockblacklist prevent assets from loading, or does it unload them? Or, more important question: does it actually free up memory?

It seems that different exhaust transform names in replaced engines mess up some of the RealPlume Stock patches. What would be the correct way to ensure compatibility?

Installed KER, getting the same results. BTW, what exactly does torque readout represent? The rocket is entirely symmetrical except antennae and chutes near/on the pod.

Is 90 degree rotation and lack of lateral symmetry intentional in shielded docking port model?

Seems to be mod-related. I tried to reproduce on clean game + MH, BasicDV, B9PartSwitch, MM (and no patches), unsuccessfully. In my heavily modded game there is some magic number of parts in this ship (not booster) beyond which numbers become nonsensical. (this happens only in VAB, not in flight)

Kopernicus + Sigma Dimentions = Scalable solar system as a difficulty setting. Simplified for Stock as presets, like 2x, 3.x, 6.2x, etc... (or 0.1x, 0.2x, etc... relative to realistic sizes)

Stages are independent, no crossfeed. Core engine (which is Skiff from MH, but patched to use LH2) is shrouded with a decoupler and inverted nose cone (dropped off with the boosters). I'll try to find what action triggers numbers to change.

I'm having some problems with readouts. Stage 5 is the core LH2 engine, no dV value. Stage 3 ejects LES, reads ISP and dV of what looks like stage 5 engine, sort of. Stage 1 is the main ship engine, no output. After a bit of fiddling and probably an undo action, the picture changes: dV values differ (look more correct, apparently) Stage 1 now has output, Stage 3(5) dramatically decreases.

Switching surface/universal rotation reference would be essential for any static hold (even plain stability assist). I can not imagine life without this feature of Persistent Rotation mod. Also somewhat related: https://bugs.kerbalspaceprogram.com/issues/16117 and:

Everything looks great, values are shown even when the engine of current stage is shut down after use. Maneuver time also shown correctly in this situation.

Your new Mk1-3 pod model has the top node exactly 1.25m in diameter! Hell friggin' yes! Thank you!

I would favor a set of landing legs with horizontal attachment base (as opposed to current vertical attachment base). BTW, Federation's landing legs.

Oh, it's alive! That is a pleasant surprise.

What mod do you use for thrusting in timewarp?

Well, I fluently touch-type in both I doubt it even has a full-blown keyboard. Definitely not as a flight control input device. And those two joysticks would require some training to use.

Using throttle in docking? How crude. OK, I left out Navball Docking Alignment Indicator.

WASDIJKLHN. I probably could dock Soyuz on the first try if it had a qwerty keyboard.

From a technical standpoint there should be some structure between the tank and the engine that bears the loads of both thrust and interstage. So MH engine plates look like a step in the right direction. But it is still inflexible. Adding fairings to decouplers has a lot of potential, but it is unusable in its current stage: collider clipping, properly closing fairing geometry is hard, staging not working properly. How about this: add procedural fairings to decouplers (code reuse is good) remove static fairings from engines and thrust plates add special cues to engines and thrust plates to aid interstage fairing closure predictable position and diameter of interstage attachment maybe via a new type of node changeable with part variants to account for different tankbutts add bevels to fairing wall ends (it's a minor thing that helps greatly in Decoupler Shroud mod) This would allow easy interstage creation with predictable results, and also a killer feature: instant size adapter interstages!

The proper question would be: why the hell splash effects cause such a cringy slowdown. (I'm affected too). ...and for that matter why having planet surface in the frame slows the game down despite there is nothing technically fancy about planet surfaces: they look like the game was made in 2000s, yet they perform like they are loaded with super advanced shaders.