Search the Community

Hello, I'm trying to use KSP with Nvidia Surround across 3840x1080 resolution. It's working but I'm trying to do what the mod below, does. I can set the resolution to 1920x1080 in game, and it still uses multiple monitors with black areas on the sides, which is what I want. But it centers it between two monitors, I'm wondering if I can adjust the drawing area position to X=0, Y=0, starting from top left, leaving all the second monitor completely blank. So I can move some stat windows there like mechjeb, final frontier etc. Anybody know which line of code to edit or add to the settings.cfg?

All right, so many of us have watched the 2015/3/24 Squadcast and seen what the current state of the game is re: multithreaded PhysX. As is known, Unity 5's PhysX 3 implementation allows for multiple physics threads. The discussions happening on this board for the past several months have been about whether there was a possibility that single vessels could be spread across threads, and the general consensus was that no, they could not. The squadcast pretty much confirmed this; single vessels are indeed individual threads, and new threads are spawned when vessels undergo separation in the flight scene. It also showed a major problem with this: complete game freeze while the (new) threads are prepared. On KasperVld's not-junk gaming laptop a 650-ish vessel was split into a rocket and launch tower, and took 45 seconds to prepare and spawn the new threads. Another significant freeze of 15 seconds was also encountered on booster separation. Further staging events (what I would call "reasonable" part counts) showed no noticeable freezes. Now, the vessel being shown is pretty excessive, and Kasp is on a laptop. But his laptop is a powerful gaming laptop, and even small freezes during gameplay are quite immersion-breaking. Especially on less-powerful older systems that many of us may have. So - we who are not the developers, how do we think they should approach fixing this, and how can they? I have three different thoughts on the matter, but I'm not really knowledgeable about multithreading, or about Unity/PhysX thread handling in particular. But here goes: Code cleanup. Don't worry guys, it'll get better. Just wait. It could be simply that the current state is running in a non-optimized manner for pre-release, and small things will be done to speed up this simulation step. I don't have high hopes for this, at least for the 1.1 release; after all, they've been workng on the Unity 5 port for nearly a year, and I'd expect low-hanging fruit to be picked by now. But one can always hope. Delay thread splitting. I'm sorry PhysX, I'm kinda busy right now. Vessels are running just fine on a single thread prior to a staging event, and from experience, we know that KSP vessels run just fine on a single thread after staging events, too. It may be possible to prevent PhysX from splitting the objects into separate threads immediately and wait until we have more time to let it happen. Figuring out when that good time is, however, is another problem. But once vessels are in space and no longer thrusting or under atmospheric forces things are much less time-sensitive and we can better afford to be inconvenienced by this. Pre-stage threads for separated vessels. I can see the future. Trust me. The problem with trying to split a single vessel across threads is that information has to be shared in two directions between threads, which is slow and cumbersome. Also, if a vessel can break up in an arbitrary manner, there is no way to predict the best way to split the parts up. However, we have an ace up our sleeve here - the staging list is well-defined. We know which parts will go to which threads beforehand. It may be possible to prepare these threads while the stage prior is active, and only have to copy the state of the appropriate part nodes to them rather than having to stop and wait while the new threads are created from scratch. We don't need to worry about two-way communication for this; the child threads are strictly slaves to the previous stage thread. Ideally we only have to do this for the next staging event if these threads can be created in the background. Now, as I stated before, I know very little about multithreading besides what's been discussed on this forum, and next to nothing about PhysX, so what I'm suggesting may be completely impossible. It's also possible that some of this is already happening and the process is just that slow. But I'd sure like to hear the thoughts of those of you more knowledgeable than me! Because while the vessels I saw in the Squadcast are excessively large and complex, the freezes are a little scary. And if there's anything that can be done to mitigate that, even if it's a little more processor intensive, it would make me very happy. TL;DR: Staging can freeze the game. Can it be fixed? I'd rather have a slowdown than a freeze.