Jump to content

Lisias

Members
  • Posts

    7,456
  • Joined

  • Last visited

Everything posted by Lisias

  1. Yep. People is used to ask for help here, not only on TweakScale but sometimes to not directly related issues. And they get help most of the time. I have this behaviour when Add'Ons throws exceptions on the Start, Load or Copy KSP handlers. Yes. To publish the KSP.log (and the Player.log) so people can help you diagnosing the problem.
  2. "In Space, no one can hear you farting..." Kerman, Jebediah.
  3. Just watched the most recent release of Within Temptation and, boy... Not sure if it would be allowed here! So I decided to publish this one.
  4. 4 Years later, and another one bites the dust. I'm facing this exact problem - but I had found that what's happening is the prefab data being shoved back regularly on the ui_control. By changing the value using Reflection, I managed to get the new Min and Max values working for some time - but as soon as you change scenario, the values are reset again and, curiously, they become imune to the new changes from the code (i.e., trying to restore the data using OnStart, OnCopy or even Update is useless). Curiously, this appears to do not affect the Resources controls - i.e., I can mangle the Min and Max values for a Resource control.
  5. Just installing Add'Ons is not enough. The Add'Ons need to support each other. I don't know about BDArmory, but Airplane Plus doesn't have support for TweakScale and until the moment nobody had wrote such support. SXT works with TweakScale because someone wrote support for it. -- POST - EDIT -- @theKSPnoob I wrote APP support, and it's currently in Beta (i.e., it's being testing and can have bugs, besides I think there's none left and there are people are already using it). You can download it from here.
  6. Well, just to mark the support, this was answered on the GitHub issue #13. (so I don't try to answer it again in a few days ).
  7. I'm not pushing it here. And pushing it on elsewhere is not a problem at all. Language barrier. I was not counter-attacking neither. But I stand by what I wrote nevertheless - there's a place for each approach, but people should have the choice to opt for what approach suits them better, instead of being locked up on the whims of someone that don't care about his/her needs. So, instead of continuing fix things again and again everywhere, I choose to pursuit the simpler path: fix what's really broken, instead of fixing working things to cope to what's broken. It's how I keep some of my Add'Ons working fine on multiple KSPs, from 1.4.1 to 1.9.1 - and some few of them even working on 1.3.1: you will see some of my Add'Ons (official or not) working flawless from 1.2.2 to the latest KSP 1.x with the same binary, mark my words. And it's with this spirit that I choose not to push a change on the @girka2k's Official fork that would just deactivate a pretty useful feature (auto reloading parts), or shove some code that would introduce risk of creating maintenance headaches - Module Manager already have the feature, and it was open and being in use since 2014, so why changing it for worse in a way or another? I choose the simpler path. It's working. It's legally available to those who prefer the simple way. Our concepts of "Right Things" are fundamentally non convergent, as it appears... I'm already doing the Right Thing™ on all my works: I'm following Forum policies when such works are published here, and I'm following the host's policies when they are published somewhere else (not to mention the proper legal licensing terms). Every single fork states clearly it's a fork of mine, and it pinpoints the Upstream on the References. And this should be more than enough. But... It's always possible to make things better. And yes, it's working on KSP 1.4.0 to 1.9.1, have all the fixes (and some minor ones of mine too) and it is working with the @girka2k's fork right now on the spot without the need of changing the WeldingTool code - and this is the only reason I'm posting this here. I think that this is our last post pertinent to this Thread. Perhaps we should move any further discussion somewhere else?
  8. TL;DR: Check: change, the last change before, oldest mention of the file before a internal refactoring, and the first time MMPatchLoader was extended with LoadingSystem. This first LoadingSystem commit was made in 2014, so we have 5 years of a public class being served this way!! Source. But the maintainer dismissed the report, so there's nothing it can be done on the official fork. So I decided to solve it on mine. It's good that someone would step ahead and fix all the Add'Ons on the wild to cope with these gratuitous changes that happens now and then - but I found easier to just fork a few things and fix them, and then everything else would just keep working.
  9. The official MM doesn't works on 1.3.1. Mine does. Being the reason my forks are not advertised on Forum neither goes to CKAN or Spacedock. Open Source is not about being forced to use broken things because one developer decided you don't matter.
  10. And that's the reason I decided to fork ModuleManager instead, and avoiding having to change every single other Add'On. My forks are working from 1.4 to 1.9 (some of them 1.3.1 too)
  11. FRITZ VON OPEL - the Kerbal among Humans. Source: https://silodrome.com/fritz-von-opel-rocket-car/
  12. Hi. I did a look, and on a (almost) clean install, I found no problems. Publish your KSP.log on some file sharing service (as drobox) and link it here, and I will give a look on it for you. In time, you need to extract the CompletelyNonAggressiveRocketry contents from the zip into GameData (ie, there should be a GameData/CNAR folder on it, not a GameData/CompletelyNonAggressiveRocketry/CNAR ). Some of the troubles I had diagnosed in the past were related to improper installation, so it worths to mention it.
  13. Thank you. You have a good taste. Yep, it was a possible side effect of the way KSP define Mass on the config file: by some reason, the Mass value on the Part on the config is related to the total mass of the part including resources, but TweakScale needs to calculate the Dry Mass of the part at default scale before scaling the part (since only the part's dry mass should be scaled!!) - what can be tricky with Fuel Switches, as different resources have different densities and, so, different mass for the same amount of Units of the resource: if you have a Part with 1.000 Units of Lead, and then a Fuel Switch change it to 1.000 Units of Cotton, failing to proper calculate the Dry Mass will lead to problems. The commits you mentioned does not touch Mass in any way, whatever you detected, it was already happening before. Well, since I'm already here: See? No negative mass. Well, I think you are using an older KSP version? The newer ones are not giving me negative mass. Please mention the KSP version you are using, this is very important to diagnose the problem.
  14. Check of the SAS was engaged when you turned on AA. I solved some weird behaviours this way. Perhaps it would work to you.
  15. Yes. I'm working on it right now - it will be available on CKAN as soon as I fix a last mistake. It's there already!
  16. Welcome! Kick me if you need some assistance on understanding the TweakScale interaction on the bug. If the thing explodes inside TweakScale, I can diagnose the Exception easily!
  17. This one is epic!! https://steampunktendencies.com/gabriel-o-the-steampunk-sidecar/
  18. Believe me, it was. I was fearing for something... yet less then desirable. KSP2 having a push back after such an... event... as covid19 is probably one of the best notices I had for months - it means that there's something to push back, and it is expected to be released.
  19. NOTAM I just updated KSP Recall to 0.0.3.1 . I highly recommend installing it on KSP 1.9.x, as now it also fixes a glitch on the Editor when cloning parts with the amount of a Resource changed! (TweakScale not needed to use the fix, KSP Recall is a stand alone tool)
  20. I managed to fix it!!! I just published an update for KSP Recall where I have this problem (kinda of) fixed on KSP 1.9.x Besides being created mainly for TweakScale (at least, I don't know any other Add'On willing to use it), you don't need TweakScale installed, just install KSP Recall and it will intercept some Editor events and fix the Resource Amount of the parts being cloned! I didn't found any collateral effects until this moment - but if someone detects something weird, please report on the KSP Recall thread. ping @Kerbalwerks, @bestPlayer_xu . @Rhomphaia can you test it the same way you did above?
  21. ANNOUNCE It appears that this stunt is still working fine, after all! KSP Recall 0.0.3.1 is available for the brave Kerbonauts willing to risk their SAS with these stunts. This release fixes an Editor glitch that resets the amount of a Resource when cloning the part. Now, the resource's amounts are preserved! Exercise prudence however - this thing is still not completely tested with Fuel Switches. Use S.A.V.E. just in case. Good Luck! This Release will be published using the following Schedule: GitHub, reaching first manual installers and users of KSP-AVC. Right now. CurseForge, Right Now! SpaceDock, Right Now! The reasoning is to gradually distribute the Release to easily monitor the deployment and cope with eventual mishaps.
  22. Hi! Make a request on TweakScale Companion Thread. To make my life easier, mention the URL on Forum for the Add'On you want support and I will take it from there.
  23. Publish the KSP.log and I will give it a look.
  24. My friend, I own you an apology. I managed to bork the NFS patches on TweakScale, I screwed up a merge somehow and didn't noticed - an old CFG file resurrected from the deepest tombs of the GIT history and I didn't noticed. I will release yet a new release for 2.4.3.x series with this fixed (and after double eye ball everything just in case). Until there, delete the following file: GameData/TweakScale/patches/NF/NFS_TweakScale.cfg It should not be there. The ModuleManager.3.1.1.dll is still being distributed because is the less old ModuleManager that works everywhere (i.e., on every KSP version TweakScale supports). If I distribute the latest MM 4, I would break a few of TweakScale users, and if I do not distribute MM at all, some would complain because they are used to just unpack the zip into GameData and call it a day. Since multiple MMs when installed negotiate between themselves who will be in charge (i.e., the older ones shutdown and only the most updated do the work), it's safer for me to distribute 3.1.1 as anyone just unzipping everything on a more current GameData (with MM4) would not be breaking anything, where if I distribute the latest MM4 and the user is playing on 1.7 or even 1.4, it would break things. The 16 FATALities is due bad patching (and, shame on me, I was the toe stomper this time! Again, my apologies!). I fail to understand why B9PSW is complaining about 3.1.1, since MM4 overrules it - essentially, it's as MM3 is not there. However, the author must have a reason for that, and if you want to get support for B9PWS, you should do what he says - he would not accept support requests otherwise.
×
×
  • Create New...