Starman4308

The developers wouldn't think much of your suggestion because it is almost never needed, and tools already exist for the rare occasions that it does happen: reinstall, or have Steam validate local game files. Again, the overwhelming majority of the time when a modded game misbehaves, it's because of a mod... and we don't even have any logs to try to figure out what the problem might be. Also, Module Manager is not stock, it is a mod, one of the most widely used ones out there.

The Saturn V was truly a terrible paperweight, indeed. Way too heavy to be practical. It's almost as though there are multiple programming tools for multiple types of problem.

I thought ATM hadn't been updated since 1.0, since much of its functionality was rendered redundant by improvements to how KSP loaded textures.

Personally, I'd argue that for what it was meant for, Unity is an excellent engine. By limiting access to variables to the main thread, novice programmers don't wind up 10 feet under in synchronization issues. Unity might not be a high-performance engine, but for the tasks it was designed for, it is a good engine, because most of what it's intended for are mobile and indie games where the CPU wakes up for a couple hundred microseconds, yawns, registers the user input, moves a couple variables around, and goes back to sleep for another few milliseconds. I would prefer it were KSP on a higher-performance game engine, but I entirely understand why they chose Unity: it was free, had an extensive API, rigid-body dynamics were already implemented, and so Squad could get KSP off the ground quite quickly so we could get our rockets off the ground.

Please read the linked thread and follow the instructions there. It will be invaluable in debugging this. The only guess I have right now is that you either updated MechJeb to a version intended for KSP version 1.3, or updated KSP to version 1.3 without updating MechJeb.

Logs. Also, check if your mods are of the correct version for the version of KSP you are running.

Uninstall the 1.3 version and find a 1.2 version of the mod to install. Also:

Okay, it isn't Sigma Dimensions. I've finally tracked down what I think is causing it; it's the KSC Switcher configuration. For some reason, if you switch to "KSC Main"*, it's placed above where it should be with GPP, with the 3.2x config. *You don't start at "KSC Main", but rather at a launch site that is actually at ground level at the same spot.

Alright, thanks for that. I think the last time I used stock aero was the Great Souposphere of 0.25. I made at least one asparagus staged pancake abomination back in those days.

If the problem isn't a mod that isn't updated to 1.3, I'll eat my socks. If a stock game misbehaves, maybe it's time to either reinstall KSP, or, if you have Steam, have Steam validate the local files. If a modded game misbehaves... 95% of the time, it's either due to a mod or mis-installation of a mod.

My current guess is that you have way too much wing area forwards and too much mass to the back, leading to a dynamically unstable craft that wants to flip out at the slightest opportunity. For stability, you will want to move mass forwards and wings backwards. Granted, if you want to dogfight, you don't want it too stable; I think real-world fighter aircraft are generally speaking slightly dynamically unstable and require constant computerized input (fly-by-wire) to stay on a steady course. You can compensate somewhat with control surfaces, but until you're more confident as a pilot, I'd stick to dynamically stable craft, where center of pressure* is behind center of mass. *I think KSP in stock displays center of lift, which doesn't account for just drag of parts, and I'm pretty sure is an arbitrary distinction caused by KSP's stock aero model. Somebody who's played stock can correct me if I'm wrong.

I'll say this: this subforum has cured me of any insane desire to ever enter the IT field. To the OP: there was a reason why this thread was stickied, and labeled "READ FIRST". My suggestion: read it. In the vanishingly slim chance your problem isn't another out-of-date mod, there will be much more informative logs for debugging.

So far as I can tell, there are a few parallelized rigid-body dynamics solvers out there, but they haven't extensively penetrated into actual game software yet. Which is kinda funny, when a big part of rigid-body dynamics is avoiding penetration. As to why they aren't being used in current games, that's due to a few different things. #1: Only relatively recently did it become the case that consumer CPUs became multithreaded and GPUs used for anything but pixel-pushing. #2: It takes a long, long time for algorithms developed in academica to find their way into industrial/commercial code. For an example, free energy perturbation, despite being used for quite a while now, only recently started to get used in a serious fashion by the pharmaceutical industry. #3: Academic implementations of sophisticated algorithms tend not to lend themselves well to becoming a commercially viable API, something about "who cares about the code being clean, we need data to put in the grant, now get it finished so I can graduate you and get tenure". #4: Not many games call for rigid-body dynamics on the vast scale KSP does. Squad doesn't have the resources to write an OpenCL kernel for rigid-body dynamics working from primary literature; an organization like the people behind Unity might, but they just don't have many customers who need that sort of performance, so their current single-threaded CPU implementation is good enough. #5: The math can get ferociously complicated in a hurry, and whatever is difficult on single-threaded CPU codes is an endeavour to parallelize and a Herculean task to make work efficiently on a GPU... assuming it's even a problem that parallelizes in the first place.

Real reaction wheels or KSP ones? KSP wheels are magic torque machines that apply torque in the requested direction indefinitely. Real reaction wheels* spin up a wheel rotating in the opposite direction as you want to turn; you spin the wheel, the wheel spins you back. They quickly saturate when the wheels are spinning as fast as they can go, and are best thought of as devices for storing and releasing angular momentum. *There's another variant that deflects an already spinning wheel, but the net effect is similar.

