pellinor

while we're talking music:

If this is supposed to execute once per frame, you should add a "wait 0." at the beginning or at the end of the loop. Otherwise * it would execute multiple loops until the IPU run out (wasting EC). * at the end of the frame, the last loop would be interrupted at some random line. Such interruptions have caused a few hard to find bugs for me. For example this looks like perfectly safe code: if HasTarget print Target:Name. However, suppose that one frame ends after the first line is executed (with HasTarget=true), and then the target is lost. In this case kOS will execute the second line, and fail with the error that there is no target. I had something like that in a docking function that would sporadically fail in this way. Since then I sometimes add "wait 0." at the start of a section that should happen within one frame.

In general things should execute in sequence just like C++. The best way to help you is if you post simple code examples of the things that seem not to make sense. I usually debug my scripts with lots of tracecode. Either one-time as a new line in the terminal, or updated every frame at some fixed location (note to self: finally clean up those scripts so I can give them a thread in the forum) https://github.com/pellinor0/kOS-MissionFramework/blob/master/Script/libatmo.ks#L145#L149

They have their pros and cons. As you say the patches are more efficient, but they may also be less obvious to read (a search for the part name will not find the patch) and might catch parts that were not intended. So I use them with a bit of caution.

It is no secret that my most active days in the community are long past. All I had envisioned for TweakScale is done, and I am merely doing housekeeping these days. So I'd just like to state that I would be happy to become dispensable in the future. It seems to already work well for the configs, feel free to also dive into the code and add (or fix) things you are missing. There are surely enough known bugs and ideas. Just keep in mind that TweakScale is used in different ways and no one should force his playstyle over everyone else. @eberkain @Mikeloeven there is a merge conflict for the NFT configs, and you both reordered that file, so I see no simple way of merging this pull request. Maybe one of you still knows what he changed and could check if the other file misses any of those parts? Layout-wise I am fine with either style.

We also have the TWEAKSCALEBEHAVIOR nodes I use for group-specific exponents https://github.com/pellinor0/TweakScale/blob/master/GameData/TweakScale/ScaleExponents.cfg#L456-L504 or MM patches that look for specific modules.

I'm not talking about this. All I am saying is that the tech to scale any engine up one scale factor could be the same. I don't know if a part needs to have a bulkhead profile. What I know is that it can have multiple ones and people can invent their own profile names. So probably not a good idea to rely on people using them in a consistent manner.

Never mind, I just read something with using smokescreen in real time and thought that implied coding (because configs are only read once at the start of the game). I see no fundamental problem with having a single tech that would for example allow all engines to be scaled up. We could also code something with child techs but note that a tech may have multiple children or none at all. Also if the restrictions are scattered too far across the tech tree, how shall the player know when which scale is unlocked? Trial and error in the editor? Spam the tech tree with dozens of dummy parts? You don't want a flood of bug reports from people who don't understand the restriction system.

Yes because changing antenna power does not work while a vessel is unloaded (which is the main use case for a relay antenna). This is a problem of the base game: non-persistent values can only be modded for loaded vessels.

Why 2? Shouldn't all geometry scale linearly (exponent=1)? And do we need a config interface for this? My understanding is that it can be hardcoded because these things should always scale like the rest of the model geometry. This is what TweakScale does today concerning particle effects (I'm not familiar with that code yet): https://github.com/pellinor0/TweakScale/blob/master/Updater.cs#L140-L241 Maybe you could have a look, if you are already familiar with the smokescreen interface?

I don't really understand, this does not look simpler to me than what eberkain already has. My idea is more like this techRequiredPlus = largeTech, largerTech, hugeTech techRequiredMinus = smallTech, never which can be defined globally, in a scaletype, or on the part level. By default everything is allowed at start. If the list is shorter than the available scales, the last entry would be applied. So in the example hugeTech would allow arbitrary upscaling, and downscaling would always be limited to one step. Known issue with MFT+TweakScale, fixed in the dev version

