phoenix_ca

True. As I said, some comments on that article indicate that the new constraint solver is actually making much better use of CPU cores when not using GPU acceleration at all. It might come to KSP eventually. It's not a frivolous extra-pretty effect but part of the core gameplay. Keep in mind that it is a hybrid GPU/CPU solution at the moment, and you can actually take the GPU out of the equation entirely. No GPU acceleration then, but as the article makes clear, the main benefits of the GPU acceleration come only when dealing with many thousands of objects. With the object counts we're taking about in KSP, the CPU may still reign supreme. Also the biggest reason that PhysX and the like have typically been relegated to only pretty-fluff is because those are the easiest to parallelise. If the objects don't have to interact with each other, just with one other object (e.g. a player) then the whole problem gets a hell of a lot simpler and sticking it on a GPU. Think of it this way: With huge object counts (many thousands) in a scene, it's much easier to break the scene down into smaller chunks to work on. The objects that are interacting directly with each other may still need to be calculated linearly, but you can run those linear operations in parallel between those chunks. With smaller object counts, the benefit of this disappears, hence why GRB sees little to no benefit at smaller object counts. As for it being Nvidia-specific, I don't think that'll last forever. If everyone else can figure-out that this won't be as viable for games, Nvidia can too. It's possible they might decide to leverage Vulkan's compute support in future (or at least DX12's, but again with the way the market is going, especially with Steam OS, I'd bet on Vulkan) to make it cross-platform. The important thing is that they have a solution, which is the hardest part of the problem. Porting it is tricky but probably doable. Depends on what objects you're talking about. Synced physics-based object destruction between players in multiplayer games is something that's being worked on. I can't recall which game that was for though right now. Battlefield-something probably. There are a lot of other animations in KSP. Like a lot a lot. Without PhysX GRB, no, all the graphics card is doing in KSP is pumping-out frames. All of the physics calculations are still done on the CPU. Erm...what? Are you talking about GPU-accelerated PhysX effects? Does KSP even use any of those? I'm pretty sure it doesn't.

