pellinor

My understanding was that exceptions generally work that way. And I've seen things (probably in some older KSP version) like some problem during vessel load making it skip half the load. So all parts coming after the first problem were just not loaded at all. Coming from c++, I actually find exceptions extremely comfortable. If a serious problem occurs that would otherwise make the problem crash, it is written to the log, together with a call stack. And afterwards, the program finds back into a stable working state (skipping stuff that is probably not safe to execute).

The best way is to copy from the defaultScales.cfg. Since Version 1.52.1, all scaletypes use the scaleFactors list. However I'd expect that the min/maxScale would be used as a fallback. I'm also not familiar enough with MM to know what those % expressions do (so maybe you wanted to change something but tweakscale still sees some of the old values, like the scaleFactors of some other scaleType?).

So far, I can't reproduce any reverting other than the root part. What are you doing differently? And warnings or exceptions in the log? @slenth: took a look at your log, there are lots of exceptions. If an exception occurs, the following code is skipped until someone catches and handles it. This can lead to reverted parts because the TweakScale module never gets called.

I'd like to add a few remarks: As I understand, 6) is not a KSP restriction but just the current state of IR. I don't see much of a problem with toggling that state in the editor instead of the part.cfg. In any case, free-moving joints do not allow limits, so at the moment they only make sense for 360°-rotation pieces. Also, 4) will not help for your legs because zodius's speeds are normed to the full range of each part. So if you only use part of that range you still need to tweak speeds.

There is no known fix. Why does the craft depend on the scaled root part? You know there is some freedom for choosing which part is the root?

Actually we are just building variable speed robotics :-) In my opinion, binding of position or speed to joystick axes or throttle is not that far away. Maybe not in the core IR, but we plan to make an API that allows others to write their own control solutions that send movement commands to IR servos. Now I think of it, analog input would be quite useful for that.

That's a bug in TweakScale! The last version includes some code to better survive incomplete configs, which should not get active here. As a workaround, you can remove the minScale and maxScale lines of the IR scaletypes. Those are obsolate now (TweakScale 1.52.1), and in this case were not needed anyway. I'll fix the bug in the next version of TweakScale.

This probably means that tweakscake considers the config as incomplete. I'll look into it.

I can't really tell, have tested very few things with that version. It's surely not intended behavior. There will also be no maintenance of this particular version since I ported it over into the ongoing rework.

There's also a recent Code rework going on, you can see it well in the Github version tree: https://github.com/sirkut/InfernalRobotics/network

Update from the smooth interpolation front (Github), (you only need the updated InfernalRobotics.dll). (WIP, may contain bees) Translation works now. Axis inversion works (BUT toggling it in flight will cause jumps!). Speed and acceleration can be configured in the right-click menu. After tweaking min/max, accel or rotateLimits on/off, the new values get active after click 'configure interpolator' (it will refuse to update while moving). A little flight test. The blades were mounted flush on the rotatron, the gaps are caused by centrifugal forces (rotation speed is 2000°/s or about 5.5 revolutions per second). This will probably be the last version from my fork, since I noticed there is already another rework going on and I'd rather contribute there than develop something concurrent.

If you want to pach many parts in the same way, better patch their scaleType instead. Are you talking about the root part of the vessel? That should never be rescaled because of a current KSP bug. I probably don't understand the question here, yes it should work with all sorts of attachment nodes and intermediate sizes.

A first testing version for smooth interpolation is available: Github repo (you only need the updated InfernalRobotics.dll). (very WIP, likely to break stuff!) So far it is only wired to rotation, and tested only with the "IR rotatron" part. Max Speed and Acceleration are still hardcoded, but it takes its modulo flag and min/max position (if modulo is off) from the interface in the right-click menu (will not update during flight). If anyone is curious about smooth acceleration, feel free to test! I wired the three buttons (left, zero, right) with movement commands that last only while the button is pressed. On release the axis will smoothly brake. The debug output shows a bit of the inner workings (like the generated commands and current pos/speed).

