Jump to content

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


sarbian

Recommended Posts

  On 5/16/2023 at 12:16 PM, linuxgurugamer said:

My conclusions are this:

  1. Only one copy of MM is installed
Expand  

I'm not talking only about one MM copy being installed, but about more than one instance being running. It looks nuts, but I have at least one situation in which multiple (at least two) copies of MM were running concurrently in memory and I only found one Module Manager DLL in the whole KSP.log.

I detected this problem due a screwed up patching on the Localization file (a node containing another copy of itself inside it), that I only detected by eye balling the ConfigCache file. I should had write a full report at that time, however, now I do not recall how the KSP.log was looking like, I don't recall if an occurrence I detected of a unique patch being applied twice to a part were logged twice on the KSP.log or not - thinking a bit more about the problem, it may be a problem inside MM that by some reason is firing up more than one MMPatchLoader threads.

Anyway, back to the problem at hands.

 

  On 5/16/2023 at 12:16 PM, linuxgurugamer said:
  1. Something else (KSP and/or Unity) is keeping the file open, even after reading it into memory
Expand  

By the time Module Manager's MonoBehaviour is started, KSP had already loaded, resolved and linked every single Assembly from every single DLL in the GameData (as long it's not inside a PluginData directory). Loading KSP plugins is as simple as calling "AssemblyLoader.LoadPlugin" , so I'm betting this is the call KSP is using for loading the KSP Assemblies.

When I load Assemblies for inspection, I do something like this:

System.Reflection.Assembly.ReflectionOnlyLoad(System.IO.File.ReadAllBytes(filepath))

but someone else could use too:

using (System.IO.FileStream fileStream = new System.IO.FileStream(filepath, System.IO.FileMode.Open, System.IO.FileAccess.Read))
{
	byte[] rawbytes = new byte[fileStream.Length];
	int n = fileStream.Read(rawbytes, 0, rawbytes.Length);
 	// n should be equal to rawbytes.Lenght now, or something went South.
  
	System.Reflection.Assembly.ReflectionOnlyLoad(rawbytes)
}

In both situations, the file will be closed after the operation (you need to call Dispose on Streams, and using do it automatically for you).

So, we have now two possible situations in which the DLL files would be still opened by the time Module Manager calculates the SHA :

  1. An external program is, deterministically, keeping the damned files opened at that time - probably an anti-virus
  2. KSP is leaking file handlers in objects still to be collected by the Garbage Collector.

Given that you, by using a small delay, was able to open the file, I think it's reasonable to assume option 2 (as long we agree to rule out multiple MM threads running concurrently).

But in order to KSP be leaking file handlers, it should be loading DLLs more or less like this:

void loaddll(string filepath)
{
	System.IO.FileStream fileStream = new System.IO.FileStream(filepath, System.IO.FileMode.Open, System.IO.FileAccess.Read);
	byte[] rawbytes = new byte[fileStream.Length];
	int n = fileStream.Read(rawbytes, 0, rawbytes.Length);

	System.Reflection.Assembly.ReflectionOnlyLoad(rawbytes)
}

What's, frankly, a very, very, very stupid move. The filestream will be lingering in memory until being collected by the GC.

Now, and assuming this is the problem afflicting MM right now, you are experiencing the problem on the bigger rig not exactly because it's faster, but because it probably have way more memory and so there's less pressure over the Garbage Collector to collect memory, delaying the disposing of the filestreams that were leaked by the hypothetical shoddy code I posted above.

The way you used to cope with the situation (by opening the files in share mode with sharing write privileges), besides not addressing the root problem, is also:

  • being potentially flagged by antivirus as you is opening a DLL file with write permissions, what's a very suspicious move that antivirus look for, triggering some monitoring code that would not be triggered otherwise
  • you are using a slower call.
    • opening a file for sharing is always slower than just opening the thing.
    • reading from it, too.

what makes loading KSP slightly slower than otherwise - and I want to stress that KSP loading times are a common cause of complains.

So, before pushing into the upstream a solution that will make loading KSP slightly slower for everybody no matter they are being affected or not, I would try to pinpoint the root cause of the problem and try something that would tax only the affected rigs.