To expand on this (since no one has really pinpointed where the problems are), the reason, as I understand it, that KSP is CPU-bound so heavily is because it depends on rigid-body physics simulation for most part interactions. (The devs made a lot of improvements early on in smartly removing any parts from these interactions that didn't absolutely have to be included.) PhysX 2.whatever.the.heck.it.was did all rigid-body simulation on a single thread. This was what we were stuck with while KSP was using Unity 4. Enter Unity 5, and we get an upgrade to PhysX 3.3, which by default parallelizes rigid-body simulation. Undoubtedly with some backend fiddling on Squad's part, this led to the holy-crap jaw-dropping performance increase with KSP 1.1 with larger part counts in a scene. In a little bit of even better "woo hoo!" news, Nvidia announced PhysX GRB (GPU Rigid-Body), which allows a hybrid GPU/CPU distribution of physics calculations. Undoubtedly, being able to leverage a user's GPU will see absolutely massive performance increases for games that depend heavily on rigid-body physics. The downside is that it's coming with PhysX 3.4, and there really isn't any telling when that'll get incorporated into Unity. Hopefully, it will be, and maybe KSP performance will see another increase as we just saw with 1.1. Not really Unity's fault either. PhysX is Nvidia's department. That said, this particular problem (how to do a rigid-body physics simulation with parallel operations) was a really tough nut to crack. There are several years of really heavy (and cool!) maths and theory that had to be figured-out by some extremely intelligent computer scientists (Nvidia has a fair number of articles published on just this problem, or parts of it, in recent memory, going back to 2010 at least, IIRC) just to figure-out how to do this with more than one CPU core. But that's computer science for you. A great many problems don't lend themselves to parallelization well. Hardware engineers ran out of ways to make single cores faster (essentially), so they slapped more of them on one CPU and dared software engineers to program them. O.o Edit: I should probably make clear, that the above advice of "higher speeds, not more cores" is very good. Get a good heatsink. For now, your GPU is just there to make things look pretty. But the new solver (and other stuff) introduced in PhysX 3.4 is really, really, really exciting. Comments on the page I linked indicate it may even be doing a much better job of using multiple CPU cores. Long-term, I expect we'll see an end to the tyranny of CPU-bound physics. It'll just take a bit more time and some more really bright ideas.

It's not a mod conflict. I tested it with my clean install of KSP. The death spiral probably means you had the mode change set to manual. The engines switch to closed-cycle at 3km if left on automatic. @JPLRepo has already said he'll take a look at the Ranger's performance though.

It's okay. I have work too. Though it's not nearly as exciting as that.

I think I get what's going on now. I'll wait on that next release.

Consider this a humble request. It'd be awesome to have an option to include OPM.

The forum thread pointed-to by SpaceDock is out-of-date. Still points to the old thread (which is very annoying on mobile, having to click through twice >.< ).

Well, I lol'd. I'll still wait for @panarchist's answer but thanks; that's good to know.

The CLS modules aren't MM configs like your description suggests but actually part of the parts' config files. Was that intentional? (I'm trying to figure-out if CLS should be a hard dependency in CKAN or just recommended.)

This thread would be more appropriate. People have recently reported issues with using wine to run CKAN on Linux, and I believe they filed a bug report with the wine peeps themselves.

I too, can't get the darn thing to orbit. I mean hell, the open cycle mode flames-out at 3km high...that's a little...well. It's darned annoying, since in closed cycle TWR drops like a stone.

Neat. Gives me a few ideas for my own interplanetary ship that I intend to make eventually. (Though I'm kinda drooling over the Hermes from The Martian so it'll probably resemble that more.) I guess you're probably glad time dilation isn't a thing in KSP.

Historian-expanded doesn't seem to be updating for me properly. I've refreshed the modlist to no avail. And the correct metadata file is available, so I'm at a loss. Anyone else having this issue? The CKAN app is reporting that 1.2.4.12 is the latest version. O.o

I'm having the same problem. Exception Detector registers 10 throws/s while in the flight scene. This is on Windows 10, ARP 2.8.0.0. [EXC 01:45:24.331] KeyNotFoundException: The given key was not present in the dictionary. System.Collections.Generic.Dictionary`2[System.Int32,KSPAlternateResourcePanel.ARPResourceList].get_Item (Int32 key) KSPAlternateResourcePanel.KSPAlternateResourcePanel.RepeatingWorker () KSPPluginFramework.MonoBehaviourExtended.RepeatingWorkerWrapper () Also have the same issue with ARP not displaying any resources (though just like @Deimos Rast I can see that all the resources possible are listed in ARP's settings). I'm running a heavily modded setup (223 mods via CKAN). Are there any files I should provide to help? (Not sure what you mean by resource config.)

I know what you mean. I actually got sucked down a rabbit hole thinking new metadata files were supposed to be merged with the CKAN-meta repo. If you see any place for improvement on the wiki, I'm sure people would appreciate it.

Downloads for ckan.exe and netkan.exe are linked here in the "quick downloads" section: https://github.com/KSP-CKAN/CKAN/wiki/Adding-a-mod-to-the-CKAN

Not necessary. At all. I'm looking at that again and I think it was just tired ramblings. If I remember what I was actually thinking at the time I'll let you know.

Yeah...but that used freaking nuclear bombs. Thankfully, this research is focusing on nuclear reactors.

I think Arrowstar was saying earlier that for some specific mathematical reason the resources set had to be static. I might've interpreted that wrong though. As for consumption rates, keep a constant rate during a Coast, methinks (because if you're doing a rendezvous in-between you're probably going to use the tool to plan that too), and then perhaps just require the user to add a Mass Dump before the next maneuver, since that's when it matters. For convenience it might be nice if the Mass Dump event looked at the closest previous Coast and provided a button that would estimate the consumption of resources based on the time between the Mass Dump and the end of the previous Coast. You'll already have the consumption rate data and which resources were set once you look at the previous Coast event. Perhaps something to add to the respective maneuver UIs to help prevent user errors.

D'oh.

I saw that, and I actually started a pull request (and closed it for other reasons), but I'm (if someone disagrees by all means make a new PR) not keen on adding it again until the next major update. Not without a way to prompt the user with a warning about the fact that the next major update is going break everyone's ships. Especially since that warning is buried deep in the mod's thread and not on the first post. If there was a big warning on the first post, hey, caveat emptor. Unless there's a way with CKAN to block an update with a warning later. I haven't seen anything that suggests that capability in the spec.

@FreeThinker (or anyone else who can provide input): Arrowstar is going to be adding in the ability to rename and track more propellants/masses in KSP TOT. It's a big undertaking though and he asked me how many would be enough; you can see the conversation starting here: I figured six in total would be plenty for most applications, assuming both KSPI-E *and* TAC-LS. TAC-LS takes two, leaving four "buckets" for propellants (any propellant combinations could be converted by hand to fit in one slot, like LFO already is). If anyone can think of edge cases that come-up enough that more propellant tracking would be helpful, best get it done now, since once he's done it he won't want to do it yet again.

I don't want to send you on a wild goose chase. I run a very heavy mod setup with TAC-LS and KSPI-E which as far as new resources go are probably the worst offenders in this area, so-to-speak. I'll give that a long think and look at some possible designs and then count how many. It's going to be hard-coded, but how much more effort will it take do you think per resource? I assume that adding more resources will also add more overhead to the program and effect how long it takes to compute optimizations and the like. For TAC-LS, or any other life support mod I know of, all the resources tend to be used at once at a constant rate. So it should be possible to use a conversion table and only use two resources in TOT to track all six in TAC-LS' case. Leaving propulsion fuels. Those ones get dicey because sometimes you're using a combination of fuels but one of those in a combination is also used by something else. Spaceplanes are an example where LF and LFO get used depending on mode. Hm. I'd say at least four would be sufficient, plus two for life support. Ignore MKS' resources because that's just insane. I'll post in the KSPI-E forum and see if @FreeThinker would be willing to give some input here (or anyone else). Very tentatively, I'd say six would be enough. 7-8 if you're feeling generous and don't think it's too big a hurdle.

Aha. Now I understand. I may have to fiddle with things as a mission goes along but I expect that's actually par for the course when it comes to applying a mission plan. It sounds really helpful. Renaming resources would be really nice to keep things straight in one's head instead of having to take separate notes. But as for tracking life support stuff...that's where things might get dicey in practice. If you've only got three resources to toy with, then that only leaves one for propellant, and it's not uncommon to have two or three of those with mods like KSPI. Is faking-it an option? Add "custom resources" but on the back-end lump them in with dry mass? ... Sounds really kludgy to me now that I mention it. But if adding new resources is a hardship maybe that would be a workaround. Ish.

Hopefully I got the MM patch right and it's only removing TweakScale from the right things. As I said, no guarantees. It's an ugly bit of code because it's undoing a huge swath of changes. If MM could take directives to the effect of "don't add X module to any parts, and ignore any MM patches that do, except for patches that have Y in their model value", that'd be much cleaner and waste less time loading the game. As for Cact-Eye...good grief. I'll take a look at it later if someone else doesn't beat me to it (since I have to go to work soon and won't have time for several hours).