pellinor

Can anyone direct me to the in-game mesh of the Kerbal EVA suit? Ideally I'd be looking for one in the 'falling' pose (arms stretched out) and one on a ladder. Not sure if I'm right here, is there a better place to ask? EDIT: solved!

Wow, so many replies to keep up with... I doubt that blocking is a good idea. It will not completely save you because the root part of a vessel can change in flight (for example when undocking, or when parts are destroyed). On the other hand a scaled root part is completely fine while building, or when using a vessel as a subassembly. If someone wants to code a warning, I'd accept a pull request. I haven't used that mod yet, so feel free to write some patches. If the revamped parts keep their names the stock patches should already apply to them. - - - Updated - - - You can check the patches by looking at a save or craft file and searching for TweakScale modules. - - - Updated - - - Thanks for the advertising! - - - Updated - - - It should work, but I am not sure how good the exponents for the landing gear module are (like braking force or suspension stiffness). I think I remember tiny wheels that did not support as much weight as I expected. However, the landing gear module is probably not worth too much research because it will be redone in the next KSP version. - - - Updated - - - MFT does its own TweakScale support, so I do not touch fuel amounts if a MFT module is present. Most likely the breaking change comes from MFT. - - - Updated - - - There are loads of errors and exceptions in your log, it looks like the install has more problems than just TweakScale. Just one example: - - - Updated - - - An enlarged reaction wheel should be equal in mass, power and cost to several smaller ones. I don't see what's wrong with that. (However there is a known issue about power consumption)

And merged into the dev branch. Thanks!

Sounds useful, and clearly out of scope for TweakScale. If you're interested in writing such a module there would surely be some demand for it. - - - Updated - - - The idea behind an enum is to contain states like red/green/blue, and this is clearly how docking ports are intended. The assumption that red= 2*green = 4*blue only applies to the stock parts. For the mechanics they could just as well be "round" and "square". For node size it depends how it is handled internally. Keeping a list of strings for a specific exponent would conflict pretty heavily with the way TweakScale works today.

MODULE { name = ModuleGrappleNode nodeTransformName = ArticulatedCap deployAnimationController = 1 nodeType = size1 captureRange = 0.05 captureMinFwdDot = 0.866 captureMaxRvel = 1 } There are no exponents for the grappling module, maybe scaling the captureRange will fix it. Anyone willing to test? No Idea what captureMinFwdDot does. nodeType looks like it should be scaled but would not work with the current system (because it uses hardcoded strings instead of a number). - - - Updated - - - I'm not playing KSP at the moment, so I'm not too familiar with the latest mechanics, and won't get much done during the summer. There might be an axponent missing. The stock ISRU hast a value generatesHeat=false, so the converter heat mechanics are probably not tested at all. For the engines there is a heat generation value that got an exponent, maybe the converter also has such a value (that is not set in the stick part). Generally, if an enlarged converter scales to 8x the power and 4x the surface area, I'd expect it to be more prone to overheating.

Thanks! Included in the dev version.

The patches have their current form mainly because I inherited them like this, so I'm open to change there. My main point against wildcard patches is complexity. The sum of all moduleManager patches forms a piece of software that is * hard to debug/diagnose * different for each KSP install (depends on mods, player can add custom patches) * scattered across GameData So if something is wrong, it usually is hard to tell what exactly MM did, and where to find the code of the involved patches. To make modders' and players' life easier I tend to keep patches as explicit and readable as possible. Also, mods should not use the 'FINAL' time, because others might want to act later (e.g. balancing mods removing TweakScale patches). PS: Just as a remark about "they're always radially attached": there are curved solar panels which use stack sizes, and there might also be a mod with foldable panels in a stacked package. Of course the solution would be to support those with explicit patches, but this illustrates how easy it is to hard-code assumptions that do not hold for all other mods. - - - Updated - - - Sounds like a problem in your install. You can scale things, so the mod seems working. The effects of scaling are described in ScaleExponents.cfg, do you have this file? Maybe other mods that overwrite stuff? Fuel quantity should change instantly, the displayed weight may be bugged in the stock editor display (KER/Mechjeb should show the right weight). Any exceptions in the log?

OP updated, thanks! Drag should work now.

If KSP does not break saves TweakScale should be fine. - - - Updated - - - The known bug only applies to the root part. I haven't reproduced anything special about parachutes. Note that the same bug happens in stock for parts with rescaleFactor != 1 (for example the MKS containers), also only for the root part on load/revert but not on launch. - - - Updated - - - If the radiator function is done with a new part module it might need new scale exponents. Haven't really looked at for new part modules yet.

No idea what you are seeing. If tweakScale does nothing the most common error would be a missing moduleManager.dll in the gameData folder.

