• Content count

  • Joined

  • Last visited

Community Reputation

452 Excellent


About pellinor

  • Rank
    Miniature Builder
  1. We also have the TWEAKSCALEBEHAVIOR nodes I use for group-specific exponents or MM patches that look for specific modules.
  2. 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.
  3. 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.
  4. 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.
  5. 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): Maybe you could have a look, if you are already familiar with the smokescreen interface?
  6. 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
  7. 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:
  8. 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.
  9. 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.
  10. 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
  11. 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.
  12. 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.
  13. I'm happy to see some sharing of knowledge here. Feel free to use the wiki. There is also a bit of documentation here: 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.
  14. I won't be around until monday so if someone wants to post a recompile for the prerelease ( if necessary) feel free.
  15. 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.