Lisias Posted October 16, 2018 Share Posted October 16, 2018 (edited) As from 2018-1016 and under @pellinor agreement, I'm the New Management for TweakScale. From now on, it's all officially my fault! (well, not everything... ) In a Hurry: Help Wanted! See this post. Current Release: 2.4.8.8 for KSP >= 1.3 (2024-1117) It works from KSP 1.3.0 to KSP 1.12.5! Seriously! How to check Compatibility on CurseForge. IMPORTANT Users of KSP 1.12.x need to install KSP Recall. Users of KSP 1.11.x need to install KSP Recall also. Users of KSP 1.10.x need to install KSP Recall too. Users of KSP 1.9.x need to install KSP Recall too. Users of KSP 1.8.x need to install KSP Recall also. Users of KSP 1.7.x need to install KSP Recall also. Users of KSP 1.6.x need to install KSP Recall too. Users of KSP 1.5.x need to install KSP Recall as well. Users of KSP 1.4.3, 1.4.4 and 1.4.5 need to install KSP Recall. Am I detecting a pattern here? read this post before updating! Announce for 2.4.8.0. 2.4.8.1 was ditched. Announce for 2.4.8.2. Announce for 2.4.8.3. Announce for 2.4.8.4. Announce for 2.4.8.5. Announce for 2.4.8.6. Downloads on CurseForge. Soon™. on SpaceDock (for CKAN users). Soon™. on GitHub (for manual and/or KSP-AVC users). TweakScale Companion Program Third Party support is being implemented into Companions, and all legacy patches are going End Of Life on TweakScale 2.4.4. Most of them are unusable anyway Check the TweakScale Companion Program's Thread for more information. New Companions are being released on a regular basis. Or get the ÜberPaket from: CurseForge. SpaceDock (for CKAN users) Github (for manual and/or KSP-AVC users). Relevant Notes Kraken Food (unholy interactions between Add'Ons) is detected on startup, and a proper (and scary) Warning is shown when appropriated. Pay attention to that message, and reach me here for help! Overrules and HotFixes can be issued to workaround the problems if needed. See this post. A PhD thesis about the current problems can be found on this post. An article about how new patches will be handled is here. For users of Infernal Robotics: The Classic Infernal Robotics has a showstopper bug. See this post for details. TweakScale strongly advise using Infernal Robotics/Next where these issues were solved. Spoiler Old thread: on Forum. Project: Source: on GitHub From 2.4.4.0 and newer: SKL1.0 License and GPLv2 too yeah, this thing is DOUBLE LICENSED. The SKL grants you essential rights for binary use and redistribution. Non revokable but restricted for use and redistribution. GPLv2 grants you additional rights when applicable. Older versions, from 2.4.3.21 and older WTFPL This project makes use of KSPe.Light for TweakScale under the SKL 1.0 license. Current Road Map. Previous. Change Log. Known Issues Mandatory Reading Issue Tracking (You can check what I'm doing here!) Description: TweakScale lets you change the size of a part. Not just that, but it will figure out how much fuel is in the resized part. And if it's an engine, it will become more powerful by scaling it bigger, or weaker by scaling it smaller. (Pictures are eternal work in progress! ) Credits: Contributions From: Goodspeed and Biotronic. [original release thread] Pellinor [previous release thread] And future new features/bugs/mishaps from yours truly. Support: I need help in order to proper help you. Open the spoiler for instructions about how to get support: Spoiler Please provide: A concise, textual description of the problem Mentioning the KSP version and the TweakScale version involved A screenshot of the problem When applicable, the .craft file with a vessel that have the problem When asked, the KSP.log and output_txt log from Unity. See this article for instructions. The Player.log changed location: On MacOS For KSP < 1.8, they are on ~/Library/Logs/Unity On KSP >=1.8, you will find the Player.log on ~/Library/Logs/Squad/KSP/ On Windows On KSP >=1.8, you will find the Player.log on C:\Users\<USERNAME>\AppData\LocalLow\Squad\KSP\ On Linux On KSP >=1.8, you will find the Player.log on ~/.config/unity3d/Squad/KSP/ Publish the files on DropBox, Google Drive or similar, and post the link so we can inspect it. DO NOT paste the log on Forum, this causes a lot of problems and it's useless, as Forum also truncate the file It's ok to paste small excerpts to pinpoint something, but we still need the full KSP.log and Player.log in order to help you/ Do not use pastebin, gist or similars. They have a pretty small cap on the file size, and will truncate the log rendering yet more useless Imgur is a good choice for publishing screenshots when needed. Be sure to quit KSP before copyong the KSP.log, otherwise we risk losing information due the internal file buffers (technical thingy, it's a way to make writing files faster by consolidating lots of small writes into a big one). Using the Issue Tracker is highly encouraged, as GitHub provides services that make everything above easier. You can open an issue there, and call me here pinpointing there to be sure to get my attention. Thank you. Scale Safe! Edited November 18 by Lisias 2.4.8.8 is on the wild. Distributions Channels are being updated as (or besides) scheduled. Quote Link to comment Share on other sites More sharing options...
Lisias Posted October 16, 2018 Author Share Posted October 16, 2018 First Post! (ok, it's unfair) In the next few days, a proper TweakScale release will be issued. The current "unofficial" of mine, by being… unofficial… , it's full of crazy ideas that still need to be proven. Eventually some of them will be merged into the 'mainstream', but until there, I'll keep the official releases the more orthodoxically as possible. Welcome aboard. Fasten your seat belts and sit tight. Quote Link to comment Share on other sites More sharing options...
JedTech Posted October 16, 2018 Share Posted October 16, 2018 Congrats and good luck! Don't go too crazy...Tweakscale is awesome because "it just works". Quote Link to comment Share on other sites More sharing options...
GDJ Posted October 17, 2018 Share Posted October 17, 2018 1 hour ago, Lisias said: From now on, it's all officially my fault! Oh you poor bugger! I wish you well..... Quote Link to comment Share on other sites More sharing options...
Lisias Posted October 17, 2018 Author Share Posted October 17, 2018 2 minutes ago, GDJ said: Oh you poor bugger! I wish you well..... You also have the feeling that pellinor is way too happy? Quote Link to comment Share on other sites More sharing options...
GDJ Posted October 17, 2018 Share Posted October 17, 2018 Just now, Lisias said: You also have the feeling that pellinor is way too happy? Oh maybe. Maybe not. Depends on how much maintenance Tweakscale needs. I'm guessing not a huge amount. Quote Link to comment Share on other sites More sharing options...
Lisias Posted October 17, 2018 Author Share Posted October 17, 2018 1 minute ago, GDJ said: Oh maybe. Maybe not. Depends on how much maintenance Tweakscale needs. I'm guessing not a huge amount. There're new attributes on KSP 1.5 (on the gears, for example) that will need to be handled or stuff will be blown into orbit against your will. I think (but I still need to correctly study the problem) that some issues on 1.4 are due the same. The first step, probably, is to read cautiously every KSP's Change Log from 1.3.1 to 1.5. Quote Link to comment Share on other sites More sharing options...
GDJ Posted October 17, 2018 Share Posted October 17, 2018 42 minutes ago, Lisias said: There're new attributes on KSP 1.5 (on the gears, for example) that will need to be handled or stuff will be blown into orbit against your will. I think (but I still need to correctly study the problem) that some issues on 1.4 are due the same. The first step, probably, is to read cautiously every KSP's Change Log from 1.3.1 to 1.5. The only think I can add to the fix pile (sorry about this) is the strength of the parts when they are "blown up" to around 180% of original size or more. The mass increases predictably, but I find that certain parts can get destroyed easily or they peel off the craft under their own mass (ie wings). It gets worse if there is fuel in the mix (even more mass). Quote Link to comment Share on other sites More sharing options...
Lisias Posted October 17, 2018 Author Share Posted October 17, 2018 5 hours ago, JedTech said: Congrats and good luck! Don't go too crazy...Tweakscale is awesome because "it just works". "What could possible go wrong?" Quote Link to comment Share on other sites More sharing options...
kcs123 Posted October 17, 2018 Share Posted October 17, 2018 9 hours ago, Lisias said: "What could possible go wrong?" When comes to coding ? Answer is simple - "everything" can go wrong. It is just a metter of timing, when it will go wrong at some point Quote Link to comment Share on other sites More sharing options...
FreeThinker Posted October 17, 2018 Share Posted October 17, 2018 (edited) 15 hours ago, Lisias said: First Post! (ok, it's unfair) In the next few days, a proper TweakScale release will be issued. The current "unofficial" of mine, by being… unofficial… , it's full of crazy ideas that still need to be proven. Eventually some of them will be merged into the 'mainstream', but until there, I'll keep the official releases the more orthodoxically as possible. Welcome aboard. Fasten your seat belts and sit tight. Good to hear Tweakscale is in good hands. For a time I considered taking over myself as I had several ideas to improve it. but my hands are already more than full But about ideas, I have several: A: One thing that always annoyed in Tweakscale me is the tech unlocking. You can unlock a specific tweakscale size only by a single tech. Instead, I propose it will also be the combination of the part unlocking tech and the specific size unlocking. That way I can unlock fuel tank with a fuel tech but only allow a bigger tweakscale sizes after unlocking colossalRocketry. B: Another big limitation of tweakscale is that is by default only always only one method of define is scaling growth which is a single exponent. Although this works reasonably well for scaling up, when scaling down it often resulted in ridiculous numbers. Therefore instead, I would like the ability to use float curves that allow we to define exactly how parameters should grow or shrink. Edited October 17, 2018 by FreeThinker Quote Link to comment Share on other sites More sharing options...
pellinor Posted October 17, 2018 Share Posted October 17, 2018 1 hour ago, FreeThinker said: A: One thing that always annoyed in Tweakscale me is the tech unlocking. You can unlock a specific tweakscale size only by a single tech. Instead, I propose it will also be the combination of the part unlocking tech and the specific size unlocking. That way I can unlock fuel tank with a fuel tech but only allow a bigger tweakscale sizes after unlocking colossalRocketry. This is possible today by putting the "TechRequired" field in the part-specific config, which overrides the one on the scaletype. Yes, doing this for hundreds of parts is probably not the most elegant solution. And there is currently no transparency in-game when things will unlock. Quote Link to comment Share on other sites More sharing options...
FreeThinker Posted October 17, 2018 Share Posted October 17, 2018 12 minutes ago, pellinor said: This is possible today by putting the "TechRequired" field in the part-specific config, which overrides the one on the scaletype. Yes, doing this for hundreds of parts is probably not the most elegant solution. And there is currently no transparency in-game when things will unlock. I don't think I was clear enough. I mend that a part cannot be tweakscaled to a specific after both the Tweakscale TechRequired and part TechRequired are BOTH unlocked. Currently the Tweakscale TechRequired overrides the part TechRequired Quote Link to comment Share on other sites More sharing options...
Lisias Posted October 17, 2018 Author Share Posted October 17, 2018 (edited) Just to clarify some things: There're TWO development branches on the repository: the orthodox and the heterodox. All bug fixes and "safe" development are done on the orthodox, and this branch is the only one that can be promoted to master now and then. The heterodox branch is where we can play with nitroglycerine without killing the neighbours. We can discuss and even implement some ideas on there just to see what happens - the worst it can happens is to ditch the code. This branch will be never merged back to the orthodox one. If the event an idea proves valid and worths the potential migraine of becoming mainstream, the changes will be cherry-picked and eyeballed prior being committed into the production safe branch. On the other hand, every change on the orthodox is merged to heterodox, so it keeps synchronized with the status quo. This broke something on heterodox? Too bad: fix it or ditch it. I didn't mentioned Dante's Inferno just because. So… Yeah.We can go wild on new ideas and even try an implementation on the heterodox branch without opening the gates of hell into us. Note to myself: Implement a very scary warning to be issued every time you enter Space Center on the heterodox branch. Edited October 17, 2018 by Lisias tyops, as usulla. Quote Link to comment Share on other sites More sharing options...
pellinor Posted October 17, 2018 Share Posted October 17, 2018 2 hours ago, FreeThinker said: I don't think I was clear enough. I mend that a part cannot be tweakscaled to a specific after both the Tweakscale TechRequired and part TechRequired are BOTH unlocked. Currently the Tweakscale TechRequired overrides the part TechRequired Ok then I was not clear enough. Most TweakScale config values can appear in two places: the scaletype or the part module. The code will first look in the config of the part module, any values found there will win over those in the scaletype (I'm talking about this part of the code). So if you put something like "techRequired = tech1,tech2,tech3" in the TweakScale module of a specific part, the requirements should only apply to the scaleFactors of that specific part. So my statement is that the current interface allows to specify a separate tech for any scale of any part, which is the finest granularity possible. Or maybe the missing piece is that techRequired is not a single value but a list, mapping a tech to every scaleFactor? Quote Link to comment Share on other sites More sharing options...
FreeThinker Posted October 17, 2018 Share Posted October 17, 2018 9 minutes ago, pellinor said: . So if you put something like "techRequired = tech1,tech2,tech3" in the TweakScale module of a specific part, the requirements should only apply to the scaleFactors of that specific part. So my statement is that the current interface allows to specify a separate tech for any scale of any part, which is the finest granularity possible. Yes I know, but its not a lack of granularity , but a lack ability to combine. Let me illustrate with a little example PART { name = AdvancedFuelTank module = Part TechRequired = specializedFuelStorage MODULE { name = TweakScale type = stack defaultScale = 2.5 scaleFactors = 0.625 1.25, 2.5 techRequired = heavyRocketry,heavierRocketry, veryHeavyRocketry } } Now currently the AdvancedFuelTank will get unlocked with heavyRocketry, what I want is that you require BOTH at least specializedFuelStorage and heavyRocketry to use this fuel tank. Quote Link to comment Share on other sites More sharing options...
pellinor Posted October 17, 2018 Share Posted October 17, 2018 1 hour ago, FreeThinker said: Now currently the AdvancedFuelTank will get unlocked with heavyRocketry, what I want is that you require BOTH at least specializedFuelStorage and heavyRocketry to use this fuel tank. Now I understand. So if no scale is allowed the current behavior is probably to allow the defaultScale. This looks like a workaround because once the partModule comes to life it is too late to hide the part. Instead, some global object could check this condition whenever an editor is opened, and hide all parts that do not have at least one unlocked scale. Yes, I agree that would be useful. Quote Link to comment Share on other sites More sharing options...
FreeThinker Posted October 17, 2018 Share Posted October 17, 2018 (edited) 10 minutes ago, pellinor said: Now I understand. So if no scale is allowed the current behavior is probably to allow the defaultScale. This looks like a workaround because once the partModule comes to life it is too late to hide the part. Instead, some global object could check this condition whenever an editor is opened, and hide all parts that do not have at least one unlocked scale. Yes, I agree that would be useful. Yes, that would be even better. It would allow use to balance tweakscale much better. Tweakscale is often shunned because it gives access to higher sizes too fast, well with the discussed improvement we can balanc it better by using the higher technodes like veryHeavyRocketry, giganticRocketry and colossalRocketry, which is now not used Edited October 17, 2018 by FreeThinker Quote Link to comment Share on other sites More sharing options...
Trollsama Posted October 18, 2018 Share Posted October 18, 2018 So Random question, The mod is posted on CKAN as well. Im curious if it will continue to be maintained on CKAN under new ownership or if CKAN support will be dropped.. I ask because I tend to check for updates out of CKAN and not the forums themselves. (i found out about new management out of fluke TBH lol) unless the mod in question isnt listed on CKAN in the first place. Quote Link to comment Share on other sites More sharing options...
viperwolf Posted October 18, 2018 Share Posted October 18, 2018 Looking forward to it, thanks for taking this up. Quote Link to comment Share on other sites More sharing options...
FreeThinker Posted October 18, 2018 Share Posted October 18, 2018 (edited) 5 hours ago, Trollsama said: So Random question, The mod is posted on CKAN as well. Im curious if it will continue to be maintained on CKAN under new ownership or if CKAN support will be dropped.. I ask because I tend to check for updates out of CKAN and not the forums themselves. (i found out about new management out of fluke TBH lol) unless the mod in question isnt listed on CKAN in the first place. Well that sound be to hard. Its just a matter of changing the download reference to the new spacedock location where the new releases are hosted Edited October 18, 2018 by FreeThinker Quote Link to comment Share on other sites More sharing options...
Lisias Posted October 18, 2018 Author Share Posted October 18, 2018 (edited) 8 hours ago, Trollsama said: Im curious if it will continue to be maintained on CKAN under new ownership or if CKAN support will be dropped.. I'm not an enthusiastic user of CKAN, mainly because the Mono defaults are a mess on Linux and Mac, and I'm a heavy user of these OS'es. I was also bitten heavily when a bunch of mods were automatically updated, but one of them caused undesired behaviour and it took me an awful amount of time to figure out what happened. Doing things by hand revealed to be a better solution for me, with me relying on KSP-AVC to keep me informed about updates. That said, I will not drop CKAN support on Releases, but pre-releases (the present state) and experimental will not be CKAN'd (neither published on SpaceDock and Curseforge) for obvious reasons. Edited October 18, 2018 by Lisias Quote Link to comment Share on other sites More sharing options...
Lisias Posted October 18, 2018 Author Share Posted October 18, 2018 13 hours ago, pellinor said: Instead, some global object could check this condition whenever an editor is opened, and hide all parts that do not have at least one unlocked scale. Yes, I agree that would be useful. Meddling with Module Manager and Hide Empty Tech Nodes, I understand how they handle customized Tech Trees. On the fly, in the case of HETN. The same technique appears to be applicable on parts list - obviously, this info is to be confirmed. However... There're risks on such endeavor. I found that it's currently common practice to "hijack" the TechTree unconditionally, what ends up in a race condition where the TechTree currently in use is determined by the not necessarily deterministic order in which such "hijacks" happen. I'm foreseeing the same happening here. I think we will need an Arbitrator for customs Parts List. I think we already need one for TechTrees... Quote Link to comment Share on other sites More sharing options...
pellinor Posted October 18, 2018 Share Posted October 18, 2018 (edited) 6 hours ago, Lisias said: 12 hours ago, mattinoz said: Is there a more advanced version of Tweakscale that allows scaling independently in one direction? Almost a purely aesthetic thing that parts that transition between to sizes often feels to short blend nicely with the next part. 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 parts in TweakScale assume the scaling has one degree of freedom, for example the config interface (scaleFactors, exponents, techRequired), the API for other mods. Is it clear how they should behave once a part can be scaled with two or three degrees of freedom? What additional config possibilities does this need? * Will the resulting config interface still be usable for the average modder? * How many parts benefit from non-isotropic scaling? This is the main point why I haven't done this yet. Most models just look bad when stretched. Edit: for simple cases like visually stretching an adapter, it could also be a separate part module that lacks all the interaction with other part modules. Edited October 18, 2018 by pellinor Quote Link to comment Share on other sites More sharing options...
pellinor Posted October 18, 2018 Share Posted October 18, 2018 5 hours ago, Lisias said: That said, I will not drop CKAN support on Releases, but pre-releases (the present state) and experimental will not be CKAN'd (neither published on SpaceDock and Curseforge) for obvious reasons. My experience is that CKAN hasn't caused trouble for TweakScale yet. It targets inexperienced users and should only see the stable releases. I found it quite useful for the initial installation, but also prefer to update things manually and selectively. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.