Gaalidas

Honestly, I find them both irritating. However, they're only irritating unless it's me who's reporting it. In those situations, it's completely valid. It's a bit like driving. When in the driver seat, everyone else on the road is automatically an idiot. That said, I'm not referring to anyone else posting here as an idiot... I'm just making a feeble attempt at correlating the current topic to a real-world scenario. I'm not sure if I succeeded or not, but it doesn't really matter anyway. I think the real feature request is for a toggle in addition to the in-flight auto-removal. I'd work on implementing something like that myself, but I'm unsure if the available source includes the current working version of that feature.

Or don't be patient and we'll have to track you down and land a flying car on your head. If it ever gets done that is...

Eesh! First they want to know why they can't place them "right-side-up" and now they want us to remove the arrows. Never happy! Gah! Yes, that's meant to be humorous. The possibility of you making a typo, lo-fi, is quite high. You made one in a config a while back and, despite letting you know about it and waiting several days, I had to go update the github myself just to get it fixed. At least you have a slightly OCD nutcase like me to look after your slip-ups. Yes, I am that awesome. Awesome rover by the way.

That's news to me. I use PNG for all of my mods (a batch file I run which extracts all archives in a "downloads" folder and scans for "MBM" or "TGA" files and converts them to PNG) and I have yet to experience anything not loading properly. TGA format has problems sometimes in the current loader. Perhaps that's what you were thinking of?

Now if only someone came along and created an override for the stock toolbar that would redirect everything into this one. I supposed you'd also need to be able to restrict the icon sizes from their loaded size to the size you use. hmmm... I could be on to something there.... ... no, I'm not. I have no clue how to do that. Oh well. I was a genius for a moment there, but the moment has passed.

At first I didn't notice the scroll bar next to your log in the post and was going to mention that I doubted the hall of fame for your awesome kerbal has anything to do with reflections... aside from the likely fact that this super amazing kerbal probably looks at himself in the mirror every morning and says, in whatever language kerbals communicate in, "I am awesome!" Let that be a lesson to you all. Scroll Bars are good.

or.... oh this one's really good... a secretive society of aliens!

I knew we couldn't have figured all that stuff out ourselves. It had to be either an advanced secretive society, or aliens.

Let us know what happens. And lo-fi, you gotta update the github with your recent updates. It's starting to get sad over lack of activity.

That is really weird, because I run in OpenGL mode and while the initial loading does have a few glitches (it's open, but shows my desktop instead for a few minutes before opening properly) it eventually fixes itself and runs perfectly, even on the RPM screens. UPDATE: And yes, to answer your question, I'm on a PC. a non-gaming laptop too, so that means sub-standard integrated graphics.

I'll say one thing in your favor... that concept image sure it pretty.

Don't worry about it, I don't understand what I'm trying to say half the time anyway.

I've noticed as well that in both editor environments the camera seems to still be locked to the default range of motion.

Are you quite sure about this little factoid? I run in OpenGL mode quite regularly and have had absolutely no trouble with the screens.

Llama attacks are a genuine possibility. Those things look pretty harmless, but every now and then you get one with a taste for blood.

Once you do an IVA, that large view area just begs for an RPM transparent pod setup.

Yeah, I've been looking at the new released of TweakScale and I definitely intend to look at making it more friendly towards free-scaling. I will be updating the file eventually once I get some of the new stuff figured out and redetermine the logical limits to scaling the different parts.

Yeah, I know, it's pretty nutty that I'd be so bugged about that one little textual thing, but as long as it takes KSP to actually go from the exiting process to actually disappearing from view, it just bugs me a ton while I wait. I want to yell at the monitor and say "you stupid program, you're not exiting in 5 seconds, you're exiting now dammit. There's got to be something wrong with my brain to explain it, but until then... thanks. I'll look forward to that. I suspect that it's all nailed down to the value of "i" in the "if" query that performs the "ExitNow()" function. I'm typing from memory here, so I'm probably not getting it exactly right. Anyway, looking forward to it.

That's interesting. That should lower the issues people have with orientation and whatnot as far as the repulsors are concerned. Better keep a version of the repulsors which don't work like that available for those of us who use them as braking cushions and/or an alternative to the inflatable airbag landing system. Crashing a pod covered in repulsors is really quite hilarious. - - - Updated - - - Those indicators should remove themselves upon launching the craft. Still, a toggle function should be made into the editor's context menu in the future I'd think. - - - Updated - - - So, how's the Homeworld marathon going? I can't really afford to buy it again just yet, but I do eventually plan on doing so.

No no no, you're taking it too far. The only thing that bugs me is that before exiting, the count returns to display 5 instead of staying at 0. It still works exactly the way it's expected, it's just that it displays a 5 instead of a 0 while exiting. I know, it's so stupidly simple that it shouldn't bother me. I'm weird that way.

SharpDevelop has a lot in common with Visual Studio, and so far (at least as far as most of the recompiles I've done for experimental stuff) it has proved to be sufficient. I used the project files received with the source, just had to redirect the references to their local paths. It is, however, quite possible that there's a reference or targeted framework mismatch somewhere. I'm still too new at this to even know what the heck I'm saying right now. As an experiment, I have temporarily extracted the code used to make the transparent pod work and created a new project in which I referenced the RPM plugin and I'm going to see if I can get just that code to work right with the precompiled build from the download. That will, at least, tell me if I'm totally unable to build for KSP or not. I suspect this will work though, as long as I wrote my MM patch properly, considering I've collaborated on the Kerbal Foundries project and successfully compiled and run several builds before. Really frustrating though. UPDATE: And... success. So, I can compile new mods for KSP without issues, it's just something about the rest of the RPM mod that is acting screwy for me. So, a little update on what I did with the original code just in case you decide to roll it in to a real update. Under the KSPField definitions I added a new field: [KSPField] public bool disableInEditor;And then I added this to the "public override void OnStart(StartState state)" function: if (HighLogic.LoadedSceneIsEditor && Equals(disableInEditor, true)) return;which basically just skips the rest of the transparent pod code if you're in the editor AND the "disableInEditor" bool comes out as true. It defaults to false. In this way, the author of the pod (or the user along with an MM patch or a cfg edit) can choose whether or not editor performance is an issue. I've found that cockpits with simpler setups and a single window transform operate with very few issues, but pods that have several window transforms and a lot of props that have RPM functionality in them (such as the ASET ERS rover) make editing a real chore. To edit all the pods I have installed with the new parameter, I simply made an MM patch that searched for all the pods with that module in them and added the "disableInEditor = true" line to them. No failed functionality on the rest of the pod so far as I can see.

Did I scare everyone away? Dang I'm good.

Yeah, that's probably the culprit. I found that one out the hard way too when I started minimizing my local memory footprint.

Hey, one small thing that's been bugging me about QuickExit... when the countdown finishes it displays something to the tune of "will exit in 5 seconds" instead of what i would expect, which would be something along the lines of "exiting..." or "will exit in 0 seconds." I attempted to make an adjustment myself and recompile, but, as I've been discovering recently, some mods simply cannot be recompiled by me without the whole thing breaking. As it turned out, the build was a success but the functionality was not... the button stopped showing on the toolbar and it produced an exception on load. So, I'm appealing to the author to help me regain my sanity over this little visual issue that would probably not bother anyone else with a normal brain structure.

So, from the looks of it, my attempt at recompiling RPM with my little addition that I wrote about a while back was a fail. The effect that I was going for was a success, in fact it was a pretty good success... but in the process it seems that half of the functions in reference to certain buttons and such get broken and produce exceptions in the log when the DLL is processed. This doesn't happen with your compiles. So yeah... I can't do it right apparently.