[KSP >= 1.3.0] TweakScale - Under Lisias' Management - 2.4.8.8 - 2024-1117

[Hypercore]

KSP version: 1.10 windows 64 bit

Problem: Errors with other mods

Mods installed: Many, link below

Detail: over 900 Showstopping errors, 

Log: https://drive.google.com/file/d/1mBBqo33zDypN9AN3NxxXyMsYDIdLfftt/view?usp=sharing

Mods installed: https://prnt.sc/u6k7vx

Note: the mods worked before, but I changes computers, reinstalled, now it dont work.

Help appreciated!

[etmoonshade]

27 minutes ago, Hypercore said:

Log: https://drive.google.com/file/d/1mBBqo33zDypN9AN3NxxXyMsYDIdLfftt/view?usp=sharing

JFC, that log is 133MB.

You... might want to start over from a clean install, because holy crap that's a lot of exceptions in that log. I'm not even 3000 lines in, and... I assume you meant to type "over 9000 errors," because that's probably a conservative estimate. :V

Verify game files, etc. etc. I suspect that TweakScale isn't the root of the issue here.

Edit: Well over 9000... 326168 Exceptions, to be exact. I swear that's got to be a record of some sort. 

 

Edited August 27, 2020 by etmoonshade

[Lisias]

3 hours ago, etmoonshade said:

JFC, that log is 133MB.

I got bigger ones.  

 

3 hours ago, Hypercore said:

KSP version: 1.10 windows 64 bit

Problem: Errors with other mods

[cut by me]

Note: the mods worked before, but I changes computers, reinstalled, now it dont work.

Help appreciated!

Install ZeroMiniAVC. Really. I doubt it's related to your (long list of) problems, but these ones will cause some trouble later for sure.

About your log,

326168 Exceptions

29 being "CustomAttributeFormatException: Could not find a field with name guiName"
1 being "IndexOutOfRangeException: Index was outside the bounds of the array."
4 being "MissingFieldException: Field 'KSPField.guiName' not found."
31006 being "MissingFieldException: Field 'KSPParticleEmitter.pe' not found."
155870 being "MissingFieldException: Field 'KSPParticleEmitter.pr' not found."
1 being "MissingMethodException: void PopupDialog.SpawnPopupDialog(string,string,string,bool,UnityEngine.GUISkin)"
139290 being "NullReferenceException: Object reference not set to an instance of an object"

Pretty messy - but the really big numbers are happening because these ones are being issued on the Update of FixedUpdate thingy. These ones happens dozens (sometimes near hundreds) of times per second.

The "could not find" or "MissingFieldException" happens when the code from the DLL tries to access a code from another DLL that doesn't exists. This happens when the DLL versions you have on the rig doesn't matches the version some other DLL is expecting. Usually, when you compile a DLL on a new KSP version using some of the new thingies, and then try to run it on an older KSP.

This also happens when  you compile it using an old DLL that had a thingy that was deprecated. Pretty sure this is related to Unity, a lot of thingies from Unity5 were deprecated on the 2019 used on KSP 1.10 you are using.

One of the problems I'm sure is AirplanePlus:

[LOG 18:11:54.873] Load(Audio): AirplanePlus/Sounds/109_startup
[EXC 18:11:54.992] MissingFieldException: Field 'KSPParticleEmitter.pe' not found.

As far as I know, AirplanePlus was not updated to KSP 1.9 and 1.10 yet.

My advice: remove AirplanePlus and see if the Exceptions go away. If yes, you will need to choose: remove AirplanePlus permanently, or downgrade KSP to 1.8.1 .  All these exceptions are hindering terribly your framerate,, your machine will perform way better when you fix these ones.

In time...  Yeah, there's a lot of FATALities too on the log. Usually, such a huge number of fatalities is due something wrong on the installation. And checking the patching process, I detected that BlueDog is duplicated on your instalment. Somehow, you installed it twice on it:

[LOG 18:12:00.604] Applying update Bluedog_DB/Compatibility/Tweakscale/tweakscale_Agena/@PART[bluedog_AgenaA]:NEEDS[TweakScale] to Bluedog_DB/Parts/Agena/bluedog_AgenaA.cfg/PART[bluedog_AgenaA]
[LOG 18:12:00.607] Applying update Bluedog_DB/Compatibility/Tweakscale/tweakscale_Agena/@PART[bluedog_AgenaA]:NEEDS[TweakScale] to Gamedata/Bluedog_DB/Parts/Agena/bluedog_AgenaA.cfg/PART[bluedog_AgenaA]