Keep in mind that TweakScale does not work on config nodes but on the internal c# structures. For engine plumes you rare probably seeing this issue: https://github.com/pellinor0/TweakScale/issues/11

This was a conflict with MFT and should be solved in the dev version (which unfortunately requires KSP1.2.x). Yes, wheels are wonky, especially at extreme sizes. And I'm already glad that I got them as good as they are now. Well you can try to tinker with the exponents yourself, and I'll happily take a pull request if you find a better exponent setting.

update of the dev branch: * merge several pull requests for patch updates * scaling support for resource lists (for drills and converters) * merged the derivedModules branch into dev (so TWEAKSCALEEXPONENTS should now affect not only the mentioned module but also derived modules, e.g. ModuleRCS=>ModuleRCSFX) There is someting wonky with the tree on github. In my local repo, dev derives from the derivedModules branch (and it also contains its changes), but in the tree diagram it seems not to. But it looks like the content is ok.

My current idea is: * if there is a techRequired entry (from the part or inherited from the scaletype) then this is used (= the old interface) * otherwise look for a new entry that has yet to be defined, containing tech requirements for relative scales

Ah, finally someone who is willing to work on the problem of restriction configs for TweakScale, thanks for your effort! This is some nice MM magic for sorting out the stack sizes. I thought about the relative scaling limits you wanted and agree they are a good idea (and probably can coexist with the tech tree interface we already have). And now this whole thing getting more serious I am also willing to adapt TweakScale to make your life easier (considering things like config interface, packaging, CKAN definitions). My wish is just that a liberal configuration remains available. You can do this at part level (instead of scaletype level), so the config interface is powerful enough. My gripe with it is that a complete set of configs would probably be a nightmare both to write and to maintain.

This is the increment size for the slider (for each interval). It should be roughly small enough to give enough steps, and large enough so searching a particular value does not get too fiddly. I keep procrastinating this because it feels much like another piece of duct tape on an issue (proper restriction configs for career mode) that already has a config interface but is missing both a good concept and someone motivated to implement/balance it.

I'm happy to see some sharing of knowledge here. Feel free to use the wiki. There is also a bit of documentation here: https://github.com/pellinor0/TweakScale/blob/master/GameData/TweakScale/documentation.txt. I'll have a closer look at the wiki when I find the time, there seems to be a bit of confusion about how the stock/MM config syntax works. Not sure what a 'register' is. The 'type' in a TweakScale MM patch refers to (the name of) a configNode of type SCALETYPE, like the ones found in DefaultScales.cfg. Those nodes define the behaviour of the UI and also act as an intermediate scope for scale exponents (this feature is used in the "*_square" scaletypes). Other mods can bring their own scaleTypes, for example IR.

I won't be around until monday so if someone wants to post a recompile for the prerelease ( if necessary) feel free.

Or you require the player to set the destination vessel as target. Then you only need to check the distance, and don't need a UI.

When packing stuff into kits I usually end up with several oddly sized boxes that are hard to fit onto a rocket. They are also about the only big parts in the game which are not round. Would it be possible to add a kit in the form of a cylinder, where the diameter is tweakable and the content determines the height? If I was told to pack things for launching them with a rocket, that would be the most natural form factor.

Do we? As soon as it gets to mods containing artwork my impression is that we are pretty deep in ARR-land. Which worries me because all it takes for good things to vanish is a single person getting mad at someone (which has happened before, and I do notice threats about pulling back close-licensed content every now and then).

I think the problem here is more the antenna system which only allows modding of those values (strength and relay-ability) only in flight but also uses them on unloaded vessels.

Just came to report the same thing. Probably they work only when the ship with the relay is loaded. TweakScale had a similar problem with antenna power. The problem was that it is a non-persistent value that affects unloaded vessels. So you can write it in the flight scene, but any changes get lost on unloading and unloaded vessels will always use the value from the part prefab. This is why I removed TweakScale support from the stock relays.

"But the GameData folder contains a file myCustomPatches.cfg. That is my mod, the rest is packaged dependencies."