Jump to content

[KSP >= 1.3.0] TweakScale - Under Lisias' Management - 2.4.8.6 - 2024-0921


Lisias

Recommended Posts

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

finally implemented a proper "TweakScale Upgrade Pipeline" :sticktongue: for TweakScale patches. This means that your savegames and craft files will not be screwed anymore if:

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. :)

159203682-5e46d0cf-b151-4574-8ad4-e1698d

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. :D
    • 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 by Lisias
All your Distribution Channels are belong to us! :)
Link to comment
Share on other sites

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 by Lisias
Some entertaining grammars made less entertaining.
Link to comment
Share on other sites

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:

142079978-348b8177-7a9c-4db2-8718-bd3342

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 by Lisias
post edit
Link to comment
Share on other sites

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!! :sticktongue:). 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:

MBprx5V.png

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 by Lisias
Hit 'save" too soon.
Link to comment
Share on other sites

5 hours ago, TheLoneOne said:

hello I'm having an issue with this mod. it works perfectly, how do I fix this problem?:huh:

Give me some time, I'm surely will be able to correct this soon!! :sticktongue:

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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!

 

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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 :P 

 

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:

160735464-59946829-b7ec-40ef-ae1c-b6230d

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:

160737989-efa3a414-4953-4e96-a061-b5929f

 

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:

  1. TweakScale 2.4.6.9 screwed up your craft file.
    1. It can be a problem while saving a craft file, but the existing ones are safe.
    2. Recreate the craft using TS 2.4.6.8 or 2.4.6.10 and see what happens
  2. Something are preventing KSP-Recall from patching Procedural Parts with AttachedOnEditor.
    1. Please send me the affected craft so I can inspect it.
    2. You can compress it and attach it on a post on this issue: https://github.com/net-lisias-ksp/TweakScale/issues/240
  3. 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)
    1. 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).
    2. Send me (see the previous item)
      1. your affected savegame (the whole thing) on a zip file
      2. a CKAN export file
      3. the whole <KSP_root>/KSP.log, and <KSP_root>/GameData/ModuleManager.cache and the <KSP_root>/Logs/ModuleManager/* ones too.
        1. Zip everything into a file and send it to me (se the previous item).

Cheers!

Edited by Lisias
tyops! Who would thought of that? :P
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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 by Lisias
post post edit
Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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 by Lisias
Some entertaining grammars made less entertaining.
Link to comment
Share on other sites

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 :P ):

Spoiler

55228666-75687f80-51f9-11e9-8246-e37c25e

54075134-4efa9880-427a-11e9-9d24-0917306

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!

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...