I'm surprised that this legacy module is still in use. Which mod does that config come from? Any idea what would be needed to support that? If it can be done with a simple config then I'll gladly include it. For the root part there is no fix (this is a KSP bug). For other parts, I can't reproduce any reverting.

Pull request created. The thing I thought about for IR is two extra buttons tied to +/-infinity. Most likely they would only be used together with a single interval, so that is better done as a separate thing instead of adding it here. So from my part the tweakable is finished and ready to merge. Code review is always welcome, since C# is not my native programming language.

That's fine for private configs but I hesitate to pull it into TweakScale because I have no experience with MFT. Can someone confirm that this is the correct way to scale MFT? You said it already worked in the past, so maybe there already is a config somewhere which broke? EDIT: I took a quick look into the MFT gihub repository. It has its own code to react to rescaling. So something broke in your install and a custom config may be a useful workaround but should not go into tweakscale. I'll get MFT and do some tests myself. Your warnings are probably related to this, MFT uses the Tweakscale updaters to get notified of rescales, of something breaks there it will not do the rescaling. - - - Updated - - - I looked into Regolith support, the harvester module was easy to add. However the converter seems not to work with existing config options. It seems that TweakScale currently can handle structures but not one-line lists. Regolith already has an issue about this. So I'll hope for a fix on regolith's side.

And I've been a bit too impatient to release the next TweakScale version. At the moment the tweakable is doing its work fine within TweakScale, so there is no need to hurry. Currently I am also working on stuff for Infernal Robotics, which gave me some ideas to improve the tweakable. So I'd prefer to give it a bit more time before integrating. As I understand, a pull request means that someting is finished and ready to be merged. Or is it also used for "let's discuss about this piece of WIP code" ?

At the moment min/max values are still used if TweakScale does not find any scaleFactors. So everything is still backwards compatible. (Maybe ksp 1.0 will be a good point do drop obsolete stuff like this)

No, just like everything else you can define a standard in the saletype. Then you only need to patch parts that should differ from that standard.

Sorry for the inconvenience, v1.52 had a bug that can corrupt craft files, and I thought I saw downloads on KerbalStuff increasing even after the fix was up so I decided to take that one down.

The DefaultScales.cfg file provides examples how I would do it. Define the scaleFactors just like you would before for a discrete scaleType, these are the numbers you can reach without using the slider. Highly grained means large steps? You can do this with the slider increment, either globally or separately for each interval. For example the default stack config snaps to 0.1m increments for the largest sizes to allow for round numbers. If you have any configs that do not give the result you want, I'll gladly look through them.

Still exists: you can define a techRequired list (either globally in the scaletype or per part) that will filter out scaleFactors that have not yet been researched. A byproduct of the last version is that this now also applies to free scaletypes. This is an example I found in the OP of the old TweakScale thread: MODULE { name = TweakScale type = stack techRequired = basicRocketry, start, generalRocketry, advRocketry, heavyRocketry }

In general, just look into the configs and copy from there (DefaultScale.cfg in this case). One thing I'll probably change is add :FOR(TWEAKSCALE) to the part patches, so they run at a defined time and other mods can use the :BEFORE and :AFTER times to modify them. Can't say much about exponents since I haven't really looked into that part of the code yet.

My guess is that this only affects parts that were added while using v1.52, and that you need to delete the part and take a new one to fix it.

AVC is supposed to nag you about official releases, and v1.52.1 is one because I consider the part cost bug as critical. Due to a change in the way parts are set up, TweakScale falsely thought it had already done the dryCost calculation so the value was never written. Unfortunately dryCost is persistent (as well as probably the stock part cost), so this can corrupt new craft files. I'd guess it only affects parts you added while using v1.52. I haven't looked at the download button yet, surely some missing config line on my side. I deleted v1.52 from KerbalStuff since I had the impression that there were still people downloading it while the fix was already up. Unfortunately I can not do anything about curse, who is still distributing the buggy version 6 hours after uploading the fix. So what do we learn from this? Maybe I should wait a bit longer before pushing out releases, and be clearer about which version is worth testing. The thing is, there usually is no positive feedback. So if a anounce a pre-release version and nobody complains for a day or two, I can not tell if people are content or if noone has looked at it.