Well, worst case, eventually you'll be on your own and can pursue this at your own pace. Assuming you go to a university*, most of them will probably have an astronomy club, and many of those probably will have ground their own mirrors as well. Plus, if you get a driver's license and your own vehicle at 16-17, you could drive yourself to that Stellafane class, assuming that's something you'd actually want to do. *Don't feel like a 4-year college/university is the only way to go, though; many people just straight up aren't suited to it, and might be better off either with a technical degree or trying to find a job straight out of high school.

Somehow, I just don't think he cares. I know I don't. Not everything has to be up-to-date passing fads. Back to the original topic: I haven't yet played on full RO, but I still suspect I would be tripping over myself switching back to stock: I've gotten so accustomed to adding a bit of RCS for ullage, ensuring I have enough solar panels and batteries for RemoteTech antennae, checking whether I have a cryogenic or storable propellant loaded, etc, that I'd probably wind up adding unnecessary parts to my vehicles because I forgot I didn't need them. And that's if I don't forget that no, I don't need quite that much delta-V...

Sorry to hear it didn't work out Augustus. It's not an easy project you got yourself into, and I find it plausible that something happened to the pitch after that long in storage to make it a bit more sticky. I wish you better luck when you try again; hopefully you'll have learned a fair bit from trying to get this mirror ground.

A workaround for that specific problem is TAC Fuel Balancer, but I don't know of anything for the general case you described.

A frequent cause for alt-F12 working is NVIDIA Shadowplay. You can use alt-Z to open its GUI, and rebind whatever it has alt-F12 set to. Also, CommNet, etc.

Video cards do physics calculations slower than CPUs do. They can just run thousands of physics calculations side-by-side. Now, this has two major consequences for KSP: #1: I'm not sure how rigid-body physics are usually handled, but it's possible that it's difficult to impossible to thread them. In that event, OpenCL physics acceleration is an outright no-go, because each individual CPU core is far more powerful than a GPU core. #2: Even if it's theoretically possible, threaded code is an absolute bear to write. Everything becomes more complicated when you have to worry about things like work balancing, cache synchronization and interference, and the typical languages for GPU programming (OpenCL, CUDA) are not known for ease of programming and productivity. The Unity engine on which KSP runs was chosen in part because it already had the rigid-body physics engine they would need; it's not a super-optimized engine, and it only runs on a single thread per vessel, but it existed. It runs reasonably well on small part count vessels, but really chugs once you get past a certain level. What doesn't help in the slightest is that the physics engine exhibits super-linear scaling; for N parts, it needs to do more than O(N) calculations. I can't right now say it's impossible, but I can say with reasonable confidence that it would be an enormous coding project to offload physics calculations to an OpenCL kernel, and I doubt Squad has the money to see that through.

In addition to the suggestions of keeping it lightweight, and of installing new mods as you feel something is lacking, there are a few mods that offer reasonable expansion to the game without requiring huge amounts of mental investment. Granted, I probably wouldn't install them yet, just when you start to want to do more things with your game. Alshain's list has the core quality-of-life mods, though Better Burn Time might be added to that list. The science part of stock gameplay has seemed lacking to me for a while: DMagic has a few good mods for that. His Orbital Science mod adds some new science parts, SCANSat helps you map out other planets, and I think he collaborates on Surface Experiment Pack*, which has fairly involved science projects. *That's a bit more heavy-weight than SCANSat or DMagic Orbital Science, as it basically requires Kerbal Inventory System and Kerbal Attachment System. If you're much of a programmer, kOS might be nice to get into, especially if you play with CommNet or RemoteTech a lot.

Please, please use mod versions compatible with your KSP version. We can't magically fix your installation when you are ignoring basic things like "check your versions". If you plan to revert to 1.2.2, revert all your 1.3 mods to their latest 1.2.2 versions (no, they are NOT backwards-compatible), and update all the mods that came before 1.2.2 to their latest 1.2.2 release. If you plan to go to 1.3, delete every single mod that is not yet up-to-date for 1.3. Then, and only then, come back. A few mods that do not have plugins (no .dll files) might work on later or earlier versions of KSP, assuming that they don't contain invalid fields in .cfg files. Those with plugins have a tiny, tiny chance of working with later versions, but that should not be assumed to even be a frequent event.

Did you remember to revert your mods back to 1.2.2 versions? There is no guaranteed forwards or backwards compatibility with mods. Overall, your mods are all over the place; OPM is on a version from 0.90, Filter Extensions and Distant Object Enhancement for 1.3... just please, go through your mods, and make sure they are all at the most recent version compatible with the intended version of KSP.

Please provide the actually useful logs and information. Also be aware that running mods compiled for 1.2 will cause errors in 1.3 and vice-versa.

In the limit of a completely rigid vehicle, no. All that matters for reaction wheels in rigid vehicles is how much torque they output and the craft's moment of inertia. Since KSP vessels are not completely rigid, I would avoid placing them anywhere too wobbly, but it's generally not an issue.