You have a copy on Gamedata/Bluedog_DB , but also somewhere else outside GameData but that is also being catched by KSP. My guess is that you installed it too on KSP root.

Open the folder where KSP_X64.exe is, then check if there's a subfolder called Bluedog_DB there (as a "brother" of GameData, instead of its son). Delete it. It will fix the FATALities for sure.

 

3 hours ago, etmoonshade said:

Edit: Well over 9000... 326168 Exceptions, to be exact. I swear that's got to be a record of some sort. 

You will like this one:  

cat KSP.log | grep -oP "^\[EXC .+? \K(.+?)$" | sort -u | while read line ; do echo $(cat KSP.log | grep -e "^\[EXC " | grep "$line" | wc -l) :: "$line" ; done

 

Edited August 27, 2020 by Lisias
Tyops galore!!!

[etmoonshade]

22 minutes ago, Lisias said:

My advice: remove AirplanePlus and see if the Exceptions go away. If yes, you will need to choose: remove AirplanePlus permanently, or downgrade KSP to 1.8.1 .  All these exceptions are hindering terribly your framerate,, your machine will perform way better when you fix these ones.

AirplanePlus was working (relatively) fine for me in 1.10.1, for what it's worth. Certainly not with that many errors.

[TranceaddicT]

28 minutes ago, etmoonshade said:

AirplanePlus was working (relatively) fine for me in 1.10.1

 

