Jump to content

[1.8.x-1.12.x] Module Manager 4.2.3 (July 03th 2023) - Fireworks season


sarbian

Recommended Posts

@shoe7ess it’s alphabetical too so you could have a file name with lots of zzzzz in the file name :FINAL 

that’s pretty brute force. You’re probably better off nailing down what mod is doing it and targeting to go after it in order. 
 

you should also verify for sure that something else really is doing something to the part. Read the ModuleManager.ConfigCache and find the part config in there. That will show you its final form

Link to comment
Share on other sites

21 hours ago, Starwaster said:

@shoe7ess it’s alphabetical too so you could have a file name with lots of zzzzz in the file name :FINAL 

that’s pretty brute force. You’re probably better off nailing down what mod is doing it and targeting to go after it in order. 
 

you should also verify for sure that something else really is doing something to the part. Read the ModuleManager.ConfigCache and find the part config in there. That will show you its final form

You're right, the attach nodes are not being altered at all. I only found 3 parts that didn't follow 1,1,1,1,0, and they were engine adapters from BDB. I don't get it. I can attach the part from the top or bottom node to any other part other than itself (so no daisy chaining multiples unless I over-ride with NH). I may try one last attempt with just adding an extra top/bottom stack node, but if  somehow the attachment rules are getting changed (I'm wondering if at this point it's in the VAB editor or something post-launch, since all signs say it should work. The result may be the same but who knows, can't make things any worse at this point. Thanks for the help!

Edited by shoe7ess
Link to comment
Share on other sites

@shoe7ess

so, what’s not working is its stack nodes won’t attach to the stack nodes of another of the same part? Did you check the console to see if any exceptions are being thrown when you try to attach?

 I’d also think about moving this to that mod’s thread. Definitely sounds like something is going on with it. 

Edited by Starwaster
Link to comment
Share on other sites

15 hours ago, Starwaster said:

@shoe7ess

so, what’s not working is its stack nodes won’t attach to the stack nodes of another of the same part? Did you check the console to see if any exceptions are being thrown when you try to attach?

 I’d also think about moving this to that mod’s thread. Definitely sounds like something is going on with it. 

I think you're right. I'm working on a new testbench, going to try and get a nice simple log to provide Linux. Thanks for your help Star, learned (and am continuing to learn) a lot from this little experience! :D

Link to comment
Share on other sites

  • 2 weeks later...

Question regarding maximum value for Parachute Altitude slider.

I created a custom parachute increasing the deployment altitude of the parachute with a little module manager config:

+PART[parachuteRadial]:FINAL
{
	@name = parachuteRadial-High
	@title = Mk2-R Radial-Mount Parachute (8000m deploy variant)
	@MODULE[ModuleParachute]
	{
		@deployAltitude = 8000
	}
}

This works, but when I click on the slider for altitude in the UI the maximum value reverts back to 5000. Is there a setting that controls the maximum value for the UI? Like @clampMinAirPressure for the minimum of the pressure slider?

Thanks!

Link to comment
Share on other sites

  • 2 weeks later...

An error was reported to me by a user on github who doesn't want to open an account :-( on the forum.  I'm posting the info here to see if anyone can help

Quote

