phoenix_ca

Well I'm not having any super-lag when I place KSPI radiators now. Whether or not that was caused by your changes or something else is unknown, but...eh it works.

That's pretty much all I do. If it's green, full power. Yellow, a little less than max is possible. Red is serious problem land. Way, way, way easier to remember and think about than doing the math yourself, which is...vaguely described at best in current documentation.

This isn't covered in the documentation (or in this thread...) so time to ask: What exactly does the "threshold" setting do for visibility? Does it mean the resource will only be displayed if it reaches the Warning Level percentage? Or...something else. Because I'd expect it to change behaviour depending on the Monitoring Levels setting. Yeah. It could mean a few things now that I think of it. Which is annoying. Edit: Would you consider sharing those vectors? I'd like to make a bunch more icons and it'd save me a lot of time tracing. Derp. It's all in the template svg. Except for the box used for food and rocket parts. That's not in there.

He also said in a video that random component failures would be interesting, like engines flaming-out because of some simulated internal failure, or fuel pumps stopped working, or dishes not opening. Those are horrible ideas from a gameplay perspective, because all it would really do is make players hit "revert flight" more often.

Very simple config to prevent the toolbar texture from getting squished by ATM: AntennaRange.cfg ACTIVE_TEXTURE_MANAGER_CONFIG { folder = AntennaRange enabled = true OVERRIDES { AntennaRange/Textures/toolbarIcon { compress = true mipmaps = false scale = 1 max_size = 0 make_not_readable = true } } } Would be nice to see that packaged with the mod, until such a config gets packaged with ATM itself. Go poke them about it.

There are some issues in the KSPI code that haven't been fixed yet, but getting NaN entries for resources on KSPI parts seems to happen on occasion. Your best bet is to work around the problem by editing the value in your persistence file. (If you don't already, I highly suggest using Notepad++ on Windows, Geany on Linux, or TextMate 2 on OS X to do your editing. The persistence file is rather large and not something you want to step into without a program that at least supports decent folding.) Apparently, bad things happen when saving or switching scenes while at warp. Simple solution: Don't do it. Ever. Only save or change scenes when a ship is not using KSPI warp. More complex fix for your problem: Go into your persistence file and edit it. Alternately, you could use HyperEdit to undo the error in-game. I'd go with HyperEdit. Editing orbits via the persistence file is a serious pain in the ass.

I copied the post from the MSI IR page because it seemed more appropriate to bring the discussion here. Does that fixed DLL fix Interstellar radiators derping out and eating frames while placing them? I recall you mentioning discovering the issue when placing rads.

I'd love to see that. Seriously. I think it would be quite funny to watch as FAR...does its thing.

I certainly hope not. That'd be...painful.

I'm pretty sure that's handled by WarpPluginSettings.cfg . You could change the settings there, but I don't think you can get away with adding anything. Seems they are referencing values that are probably being used in the dll itself. As long as you add water to the atmosphere via /OpenResourceSystem/PlanetResourceData/atmosphericresourcedefinitions.cfg it should work. I think.

Shielded versions of the bays, pretty pretty please, for FAR players. >.>

O.o What sort of options?

I made a few configs and fixed some of the included ones. Some I found were creating mipmaps for GUI textures. Kinda bleck. And since github is a no-go it seems, I can't exactly do pull requests. So here's a zip. Two new ones for DPAI and notes plugins. Fixed: Kethane.cfg Nereid.cfg RCSBuildAid.cfg ThunderAerospace.cfg Created: NavyFish.cfg notes.cfg I'm guessing here, but possibly it's ATM mishandling normal maps for those parts. Have you checked that those parts have their normal maps declared in a configuration file? And if not, try making one. What would be useful beyond the output_log is also copypasta of the config file you're creating. It's possible you made an error.

First page, original post, this line: You ignored the warning, and the Kraken struck. Simple as that really. :/

"adding some randomization to the aerodynamic failure point" That sounds like the very same thing with the same result as I described. Maybe you're closer to what they meant, but I stand by my interpretation. Edit: And ferram seems to have covered the other reasons why even if my interpretation is wrong, it's still a bad idea.