Being the reason I suggest so:

  • making all the DLLs inside GameData read/only to see if anything changes
    • r/o files are handled in a less strictly way by the O.S., as it knows that no one is going to be able to write on it.
    • (your O.S.'s mileage will vary, of course)
  • call GC.Collect() before starting the SHA computations.
    • If I'm right about the leaking file handlers, this may mitigate the problem.
  • On UNICES listing  the open files immediately before and after the SHA computation is relatively trivial, but I don't have the slightest idea about Windows.
    • if feasible, dumping the process's opened files before and after the SHA computation may help to correctly diagnose the problem
    • on a UNIX, I would have a second process waiting for a signal, and then dumping the open files from the KSP process, and then I would, so, send this signal from Module Manager before starting the SHA computations.

 

 

Edited by Lisias
Entertaining grammars made slightly less entertaining.
Link to comment
Share on other sites

  On 5/16/2023 at 3:31 PM, Lisias said:

Given that you, by using a small delay, was able to open the file, I think it's reasonable to assume option 2 (as long we agree to rule out multiple MM threads running concurrently).

Expand  

No, the small delay did NOT let the file be opened

  On 5/16/2023 at 12:16 PM, linuxgurugamer said:

Add a sleep delay when trying to open the file, just in case it would be closed.

Expand  

This did not work

Link to comment
Share on other sites

  On 5/17/2023 at 4:26 AM, Lisias said:

So what leaded you to the conclusion that it would be KSP and/or Unity the problem and not some other process running on that specific rig?

Expand  

Because other than being a lot faster, the new system is running all the same software, OS, etc.  Nothing is really different. Same Antivirus, same filters on the browsers, etc.  Also, because I have seen the same messages on my old system, just not every time.

Link to comment
Share on other sites

TL;DR: KSP may be innocent, the problem may be on how Windows works internally.

But I am wrong too (and for sure), as by some reason using FileShare.Read is faster than not using it both on MacOS and Windows under C#'s runtime.

Go straight to the bottom of this post for the gory details.

  On 5/18/2023 at 1:22 AM, linuxgurugamer said:

Because other than being a lot faster, the new system is running all the same software, OS, etc.  Nothing is really different. Same Antivirus, same filters on the browsers, etc.  Also, because I have seen the same messages on my old system, just not every time.

Expand  

The amount of memory between the systems are the same or the new rig has more memory? How faster are the disk access on the most powerful rig (m2 in the new, spinning disks on the old, perhaps)?

Now, I need to ask you to bear with me, as this is not a private message and there're lots of people reading us (and probably more in the future) that may not have all the needed knowledge to understand how deep is this rabbit role.

It also helps me to think. Rubber Ducking effect.

In order to the AntiVirus be a problem, it may be being incited somehow,  but since you had the problem before applying the stunt, at worst you exchanged a problem with a smaller one (after all, the stunt worked for you). So, on a second thought, it's probably not the antivirus the cause of the initial problem.

Assuming we have a problem inside KSP, the older rig being not too much prone for the problem may be related to memory or disk access more than processor speed (if at all). More memory available means less pressure on the GC, and bigger chances of a leaking file handler be around for more time (if we have a file handler leaking). Faster disk access means we have a race condition, in which the slower disk was delaying things enough to prevent it for the most part (and on this case, we may not have a file handler leaking).

As a race condition, I meaning the KSP's thread that was loading all the Assemblies starting the ModuleManager's thread before closing all its file handlers.

On a slow file system, the code that MM uses to search the GameData for DLLs would cause enough delay on a slow disk that it would let the caller's thread to finish closing the handlers.

On a pretty fast file system, the search for the DLLs may be so quick that there was not time for the caller's thread to close the handlers before the MM's thread try to open one of that files.

However, had you having a race condition situation, a delay before trying to open the file should had worked for you - but the ultimate test would be running KSP on a slow disk in the new rig, as a USB thumbdrive or USB to SATA adapter. You reproduce the problem consistently using this, and we rule out definitively the file system from the equation (and, so, a race condition derived from disk access).

So we are back to a file handling leakage problem - with me having to eat my words, as you may be right on thinking the problem is in KSP itself. And/or Unity, but KSP is the one borking, so it is, indeed, the prime suspect by now.

But to understand why this would be a problem, we need to understand how opening files works on a concurrent environment. And now we are getting technical.

When multiple actors try to open the same file for reading, a UNIX O.S. couldn't care less - the damned file are not going to change, everybody is going to read the same data, let them do it as they please. If by some reason you want to be the only one reading the file (as when using the file contents to synchronise multiple processes), you need to explicitly tell the O.S. about.

This is where sane O.S.s like UNIX differs from Windows: what happens if someone tries to delete the file when another process had opened it for reading? On Windows, you have a serious data integrity problem, but on UNIXs deleting a file is only removing a named pointer from a directory file - the file itself is located on the disk by a thingy called inode, and when you open a file, you fetch a pointer to that inode. Only when there's nothing else (as another directory entry or at least a file handler) pointing to a inode is that the file is "physically" erased from the disk. And, yes, you can have the same file "linked" in multiple and different directories on a UNIX file system (it's what we call a hard link).

And perhaps this is the reason we don't have such complains from Linux and MacOS users?

So, by default, on UNICES all files are opened in a way that multiple processes can open it for reading at the same time and you need to go an extra mile to tell the O.S. that the file should be opened by exclusive or controlled access.

On Windows, the default is exclusive access and you need to go that extra mile to tell it to allow multiple process reading it at the same time.

This difference is pretty important, because programmers used to the UNIX way have a mental posture about reading files completely different from Windows programmers. And this played a role on my initial approach to this case. And it's the reason I was subconsciously averse to the idea of using FileShare (being it Read or ReadOnly) on the solution without further considerations. Yep, my apologies.

Using, however, FileShare.ReadWrite is undesirable on an executable file. The ideal mitigation code IMHO should use FileShare.Read (as you already stated on a previous post). Denying write access while opening files may, at very least, get the AntiVirus out of our necks - if no one is going to be able to write the file, there's no need to monitor such a thing.

But now we have a serious problem on KSP itself: as it appears, we have a problem of leaking file handlers (or less likely a race condition, see above). KSP loading times is being consistently criticised, and we are only making things worse.

So, it's time for some benchmarking. I wrote this little program:

  Reveal hidden contents

And I ran it 3 times on my MacOS rig:

> /Library/Frameworks/Mono.framework/Commands/mono Tests.exe
Hello World!
/Users/lisias/Workspaces/KSP/GIT/net-lisias/ksp/KSPe/bin/Debug/Tests/Tests.exe
OpenFileWithRead 00:00:08.24
OpenFile 00:00:09.07
--
> /Library/Frameworks/Mono.framework/Commands/mono Tests.exe
Hello World!
/Users/lisias/Workspaces/KSP/GIT/net-lisias/ksp/KSPe/bin/Debug/Tests/Tests.exe
OpenFileWithRead 00:00:08.14
OpenFile 00:00:08.83
--
> /Library/Frameworks/Mono.framework/Commands/mono Tests.exe
Hello World!
/Users/lisias/Workspaces/KSP/GIT/net-lisias/ksp/KSPe/bin/Debug/Tests/Tests.exe
OpenFileWithRead 00:00:08.39
OpenFile 00:00:08.98

And… I gone down in flames! Using OpenFileWithRead is FASTER. This caught me with my pants down in a very precarious situation...

Since I'm here, I ran the same binary on my Windows 10 test bed:

C:\Users\lisias\Desktop\OpenRead>Tests.exe
Hello World!
Tests.exe
OpenFileWithRead 00:00:04.65

Exceção Não Tratada: System.IO.IOException: O processo não pode acessar o arquivo 'C:\Users\lisias\Desktop\OpenRead\Tests.exe' porque ele está sendo usado por outro processo.
   em System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   em System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)
   em System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy)
   em System.IO.FileStream..ctor(String path, FileMode mode)
   em Tests.MainClass.OpenFile(String fn, Int32 i)
   em Tests.MainClass.TestSession2()
   em Tests.MainClass.Main(String[] args)

C:\Users\lisias\Desktop\OpenRead>

My Windows is PT-BR. The message above is telling that the process could not access the file because it was in use by another process.

This caught my attention: the EXE file is kept open while running the program! So I copied Tests.exe to T.exe and ran T.exe instead (and, so, Tests.exe would not be opened at runtime):

C:\Users\lisias\Desktop\OpenRead>T.exe
Hello World!
T.exe
OpenFileWithRead 00:00:04.17
OpenFile 00:00:04.50
--
C:\Users\lisias\Desktop\OpenRead>T.exe
Hello World!
T.exe
OpenFileWithRead 00:00:04.07
OpenFile 00:00:04.47
--
C:\Users\lisias\Desktop\OpenRead>T.exe
Hello World!
T.exe
OpenFileWithRead 00:00:04.06
OpenFile 00:00:04.49

Oukey, the results are consistent. Once I avoided opening the file from the executable in use, I got similar results - with the exception that my MacOS is twice as slower than Windows. A real surprise, as my MacMini is using spinning platers and the Windows notebook a M2 - I was expecting better performance from a M2 (perhaps the one I have is crappy?). APFS appears to be less performatic than HPFS, by the way, but since I make heavy use of the CopyOnWrite thingy, I will just take the hit on this.

Anyway, since I'm here, I gave this a last shot and created a test case for FileShare.ReadWrite and got the following timings:

> /Library/Frameworks/Mono.framework/Commands/mono Tests.exe
Hello World!
/Users/lisias/Workspaces/KSP/GIT/net-lisias/ksp/KSPe/bin/Debug/Tests/Tests.exe
OpenFileWithReadWrite 00:00:08.20
OpenFileWithRead 00:00:08.17
OpenFile 00:00:08.76
--
> /Library/Frameworks/Mono.framework/Commands/mono Tests.exe
Hello World!
/Users/lisias/Workspaces/KSP/GIT/net-lisias/ksp/KSPe/bin/Debug/Tests/Tests.exe
OpenFileWithReadWrite 00:00:08.25
OpenFileWithRead 00:00:08.22
OpenFile 00:00:08.86
-- 
> /Library/Frameworks/Mono.framework/Commands/mono Tests.exe
Hello World!
/Users/lisias/Workspaces/KSP/GIT/net-lisias/ksp/KSPe/bin/Debug/Tests/Tests.exe
OpenFileWithReadWrite 00:00:08.34
OpenFileWithRead 00:00:08.82
OpenFile 00:00:09.12

Well, I'm not that wrong after all - opening with FileShare.ReadWrite is, indeed, slightly slower then FileShare.Read, but barely. And it's way faster than not using FileShare at all.

On Windows, I got:

C:\Users\lisias\Desktop\OpenRead>T.exe
Hello World!
T.exe
OpenFileWithReadWrite 00:00:04.06
OpenFileWithRead 00:00:04.03
OpenFile 00:00:04.48
--
C:\Users\lisias\Desktop\OpenRead>T.exe
Hello World!
T.exe
OpenFileWithReadWrite 00:00:04.04
OpenFileWithRead 00:00:04.04
OpenFile 00:00:04.48

The difference is way tighter than on MacOS, but it's still there. Perhaps due the M2?

Well, concluding: I'm still smelling something funny on the root problem, but I'm not convinced anymore it's something in KSP. It may be something on Windows, taking some time to wave the file handler of the opened DLL file (in a similar way Windows kept the EXE file opened while running it - I had completely forgot Windows does this stunt).

However, intentionally or not, LGG solution for the problem is not only a working mitigation for the problem at hands, it's also the near the best way to open a file on C# - second only to my counter-proposal, FileShare.Read (and by a very narrow margin, virtually negligible in Windows).

Given the results I got on these benchmarks, I recommend to everybody to always open files on C# using FileShare.Read when reading files.

Edited by Lisias
Link to comment
Share on other sites

  On 5/18/2023 at 7:48 AM, Lisias said:

The amount of memory between the systems are the same or the new rig has more memory? How faster are the disk access on the most powerful rig (m2 in the new, spinning disks on the old, perhaps)

Expand  

Memory is the same (64 gig), both systems have nvme.  New system is a new cpu, i13900k, old system was i9900k.  Memory is faster, and probably the nvme is a bit faster as well.

Link to comment
Share on other sites

  On 5/18/2023 at 12:29 PM, linuxgurugamer said:

Memory is the same (64 gig), both systems have nvme.  New system is a new cpu, i13900k, old system was i9900k.  Memory is faster, and probably the nvme is a bit faster as well.

Expand  

With this information, and the benchmarks I did last post, I'm inclined into believing that the problem may be affecting only Windows users.

If this is a KSP problem, then we have a file handler leakage but I failed to understand why a faster processor would be making this more prone to happen unless...

hummm...

I checked the i13900k specs and realized it is an asymmetric CPU! 8 pretty fast cores and 16 slower ones.

It's more like a hunch than anything else, and the FileShare stunt ended up working around the problem anyway, but I think you will get better overall game performance if you set Windows to run KSP only in the performance 8 cores (assuming you didn't did it yet), I remember a setting calling Affinity in which you tell Windows to use only a subset of the threads for a process.

KSP(1) predates a lot of new things as asymmetric cores and unless something on Windows is able to tell an application from a game automatically, KSP is probably spanning itself indiscriminately over different cores. And Unity (ab)using busy waits is probably not helping the situation, as we would have events being consumed slower than others depending what core the thing is frying at that moment.

There is some multithreading on KSP, and if the MM thread is fired on a fast core while the Assembler Loading thread is running on a slower one, then we have a race condition aggravated by the difference on the speeds of the cores.

The MM mitigation allows the thing to keep going (and, again, my benchmarks above suggests it should stay), but the asymmetric problem may be screwing up others things too - Unity relies reavily on spinlocks and I bet no one ever considered that some locks would be spinning faster than others.