Is Rescale.cs still needed at all? It looks like MuMechToggle now implements IRescalable (which comes from TweakScale) directly instead of using an intermediate class IRRescale. Anyway, your solution looks good to me, you are on the right version and something is wrong in the github repo. My guess is that the github version InfernalRobotics.csproj is not up to date. This file contains paths to the KSP binaries which are different for all of us, so we don't keep it as synchronized as the other files. This would be a bug that is only found if a new person tries to compile the code.

The problem is, it would add interface clutter and look ugly for pretty much all parts. What we need here is a procedural parts mod with a stretchy (or tiled) middle and separate end caps. - - - Updated - - - Release is up: v2.2.1 for KSP 1.0.4

Recompile is up (dev version), release is on the way. - - - Updated - - - Scale_editor is unused code from my predecessors, I still need to clean that up. You can ignore it for now. Scale.dll is all you need to recompile. (Scale_redist has no dependencies so no recompile necessary).

I'll have a look at the new KSP version tomorrow, havent even tested 1.0.3 yet. TweakScale depends on KspApiExtensions, so a clean build needs a KAE update. Often the old dlls still work, has anyone tested TweakScale yet? - - - Updated - - - I'll eventually do it, just don't have much time for tweakScale at the moment, and bugfixing comes first.

Prerelease v2.2 is up! I'll publish this as a release in a few days, or after some feedback that it works for you. Please help me and your fellow players by giving this version a try. Changelog since v2.1: * KSP 1.0 support: scaling of part drag * exponent -0.5 for heatProduction * support for HX parts from B9-Aerospace * support for firespitter modules: FSEngine, FSPropellerTweak, FSAlternator * remove support for KAS connector port so it stays stackable in KIS * a few missing part patches * update NF-Solar patches (some parts were renamed) * catch exceptions on rescale * survive duplicate part configs

Dev update: drag scaling The dll is recompiled so anyone can help testing. My small test with a 1.25m Mammoth engine looks reasonable now, however there are several distinguished properties to the aerodynamics of a part and it is likely enough that I missed something.

Will be in the next release (already fixed in the dev version).

I'm pretty sure I've already seen something similar in mod code (no idea which mod that was). It would automatically load a save and start for example in the KSC scene. It was meant as a debugging feature because debugging a mod involves starting the game lots of times for small tests.

Ah, this is just what I was looking for, thanks a lot.

How do you adjust the drag model for procedural parts? TweakScale has the problem that KSP uses the unscaled model for the aero calculations, so drag is broken. Are there any other mods that might have solved this problem?

I did some tests for the drag, and I'm hitting a wall there. * I can reproduce a 1.25m mammoth engine having insane amounts of drag. * When trying to scale maximum_drag, minimum_drag and angularDrag, nothing changes. Those values are still in the part.cfg files, though I could imagine they are no longer needed, and will only have an effect when the old drag model is used. Also tried lowering them with a MM patch, no change. Can someone confirm these values do not scale drag? Any more insights in how this new drag system can be manipulated? Edit: solid advice here. Will try that when I find the time to do some more coding.

There is a simple explanation for that, the tweakscae dev does not know how exactly these new systems work. I only find heatConvectiveConstant in one stock part (the shock cone intake). The fact that it is the same for stock parts of different scale strongly suggests that it does not need scaling. Furthermore I'd expect large parts to exchange heat less efficiently because mass usually scales with the cube and surface area with the square of the scale. Of course there might be a problem similar to drag (KSP not taking into account the scaled 3D-model) that can be worked around by scaling this constant, but I'd like to understand that before hacking in something that does not look right.

I'd doubt that part attributes are as arbitrary as you think, they still need to fit into a consistent system. Have you tried playing with them? What changes would you propose? About the general problem, I fully agree. Aero sort of acts as a black box at the moment: you put in your design and you get some strange result without any explanation why it behaves that way or how you could change it. The "stable orientation" display someone suggested sounds like a good idea. I'm just not sure if such an orientation is unique, or is guaranteed to exist at all for an arbitrary craft.

People are saying just the opposite thing about rockets ("please make them fly nose first"). So in my opinion the problem is more about general control (and understanding) of aerodynamic behavior. So you don't change the physics of the game to keep old designs working, but provide people with the information and the tools to evolve their designs. I'm not asking for the lander to fly backwards, instead I want to tell it which way to fly. Building the tools might be more about clever ideas than about writing code. So I see this happening in the player/modding community just as much as on squad's side. The aerodynamic model is very young so the tools to master it just need some time to emerge.

It does not matter how the .cfg file is named, or where in GameData it is located. When distributing such a patch with another mod you should place it in that mod's directory. The clean way to update a mod is to completely delete it and then install the new version. Files from other mods or manual changes tend to get lost in this process. This is also why it is advisable to put your personal tweaks as ModuleManager patches in a separate folder instead of directly editing .cfg files.