

pellinor
Members-
Content Count
940 -
Joined
-
Yes, if you want to check the limits, probably a second interpolator variant is the the way to go. The interface is supposed to provide a moving target and the servo tries to follow that target in real time.
-
A servo could run in two modes: 1) It once gets a target and then autonomously moves there, such that the trajectory respects the limits (range, speed, acceleration) and comes to a stop at the target. This process is what I call interpolation. 2) Some other device does the interpolation, and sends a position to the servo at every physics tick. The servo moves to this position without trying to stop there. It may enforce its limits, or leave that to the other device and just blindly copy the position. When I wrote the interpolator, we built the interface for mode 1 because that w
-
Just for your info: the last problem that only hit the root part was an access with a hardcoded index, something roughly like 'transform...getChild[0]', that should have been 'transform...getChild["model"]'. That code had worked for years, until in a new KSP version the index [0] of the root part pointed to some camera-related transformation. Which led to a hard to find bug that broke the camera whenever the root part was scaled. Maybe the issue here is similar.
-
These are the exponents for the stock wing modules: https://github.com/net-lisias-ksp/TweakScale/blob/master/GameData/TweakScale/ScaleExponents.cfg#L169-L186 Mass of wings is scaled with an exponent of 2, so that a large wing should be equivalent to the same area worth of small wings. dragAtMaxAoA does not appear (hopefully that means that it is a coefficient and not a total value).
-
My decisions for the exponents mostly came from gameplay considerations. For example stock tanks have a fixed ratio between fuel content and dry mass. If one stock tank is twice as big as another in all directions, it has 8x the fuel and 8x the dry mass. As a rule of thumb, an enlarged part should compare to the same mass, cost and utility as several copies of the original. And most general, an exponent is right when both the enlarged and the shrinked part have some use in the game. A wrong exponent usually leads to one side being overpowered and the other being useless. Example: for a
-
Actually most non-stock modules work fine with TweakScale's config interface, see all the non-stock entries in https://github.com/pellinor0/TweakScale/blob/master/GameData/TweakScale/ScaleExponents.cfg#L236-L463 If the effect you need can be done by scaling a kspField in the target partModule, TweakScale support can be done with a ModuleManager config. Note that the exponent names refer to variable names in the C#-code (which might or might not correspond to config nodes appearing in some .cfg file). Only if this mechanism does not work do we need C#-code, either in the TweakScale codebas
-
Curiously, I thought on something like that recently. But I consider this to be "tricky" to implement as it would break an (programming) interface that are in use for years. OK, there're techniques to make things coexist, but we need to balance cost and benefits of such a feature. The "easier" changes on the programming interface would render the user interface less intuitive, and vice versa. (quoting this from the old TweakScale thread) The scaling part is quite simple and has been done before (for example the DIY Kits in GC). Some other questions are * Many par
-
Let's move the discussion to the new thread and close this one.
- 1,331 replies
-
- renaissance compilation
- visual enhancements
-
(and 3 more)
Tagged with: