dueb

I just can't wait ! Full rewrite, physics, graphics, immersion, exploration, interstellar, colonies...to name a few !

Oh, ok! I was just guessing after a quick look at it (trying to be helpful ). Thanks for the links, I'll take a look at it when I'll get some free time (at least, to learn).

Maybe https://github.com/JonnyOThan/RasterPropMonitor/commit/33b12e6d91ce0df3a0140f8efe53fb1d558c8fcb ?

Yes, on older version of RPM (long time user), empty lines didn't display at all (i'm talking pre-KSP 1.3.x here). Something changed, but not the Resources page. So, that tells me that's something internal to RPM that changed. But as you said, "probably not worth the effort"... (Just wanted to report it.)

Sure: (as I said: it is a minor )

Hi! First, thanks for keeping this alive! I just wanted to report that the Resources page on stock MFDs looks broken (at least to me: stock 1.12.3 + RPM). But as it is a minor issue, I did't want to create a github issue just for that. But I would like to know: is it a known issue?

Ahah I guess... Updated for 1.8.1! Bulb : Issues / Downloads ElectricLights : Issues / Downloads Enjoy!

I'm glad I could help! Thank you @Lunaran!

@FreeThinker: I've sent a copy of the version 0.13 to @LunaranI had in my old installs folders (<0.90 I think?).

Thank you for the clarifications @blowfish!

Hi! So, I'm a bit rusty with ModuleManager... I have 3 questions: Let's say I have this key in a node: title = #autoLOC_501028 (I took the first one on this page ) From what I understood after reading several pages in this topic, because of the way KSP process theses localization keywords, and because ModuleManager comes AFTER KSP has processed theses localization keywords, I can't do things like this: @PART[*]:HAS[#title[#autoLOC_501028]] nor this: PART { name = myPart title = #autoLOC_501028 } (Can even ModuleManager not be confused by this character '#'? I doubt it.) Now, let's say I want to test if the last parameter of node_stack_whatever exist. Is this even possible? Again, I've read several pages of this topic and still don't have an answer. I know you can index them inside nodes (I saw several examples for curves values), but can you test them in a :HAS block? And if so, how? I've tried something like this but...yeah: @PART[*]:HAS[#node_stack_whatever[6,],#myAnnoyingSecondTest[*]] @PART[*]:HAS[#node_stack_whatever,6[>0],#myAnnoyingSecondTest[*]] I don't remember my third question... Thank you for reading!

So, I love ElectricLights so much that I took the liberty to update it for myself in the first place to KSP 1.7.3. But while doing so, I noticed some problems. Like this one: ...and I found myself refactoring the entire code to fix the issue. So, since this is not 'just a simple recompile' I made a fork and a repository on Github. I don't know if I'll find time to maintain this, so this is why I post in the original topic instead of creating a new topic. Also, I don't know how stable it is. It was stable enough for me in my tests, and for my use-case. (Let me know if you find any problem: you can report them on the github issues page). @Alshain: If you want me to remove this post/repo/download, please feel free to ask! Also, if you want to merge my changes into your repo, please do! I can submit you a PR if you want! So, anyway, here's the downloads for anyone who want to test it. Edit: I can't help myself: I did the same with Bulb. Issues here. And downloads here. Also, minor fixes for ElectricLights.

Yeah, this is exactly how I 'discovered' this (long standing, I presume) 'problem'. I asked myself: "Wait, what happen if I dock multiple ships in space (with their IVAs) with all theses props?". I understand the overhead. I'm not surprised, don't worry! Theses interactive props require processing power, that's a fact! What I don't understand however, is why the reported processor activity next to inexistent. Not a single CPU core is maxed out! This is really disturbing, because I can't track down where the bottleneck is. Any idea? (Btw, you hyped me even more for MAS! Keep up the good work! (I don't know if this is the right way to say that, forgive me if it sounds awkward... This is not my native language.))

I recently ran into a 'problem', and I don't know where's the best place to report it. So, if it is not, please forgive me. So, I noticed something (wrong?) while doing some testing: The props, or at least the ALCOR capsule, seems to have a huge impact on KSP performances. Maybe it is not a 'problem' (per say), (maybe it's that something you should expect from advanced props like that), but I think it is something worth to note. What I found strange in that 'problem' is that neither my CPU nor my GPU where used. But the ingame performance graph took a huge hit: A simple test can show that behavior and tank your game simulation speed (and FPS by going in IVA) by stacking some ALCOR capsule. Am I doing something wrong? Or is that an unavoidable behavior? Setup:

Glad you finally got this working! ALCOR monitors were never finished AFAIK. This is confusing: are you talking about the kOS terminals? Or the integrated ones on RPM monitors? Additionally, what is your operating system? Either way, I can't reproduce the exact same bug. There is known problems with keyboard inputs, but they are hard to tackle since they seems to be Unity/KSP 'bugs'. (More info on that, especially here.) The original Github is a good place for now (I saw your issue).

I've finally found some time to test with ModuleManager 3.0.1: it appears to be working with either 2.8.1 or 3.0.1! So, if you don't see "DPAI|kOS" at the top of your monitor's screens @bepsy3d, that mean that either you messed up the install or you have an other problem somewhere else... (Can't tell you much with so few informations)

No, it should be working without anything else to do after merging the GameData folder of the zip with you game's GameData folder (provided that you have installed the right dependencies). You should see on the top-right of your monitor screen a "kOS" page (shown as "DPAI|kOS"). Clicking it 2 times should switch to the kOS page. I think it's caused by the ModuleManager problem I was speaking earlier. I'll take a look later. For now, life is calling. ;-D

You're welcome On the RPM monitor, when you've selected the (kOS) processor you want to use (from the kOS screen page), you have to press the O 'key' on the RPM's prop monitor to toggle the keyboard input. (It doesn't make appear a kOS console per say.) But if it still doesn't work, then maybe the problem comes from the version of ModuleManager you're using. If that's the case, I'll take a look at it.

Alright! Here it is: kOSPropMonitor Recompiled for KSP v1.3.1 x64 (Compiled with RPM 0.29.2 and kOS 1.1.3.2) From my quick test it seems to work correctly (but remember I didn't touch anything: it's in the same state as it was in KSP 1.1.3). Something to keep in mind however is I did my test with ModuleManager 2.8.1, and I know that ModuleManager 3.0.x changed some things that could potentially affect the .cfgs of this mod. If there is any problem I may re-release a fixed version later. But for now I'm lacking time to test this. @dsonbill: About the take over, I would like to help you more on this, but as I said, I'm lacking time, and I'm pretty sure I'm lacking knowledge also to maintain this...

@bepsy3d: I can recompile it for you if you want (for KSP 1.3.1). Granted that @dsonbill is agree of course. I'm recompiling with the source code of the 1.5.0.1 version (for KSP 1.1.3).

That's so cool! Thank you so much @alexustas! (for ALL your great work!)

Thanks for this new release @katateochi! Reverse flowing resources are a great idea! I thought about it but didn't to go further... Anyway, I'm still working on it on my side (with my formatting, I'm sorry ). And if I come up with something, I'll submit you a PR if you want.

So, I did an other test for good measure, and got the NaN error (again ) while pumping two facing docking ports at the same time. But I think I tracked down the error this time: NaN errors comes from divisions by zero. And the only place where there is divisions in your code, is in the OnUpdate() function. tanks["available"].Count and tanks["required"].Count can be equals to 0. So there should checks here. But I can't dig more into it today... Anyway, if I do this, it's because I'm glad to help! Be sure of that!

PR submitted! Yeah, maybe I should redo this PR then... Give me some time, I'll send you an other one inline with your formatting. If I can, sure! I'll do it then! Edit: New PR submitted!

I fully understand KerbalX eats most of your time! Don't worry! About the recompile, I didn't changed anything code-wise: it's just some reformating. So that should not affect anything feature-wise. And since I have now a github account, sure: I'll submit you a PR, but as I said, I'm not sure you'll like the changes as I makes it a bit less readable. (Just some coding habits) For the joint venture, I'm not opposed to! But I have to admit that I'm lacking plugin writing knowledge for now... What I can do however, is to try to "fix" the plugin as KSP versions releases... (PS: I changed the download link since I noticed I messed up the folder name.)