1.9.1 JNSQ install and doing fine so far.  My probs with APP (I'll focus on them when I get to them) are AJE/E related.

I don't know about anyone else, but when I do my fresh installs, I use what I call the dialpad method. Imagine a telephone dialpad with the letters (2-ABC, 3-DEF, ...) on each key.

Phase 1,  Unpack a fresh KSP install.  Launch to verify and establish settings.

Phase 2, Install only A, B, C mods and associated depends.  Launch to verify and establish settings.

Phase 3, Install D, E, F and depends. Launch.  Verify.

Rinse. Repeat.

[Lisias]

1 hour ago, etmoonshade said:

AirplanePlus was working (relatively) fine for me in 1.10.1, for what it's worth. Certainly not with that many errors.

I'm still playing on KSP 1.7, so I really don't know about AirplanePlus on KSP >= 1.8 . I fire them up to make small tests, check if the new patches of the Compantions are OK, etc - but the real playing is still on 1.7.3.

So I can't say for sure if APP is the source or the problem, or just the screaming victim.

 

1 hour ago, TranceaddicT said:

1.9.1 JNSQ install and doing fine so far.  My probs with APP (I'll focus on them when I get to them) are AJE/E related.

The ones I detected on that log appears to be related to emitters, on the Config/Models loading phase. Module Manager wasn't even started to patch things yet.

...

....

Hummm...

Perhaps I misdiagnosed the problem? It can be also some crucial game files deleted or moved to wrongly places...

@Hypercore - There's a good chance I gave you a less than optimum advise (A.K.A., I'm probably wrong). I think you should create a new install from scratch, there's a good chance you removed or moved some KSP assets, and that it's the cause of the AirplanePlus problems!

(thinking is a pretty healthy and useful exercise. I should do it more frequently...).

[TranceaddicT]

27 minutes ago, Lisias said:

Perhaps I misdiagnosed the problem?

HAHAHAHA   I can actually say yes to this. ::giggitty::

That looks like a KSP_Data problem (hang on, currently running a TCsearch RegEx).

*patiently strums desk*

*ding*

globalgamemanagers.assets
Assembly-Csharp.dll

Yep, bad base install.

[Hypercore]

8 hours ago, TranceaddicT said:

HAHAHAHA   I can actually say yes to this. ::giggitty::

That looks like a KSP_Data problem (hang on, currently running a TCsearch RegEx).

*patiently strums desk*

*ding*

globalgamemanagers.assets
Assembly-Csharp.dll

Yep, bad base install.

So what can I do in a case of that?

[Hypercore]

@Lisias

So if I move all my gamedata files and extras files to the new fresh install, it might work?

 

[Lisias]

1 hour ago, Hypercore said:

@Lisias

So if I move all my gamedata files and extras files to the new fresh install, it might work?

Yes, but I would advise to COPY them, one by one. So if something goes wrong, you don't risk losing them - you can erase the new borked instalment and start again.

Only when the new instalment works fine I would consider deleting the old one.

To tell you the true, I stil have my 1.4.5 carrer instalment lingering here, I choose to keep it after migrating to 1.7.3 . just in case

1 hour ago, Hypercore said:

So what can I do in a case of that?

Dowload a fresh copy of the KSP you want to use (assuming you dont have a backup of it already).

Then copy the folders to the new installment, following the telephone method suggested by @TranceaddicT above.

Create new savegames to do quick checks. Delete them after using.

Once you manage to get the new instalment working fine, just then COPY then savegames from the old instalment to the new.

Edited August 27, 2020 by Lisias
Hit "Save" too soon.

[TranceaddicT]

1 hour ago, Hypercore said:

So what can I do in a case of that?

 

My personal recommendation ... Start over from stratch.

Follow these instructions ...

12 hours ago, TranceaddicT said:

1.9.1 JNSQ install and doing fine so far.  My probs with APP (I'll focus on them when I get to them) are AJE/E related.

I don't know about anyone else, but when I do my fresh installs, I use what I call the dialpad method. Imagine a telephone dialpad with the letters (2-ABC, 3-DEF, ...) on each key.

Phase 1,  Unpack a fresh KSP install.  Launch to verify and establish settings.

Phase 2, Install only A, B, C mods and associated depends.  Launch to verify and establish settings.

Phase 3, Install D, E, F and depends. Launch.  Verify.

Rinse. Repeat.

Oh, I forgot to add something to this ...  when you're done, compress it all.  Send the whole shebang (kspRoot and all) to a 7z.

[Hypercore]

@TranceaddicT @LisiasTrying now, thanks for all the help!

 

[Hypercore]

@TranceaddicT @Lisias

https://prnt.sc/u74vf8 

I tracked it down to one of these

any ideas?

Edit: it worked after I removed mmwatchdog

any ideas why this is happening?

Edited August 27, 2020 by Hypercore
New findings

[TranceaddicT]

1 hour ago, Hypercore said:

@TranceaddicT @Lisias

https://prnt.sc/u74vf8 

I tracked it down to one of these

KSP.log is always the better way to track down.

Not familiart with VirginKalactic, DeployableAeroSurfaces, KAX, KSPModFileLocalizer.

[Lisias]

18 hours ago, Hypercore said:

Edit: it worked after I removed mmwatchdog

any ideas why this is happening?

I know WHAT but doesn't understand WHY. See below.

 

17 hours ago, TranceaddicT said:

Not familiart with VirginKalactic, DeployableAeroSurfaces, KAX, KSPModFileLocalizer.

KAX is mine. But I do not distribute a KAX_Readme file on the zip. Where did you downloaded KAX, @Hypercore?

-- -- About the MMWatchDog bork -- --

This is just INSANE.  

KSP-Recall is being distributed with a corrupted DLL file! That's the reason I didn't found any problems on my rig, the only corrupted copy is on the KSP-Recall zip file. I was scratching my head trying to figure out how in hell I leaked a corrupt file into the mainstream when I decided to download everything I ever published, and that's how I detect it's on KSP-Recall.

WORST. The file on Recall is not exactly corrupted, it had ONE BYTE DELETED, all the rest of the file is identical to what I compiled.

And not, it's not a missing byte at the end of tile, it's the byte at the position 0x76 (a 0x0D) that was deleted somehow from the file. Since the 0x0D 0x0A is the MS-DOS end-of-line marker, I'm guessing something somewhere preprocessed this file and "fixed" what would be a bad EoL (0D0D0A -> 0D0A) marker completely disregarding the frakking file is binary, damnit. #facePalm

I probably didn't detected it before by the same reason I had to put it there - since everybody just unzip files into the GameData, I do the same (end-user simulator  ), but since KSP-Recall is alphabetically less than TweakScale, usually is comes first on the Explorer, and so it's unzipped first - and anyone installing TweakScale would overwrite the bad file with the TS's one, what's good.

It was needed a non TweakScale user that does thing manually to detect this. @TranceaddicT was the first, but since I had sent him some DLLs on PM on a diagnosing fest, I tacitly assumed I had borked on that DLLs. But now we have @Hypercore with similar problems, so it became clear the problem is on a distribution file. Since TweakScale don't borks on me (I really do tests before shipping), the only remaining suspect is Recall - and since I don't remember testing only Recall, I completely missed this absolutely appalling problem.

At least this one is easy to fix. I'm packing a new minor release of KSP-Recall.

@Hypercore, this is the reason we always ask for the KSP.log when doing support. I would detect this one in 5 seconds, just looking on the log.

-- -- -- POST EDIT -- -- --

It was GITHUB. Recall is a new repository (couple months only), and apparently some idiot on Github decided it was a good idea to "help" people by transparently shoving what follows on new repositories on the .gittatributes :

# Auto detect text files and perform LF normalization
* text=auto
* text eol=lf

DAMNIT - I hate when <insert your favorite non forum compliant compliment here> try to second guess me, "helping" me to do what THEY think is right.

I just remembered what I did - I usually starts project locally, and create the github repo later, and then I already have a initialised repo to push up. For Recall, I created the repo on the github and clone it first. #facePalm.

Oh, well... 

-- -- -- POST POST EDIT -- -- -- 

Just for the sake of completude - I created a bunch of repositories locally, on github and on bitbucket (where most of my professional and retro works are hosted).

None of them added the .gitattributes file.

I don't have the slightest idea from what deepness of hell that file came, all I know is that it's there since the first commit. But it's not Github for sure. It's something else I was using on Feb this year.

What I can say for sure is that I didn't added that file consciously, something added it for me and I did't realised it.

Oh, well....  Now I have a bunch of release notes to fix. Sometimes the Grumpiness Factor strikes back.

Edited August 28, 2020 by Lisias
post post edit

[steve_v]

2 hours ago, Lisias said:

apparently some idiot on Github decided it was a good idea to "help" people by transparently shoving what follows on new repositories on the .gittatributes :

That's... Proper dastardly. Find another host level of dastardly even.

I have personally have a seething hatred of automatic "helpers/fixers" in software in general. I don't mind being informed about potential mistakes, but any and all fixing must be confirmed by the user, especially if it has the potential to touch many files.
"MSDOS linefeeds detected in the following files: [], proceed anyway?" would be fine. "Hi there, we fixed up some files for you" would most definitely not. Mangling file encoding silently is cause for tarring and feathering the developer responsible.


Off topic, the same goes for the "friendly helpful computer" approach many large software developers seem to be taking with user interaction in general (and error messages in particular) - I expect a message from an application or OS to contain enough information that I can act on it, not treat me like a bumpkin and offer nothing beyond a meaningless spinning graphic or a sad face emoji and a "send report to <some ******* company>" button.

I installed Winblows 10 in a VM the other day, and the vacuous, unctuous, meaningless "We're just setting up a few things", "Leave everything to us", "Would you like to talk to Cortana" and the like had me trying real hard not to throw up in my mouth the whole time... Oh, and the installer will merrily "fix" your bootloader configuration for you too, without a word. :rage:
 

[Lisias]

15 minutes ago, steve_v said:

That's... Proper dastardly. Find another host level of dastardly even.

Github was innocent on that one. I spend some time creating repos with different options, none of them came with a .gitattributes file. I spent some time checking evert cloned repository of mine, a few have the file - all of them forked from someone else. And as far as I checked, no one was like this one, besides I found some similarities. MSYSGIT is known to add a standard .gitattributes file with a lot of settings for Windows - but the format of the file I had on Recall is different.

 

20 minutes ago, steve_v said:

I have personally have a seething hatred of automatic "helpers/fixers" in software in general. I don't mind being informed about potential mistakes, but any and all fixing must be confirmed by the user, especially if it has the potential to touch many files.
"MSDOS linefeeds detected in the following files: [], proceed anyway?" would be fine. "Hi there, we fixed up some files for you" would most definitely not. Mangling file encoding silently is cause for tarring and feathering the developer responsible.

Agreed. This kind of stung should be considered extenuating circumstances on some kinds of unlawful and permanent activities (not allowed to be mentioned here).

 

23 minutes ago, steve_v said:

Off topic, the same goes for the "friendly helpful computer" [...] Oh, and the installer will merrily "fix" your bootloader configuration for you too, without a word. :rage:

And I'm gathering evidences that similar approaches was/is one of the greatest sources of problems lately on a somewhat famous space simulator where you kick some green critters into space.

[TranceaddicT]

3 hours ago, Lisias said:

apparently some idiot on Github decided it was a good idea to "help" people by transparently shoving what follows on new repositories on the .gittatributes :

# Auto detect text files and perform LF normalization
* text=auto
* text eol=lf

 

 

I was just trying to get my JNSQ install backedup on GH and it kept getting muckedup.  There's a line from my push attempts that read something like "warning: LF detected normalizing to CRLF. Local files retain LF."  or some such rot.

4 hours ago, Lisias said:

Just for the sake of completude - I created a bunch of repositories locally, on github and on bitbucket (where most of my professional and retro works are hosted).

None of them added the .gitattributes file.

 

 

Did you create the KSP-Recall repository locally THEN push/create a GitHub repo?

 

Thank you for you diligence

[Lisias]

14 minutes ago, TranceaddicT said:

Did you create the KSP-Recall repository locally THEN push/create a GitHub repo?

I don't remember.

But since this is what I usually do, and since the first commit's dot files don't look as anything github gave to me on repo creation fest I did now, I was wrong on my initial claim of being github. Now I'm... "curious" to pinpoint from where that file came - but since we live on times of continuous integration, with nearly weekly updates from the mailer to the IDE and the kitchen's sink, that could be something stupid done by some developer on some previous version of some iDE ("hey, let's add this nice gitattributes file for this idio... I mean, UNIX user!") when using the embedded github support while building the first release of Recall.

Oh, well... In a way or another, I'm caught with my pants down only ONCE per issue. Development will be suspended for a couple of days while I normalize every single repo of mine with a carefully curated .gitattributes file (and boy, I have quite a few on github and bitbucket...)

[Hypercore]

@Lisias I downloaded it from curse forge, but unfortunately I'm not on my main pc, so will post log later asap.

Edit: On a unrelated note, I also tracked some issues with b9 part switch and bluedog, but after I deleted bluedog, b9 seems to still load up bluedog parts, and continue to have errors. It doesn't shows up in the vab tho. So I wonder if you have any insights into this, will be much appreciated!

Also btw, once I had a 1.5 gb log! Idk what happened, but it can't even be uploaded to discord, or notepad ++!

Edited August 28, 2020 by Hypercore

[Lisias]

21 minutes ago, Hypercore said:

@Lisias I downloaded it from curse forge, but unfortunately I'm not on my main pc, so will post log later asap.

I had forgot about that. That page is stalled since 2016, when the Author gave KAX to the previous maintainer - that so passed it to me in 2018. Try my updated version, it works for sure on 1.7.3 and I had success playing it on 1.8.1 - but I still didn't tried it on 1.10.1.

 

34 minutes ago, Hypercore said:

Edit: On a unrelated note, I also tracked some issues with b9 part switch and bluedog, but after I deleted bluedog, b9 seems to still load up bluedog parts, and continue to have errors. It doesn't shows up in the vab tho. So I wonder if you have any insights into this, will be much appreciated!

Weird. Delete the ModuleManager.ConfigCache and load it again. It's by best guess at the moment - if it doesn't works, send me the KSP.log in PM and I will give it a look.

 

35 minutes ago, Hypercore said:

Also btw, once I had a 1.5 gb log! Idk what happened, but it can't even be uploaded to discord, or notepad ++!

99.99% of the time, it's related to NRE or some other exception being triggered on the Update or FixedUpdate thingy. The first one happens once a frame (ideally), and the former each 50ms (if memory serves me right). So anything being logged on them will rapidly grow up the KSP.log through the roof.

When you see this happening, quit KSP, reload it, and play for a few minutes. Then quit KSP again. And so send the KSP.log on a bug report on the Forum - whatever happens on that two thingies, happens all the time so just by playing it a few minutes will (most of the the time) flag the problem on the log.

[Ciko]

@Lisias can you please add support for Tundra exploration Falcon 9 tanks?

[Lisias]

20 minutes ago, Ciko said:

@Lisias can you please add support for Tundra exploration Falcon 9 tanks?

Sure thing! Can't give you a deadline, but it will be tackled down as soon as possible.

Keep an eye on the TweakScale Companion Program. New support is being worked out and published there (as TweakScale "Stock" is being trimmed down to handle only Stock and DLC parts, waiving third parties add'on support to a Companion!).

 

[TranceaddicT]

4 hours ago, Hypercore said:

Also btw, once I had a 1.5 gb log! Idk what happened, but it can't even be uploaded to discord, or notepad ++!

Used 7z, not zip.

[Lisias]

Announce

TweakScale 2.5.0.20 Beta is now available for the brave Kerbonauts that don't fear burning savegames in sacrifice to the Krakens.

Some pretty important fixes were implemented that will allow The Companions to survive third-parties "less than happy" patches (being the proof of concept the complete overhaul of FS patches, that changed a lot of thingies and are now safe to be applied!!!), but will also help in some cases of bad patching (a plague still haunting TweakScale nowadays).

This was one of the last real showstoppers preventing TweakScals 2.4.4 to be kicked through my door. Things will start to really happens soon! #HURRAY!

Please note that TS Beta is to be used on disposable savegames only. I'm using this stunt on my own savegames, obviously, but now and then a bug passes through - but I know how to edit and fix my own savegames, and I'm a S.A.V.E. heavy user!

Any reports about it (being a bug or not) should be posted on issue #42 (or I will get lost - again - on the sea of bug reports!).

Edited August 31, 2020 by Lisias
It's 2.5.0.20 now!