I would like to suggest trying the "unmitigated" MM on the new rig setting the affinity to use only similar cores (a run using only the fastest ones, and another using only the slowest) to see if anything changes - not due this problem (it's already mitigated), but to check the asymmetric hypothesis.

If we have confirmation about asymmetric cores screwing up something, suddenly a lot of absolutely weird concurrency problems I'm detecting on the field have now a feasible explanation!

Edited by Lisias
Tyop!
Link to comment
Share on other sites

Hello! I'm trying to get a thing to parse, but it won't because it has a space in it. How would I get KSP to parse the literal?

@MODULE[ModuleB9PartSwitch]:HAS[#SwitcherDescription[Engine Config]]{

this crashes at [Engine .

Edited by eagleswing12
Link to comment
Share on other sites

  On 5/22/2023 at 7:15 PM, eagleswing12 said:

Hello! I'm trying to get a thing to parse, but it won't because it has a space in it. How would I get KSP to parse the literal?

@MODULE[ModuleB9PartSwitch]:HAS[#SwitcherDescription[Engine Config]]{

this crashes at [Engine .

Expand  

use a dot or a question mark (I don't remember which) to replace the space

Link to comment
Share on other sites

Hi, I'm trying to add Snacks Fresh Air support to some of the SSPX-R parts and could use a hand. Specifically I'm using the logic that if it has a soil recycler it should probably have an air scrubber, and to that end I more or less just copied the Snacks patch and modified variable names and numbers as made sense to me, as such:

  Reveal hidden contents

When I run the game with this added to the SSPXRSnacks patch (between the normal snacks stuff but before the Snacks Stress section) it does apply the stale air capacity to parts so I know I'm doing at least part of this correctly, but it doesn't seem to actually add the air scrubbing modules like I thought I had. If anyone can point me to what I'm doing wrong, I'd appreciate it. I figure once I get this right I can also add them to a few more parts from other mods that I'm using, but if anyone's already done more extensive Fresh Air support for more than just the modifications to the three base parts supported by the base mod addon, I'd also love to be pointed at that work so I don't have to clumsily duplicate it.

 

Edited by Maeamian
added details
Link to comment
Share on other sites

  On 5/24/2023 at 3:40 AM, Maeamian said:

Hi, I'm trying to add Snacks Fresh Air support to some of the SSPX-R parts and could use a hand. Specifically I'm using the logic that if it has a soil recycler it should probably have an air scrubber, and to that end I more or less just copied the Snacks patch and modified variable names and numbers as made sense to me, as such:

  Reveal hidden contents

When I run the game with this added to the SSPXRSnacks patch (between the normal snacks stuff but before the Snacks Stress section) it does apply the stale air capacity to parts so I know I'm doing at least part of this correctly, but it doesn't seem to actually add the air scrubbing modules like I thought I had. If anyone can point me to what I'm doing wrong, I'd appreciate it. I figure once I get this right I can also add them to a few more parts from other mods that I'm using, but if anyone's already done more extensive Fresh Air support for more than just the modifications to the three base parts supported by the base mod addon, I'd also love to be pointed at that work so I don't have to clumsily duplicate it.

 

Expand  

Can you post your module manager cache file?

Link to comment
Share on other sites

  On 5/24/2023 at 4:17 AM, Maeamian said:

I believe that I've got the right file (modulemanager.configcache from my game data folder) and it's at dropbox here

Expand  

It appears to have applied from what I can tell..

This is: sspx-greenhouse-25-1
 

  Quote

    

MODULE
        {
            name = AirScrubber
            ConverterName = Air Scrubber
            StartActionName = Start Air Scrubber
            StopActionName = Stop Air Scrubber
            AutoShutdown = false
            GeneratesHeat = false
            UseSpecialistBonus = false
            RecyclerCapacity = 2
            INPUT_RESOURCE
            {
                ResourceName = StaleAir
                Ratio = 0.000074
                FlowMode = ALL_VESSEL
            }
            INPUT_RESOURCE
            {
                ResourceName = ElectricCharge
                Ratio = 0.4
                FlowMode = STAGE_PRIORITY_FLOW
            }
            OUTPUT_RESOURCE
            {
                ResourceName = FreshAir
                Ratio = 0.0000296
                DumpExcess = false
                FlowMode = ALL_VESSEL
            }
        }

Expand  

Just checked sspx-greenhouse-375-1. It is applied, though the output looks weird, but it does appear to have multiplied right.

  Quote

        MODULE
        {
            name = AirScrubber
            ConverterName = Air Scrubber
            StartActionName = Start Air Scrubber
            StopActionName = Stop Air Scrubber
            AutoShutdown = false
            GeneratesHeat = false
            UseSpecialistBonus = false
            RecyclerCapacity = 3
            INPUT_RESOURCE
            {
                ResourceName = StaleAir
                Ratio = 0.000074
                FlowMode = ALL_VESSEL
            }
            INPUT_RESOURCE
            {
                ResourceName = ElectricCharge
                Ratio = 0.5
                FlowMode = STAGE_PRIORITY_FLOW
            }
            OUTPUT_RESOURCE
            {
                ResourceName = FreshAir
                Ratio = 4.44E-05
                DumpExcess = false
                FlowMode = ALL_VESSEL
            }
        }

Expand  

 

Edited by Nori
Link to comment
Share on other sites

  On 5/24/2023 at 4:31 AM, Nori said:

It appears to have applied from what I can tell..

This is: sspx-greenhouse-25-1
 

Just checked sspx-greenhouse-375-1. It is applied, though the output looks weird, but it does appear to have multiplied right.

 

Expand  

Huh! You're right, I just double checked the same cache and it does seem to have applied the module exactly as you pointed out, however when I loaded up those parts in the VAB just now they don't seem to have the 'Start Air Scrubber' button available, nor when I launch a new vehicle with one attached (screenshot for reference) or load an old one that already had one, any insight as to why this might be? Either way, thanks for taking the time, I didn't realize the config cache was where I could check results so you've helped a lot already in terms of my ability to double check things

Edited by Maeamian
added screenshot
Link to comment
Share on other sites

  On 5/24/2023 at 5:12 AM, Maeamian said:

Huh! You're right, I just double checked the same cache and it does seem to have applied the module exactly as you pointed out, however when I loaded up those parts in the VAB just now they don't seem to have the 'Start Air Scrubber' button available, nor when I launch a new vehicle with one attached (screenshot for reference) or load an old one that already had one, any insight as to why this might be? Either way, thanks for taking the time, I didn't realize the config cache was where I could check results so you've helped a lot already in terms of my ability to double check things

Expand  

Yeah the cache file is super helpful in tweaking CFGs and figuring out what works (or doesn't). Does the mk1 crew cabin or mk2 crew cabin have the air scrubber?

 

Hmm, I think I found your issue, maybe... I believe the MODULE should be "name = SnacksConverter" you have it as  "name = AirScrubber"

Link to comment
Share on other sites

  On 5/24/2023 at 5:40 AM, Nori said:

Yeah the cache file is super helpful in tweaking CFGs and figuring out what works (or doesn't). Does the mk1 crew cabin or mk2 crew cabin have the air scrubber?

 

Hmm, I think I found your issue, maybe... I believe the MODULE should be "name = SnacksConverter" you have it as  "name = AirScrubber"

Expand  

That seems to have been it! Thanks for your help!

For my own edification, I figured (obviously wrongly) that as long as your name was internally consistant you were fine, why does that make a difference?

Link to comment
Share on other sites

  On 5/24/2023 at 6:10 AM, Maeamian said:

That seems to have been it! Thanks for your help!

For my own edification, I figured (obviously wrongly) that as long as your name was internally consistant you were fine, why does that make a difference?

Expand  

The name in this case is calling the actual MODULE being used by the mod. For instance, you could have a EngineFX Module and you are defining a engine. Were you getting errors on start about not finding a module called AirScrubber? I suspect you were.

Link to comment
Share on other sites

  On 5/24/2023 at 6:26 AM, Nori said:

The name in this case is calling the actual MODULE being used by the mod. For instance, you could have a EngineFX Module and you are defining a engine. Were you getting errors on start about not finding a module called AirScrubber? I suspect you were.

Expand  

Oh I see! Because I'm relying on the Snacks mod to do the processing that I'm asking it to do I need to make sure that the name of the module is what the mod is looking for, the "It's fine if it's internally consistent" part is just the converter name part of it. Thank you again for taking the time!

Link to comment
Share on other sites

  On 5/24/2023 at 7:04 AM, Maeamian said:

Oh I see! Because I'm relying on the Snacks mod to do the processing that I'm asking it to do I need to make sure that the name of the module is what the mod is looking for, the "It's fine if it's internally consistent" part is just the converter name part of it. Thank you again for taking the time!

Expand  

Yep, converter name, start/stop action name can be whatever you want and it'll still work.  :)

Link to comment
Share on other sites

I need a bit of help.

There is a file included with the Magpie mod called:

MagpieMods\TU_Cfgs\StockConfigBAF.cfg (included in hidden section right below this):

  Reveal hidden contents

 

I need to be able to change a single line change line 587 from this:          

model = Squad/Parts/Utility/mk2DockingPort/model

        to this:            

model = Squad/Parts/Utility/mk2DockingPort/mk2Dockingport

Can anyone help me with this?

Thanks in advance

LGG

Link to comment
Share on other sites

@linuxgurugamer This will work. Target the instance number of the key for the edit:

@KSP_MODEL_SHADER[Stock_LessMetal]
{
	@model,189 = Squad/Parts/Utility/mk2DockingPort/mk2Dockingport
}

You may need to count for yourself and make absolutely sure.

  Reveal hidden contents

 

Link to comment
Share on other sites

  On 5/29/2023 at 10:00 PM, JadeOfMaar said:

@linuxgurugamer This will work. Target the instance number of the key for the edit:

@KSP_MODEL_SHADER[Stock_LessMetal]
{
	@model,189 = Squad/Parts/Utility/mk2DockingPort/mk2Dockingport
}

You may need to count for yourself and make absolutely sure.

  Reveal hidden contents

 

Expand  

Thanks.  

Is there any way to replace a specific value?  I'm just a bit concerned that the file may change (ie:  more lines added/removed/etc)

Edit:  The mod in question (Magpie Mods), probably won't, so my question is for any other mods

Edited by linuxgurugamer
Link to comment
Share on other sites

  On 5/18/2023 at 3:29 PM, Lisias said:

I remember a setting calling Affinity in which you tell Windows to use only a subset of the threads for a process.

Expand  

Intel's Thread Director tech and the windows scheduler should do that automatically.  If he's using Linux, it's more iffy, not sure how support for that chip is there.

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