While more realistic to add random failures, it is generally a very, very, very bad idea to add any mechanic to a game that solely punishes the player for an RNG outcome over which they have little control. It's very much a rage-quit inducing "feature" that can remove players from your fan base for good. Think about the problems random failures could create in more mundane situations. What if some player is returning to Kerbin with a design that has withstood many a reentry, at incredibly high speeds, and a randomized failure causes a wing to explode under relatively moderate conditions. Kerbals die, payloads are lost. The solution now in such a case would be to revert; previous to the rewrite of that particular bit of KSP there was no option other than going back to your quicksave and hoping it was in a reasonable place. Or alternately, random failures causing a rocket that performed very well in past suddenly breaking-up. This stuff happens enough already when dealing with payload changes and good ol' pilot error. Adding more entropy intentionally would just compound the problem, creating a situation where a player doesn't know for certain whether they were hit with just bad luck or bad design. One they can fix, the other they just hit revert and try again. But not knowing, and even suspecting that the deck may be stacked against you, so-to-speak, can be a massive downer for any player. Plainly, it's just not fun. Random failures sound more interesting than they really are, and in terms of effect, they would be equivalent to out-of-memory errors we already get with 32-bit KSP binaries, and provide just as much depth as those CTDs do.

Hey Sirkut, give us a speed control via tweakables AND in the servo control window? Yes, I'm all for that. Just like a waffle bar. I'm all over waffle bars. This. It's a text file. It'll compress REALLY well without even trying. And if you try...REALLY REALLY well.

It's extremely difficult to tell. You could try using FRAPS to record frame rate over time, then import the data to any spreadsheet editor and graph it. That would show the spikes better, as well as their frequency. Though what would really be more useful is the render time for each frame, but I can't recall what has that...maybe MSI Afterburner.

Thanks sirkut. I found myself with the same bug and 0.4 fixed it. This is fantastic for adding mods and fiddling with parts, trying to gauge memory usage.

Look through the past six pages or so. It's been discussed at length.

Absolutely nothing. Just many problems I created recently that make my head annoyed.

Try it and see.

Well, finally found a somewhat stable solution in Ubuntu 14.04 for playing KSP in sorta fullscreen. I say sorta because I do need to leave the topbar visible. Went into settings, disabled fullscreen, and set the resolution to the monitor's full width, and height minus 23px. (The height of the top bar determined with a screenshot and Gimp. WHY doesn't Gimp have a ruler tool? Goodness. I'm glad I subscribe for Adobe CC. Gimp is nowhere near what I'd need.) Set the Unity bar on the left to autohide and I'm good to go. Put the cursor on the left edge and I can easily launch stuff. Oh. The reason all this finagling was necessary is that every time I used KSP in fullscreen and just switched between workspaces, it'd flash the whole KSP screen a sort of purple (hmmm, maybe more fuchsia...yeah definitely fuchsia), and sometimes that glitch would stick. The mouse and menu buttons and all that would still work, but not being able to see any of it kinda hampered things. It looks like I'm going to have to try swapping the GRUB 2 loader onto the boot flagged partition though to try to get the backlight working. Maybe. Doubt it will. Unless that's BIOS. I honestly can't tell anymore. My brain is all messed-up between MBR and GUID syncing (goddamn Windows being goddamn anachronistic using MBR first instead of GUID) and all the other mess I had to fiddle with with a GParted live USB. O.o The other downside with Linux is there's a decent amount of artefacting. Nice big blocks of the screen will freeze for a few frames. It's really obvious that the screen is getting updated strangely. Not top-down for each frame, but in squares starting from the bottom left and moving up to the top right. I don't know if that's crappy drivers or crappy Unity rendering though. Hrmph. Maybe I'll work harder at stripping-down my Windows install of parts. Maybe. Damn thing crashes at the drop of the hat though. Edit: Welp. That was quick. I figured-out that the artefacts were being caused by Adaptive MSAA. So that seems to be a no-go for AMD users. Plain ol' MSAA works just fine though, and the screen renders correctly (top-down). sal, you might want to update your post. It's possible that AA for AMD users is actually within the realm of possibility now. Just not their fancy-shmancy advanced stuff.

TBH Capt. Hunt that's more of a Texture Replacer problem. Strictly speaking, this pack is...just a pack of textures to be used with it.

I see you rejigged your numbers to be in-line with ExPL. Or at least that's what I gather from your cfg to change the BahaPL parts. If so, yay!