Jump to content

Lisias

Members
  • Posts

    4,587
  • Joined

  • Last visited

Reputation

5,296 Excellent

Contact Methods

Profile Information

  • About me
    Boldly crashing what no Kerbal has crashed before!
  • Location
    Universe ! Virgo ! Milkway ! OrionArm ! SolarSystem ! Earth ! America ! SouthAmerica ! Brazil ! SãoPaulo ! Capital ! Home ! LivingRoom ! MyChair
  • Interests
    I felt a great disturbance in the Force, as if millions of lines of code cried out in Null Reference Exceptions and were suddenly flooding the KSP.log...

Recent Profile Visitors

15,500 profile views
  1. Use the cheats. Perhaps the indestructible one can help?
  2. It should not…. Please send me your KSP.log so I can check where the bork is happening. I'm surely misconfigured some KSPAddOn attribute! POST EDIT Don't bother, I found it already. I completely missed that! POST POST EDIT There was another issue hidden on the thing: when you click on the "Apply" from the Settings Menu, a function called "Commit" is called to, well.. , commit the changes on the running Module so you don't have to switch scenes to get the setting applied. But I forgot to check if the Module is meant to work on the current Scene on two use cases (I handled it correctly on a third, so I think I was interrupted by some R.L. issue and ending up thinking I had concluded the job after), so the after math was that VesselDraw was being activated no matter the current scene by that click. This may also explain the problem detected by @Krazy1 - if VesselDraw is already active when entering the Flight Scene, there's a very good chance that a unloaded vessel ends being the current vessel without VesselDraw getting the chance to check it - ending up with the MeshEngine trying to draw the meshes over an active one (a mishap that the original programmer surely ended up doing otherwise he wouldn't had wrote the code - and now I'm pretty glad he did!). Well, I'm finishing the tests and I think I will release the fix in the next couple hours. [ha… :P] POST POST POST EDIT This is extremely frustrating. The latest ReStock, somehow, added something to the mess that is fooling DOE to thing some parts that should not be rendered, are being rendered. [LOG 17:35:35.348] [DistantObject] WARNING: Failed to load model Squad/Parts/Utility/launchClamp1/model for part launchClamp1 from vessel Tower Of Doom! Vessel will not be rendered as expected! I will release what I have ready as it fixes some problems being reported, and I will let ReStock for another day - there's so much I can do at once on working days. I probably will add a new "Engine' just for stock, and I will deliver the DLL stand alone for beta-testers. It's not fair to non ReStock users delaying the development cycle due ReStock...
  3. Now I was caught with my pants down… There should be no binary interaction between the Scale and Recall assemblies…. Well, I will give this a try later, thanks for the heads up!
  4. You should had forgot to completely remove the TweakScale folder. I downgrade things here now and then just to see what happens, and no problems were detected - as long you completely get rid of all binaries before "downgrading" to the previous release. Keep in mind that 2.4.6.x is a deal breaker to some Companions (it's the reason I had to update some of them). In order to use TweakScale 2.4.5.0, you will need to downgrade also the Companions mentioned on the github's Release page. Breaking binary compatibility sucks, I know, but I had drawn myself to a corner with some APIs and had to do it sooner or later, and took the opportunity to do it now since some new APIs would need the Companions to be rewritten anyway, so we would endure two pains by the price of one. Exactly. Scaling Crew down works - since nobody is launching exceptions when this happens. Observe that the U,I. adapts itself normally with you scale down a 3 crewed part to 2 and then 1 crew. I fail to understand why this would be a problem for scaling up. The excuse of "people would find weird the IVA not following the new crew size" - as people would not be using borrowed IVAs from other parts and shoving more (or less) kerbals on it that the available seats. As I said, you can MM your way on it and KSP doesn't complains about the part having more crew on the prefab than IVA seats. Mangling the IVA seats was something that I had though, but since KSP resets everything to the prefab on launch, TweakScale needs to reapply the scaling on the first frames of life of the Craft - and by then, KSP already had thrown that Exception on me. The Solution for this would be writing a new PartModule with a new Crew support to avoid the KSP's ban (like KIS does with cargo). From there, I could do anything I want (including generating IVAs at runtime - a somewhat daunting endeavour ). But then we have R.L. kicking my balls and forcing me to compromise - there're more pressing things in need to be done ASAP (as you can see above).
  5. Yeah, unfortunately it's a known issue. It's two bugs bitting you in a row: the first (and most serious, as it affects everybody) is from KSP, that now and then screw up something on the UpgradePipeline (probably) and invert the Z Axis of the part (or at least, from the attach nodes). Sometimes the fairings get inverted, and you can't build the fairing towards the right end of the rocket due this. This I can't help, it's a long standing KSP problem that started to happen on 1.8.0 (I first noticed it on the control surfaces). The second bug is on TweakScale. In all these years since the first version, no one (including me) thought that someone would want to invert the part before scaling, and so the code was made assuming the part is always pointing towards the root. This is scheduled to be fixed for the next release, in which I (hope) to start to work on the middle on this next week. Until there, the only workaround is to detach the affect parts, invert it, and reattach them. This solves the problem for good on this craft - or at least, I still didn't got a report of the thing happening again on the same craft on the same savegame - the KSP bug triggers when loading crafts from another savegame I think (but I'm not 100% sure). Until this moment only ReStock parts are being reported - but I really doubt this is a ReStock problem. Once you fix the craft and save it, you can remove and reinstall ReStock that the bug doesn't triggers anymore. A more thoughtful discussion can be found on this post:
  6. Announce! TweakScale Companion for PKMC 2.1.0.1 is on the wild! Fix a bug on patch. Thanks to AccidentalDissassemly! Closes issues: #5 Missing curly braces in patch file Downloads here and in the OP.
  7. Not yet. Eventually I will deprecate for good the old patches on TS distribution, but this will not happen until I tackle down this dependency problem. As far as I know, the current patches for KAS are still acceptable, so is unlikely that I will rework them in the short run. But you can aways check the TweakScale Companion thread for news. Cheers!
  8. The main and most important reason for the recent update to the 2.4.6.x series is the KSPe.Light thingy. This guy has core services that will allow me to install Companions safely without the dependencies installed - a situation that if unhandled will end up with KSP not loading correctly due a bug on the stock AssemblyLoader. How it does it's subject for another (huge) post. (TweakScale being able to run from KSP 1.3.0 to 1.12.2 is a beneficial side effect of that core services - since they are there, I just used them on TS too!) The Companions, due its nature, have a problem called Triangular Dependencies (a "plague" that happens too on MM Patches, but MM doesn't crashes the game because of that!). Let's take , for example, the TSCo-KIS you just installed: it :NEEDS both Scale and KIS Assemblies to be installed, otherwise its loading will raise a Reflection Exception like this one: [LOG 00:58:11.276] PartLoader: Compiling Part 'B9_Aerospace/Parts/Body_Mk2_Cockpit/body_mk2_cockpit_a/B9_Body_Mk2_Cockpit' [ERR 00:58:11.294] MechJeb caught exception in core OnLoad: System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown. at KSP.IO.File.Exists[T] (System.String filename, Vessel flight) [0x00053] in <9d71e4043e394d78a6cf9193ad011698>:0 at MuMech.MechJebCore.OnLoad (ConfigNode sfsNode) [0x00097] in <2e230d4e49354a07858a9faa52799159>:0 When this happens, something inside KSP gets broken and lots of things start to fail without reason. On the KSP.log I took this example, the following borkage was the consequence : [EXC 01:00:19.076] ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown. System.Reflection.Assembly.GetTypes () (at <ad04dee02e7e4a85a1299c7ee81c79f6>:0) AssemblyLoader.GetTypesOfClassesImplementingInterface[T] () (at <9d71e4043e394d78a6cf9193ad011698>:0) Expansions.Missions.MissionsUtils.InitialiseAdjusterTypes () (at <9d71e4043e394d78a6cf9193ad011698>:0) Expansions.ExpansionsLoader+<LoadExpansions>d__21.MoveNext () (at <9d71e4043e394d78a6cf9193ad011698>:0) UnityEngine.SetupCoroutine.InvokeMoveNext (System.Collections.IEnumerator enumerator, System.IntPtr returnValueAddress) (at <5aeafee3fea24f37abd1315553f2cfa6>:0) CKAN doesn't understand Triangular Dependencies neither - I can't say to CKAN "If TweakScale is installed and KIS is installed too, you need to install TSCo-KIS" . All I can do is to suggest and/or recommend all the Companions on the TweakScale netkan file, what will probably prompt the user to install them anyway - and if by bad luck the user installs the TSCo-FS one by mistake, we will have a crashed KSP on the next boot because the TSCo-FS will fail to be loaded because Firespitter is not installed - and then that nasty bug on the stock KSP AssemblyLoader will screw up the internal game state, and lots of things will not work correctly after the borkage. The example above is just one of the possible consequences, I have tons of these issues on my database. So, in order to overcome this royal borkage from KSP since 1.8.0, I needed to reenginer the Companions to do selective DLL loading: the DLLs that are loaded by KSP are "safe", without hard dependencies. They then check if the needed Assemblies are loaded by KSP, and only then they load the DLLs with hard dependencies - avoiding the whole mess. If any of the dependencies are not met, the plugin just shuts itself down. Not even the patches are applied, as the tag needed on their :NEEDS are generated by that very same code that only does it after checking the dependencies. So, now and just now, it's safe to start to distribute the Companions using Curseforge and CKAN. The final step for a complete solution is a WatchDog for the Companions that will monitor the add'ons installed and then prompt the user to install the respective Companion if needed. It's not as nice as being able to tell CKAN to do it automatically, but at least it's better than what happened to you now! Cheers!
  9. UGH!!! That passed trough!! I'm so used to run TweakScale beta that I just filter out the problem from my sigh!! Fixing this right now. — — — Annouce TweakScale 2.4.6.1 in on the wild, with the fix for the bork mentioned above. All Distribution Channels were updated at once. Cheers!
  10. Ugh… I did a major bork once by uploading the wrong zip file on Spacedock what could explain your problem - but I just checked the file on SpaceDock and it's the correct one. However… The netkan guy's changes on the netkan file exactly due that screw up of mine may be the answer for your problem, if by some reason the netkan client failed to checkout the updated file - what's a bit odd, since the borkage happened last June 27 - many weeks ago. You will need to reach the CKAN guys to sort this out for sure, however. Send me your KSP.log (and since things just freezes on you, the Player.log will also help). The instructions about how to get these ones are on the OP, under a Spoiler on the final. There're many reasons for TweakScale shoving a Houston on our noses, I need these files to checkout what one bite you. Cheers!
  11. From all the possible problems TS 2.4.6.0 would cause, this is the most unexpected one. The difference from TS 2.4.6.0 from the previous are only are essentially the DLL loading mechanisms, and these ones are being tested for the best part of this year. What you are getting now should be happening on TS 2.4.5.x… KSP, sometimes, surprises me in the most obscure ways… Did you installed/updated the TweakScale Companion for KIS? The KSP.log would help me to diagnose the problem - I had not problems like this one while testing the latest release of TSCo-KIS and the TS 2.4.6.0 (when in RC), but something always can pass through...
  12. METAR There's a new old Kraken Food pesking TweakScale these days - but, granted, it's exarcebated by a bug on TweakScale itself. That's the history: at least on a situation that appears to involve ReStock (but it's not ReStock fault! It's only the trigger), sometimes when loading craft files from another savegame some parts ends up with the Z coordinate inverted (i.e., the part with the bottom "down" on the source savegame ends up with the bottom "up"), and this is a situation badly handled by TweakScale: On this sample craft, you will note that the fairing is Z axis inverted (node how the building goes downwards). The fuel tanks under it are also Z ais inverted, and it's the reason you see some texture fight where one tank attaches to the other (meaning that they were misplaced, and this is where TweakScale borks too). It's also the reason the Lander got pushed above the Monopropellant tank (that was also Z axis inverted, triggering the bug that pushed the Lander above it). Making things yet more interesting, the tank's texture is on the right position. What's messed up are the attachment points - and I confirmed this by detaching the tanks and reattaching them upside down - a situation where "normal" tanks would bork the scaling (due a bug on TS, just to make it clear), but on this craft it ended up working (due the swapped attachment points, apparently). Once I invert the misplaced parts (or delete them and get new ones from the Palette), the problem vanish for good. It didn't came back once I saved the craft on a new file, even by removing and adding back ReStock on the installment. And this is the reason I'm sure ReStock is not the troublemaker, but was merely involved on the fürball. Neither installments (mine and the source of the craft) had Harmony, by the way. So this is happening on a "vanilla" Stock binaries. I'm inclined to accuse the UpgradePipeline, as this one was known for screwing up the Z-Axis of Control Surfaces when KSP 1.8.x came to light - and since Control Surfaces are surface mounted parts, the attachment point bug of TweakScale doesn't kicks in, the only annoyance is having to invert the control of the part all the time once you launch it. In a way or another, I'm reporting this so people are aware of the situation - even by fixing TweakScale, the attachment points will still be inverted and this may screw up others add'ons too. Additionally, this TS bug is present on every previous version of TweakScale (including the ones from the 1.3.x era), so there's no reason to postpone the SpaceDock update as I was doing while I was not sure about the real reason of this major group borkage. So I'm updating SpaceDock this night for the latest TweakScale. As the result of this borkage, I'm rescheduling the RoadMap to tackled down this attachment related bugs for the next Release (to be issued Soon™) Cheers!
  13. If this is what I think it is, it's not only Trajectories. These Reflection Exceptions royally screw up TweakScale too - it's a bug on KSP itself, I think (but it still can be something on Unity - in a way or another, I never got this on plain Mono/DotNet). There's no other way out but to have Zero Tolerance® with Reflaction Exceptions - fit the faulty DLL or ditch it.
  14. In time… I just love the way your cars put the road on fire!!!
  15. And by doing that, they had locked themselves on a corner - they are alone now. You are the first and ultimate responsible for the consequences of the license you choose. If the license you choose allows people to do things you don't want, don't use the license - and that's all. Going ARR will not solve the problem. Once you go ARR, you are the only one responsible for checking for compliance and pursing remedies - no one will help you, unless you pay some money. Once you go for a Open Source license, you will get help: lots and lots of people on this industry relies on Open Source Licenses, and it's their best interest to keep the status quo safe. That said, going ARR is not necessarily wrong - it's a valid option, as long you know the consequences and are willing to cope with it. And to check The Pirate Bay frequently. Not to mention that some Open Source licenses even explicitly forbid you from taking any kind of action that would prevent anyone to make such forks - and, so is the life, if an user came to you asking for support on things made by other people, it's up to you to educate the guy. My suggestion, not only to protect your sanity but to value your own work, is to ask the guy to seek support from the source where he/she get the thing. This is the Right Thing™ to be done - people want your support, they should use your artefacts. You start supporting 3rd parties, you end up with your own works left behind. In the bottom line, users do what users do, we have to live with it - it's just part of the zeitgeist. Not necessarily. Sometimes is due local legislations. On this case, katateochi lives on a different country with very different culture and laws, and since he maintains (including with $$$$) the site he also have some responsibilities under his legislation. I surely have some under my own legislation (not only on my site, but also on the code I publish with my real name - and yes, I use my real name exactly due that). There's also the trademarks issues, had he registered the trademark, they bought to himself some duties that may be easier to cope under an ARR license. Time is a scarce resource, most people need to make compromises about where to spend it. Time is the coin of your life. It is the only coin you have, and only you can determine how it will be spent. Be careful lest you let other people spend it for you. Carl Sandburg
×
×
  • Create New...