Lisias Posted March 23, 2022 Author Share Posted March 23, 2022 (edited) ANNOUNCE Release 2.4.6.9 2.4.6.10 * is available for downloading, with the following changes: Removes an (now) unnecessary gambiarra, as KSP-Recall is now fixing the mess on KSP >= 1.9 editor. A small (and 3rd party safe) fraction of it remains to cover what may be a missing use-case on KSP-Recall, or a fishy code on TweakScale itself. Implements a new Sanity Check against a worrisome situation where a Part is given to TweakScale without the partInfo!!! I don’t have the slightest idea about how in hell this can happen, but I got confirmation of this problem from reliable sources. Finally implementing a full-fledged TweakScale Upgrade Pipeline, allowing run-time, on-the-fly conversions between ScaleTypes and DefaultScales. No more worries about installing or updating Add'Ons that changes the TweakScale patches. All Tweak!!! users, this one is dedicated to you! Closes Issues: #237 New Sanity Check: parts without partInfo!!! #236 Extent the Scale migration feature to allow switching ScaleTypes and DefaultScales! #218 Implement GetInfo on TweakScale’s Part Module See OP for the links. Notes I finally implemented a proper "TweakScale Upgrade Pipeline" for TweakScale patches. This means that your savegames and craft files will not be screwed anymore if: You install All Tweak!! and later install a TweakScale Companion. You install something that changes any pre-existing TweakScale Support. This was the main block for the TweakScale Companion Program: I had noticed that some add'on Authors decided to second guess my patches on the Companions as soon as I publish a beta, and since they published them on SpaceDock and CKAN before my patches going gold, I had to consider them as pre-existent patches when publishing the better crafted, better curated and better implemented patches on the Companions (hey, I AM the TweakScale guy, I know how to write patches properly, how do properly write Scale Types and even new Standard Scalings matching the parts at hand!). Now this problem is not more. All Tweak!!! users, in special, are in a way better position than before - now you don't have to fear updates and new add'ons installing different scales for your flying parts! However… Only the scalings are converted. I can't "fix" changes on Behaviours and PartModule's support: if an older part doesn't scale some attribute (or scale it with a different exponent), then the new patches will scale the part differently, and you will have crafts behaving differently from what you designed. By example, if you build an airplane using a patch that scales mass with a 2.5 exponent, and then install a new patch set that scales mass at 3.0 exponent, them your airplane will end up unbalanced. "You can't have the cake and eat it too…" But at least your craft files will be editable. Additionally, I'm starting to remove from TweakScale some "gambiarras" and shenanigans meant to cope with previous KSP's idiosyncrasies. KSP-Recall will, from now on, be the sole responsible for handling these unfortunate "features" introduced on previous KSP versions and, sadly, never fixed. The reason for this is that I recently realised that by brute-forcing my way on TweakScale, I could be screwing up any hypothetical Add'On that would be processed after TweakScale (KSP appears to process things in the order they are found on the part's config section) the same way Editor 1.9 started to screw with TweakScale, and I found this unacceptable. Fixing things for yourself while pushing your weight on everybody else is not being a Team Player, and a Community is (or should be) about Team Players. I help you, you help me, and so we help others. Some mishaps happened in the mean time, and I apologise for them - but in the process I found some borderline situations where that TweakScale's gambiarra could not even touch. The after math is a way more behaving KSP game from now on. And I pushed forward a nice feature that will help users to check if a part have TweakScale support, and the supported sizes. Disclaimer By last, but not the least... Spoiler I have this bitter and sad need to explain some unfortunate events, in the hope we finally manage to stop some slandering. I'm really saddened to have to disclose this, but pretending this was not happened didn't helped in the past. So… TweakScale (and KSP-Recal) were, recently, being targeted by slandering. Again. I don't have the slightest idea how in hell someone can openly and bluntly make easily refutable affirmations about how TweakScale or myself behaves. I don't have the slightest idea why, by Kraken's sake, some very influential and important members of this Community allow themselves to be pushed on such egregious behaviour. But yet, it was what happened. So, for the sake of clarity and Trueness: Neither KSP-Recall neither TweakScale have any hard requirement for any specific version of Module Manager other than the Forum's one, (normally) available here on Forum. I have a personal fork of MM, MM/L, that I use for development and personal use. It's faster, it's way better on log management and it works on every KSP version since KSP 1.3.0 flawlessly, so I don't have to rely on buggy, older MM versions for playing my KSP of choice. HELL. I have a KSP 1.2.2 binary for it too. And it behaves 100% like the Forum's one. Not a single patch is different, not a single MM functional feature is missing (au contraire, the /L fork is more compatible with classical MM than current MM itself!). And you DO NOT need it. You can keep your playing using Forum's MM. And this will not change. Every time the Forum's MM was unreachable by a reason or another, I always pinpointed the Forum's one on my personal repository - had the MM author published MM on github as a backup plan for when his site is unreachable, most people would not even be aware of my fork. The latest MM/L release have about 300 downloads on github, while the previous TweakScale release has about 30K downloads on SpaceDock and 40K on CurseForge. How in hell someone concludes that something those previous release have 70K downloads have a hard dependency on something else with only 300 it's absolutely beyound my comprehension. I will save you from pinpointing the posts where this slandering happened, and I will not speculate about the motivations. — — — — — * Release 2.4.6.9 was ditched due a major bork on the distribution file. My apologies. — — — — — 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 (and CKAN users). Right now. The reasoning is to gradually distribute a potentially Support Fest release in a way that would me allow to provide proper support if anything else goes wrong. Edited March 26, 2022 by Lisias All your Distribution Channels are belong to us! :) Quote Link to comment Share on other sites More sharing options...
Supersonic Rocketship Posted March 23, 2022 Share Posted March 23, 2022 This happened when I was booting the game: A warning pops up that says "Unfortunately TweakScale didn't found needed DLLs". Another warning says Mod(s) DLL that are not compatible with this version of KSP KSP log file: https://drive.google.com/file/d/1QVaBNiQdW-SB-_hU-DLNNgtHkcK8Gu4F/view?usp=sharing Quote Link to comment Share on other sites More sharing options...
Lisias Posted March 23, 2022 Author Share Posted March 23, 2022 (edited) 3 hours ago, Supersonic Rocketship said: This happened when I was booting the game: A warning pops up that says "Unfortunately TweakScale didn't found needed DLLs". This first Warning is from TweakScale, but 99% of the time it's not a problem on TweakScale - what's happening is that KSP has a nasty bug on a thingy called Assembly Resolver. When a DLL fails to be loaded due a missing or corrupted dependency, something inside the Resolver get broken, and from that point, everybody else that tries to use it borks too. It's important to mention that TweakScale is only the one yelling about the problem - every other DLL failing to be loaded will badly impact your savegame somehow, and this include TweakScale's DLLs. Without them, TweakScale (as well a lot of other add'ons) doesn't works and if TweakScale doesn't works, your flying crafts will be descaled with nasty (and unrecoverable) consequences - being the reason I choose to do not bury my head on the sand about the problem. Usually (but I'm suspecting that this is not the only situation…) the first DLL to get a "System.Reflection.ReflectionTypeLoadException" is the trigger for the problem, and from that point everybody else is being killed by the Assembly Resolver bug. I will dig on this below. 3 hours ago, Supersonic Rocketship said: Another warning says Mod(s) DLL that are not compatible with this version of KSP This message is completely bogus, it is an unfortunate short sighted measure from MM. You should bluntly ignore this message, it really means nothing. About your problem: I think that the root cause of this is Texture Unlimited. It's him the first Reflection error on your KSP log: Spoiler [ERR 00:38:22.474] ADDON BINDER: Cannot resolve assembly: TexturesUnlimited, Culture=neutral, PublicKeyToken=null [ERR 00:38:22.474] ADDON BINDER: Cannot resolve assembly: TexturesUnlimited, Culture=neutral, PublicKeyToken=null [ERR 00:38:22.476] AssemblyLoader: Exception loading 'SSTUTools': System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown. at (wrapper managed-to-native) System.Reflection.Assembly.GetTypes(System.Reflection.Assembly,bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 at AssemblyLoader.LoadAssemblies () [0x000e6] in <c1858a3f77504bd1aaa946fdccf84670>:0 Additional information about this exception: System.IO.FileNotFoundException: Could not load file or assembly 'TexturesUnlimited, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: 'TexturesUnlimited, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' <a lot of repetitions of the last message> However, something is different on your KSP.log - usually there's only one "copy" off the System.IO.FileNotFoundException on the log, but yours have a lot of them. I don't know if this is relevant, however, it may not affect the diagnosis (or the problem)- but it worths to mention for future reference that your rig has Harmony and KSPBurst installed (I had minor issues with KSPBurst in the past, but nothing even remotely related to something like this problem). Checking your "Folders and files in GameData:" section on the log I didn't found Textures Unlimited, so besides the oddities on your log, I'm reasonably confident that your problem will be fixed by installing it. If you use CKAN, I suggest to reach SSTUTools's maintainer and suggest him to add Textures Unlimited as a dependency. Cheers! Edited March 23, 2022 by Lisias Some entertaining grammars made less entertaining. Quote Link to comment Share on other sites More sharing options...
Dioso Posted March 27, 2022 Share Posted March 27, 2022 hello do u have any idea how to pull back a gui i accidentally placed my bda gui under the screen please help me Quote Link to comment Share on other sites More sharing options...
Lisias Posted March 27, 2022 Author Share Posted March 27, 2022 (edited) 1 hour ago, Dioso said: hello do u have any idea how to pull back a gui i accidentally placed my bda gui under the screen please help me Not sure about what you mean… If you had clicked accidentally on the TweakScale button: All you need to do to get rid of it is to click on the TweakScale button again (emphasised em white above). I don't know about the BDa's GUI however (it's a long time since the last time I played with it, forgot a lot of things already!). — — POST EDIT — — On the other hand, you just reminded me that if the user change the screen resolution, or accidentally move the Window to outside the visible area, this screen would be unaccessible… So… https://github.com/net-lisias-ksp/TweakScale/issues/239 Edited March 27, 2022 by Lisias post edit Quote Link to comment Share on other sites More sharing options...
Dioso Posted March 27, 2022 Share Posted March 27, 2022 so basically i was just playing when i clicked the bda gui then it went to the bottom left screen i couldnt find the Gui anymore Quote Link to comment Share on other sites More sharing options...
Lisias Posted March 27, 2022 Author Share Posted March 27, 2022 (edited) 41 minutes ago, Dioso said: so basically i was just playing when i clicked the bda gui then it went to the bottom left screen i couldnt find the Gui anymore Oh, this! Well, it's long since the last time I fired up a KSP with BDArmory (it was on the KSP 1.4.3 times!! ). I still have that installment lingering around, and at least at that time, the Windows' positions could be mangled by editing the file <KSP_root>KSP/Exodus/GameData/BDArmory/settings.cfg as follows: Edit this file with notepad and set the X and Y thingies to 0.00. By example: from: WindowRectToolbar = (x:940.00, y:150.00, width:300.00, height:65.00) to: WindowRectToolbar = (x:0.00, y:0.00, width:300.00, height:65.00) Please note: DO NOT remove/switch/mess with parenthesis, commas or collons. I don't know if BDArmory will recover from the error, or just crash while trying to read it DO NOT touch the width and height of the thing unless you had learnt your way on the arcane practices of pixel art. Bluntly removing the settings.cfg will also work, but you will lose any settings you had changed (everything will be set to default, IIRC). I don't remember if you will need to restart KSP to BDArmory recognise the changes - it's possible that it would rewrite it with the (wrong) memory values, so it could be a good idea to exit KSP before editing the file. — — — In time, if by any reason you think TweakScale is misbehaving due some TS's setting, you can bluntly delete the file <KSP_root>/GameData/TweakScale/Plugins/PluginData/Scale/config.xml. The settings is reloaded (or a new file with defaults created) every time you enter the Editor (VAB or SPH). — — — In time, who is maintaining BDArmory nowadays? I think this should be published on the current Maintainer's thread or even on a Wiki, it will be surely useful for more BDArmory users! — Cheers! Edited March 27, 2022 by Lisias Hit 'save" too soon. Quote Link to comment Share on other sites More sharing options...
TheLoneOne Posted March 27, 2022 Share Posted March 27, 2022 hello I'm having an issue with this mod. it works perfectly, how do I fix this problem? Quote Link to comment Share on other sites More sharing options...
GDJ Posted March 27, 2022 Share Posted March 27, 2022 16 minutes ago, TheLoneOne said: hello I'm having an issue with this mod. it works perfectly, how do I fix this problem? Quote Link to comment Share on other sites More sharing options...
Lisias Posted March 27, 2022 Author Share Posted March 27, 2022 5 hours ago, TheLoneOne said: hello I'm having an issue with this mod. it works perfectly, how do I fix this problem? Give me some time, I'm surely will be able to correct this soon!! Quote Link to comment Share on other sites More sharing options...
zer0Kerbal Posted March 27, 2022 Share Posted March 27, 2022 6 hours ago, TheLoneOne said: hello I'm having an issue with this mod. it works perfectly, how do I fix this problem? 48 minutes ago, Lisias said: Give me some time, I'm surely will be able to correct this soon!! @TheLoneOne, @Lisias Spoiler Quote Link to comment Share on other sites More sharing options...
TheLoneOne Posted March 27, 2022 Share Posted March 27, 2022 56 minutes ago, Lisias said: Give me some time, I'm surely will be able to correct this soon!! do it in the next 5 hours or your fired! >:( Quote Link to comment Share on other sites More sharing options...
Galland1998 Posted March 28, 2022 Share Posted March 28, 2022 I am running into a strange problem with Tweakscale. I am not sure if it is a tweakscale issue or an interaction with procedural parts. I am running a 1.12.3 RO/RP-1 install and this issue only presents itself when Tweakscale is added to the install. If a procedural part is the initial root part added to a craft then the attach nodes are offset from the part. If you add another of the same procedural part than the attach nods are in the proper place. If you make the second procedural part the root part and delete the original procedural part the attach nodes stay where they are supposed to be. In the second case if the initial root part placed in the VAB is not a procedural part all of the nodes are where they are supposed to be and if you add a procedural part then the added procedural part has its nodes exactly where they are supposed to be. RO/RP-1 messes with the base part scales compared to stock KSP so I am not sure if that has something to do with it. It is just strange that it only seems to impact an initial root part from the procedural parts mod. Quote Link to comment Share on other sites More sharing options...
Lisias Posted March 29, 2022 Author Share Posted March 29, 2022 15 hours ago, Galland1998 said: I am running into a strange problem with Tweakscale. I am not sure if it is a tweakscale issue or an interaction with procedural parts. I am running a 1.12.3 RO/RP-1 install and this issue only presents itself when Tweakscale is added to the install. If a procedural part is the initial root part added to a craft then the attach nodes are offset from the part. If you add another of the same procedural part than the attach nods are in the proper place. If you make the second procedural part the root part and delete the original procedural part the attach nodes stay where they are supposed to be. In the second case if the initial root part placed in the VAB is not a procedural part all of the nodes are where they are supposed to be and if you add a procedural part then the added procedural part has its nodes exactly where they are supposed to be. RO/RP-1 messes with the base part scales compared to stock KSP so I am not sure if that has something to do with it. It is just strange that it only seems to impact an initial root part from the procedural parts mod. Hi. As a matter of fact, I also detected a strange misbehaviour similar to this one when scaling up and down the T-12 (and similar) parts from Making History. At least for the T-12 et all, the problem is, again, something on Editor - by saving and loading the craft, the attachment nodes are "restored" to the proper places and sizes (the sizes gets screwed too on my problem). Perhaps this can help you in the mean time? I'm mostly convinced that this is something to be tackled down on KSP-Recall, since (if I'm right) by doing that everybody will be fixed (and not only TweakScale). I will give a peek on this problem to see if it's related to something already known, or if it's a new use-case for KSP-Recall. Just to be sure about the code to be tested: you are using this one, right? https://github.com/KSP-RO/ProceduralParts/releases Cheers! Quote Link to comment Share on other sites More sharing options...
Galland1998 Posted March 29, 2022 Share Posted March 29, 2022 I'm using procedural parts v2.3.0 via CKAN as part of the quick RP-1 Install. That goes along with ROv14.11.0.0 and RP-1v 1.11.7. I was using Recall v0.2.2.3 and Tweakscale 2.4.6.9. I used the v2.4.6.9 rather than the 2.4.6.10 version because the bugs were much worse than just a displaced attachment node on a root part with procedural parts. You can work around the displaced attachment node by adding another part, changing the root part and the deleting the original part. With v2.4.6.10 I was running into issues with attachment nodes would disappear after a part was attached and then removed and then that would escalate to parts only being radially attached and then not attached at all. It would then escalate to the point where I couldn't exit the VAB and would have to force a shutdown of KSP just to get back into the game. I didn't do extensive testing of the v2.6.4.9 interactions beyond what I described above. Quote Link to comment Share on other sites More sharing options...
Lisias Posted March 30, 2022 Author Share Posted March 30, 2022 (edited) 12 hours ago, Galland1998 said: I'm using procedural parts v2.3.0 via CKAN as part of the quick RP-1 Install. That goes along with ROv14.11.0.0 and RP-1v 1.11.7. I was using Recall v0.2.2.3 and Tweakscale 2.4.6.9. Did you mean 2.4.6.8 ? The 2.4.6.9 was a major blunder of mine (I really screwed the pooch on this one), it was withdrawn from every distribution channel (besides still being available for the masochistic Kerbonaut on github and probably Web Archive…). Please, please, get rid of that crap. Use 2.4.6.8 or 2.4.6.10, but do not waste your time on 2.4.6.9 12 hours ago, Galland1998 said: You can work around the displaced attachment node by adding another part, changing the root part and the deleting the original part. This is so 1.9.x Editor… Really. I made a quick test run on KSP 1.8.1 using Procedural Parts 2.3 (the one I think you are using, I checked the CKAN-Meta and this is the only one on a 2.3.0 release). I opened a Support Ticket https://github.com/net-lisias-ksp/TweakScale/issues/240 to register the research. On 3/28/2022 at 11:41 AM, Galland1998 said: In the second case if the initial root part placed in the VAB is not a procedural part all of the nodes are where they are supposed to be and if you add a procedural part then the added procedural part has its nodes exactly where they are supposed to be. If it's the problem I think it is, you have problems when the root part has not a variant, while using a part with variant works. This is essentially the problem with the Editor (VAB/SPH) on KSP >= 1.9.0 (and the reason I think they started to force their weight on us about the attachment nodes, that are reset to prefab every time you load the craft). Anyway, this is a screenshot of a test craft on KSP 1.8.1, before KSP's Editor got screwed: And it works, the attachment node are on the right place - including the surface attachments (that are also screed on 1.9.x). Every single non PP part (except the root, a Nose Code) was scaled with TweakScale. Now, I imported the testbed into KSP 1.9.1, and got the following result: 12 hours ago, Galland1998 said: With v2.4.6.10 I was running into issues with attachment nodes would disappear after a part was attached and then removed and then that would escalate to parts only being radially attached and then not attached at all. It would then escalate to the point where I couldn't exit the VAB and would have to force a shutdown of KSP just to get back into the game. I didn't do extensive testing of the v2.6.4.9 interactions beyond what I described above. This sounds more like 2.4.6.9 (yeah, I really screwed up on this one). Really, get rid of that crap - check your instalments carefully to remove every single copy of 2.4.6.9 and reinstall from scratch the 2.4.6.8 or the 2.4.6.10, but do not use .9. — — — PRELIMINARY TEST RESULTS — — — Everything works fine on a minimal test bed using TweakScale 2.4.6.10, KSP-Recall 0.2.2.3 and Procedural Parts 2.3.0 . I found no evidences of misplaced attachment nodes, being them stack or surface ones. The last screenshot above depicts a test made trying to trigger known misbehaviours (that are fixed by KSP-Recall). AttachedOnEditor, the workaround module that handle this case, is installed on the procedural part as expected. So, right now, I have the following hypothesis to explain your report: TweakScale 2.4.6.9 screwed up your craft file. It can be a problem while saving a craft file, but the existing ones are safe. Recreate the craft using TS 2.4.6.8 or 2.4.6.10 and see what happens Something are preventing KSP-Recall from patching Procedural Parts with AttachedOnEditor. Please send me the affected craft so I can inspect it. You can compress it and attach it on a post on this issue: https://github.com/net-lisias-ksp/TweakScale/issues/240 Some code are relying on TweakScale's kludge that was removed on 2.4.6.10 (as this was preventing KSP-Recall from tackling down some more borderline use cases) Unlikely, because KSP-Recall do the same trick, but properly this time (it does it on a way that it's guaranteed to emulate the proper Editor behaviour for everybody, TweakScale was doing it only for itself, and this theoretically would cause inconsistencies on the Part Module). Send me (see the previous item) your affected savegame (the whole thing) on a zip file a CKAN export file the whole <KSP_root>/KSP.log, and <KSP_root>/GameData/ModuleManager.cache and the <KSP_root>/Logs/ModuleManager/* ones too. Zip everything into a file and send it to me (se the previous item). Cheers! Edited March 30, 2022 by Lisias tyops! Who would thought of that? :P Quote Link to comment Share on other sites More sharing options...
Supersonic Rocketship Posted April 2, 2022 Share Posted April 2, 2022 On 3/23/2022 at 3:45 AM, Lisias said: This first Warning is from TweakScale, but 99% of the time it's not a problem on TweakScale - what's happening is that KSP has a nasty bug on a thingy called Assembly Resolver. When a DLL fails to be loaded due a missing or corrupted dependency, something inside the Resolver get broken, and from that point, everybody else that tries to use it borks too. It's important to mention that TweakScale is only the one yelling about the problem - every other DLL failing to be loaded will badly impact your savegame somehow, and this include TweakScale's DLLs. Without them, TweakScale (as well a lot of other add'ons) doesn't works and if TweakScale doesn't works, your flying crafts will be descaled with nasty (and unrecoverable) consequences - being the reason I choose to do not bury my head on the sand about the problem. Usually (but I'm suspecting that this is not the only situation…) the first DLL to get a "System.Reflection.ReflectionTypeLoadException" is the trigger for the problem, and from that point everybody else is being killed by the Assembly Resolver bug. I will dig on this below. This message is completely bogus, it is an unfortunate short sighted measure from MM. You should bluntly ignore this message, it really means nothing. About your problem: I think that the root cause of this is Texture Unlimited. It's him the first Reflection error on your KSP log: Reveal hidden contents [ERR 00:38:22.474] ADDON BINDER: Cannot resolve assembly: TexturesUnlimited, Culture=neutral, PublicKeyToken=null [ERR 00:38:22.474] ADDON BINDER: Cannot resolve assembly: TexturesUnlimited, Culture=neutral, PublicKeyToken=null [ERR 00:38:22.476] AssemblyLoader: Exception loading 'SSTUTools': System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown. at (wrapper managed-to-native) System.Reflection.Assembly.GetTypes(System.Reflection.Assembly,bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 at AssemblyLoader.LoadAssemblies () [0x000e6] in <c1858a3f77504bd1aaa946fdccf84670>:0 Additional information about this exception: System.IO.FileNotFoundException: Could not load file or assembly 'TexturesUnlimited, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: 'TexturesUnlimited, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' <a lot of repetitions of the last message> However, something is different on your KSP.log - usually there's only one "copy" off the System.IO.FileNotFoundException on the log, but yours have a lot of them. I don't know if this is relevant, however, it may not affect the diagnosis (or the problem)- but it worths to mention for future reference that your rig has Harmony and KSPBurst installed (I had minor issues with KSPBurst in the past, but nothing even remotely related to something like this problem). Checking your "Folders and files in GameData:" section on the log I didn't found Textures Unlimited, so besides the oddities on your log, I'm reasonably confident that your problem will be fixed by installing it. If you use CKAN, I suggest to reach SSTUTools's maintainer and suggest him to add Textures Unlimited as a dependency. Cheers! Thank you so much for replying Lisias! You're really the best Quote Link to comment Share on other sites More sharing options...
Kor Posted April 3, 2022 Share Posted April 3, 2022 I'm playing 1.12.3 with JNSQ and Tweakscale but otherwise a pretty minimally modded setup. I'm running into a problem with stackable cargo parts (struts, fuel ducts, small solar panels, etc.) - If such a part is launched in a cargo container, it remains stackable until placed "in the world." Then it is no longer stackable. - If such a part is launched as part of a craft, it immediately becomes non-stackable. This seems to coincide exactly with when these parts gain a "Refunding" section in their right-click info window. Any ideas? Thanks! Quote Link to comment Share on other sites More sharing options...
Lisias Posted April 3, 2022 Author Share Posted April 3, 2022 (edited) 8 hours ago, Kor said: I'm playing 1.12.3 with JNSQ and Tweakscale but otherwise a pretty minimally modded setup. I'm running into a problem with stackable cargo parts (struts, fuel ducts, small solar panels, etc.) - If such a part is launched in a cargo container, it remains stackable until placed "in the world." Then it is no longer stackable. - If such a part is launched as part of a craft, it immediately becomes non-stackable. This seems to coincide exactly with when these parts gain a "Refunding" section in their right-click info window. Any ideas? Thanks! I will further investigate this, but I will need your KSP.log (as usual) just to check for any anomalies (just in case). This appears to be something to be tackled by KSP-Recall, by the way. — — POST EDIT — — It appears to be a new old problem on KSP 1.12.x series (pending check on older ones). Neither TweakScale neither KSP-Recall mangles (i.e., edit, copy or removes) the Stackable properties of the parts (except on Scaling, of course, if a proper Exponent is provided). So (obviously pending further analysis), it appears to me that KSP is "forgetting" to copy the Stackable attributes into the new part instance. I think it's reasonable that KSP is also forgetting to do the same when destroying the instance to be stored in a cargo bay too. (Boy, I'm missing KIS ….) — — POST POST EDIT — — I moved the discussion to KSP-Recall thread. Edited April 4, 2022 by Lisias post post edit Quote Link to comment Share on other sites More sharing options...
Kor Posted April 3, 2022 Share Posted April 3, 2022 17 minutes ago, Lisias said: I will further investigate this, but I will need your KSP.log (as usual) just to check for any anomalies. This appears to be something to be tackled by KSP-Recall, by the way. Great, thanks! Log file: https://www.dropbox.com/s/bs49lqfbc8xb0lh/KSP.log?dl=0 Quote Link to comment Share on other sites More sharing options...
nerdhut Posted April 3, 2022 Share Posted April 3, 2022 I'm having a problem with the mod. I am running 1.12.3 and have installed it manually using the installation instructions. In the VAB, the option is available for me to change the scale on tweakable parts, and I am able to cycle through the various scale percentages, but the size of the part doesn't actually change. My log file is here. Any help or ideas is appreciated! Quote Link to comment Share on other sites More sharing options...
Lisias Posted April 4, 2022 Author Share Posted April 4, 2022 (edited) 2 hours ago, nerdhut said: I'm having a problem with the mod. I am running 1.12.3 and have installed it manually using the installation instructions. In the VAB, the option is available for me to change the scale on tweakable parts, and I am able to cycle through the various scale percentages, but the size of the part doesn't actually change. My log file is here. Any help or ideas is appreciated! You have two problems: 1) MiniAVC. I suggest you install ZeroMiniAVC on your rig. [LOG 15:37:17.950] MiniAVC -> Executing: MiniAVC - 1.0.3.2 [LOG 15:37:17.950] MiniAVC -> Assembly: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\InterstellarFuelSwitch\Plugins\MiniAV [LOG 15:37:17.950] MiniAVC -> Starter was created. [LOG 15:37:17.950] MiniAVC -> System.IO.IOException: Sharing violation on path C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameDat at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share, System.Int32 buffer at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode) [0x00000] in <9577ac7a62ef43179789031239ba8798>:0 at (wrapper remoting-invoke-with-check) System.IO.FileStream..ctor(string,System.IO.FileMode) at MiniAVC.AddonSettings.Load (System.String rootPath) [0x0001b] in <32daf95419734fac8d1e416d1f8be6d5>:0 at MiniAVC.AddonLibrary.ProcessAddonPopulation (System.Object state) [0x0006c] in <32daf95419734fac8d1e416d1f8be6d5>:0 2) You are using a pretty old version of Firespitter! (v7.3.6354.39102) [ERR 17:30:56.714] [AssemblyLoader] Exception when getting assembly attributes: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown. Additional information about this exception: System.TypeLoadException: Could not load type of field 'Firespitter.FSparticleFX:pEmitter' (4) due to: Could not resolve type with token 0100005a (from typeref, class/assembly UnityEngine.ParticleEmitter, UnityEngine, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null) assembly:UnityEngine, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null type:UnityEngine.ParticleEmitter member:(null) signature:<none> System.TypeLoadException: Invalid type Firespitter.FSparticleFX for instance field Firespitter.engine.FSgroundParticles:particleFX System.TypeLoadException: Invalid type Firespitter.FSparticleFX[] for instance field Firespitter.engine.FSvelocityController:particleFX When these kind of problems happens, they trigger a bug inside a thingy called Assembly Resolver that ends up escrewing up everybody that tries to load DLLs and use Reflection later (hint: TweakScale makes heavy use of that!). Remove this old Firespitter from your rig and install the newest one. — — Additionally — — These ones are not related to TweakScale, but they should be hindering a bit your gaming: [WRN 17:30:01.724] [Part]: sspx-habitation-25-1 holds crew but has no interior model defined! [ERR 17:30:01.764] Exception handling event onVesselChange in class WBIVTOLManager:System.NullReferenceException: Object reference not set to an instance of an object at KerbalActuators.WBIVTOLManager.FindCustomControllers () [0x00043] in <d38e1d363e2b48c6b994849a11da901e>:0 at KerbalActuators.WBIVTOLManager.FindControllers (Vessel vessel) [0x00024] in <d38e1d363e2b48c6b994849a11da901e>:0 at KerbalActuators.WBIVTOLManager.VesselWasChanged (Vessel vessel) [0x00012] in <d38e1d363e2b48c6b994849a11da901e>:0 at EventData`1[T].Fire (T data) [0x000b0] in <39c0323fb6b449a4aaf3465c00ed3c8d>:0 [EXC 17:30:01.766] NullReferenceException: Object reference not set to an instance of an object KerbalActuators.WBIVTOLManager.FindCustomControllers () (at <d38e1d363e2b48c6b994849a11da901e>:0) KerbalActuators.WBIVTOLManager.FindControllers (Vessel vessel) (at <d38e1d363e2b48c6b994849a11da901e>:0) KerbalActuators.WBIVTOLManager.VesselWasChanged (Vessel vessel) (at <d38e1d363e2b48c6b994849a11da901e>:0) EventData`1[T].Fire (T data) (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:LogException(Exception) EventData`1:Fire(Vessel) FlightGlobals:setActiveVessel(Vessel, Boolean, Boolean) FlightGlobals:ForceSetActiveVessel(Vessel) ModuleDockingNode:DockToVessel(ModuleDockingNode) ModuleDockingNode:<SetupFSM>b__142_20() KerbalFSM:RunEvent(KFSMEvent) KerbalFSM:updateFSM(KFSMUpdateMode) KerbalFSM:UpdateFSM() ModuleDockingNode:Update() There's something wrong on KerbalActuators in your rig. I suggest you seek help from the Maintainer, as I don't have the slightest clue about how to help you on them... Cheers! Edited April 4, 2022 by Lisias Some entertaining grammars made less entertaining. Quote Link to comment Share on other sites More sharing options...
giuliannoborges Posted April 8, 2022 Share Posted April 8, 2022 Hey, I got the Houston, we have a problem message. My log is here. Other times i tried to install tweakscale the slider showed up but it did not work. Thanks Quote Link to comment Share on other sites More sharing options...
Lisias Posted April 9, 2022 Author Share Posted April 9, 2022 9 hours ago, giuliannoborges said: Hey, I got the Houston, we have a problem message. My log is here. Other times i tried to install tweakscale the slider showed up but it did not work. Thanks Hi! This second symptom you are describing, I'm almost sure it's some 3rd party screwing a DLL loading somehow (yada yada yada, bug on Assembly Resolver, all that jazz. ) . When the slider doesn't works is because TweakScale was only partially loaded - but when this happens, a very specific Houston must be shown on startup, exactly like this one. Next time the slider doesn't works for you, hit me here on Forum on the spot with the KSP.log . About the problem at hands, it's a double patching problem on some parts: [LOG 17:24:44.560] [TweakScale] ERROR: **FATAL** Part SaturnAL31 (Saturn AL-31FM1 Afterburning Jet Engine) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 17:24:44.560] [TweakScale] ERROR: **FATAL** Part bdWarheadSmall (Small High Explosive Warhead) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 17:24:44.632] [TweakScale] ERROR: **FATAL** Part SaturnAL31 (Saturn AL-31FM1 Afterburning Jet Engine) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 17:24:44.632] [TweakScale] ERROR: **FATAL** Part bdWarheadSmall (Small High Explosive Warhead) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 This is bad because, until recently, TweakScale didn't knew how to "convert receipts" - TweakScale needs special instructions to know how to scale things, and if somehow these instructions change from what you had when you created the craft and what you have now, your craft will be wrongly scaled. Dramatic example on the spoiler (not for the faint of heart ): Spoiler So we need to fix your installment to fix this double-patching. And I think you gave two different patches doing the same work twice... [LOG 17:20:10.668] Applying update BDArmory/Parts/SaturnAL31/SaturnAL31_TS/@PART[SaturnAL31]:NEEDS[TweakScale] to BDArmory/Parts/SaturnAL31/SaturnAL31.cfg/PART[SaturnAL31] [LOG 17:20:10.670] Applying update BDArmory/Parts/SaturnAL31/SaturnAL31_TS/@PART[SaturnAL31]:NEEDS[TweakScale] to FAS Round 3 Patch/BDArmory/Parts/SaturnAL31/SaturnAL31.cfg/PART[SaturnAL31] [LOG 17:20:14.362] Applying update FAS Round 3 Patch/BDArmory/Parts/SaturnAL31/SaturnAL31_TS/@PART[SaturnAL31]:NEEDS[TweakScale] to BDArmory/Parts/SaturnAL31/SaturnAL31.cfg/PART[SaturnAL31] [LOG 17:20:14.363] Applying update FAS Round 3 Patch/BDArmory/Parts/SaturnAL31/SaturnAL31_TS/@PART[SaturnAL31]:NEEDS[TweakScale] to FAS Round 3 Patch/BDArmory/Parts/SaturnAL31/SaturnAL31.cfg/PART[SaturnAL31] You see, you appears to have the same patchset on the following files: BDArmory/Parts/SaturnAL31/SaturnAL31_TS.cfg Patch/BDArmory/Parts/SaturnAL31/SaturnAL31_TS.cfg I don't know what's "GameData/Patch" on your rig, but I'm pretty sure you should remove Patch/BDArmory/Parts/SaturnAL31/SaturnAL31_TS.cfg from your GameData! Cheers! Quote Link to comment Share on other sites More sharing options...
ttr Posted April 9, 2022 Share Posted April 9, 2022 Hello, Latest version (2.4.6.10) via ckan. After reverting to VAB or loading saved craft, tweak scale does not resize all info about parts - found out that fuel i being reset to part default size value. Also some stacktraces in logs. KSP.log: https://www.dropbox.com/s/vjkwrnz8fluzbl1/2022.04.09 - tweakscale - KSP.log?dl=0 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.