AetherGoddess

ya, so i went back through the RPM release and looked at how that's being done, and Mihara has remodeled (or at least reconfigured) the IVA space in order to get that working correctly. this is supported be the fact that the page on how to make a IVA that works with and without RPM suggests creating a separate IVA config and using MM to replace it at load-time. so it looks like even the "default basic multi function display" behavior requires more work then i am willing to put in. sorry about that.

I had to go back and look through the thread to figure out what you were talking about. it looks like you want to make sure the released pods can use RasterPropMonitor? unfortunately, it looks like Rover is doing his IVAs using an internal plug-in (unless i'm reading it wrong, hard to tell, at least i can't find anything that looks like IVA computer panel to me.) even worse, the RPM documentation looks like it need model elements and texture names as part of it's config ( i have no method of getting this, mainly because i can't be arsed to go and set up a modeling environment to disassemble the model files), and requires extensive configuration to set up the buttons, pages and programming for the computer. in short, it's a lot of work, and i can see why Rover asked for a pull request instead of an issue.

Hurray! thanks math teacher Sarah!

a PULL REQUEST is github speak for code submitted by a participant (i.e. you) to be pulled into a maintained project (i.e. Umbra space universe-o-stuff) by the original maintainer (i.e. Rover) without granting the first party full control over the source repository (i.e. "Here Errol, just run rampant over my code"). the most common usage is a fork-n-pull, where the first party forks (i.e. makes a private copy) the release, makes their changes, and then sends a pull request back to the maintainer with the code changes they want. if you don't code, this is not the thing you want. a GitHub request slang for Issues telling a maintainer about a thing you want or bug you've found, and lets them keep track of what's been done. if you have the skill to make the changes yourself, a pull is prefered, since the maintainer just has to review your code, and merge it, where as the issue requires the maintainer to write code and make things and such, and has to be balanced against all the other things that need doing.

this might be a totally unrelated thing, but most floating installations in the real world have their CoM below the waterline, since that means they are dynamically stable vs wave fronts.

i found this by mistake. in RemoteTech_Settings.cfg: GroundStations { STATION { Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc488 Name = Mission Control Latitude = -0.131331503391266 Longitude = -74.594841003418 Height = 75 Body = 1 Antennas { ANTENNA { Omni = 7.5E+07 } } } } so probably that.

i'm curious if you've done any testing with KSPiLITE. i'm anxious for Rover's updates, and i think i would like these changes in Wave's releases.

ya, i figured it would be in the "more trouble then it's worth" pile, given the assembly magic. maybe EVA assembly is something Kospy could be implementing as a more general solution. meh.

Ah! the perennial question: My answer over anyone who had any real contribution. who's the queen now?

Consider my additional tool</plug>

Two things you might try. First, make sure your mouse is pointing at the flat part on top of the Plyon. this is the attachment point, which is pretty far offset from the part itself. Second, use B&N to rotate in one direction, and Alt-B and Alt-N to rotate in another. Rover: i don't know how much work it would be, but you might consider adjusting the construction order to start with the front chassis, rather then the front fender, since it's much easier to feel how the orientation will end up on a big flat plane part, rather then a directional box part. i ran into the same thing, and at the time, KAS was super explody; i detonated at least 2 fenders trying to get them to just lie flat enough that i could build the thing.

the reactors don't have D/T in them anymore. do you have a source of Deuterium on the ship? Helium-3 is a byproduct of Deuterium and Tritium, or can be bred from Lithium. do you have lithium on the ship?

the problem with ScienceDefs.cfg is the ones that modify the default experiments or have other corruptions. the Squad science system does not behave well if there are certain assumptions that don't hold. Here's what i would do: get a craft into a good orbit where you can test this, quicksave with F5, test your experiement, and then remove ScienceDef.cfg one at a time, restarting and retesting to see if you can isolate which file is causing weirdness. the most common cause of weirdness is the Croud Sourced Science Logs, which replaces the default Squad ScienceDefs, so you might try replacing that file from the last update (or let steam verify cache)

pretty much. the aggressive version does a lot more to squish textures, but at the cost of some visual fidelity. if you get weirdness, then falling back to the basic will let you trade some ram back to the mods in order to get some pretty back in return.