zero miniAVC breaks several other mods (KIS for instance) by making module manager really unhappy (can't blame it though, as it does work as designed). I now have uninstalled zero miniAVC, by removing the mod from the GameData folder manually and so far I couldn't find this breaking BTW (or any of the other mentioned mods).

...

KSP.log
Player.log

video for behaviour clarification
https://user-images.githubusercontent.com/72888738/201357207-87ad6837-e70d-4e9f-b13d-db6192ec1ae8.mp4

I'm sorry I wasn't myself yesterday.
As I said, I try my best to understand it to the best of my ability.

Once I remove the zerominiAVC folder from the gamedata folder it works just fine with the other mods working fine as well.
Also, I noticed that this is technically not even the correct repository as BTW isn't directly dependent on ZMAVC but on CTB and Toolbar controller which in turn have the dependency.

 

and my response is:

Quote

This actually looks like a ModuleManager error, while it is having an error with the MiniAVC-V2.dll, the error is in ModuleManager:

I'm going to guess that it's realted to the spaces in the file name. Try copying the entire directory into a new folder on your desktop and see if it happens there.
Regardless, this is not an error in ZeroMiniAVC or MiniAVC-v2, but it's related to those being installed.

Uploading Crash Report [ModuleManager] The patching thread threw an exception: System.IO.FileNotFoundException: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\KIS\Plugins\MiniAVC-V2.dll at System.Diagnostics.FileVersionInfo.GetVersionInfo (System.String fileName) [0x0000d] in <ef151b6abb5d474cb2c1cb8906a8b5a4>:0 at ModuleManager.ModListGenerator.GenerateModList (System.Collections.Generic.IEnumerable1[T] modsAddedByAssemblies, ModuleManager.Progress.IPatchProgress progress, ModuleManager.Logging.IBasicLogger logger) [0x000a2] in :0
at ModuleManager.MMPatchLoader.Run () [0x000f3] in :0
at ModuleManager.MMPatchRunner+<>c__DisplayClass10_0.b__1 () [0x00001] in :0
at ModuleManager.Threading.BackgroundTask+<>c__DisplayClass0_0.g__RunAction|0 () [0x00002] in :0
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

He is using the Steam version of KSP, version 1.12.4

Anybody?

Link to comment
Share on other sites

Just now, linuxgurugamer said:

Were you using a Steam install or not?

I was using a steam install, but it was from a folder copied from the default steam location and launched as a non-steam game from the steam library.

It's how I prevent unwanted steam updates and file consistency issues. It also bypasses the new PDLauncher entirely.   

Link to comment
Share on other sites

Ok.  This is a bug in ModuleManager, I've found and fixed it locally, will be pushing a PR with the change

I believe in pre 1.12.4, MM was seeing the same error, but not crashing on it.  Probably due to a change in the order things are loading in

@sarbian @blowfish

I've just pushed a small PR to fix the issue of MM crashing the game due to a FileNotFound error, caused by MM seeing a list of all the DLLs, but before it is able to open the file, it get's pruned by ZeroMiniAVC.

https://github.com/sarbian/ModuleManager/pull/177

Edited by linuxgurugamer
Link to comment
Share on other sites

On 11/11/2022 at 8:41 PM, linuxgurugamer said:

Ok.  This is a bug in ModuleManager, I've found and fixed it locally, will be pushing a PR with the change

It's not a bug on Module Manager - it trusts the Loaded Assemblies structure is valid. It happens that once you delete, move or rename DLL files that KSP had found after it had found them, the data structures (obviously) became inconsistent.

You should not delete DLLs from a program after it had started or the program will break. I'm afraid this inconvenience has been happening since the first program that used a DLL was even written - on the Windows 1.0 times, perhaps?

You only detected one point in which such breakage happened. There're a lot more, including inside KSP itself.

Link to comment
Share on other sites

19 hours ago, Lisias said:

It's not a bug on Module Manager - it trusts the Loaded Assemblies structure is valid. It happens that once you delete, move or rename DLL files that KSP had found after it had found them, the data structures (obviously) became inconsistent.

You should not delete DLLs from a program after it had started or the program will break. I'm afraid this inconvenience has been happening since the first program that used a DLL was even written - on the Windows 1.0 times, perhaps?

You only detected one point in which such breakage happened. There're a lot more, including inside KSP itself.

It's the only place that causes an error.

Your suggestion to exit the game after deleting the DLLs is not good, because there isn't any easy way to display a message that early in the startup, so the game would just be exiting abruptly.  I would be interested in any suggestions you might have to help.

 

Link to comment
Share on other sites

1 hour ago, linuxgurugamer said:

It's the only place that causes an error.

Your suggestion to exit the game after deleting the DLLs is not good, because there isn't any easy way to display a message that early in the startup, so the game would just be exiting abruptly.  I would be interested in any suggestions you might have to help.

 

Could you used some boolean flag variable on first loading stage, to mark if you have renamed any dll on loading ? And after everything else is loaded (properly or not) show message on main menu or when starting/loading game.

Don't know how much KSP API would allow, though.

Link to comment
Share on other sites

On 11/14/2022 at 1:25 AM, linuxgurugamer said:

It's the only place that causes an error.

No. It's the place where the problem is being detected now. Something completely different.

You can't pinpoint this as the only place where the problem happens without a huge amount of time doing tests with different add'ons - and even  by doing it, you won't be sure: Absence of Evidence is not Evidence of Absence. You need way more information than available in order to do such affirmation.

Here you will find a search on github about the string ".assembly.Location" and also "KSP", that you had try-catch'ed it on your pull request: about 332 mentions on code. Now the same query, but mentioning Unity instead. 500K mentions on code.

It's a lot of pull requests, sir.

Right now, this "bug" on Module Manager (please note the quotes) it's what's preventing random breakage on the user's savegame. It this try-catch is the "Solution", I want my Problem back (SystemD feelings) - it's shielding me from the risk of being screwed up after loading my valuable savegame.

Right now, I'm prone to suspect that a lot of undiagnosed problems I had to handle in the past due not being able to reproduce it on my rig may be related to ZeroMiniAVC. It's a fact that it is doing something that is inducing ModuleManager to bork - there's nothing preventing it from doing the same on any other place that does what Module Manager does.

 

On 11/14/2022 at 1:25 AM, linuxgurugamer said:

Your suggestion to exit the game after deleting the DLLs is not good, because there isn't any easy way to display a message that early in the startup, so the game would just be exiting abruptly.  I would be interested in any suggestions you might have to help.

There's no other safe alternative. How many times did you restarted Windows after an update? If not even Microsoft managed to avoid restarting a program (or the whole O.S.) after removing or replacing DLLs, why do you think that Squad (or any other software shop) could manage to do that?

The only good option would not had shoved MiniAVC everywhere indiscriminately - but as it was already said before, this ship has sailed. Now we need to handle the fallout the less worst way we can.

 

On 11/14/2022 at 3:05 AM, kcs123 said:

Could you used some boolean flag variable on first loading stage, to mark if you have renamed any dll on loading ? And after everything else is loaded (properly or not) show message on main menu or when starting/loading game.

Yes, he can. And it's exactly what I'm doing on an updater of mine (not available on CKAN, to be clear).

Ideally, we should do such updates before launching the game (hint: it's exactly what's CKAN does, and CurseInstaller with some reserves). But there's currently no standard and wide consensual tool for such.

You just can't reload an Assembly on KSP (and on the C# runtime you need to create a new Application Domain to reload something, and then get screwed by internal RPCs), what to say about "unloading" things?

Edited by Lisias
hit Save too soon.
Link to comment
Share on other sites

4 hours ago, Lisias said:

Right now, I'm prone to suspect that a lot of undiagnosed problems I had to handle in the past due not being able to reproduce it on my rig may be related to ZeroMiniAVC. It's a fact that it is doing something that is inducing ModuleManager to bork - there's nothing preventing it from doing the same on any other place that does what Module Manager does.

First, let me be clear that I didn't write this mod, I only took it over, and only look at it when there are problems, such as this.

Not going to argue with you, just point out that after ZMAVC has run once (ie:  on subsequent runs of the game), nothing gets renamed, so you can tell right away if it ran or not by looking at the log file. 

My concern about exiting the game is the user experience.  What I can do is see if I can throw up a window at some point during the startup process to let the user know that the game needs to exit and he will have to restart it.  

While I'm not sure it's possible, I'll also look into seeing if I can have ZMAVC actually restart the game using the same CLI arguments as were passed.

I've started a new development thread for this work here:

 

Edited by linuxgurugamer
Link to comment
Share on other sites

Ok, it pains me to admit it but I agree with Lisias here. But I will merge the change because it will push the problem away from MM.

A popup that warns the player and stop the game after the renaming is doable and feels like a good solution that will fix most of this.

Link to comment
Share on other sites

Just now, sarbian said:

Ok, it pains me to admit it but I agree with Lisias here. But I will merge the change because it will push the problem away from MM.

A popup that warns the player and stop the game after the renaming is doable and feels like a good solution that will fix most of this.

Great.  See my new thread about what I'm going to try to do to properly fix this issue.  I'll be streaming the work this evening on Twitch if you want to pop in:  https://twitch.tv/linuxgurugamer at 6:30 PM EST 

Link to comment
Share on other sites

Is there a way to duplicate and then modify an existing PART (without copying its .cfg) file?

In C I could use the include statement to make a 2nd instance of the ISRU part.  And then using MM I would rename the (first instance), having now two parts with different names.
 

#include "ISRU.cfg" 
@PART[ISRU] { @name = ISRU_10x }

Possibly this could be done with copy node?

+PART {
  #/PART[ISRU]   // I'm thinking this would include everything within the brackets of PART from ISRU.cfg
  @name = IRSU_10x
  @MODULE[ModuleResourceConverter],0	{   
  	@OUTPUT_RESOURCE,0 {
		@Ratio = 444.0
	}
  }
}

TIA

Link to comment
Share on other sites

On 11/17/2022 at 8:47 AM, starman2022 said:

Is there a way to duplicate and then modify an existing PART (without copying its .cfg) file?

In C I could use the include statement to make a 2nd instance of the ISRU part.  And then using MM I would rename the (first instance), having now two parts with different names.
 

#include "ISRU.cfg" 
@PART[ISRU] { @name = ISRU_10x }

Possibly this could be done with copy node?

+PART {
  #/PART[ISRU]   // I'm thinking this would include everything within the brackets of PART from ISRU.cfg
  @name = IRSU_10x
  @MODULE[ModuleResourceConverter],0	{   
  	@OUTPUT_RESOURCE,0 {
		@Ratio = 444.0
	}
  }
}

TIA

Yes, you just need to specify the part name in the first line instead within the brackets. See below - this will create a copy of the part and that will include everything defined for the part up to that point.

+PART[ISRU] 
{
  @name = IRSU_10x
  @MODULE[ModuleResourceConverter],0
  {   
    @OUTPUT_RESOURCE,0 
    {
		@Ratio = 444.0
    }
  }
}

 

If there are mods that patch that part later in the loading process and you want to initiate the copy after that patch so you don't have to replicate it, you can do so by adding something like ':AFTER[<mod dll / folder name here>]' to the first line. The below example would copy the ISRU part after SystemHeat has patched it, for example:

+PART[ISRU]:AFTER[SystemHeat] 
{
  @name = IRSU_10x
  @MODULE[ModuleResourceConverter],0	
  {   
    @OUTPUT_RESOURCE,0 
    {
		@Ratio = 444.0
    }
  }
}

 

Probably good to read up on patch ordering on the MM Wiki if you haven't done so.

Edited by Zelda
Code formatting
Link to comment
Share on other sites

  • 4 weeks later...
19 minutes ago, alexalex said:

Is there a way in module manager to differentiate between a normal EVA kerbal and one sitting in an external command seat, so that I can have something apply to one and not the other? A !{xxxxx} type string of some sort?

A kerbal is, in the game, a single-part vessel

A  command seat is a vessel

Kerbals in vessels don't really exist except as some information, so the answer is no.

 

Link to comment
Share on other sites

OK I have another question, I am trying to mod Kerbalism to fix some of the issues it has.  I can use experiment_id to input a single experiment field, in this case dmbathymetryscan, to the HardDrive module, but how do I input multiple experiments to that module?  I can't input multiple experiment_id's, so I need a way around it so is there a way to make experiment_id = X  where  X = experiment A plus experiment B plus experiment C?

Quote

    MODULE
    {
        name = HardDrive
        experiment_id = dmbathymetryscan
    }

 

Link to comment
Share on other sites

  • 2 weeks later...

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