pellinor

My understanding is that the engine and the propeller are two different things. At sea level on Kerbin a huge propeller is useless if the engine is the limiting factor. In a thinner atmosphere the propeller meets less resistance, so you need a larger propeller to fully use the same engine. So I'd expect your engines to perform differently at high altitude or at duna.

known issue. There is code for rescaling particle effects but I haven't yet understood why it broke or if it worked in the past. Sounds like a broken install. Your log would help. Do any of the exceptions come from TweakScale? And for the SRB, you also compared the TweakScale patches of those parts? If it is something exotic the patch might be out of date.

Is there a simple way to get Eta:Apoapsis / Eta:Periapsis for the orbit patch after a maneuver node? Edit: next question, how do I get the times of transition between orbital patches? An orbit seems not to know when its patch starts or ends.

Ship:Body:GeoPositionOf( Ship:Position+ X * Ship:Facing:ForeVector ):TerrainHeight This should give the terrain altitude of the point X meters in front of the rover.

One more idea: it seems common ground to use KASModuleStrut for base tunnels and fuel lines. Like the stock strut, it transfers shear stress, which is both unlogic and causes/amplifies jumping with large connected bases. Wouldn't it make sense to use the behavior of the winch cables instead? They can transfer tension (normal stress) but no shear stress. If this works better, it should not be too hard to strip down that module to remove the GUI and pulling functions. Edit: better wording

Suspension also seems to help against jumping bases: if a landing leg is loaded slightly clipped into the ground, only its foot will jump. My understanding is that you need a collider with a large rigidly attached mass to clip the ground. The clipping creates a large force, and the impulse transferred to the vessel depends on how long this force needs to push the collider out of the ground (against the weight and inertia of the attached mass). So ideally any collider prone to ground clipping should have a light mass attached and be flexible against the rest of the base. This brought me to an idea, what about modelling the floor of the inflatables as a suspended collider, like in a landing leg? This would make them bounce more softly and more robust against ground clipping issues. No need to change the visual model, just let it clip the gound. Also KIS/KAS pipes can be a problem because they make the whole base one rigid object, boosting the above problem. Maybe it is possible to weaken the joints of those parts? (in a way such that they flex more easily without breaking)

Maybe you could check on loading if a Kerbal is inside, and have it start inflated in this case?

This can be caused by several things, the most common are * There are no TweakScale modules (missing modulemanager.dll) To check if your part has a TweakScale module you can save a craft and search for "name = TweakScale" in the craft file. * other mods that forbid scaling certain parts on purpose (surely not the ones from your list) * Exceptions, no matter if they come from TweakScale or somewhere else (search for "exception" in your log).

TweakScale_ModularFuelTanks is part of MFT, but does not appear in the current version. This is probably a remnant of an older version that was not removed cleanly. Issues like this are typical if you copy a new version over an older one without deleting the old folder first. It might also be in the TweakScale directory, I think some older versions of MFT used to put it there.

That's quite a bit of bashing here. If someone has issues pointing to TweakScale, other than its mere existence, I kindly ask you to bring them to the TweakScale threads.

You find those parameters in scaleExponents.cfg in the TweakScale folder. For example mass=3 means that part mass scales with volume (=scale^3) per default (unless overridden for a part or a scaleType). Engines are balanced to preserve ISP and TWR.

Thanks! That's just what I was looking for. The thing with the middle mouse button is that the camera still rotates around the CoM. For the use case of finding some tiny part on a ship with a giant asteroid attached, this is still more tedious than it needs to be.

Probably the non-scaling parts have new names. This needs some sorting through his part configs and my opt_tweakScale file to see what is obsolete and what is missing. I'd like to wait with this until there is a stable release (currently the thread says 'test release' so there might be more changes to come).

Thanks for the explanation, seems like I had a few misconceptions over the details of the scope system. Which naturally leads to errors that correlate with nested calls and the use of local variables. Especially locks of Steering and Throttle can be hard to debug if they live longer than intended, end up pointing to invalid variables and throw anonymous errors at seemingly random times.

Are there any known problems with a larger stack depth? I seem to run into lots of strange issues when running functions in a call depth of 5-6 and more. When I try to reproduce them in a simpler situation they vanish. And often when I touch something in a meaningless way, things break slightly differently. As I recall this started after I had set "lazyglobal off" and used local variables where possible. I found some hints of such problems here. Is this still the case? https://github.com/xeger/kos-ramp/blob/master/README.md "WARNING: notice the control flow between programs is fairly flat. I try never to call more than 2-3 programs deep. This is because the kOS VM seems to have bugs with programs and functions calling one another. Specifically: 1) Local variables from inner programs sometimes overwrite same-named variables from the outer program 2) Function libraries don't seem to work when they are compiled code"

Is there a way to get the latest builds from your build automation? So far I only found the official releases on Github.

I happily take suggestions, most happily in the form of working ModuleManager patches. The thing is, I can't stay up to date with all the mods I'm not using myself. So it often the users of those mods who contribute patches or notice when something needs an update.

Still using MFT? Then this is most likely the culprit.

Update: v2.2.6 * Support for NF-Construction * update for NFT Octo-Girders * fix for infinite loop between TweakScale and MFT * fix for engineer's report mass display I'm still not quite up to date with 1.0.5 (cutting down my computer time due to wrist issues). So if there's more to do please complain. (Or even better, propose a solution if you found one)

Update: v2.2.6 * Support for NF-Construction * update for NFT Octo-Girders * fix for infinite loop between TweakScale and MFT * fix for engineer's report mass display

I think the question is more about confidence that the project will lead to something useful. Coders and artists have the advantage that they can start by themselves and then show off first results. Or already have a reputation as a modder. It is much harder for leaders. Leading without actual power is hard, without meeting in person even more. Sometimes the only thing we know about this person is that he wants to lead. So it is much harder to create this kind of trust in a person or project.

Do you know there exists a script to import whole crafts into blender, using the model files from the game? This is what I used in my own 3D printing project:

The whole idea of KIS is breaking a central challenge of the game (not being able to rebuild vessels in flight). Making rescue contracts a bit easier is just one small consequence of those mechanics.

Dev update: * another try at fixing the mass in the engineer's report.

Actually they don't need to know about each other. It works if everyone remembers know what he added to part.mass and returns this as his moduleMass. It would also be my favourite solution that everyone (i.e. editor and flight) uses part.mass+getmoduleMass+resourceMass. Let's hope for the best.