in case anyone is interested, i wandered around Wikipedia and created some additional AI core names. AI_CORE_NAME { name = Data } AI_CORE_NAME { name = Cortana } AI_CORE_NAME { name = Siri } AI_CORE_NAME { name = SHODAN } AI_CORE_NAME { name = EDI } AI_CORE_NAME { name = CABAL } AI_CORE_NAME { name = VIKI } AI_CORE_NAME { name = Rosie } AI_CORE_NAME { name = Jane } AI_CORE_NAME { name = Wintermute } AI_CORE_NAME { name = Neuromancer } AI_CORE_NAME { name = Golem XIV } AI_CORE_NAME { name = Church } AI_CORE_NAME { name = ELOPe } AI_CORE_NAME { name = MARAX } AI_CORE_NAME { name = EPICAC } AI_CORE_NAME { name = Mark V. } AI_CORE_NAME { name = Bossy } AI_CORE_NAME { name = GENIE } AI_CORE_NAME { name = Frost } AI_CORE_NAME { name = HARLIE } AI_CORE_NAME { name = ARDNEH } AI_CORE_NAME { name = Moxon } AI_CORE_NAME { name = Shalmaneser } AI_CORE_NAME { name = WESCAC } AI_CORE_NAME { name = Shirka } AI_CORE_NAME { name = Millichrome } AI_CORE_NAME { name = LEVIN } AI_CORE_NAME { name = Logris } AI_CORE_NAME { name = Deep Winter } AI_CORE_NAME { name = Endless Summer } AI_CORE_NAME { name = Archos } AI_CORE_NAME { name = EMERAC } AI_CORE_NAME { name = ARIIA } AI_CORE_NAME { name = Executive } AI_CORE_NAME { name = Dreamer } AI_CORE_NAME { name = ARDVARC } AI_CORE_NAME { name = C.O.R.A. } AI_CORE_NAME { name = Eunomia } AI_CORE_NAME { name = Ada } AI_CORE_NAME { name = J.H. Eden }

all of the cached textures are stored in "[...]\Kerbal Space Program\GameData\ActiveTextureManagement\textureCache". when you delete the ATM folder, it should clean up the cache. it's always a good idea to prune that cache whenever you remove mods or do a major update.

eureka's are intended to be slow. this is a long term space experiment, not something that you can read gauge and go home. you can always add more labs.

ya, even the newest KAS is still kinda explody. haven't heard anything on that. just be VERY careful, only unload parts parts when you're ready to use them, and attach them with the "store" option as quickly as possible. everything seems stable once it's attached to the frame.

Ya, so this is a real issue with tweakscale, because scaling one part in necessarily scaling one and only part, you get a linear-esk curve of performance which doesn't look like the "real" counterbalanced S-curve-like performance curves you'd expect from scaling up a thing: REF: https://what-if.xkcd.com/21/ but there is another trade-off. the "real" scaling has memory, complexity and systems costs. each separate model is more texture ram, more costs to balance, more eccentricity to debug. where procedural rescaling means something like Procedural Fairings can do everything from 62 CM to 5 M diameters from 1 M to 200 M in length, in 5 or 6 parts, you need something like 30 or 40 parts to do it statically. such is the costs of building spaceships like legos; legos aren't like real engineering. who would play with legos if they were made out of steel and required welding equipment? you're trading off "real-ness" for game play, because real engineering is very hard and isn't much fun. ask the mars climate orbiter team.

the frame rate issue you are seeing is due to the fact that the physics system in KSP is single threaded, and with lots of interacting parts, the work for any given frame is increased and that eventually becomes the limiting factor on how many frames per second can be rendered, but it has nothing to do with memory. This mod will help you run more mods and have access to more types of parts by reducing the memory required for the texture for each type of part. you probably want to make it easier on the physics system by keeping the part count low.

please allow the guy generously providing the awesome manage his own posts in the way he likes. wheaton's law applies, here, as everywhere.

if you don't know how you are starting KSP, then you are probably using the 32 bit, which is x86 (because of vararies you don't care about, x86 has come to mean 32-bit processors).

long and short: if you start KSP from the KSP.EXE, use the 32 bit. if you use KSP_x64.exe, use the 64 bit. the different bitiness refers to the word size of the program. most modern chips run x64 faster and better, but Unity is kinda full of bees when running in x64 mode. for more info, consider , esp starting around 1:00

Strangely enough, i'm having the opposite reaction. The more i watch the KSPi updates, the less and less i am interested in the "complicated" version. Radiation belts are interesting, but certainly not worth all the complications fractal seems so excited about, new reactor system that's functionally indistinguishable from the previous reactor system, colored plasma jets? it seems like gameplay is being lost in all the minutia.

REALLY? i JUST downloaded this for the first time less then an hour ago. you really need to stop being so prolific and awesome. the rest of us are on a the red queen's treadmill trying to keep up with you.