Thygrrr

The game runs like cheeks right now even on my i7-8068k, I don't consider the Xbox version even remotely playable, other than for a few basic launches. Just as I say they are going to have much better performance in KSP 2 than KSP 1, I also say we can't expect it to run 4x faster. And that means for consoles, to pass CERTIFICATION, the game still needs to run at a decent frame rate in most scenarios, especially in multi player because that service actually costs extra on most console platforms. The people behind star theory are known to make engines and games that are well-architected and scalable, but in one of the articles/videos, star theory literally said it's for "up to 4 friends". I'll try to find that video. Of course this is likely to change.

Capable yes, but it requires specific coding. GPU physics are generally for visual effects, not gameplay effects. But Unity 2019 supports them; especially with the DOTs stuff. So exploding stuff can be accelerated. Gameplay... not so much (even though that is also possible; getting the data out of the GPU back into the memory where the game runs is usually the hard part, hard being "it's slow").

There's some code that bugs out when you have no crew on your vehicle. It seems like it tries to always assume 1, but does a division by zero for the fertilizer calculation.

Probably 4 players max because of console computing power. Could but doesn't have to be unlocked for PC. I really hope this ships on PC first. That said, 4 players is PLENTY. I barely get two together for LunaMultiplayer.

This is not how any of those work. Nothing is simulated in one giant world, and for physics you need sub-milimeter precision or you will have to marry the Kraken. Floating point numbers ("floats") are 64 bits in memory and usually 80 bits in the FPU, you can do double precision ("doubles") at double that size if you need to, but most game physics systems work using single precision. This has nothing to do with the address space for useable memory, which generally is what x64 or 64bit refers to. IEEE 754 single precision floating point numbers as used in modern computers were 32 bits for over 30 years now, and they are great and practical pop for most purposes! As a rule of thumb, single precision floats are most precise from -1.0 to +1.0, but sufficient precision for game play purposes exists out to 10000.0 if you stretch things (physics bubbles in KSP1 are 10km across). Double goes to roundabout 10 decimal digits. However, you almost never need that high a precision close up, and at astronomical distances, you sure want much much more than 10Gm before stuff starts jittering wildly. The same goes for computer 3D graphics, which get very wobbly if you want objects of 1m or less to smoothly move and be displayed next to others that are 1000s of kilometers big. Sure, floating points numbers can express astronomically large numbers, but they are farther in between the higher they get, so a smooth 10m ball with a thousand vertices becomes a distorted mess when these vertices can only make jumps of 7m or more a couple AU away from the origin. So games like KSP use dual coordinate scales, aka floating origin, usually one at the 1000 kilometer scale and one at the meter scale (mind you, at the 1000k scale you still have a lot of precision at the low end, but it can't work with physics or detailed visual objects). And when you get close, you need to switch on your closeup version of the object (usually terrain). Then these two worlds are transformed and superimposed (KSP1 uses camera stacking, which actually is not easily available to KSP2 due to how the new Unity renderer works) to form one ILLUSION of a seamless world of astronomical size, yet full physical detail anywhere you go. The meter scale is precise down to 0.1mm, which for physics is just about good enough, the 1000k scale goes down to 10 cm before calculations begin to jitter noticeably, which is great for orbits. You can also work with double precision in game logic for the On Rails stuff, but in the graphics and physics stuff will need to be float, half, or even fixed precision (half and fixed usually just in shaders, including geometry shaders, where you only need a couple thousand subdivisions and GPUs treat floats a little differently anyway). For the remote star systems, I am sure they will just add a third layer of coordinates, probably in the 1Gm or 1Pm scale (in the ballpark of solar systems or light years, respectively) They could also make their virtual coordinate system be in double precision, but they would still need to create local floating origin bubbles to even illuminate and render the stuff in it, let alone move it in a physically convincing fashion. Now one of the nicest things about the new 2019 Unity is that it allows multiple physics scenes to be simulated at the same time. This is great for multiplayer but also for crafts that split up and need to be individually simulated for atmospheric entry. In KSP1, these would just get unloaded and then killed by the rails system. I have high hopes for boosters with Parachutes actually making it back down to the ground in KSP2, instead of getting destroyed when they are more than 5km out.

Oh jeez so sorry

I really like this mod, and it works well. What I think it could do better is not make the utility weights have a fully fledged control point in them... just make them dumb weights. :-)

Skybox exposure should be something to edit, too, but I think it is programmatically handled by the game when the camera enters an atmosphere.

Thanks, yes that's what I meant! And porting doesn't just mean copy paste run. It means copy paste adapt run, versus design create iterate run. Something to adapt would be the materials for a model, but those are just a few texture references and a shader reference. The model itself already has all the UVs unwrapped so all you need to touch about a model that was already working in unity 2019/KSP 1.8 is probably the import settings regarding scale and pick the appropriate materials for the render pipeline.

I really hope there is a career mode where financials are as important as science. Sandbox doesn't do it for me, neither does science mode! GIMME THEM FUNDS!!!

I am talkin about assets, sounds, models, textures. The stuff that REALLY takes long to get right in a quality mod. They are the same between engines. Code will need a near-full rewrite for sure, as will all part definitions because the vessel system will be a new one and Module Manager will likely be superseded by the Lua scripting system.

I think maybe it's not caused by Basic DeltaV but in 1.8.1 am seeing the following issues: - Basic Delta-V display stops working (entire mod seemingly disappears at some point of my gameplay), KSP's maneuver node display defaults to 100000.0m/s, warp to node stops working. - Occasional Crashes when entering VAB Edit: Reinstalling basic dV doesn't fix it for the ship in question, but the mod keeps sticking around, throwing exceptions however. [ERR 15:23:38.535] Exception handling event onDeltaVAppInfoItemsChanged in class StageGroup:System.NullReferenceException: Object reference not set to an instance of an object at KSP.UI.Screens.StageGroup.DeltaVCalcsCompleted () [0x0009f] in <9d71e4043e394d78a6cf9193ad011698>:0 at EventVoid.Fire () [0x00127] in <9d71e4043e394d78a6cf9193ad011698>:0 [EXC 15:23:38.536] NullReferenceException: Object reference not set to an instance of an object KSP.UI.Screens.StageGroup.DeltaVCalcsCompleted () (at <9d71e4043e394d78a6cf9193ad011698>:0) EventVoid.Fire () (at <9d71e4043e394d78a6cf9193ad011698>:0) UnityEngine.Debug:LogException(Exception) EventVoid:Fire() BasicDeltaV.<WaitForPanelRefresh>d__10:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) [ERR 15:23:38.536] Exception handling event onDeltaVAppInfoItemsChanged in class StageGroup:System.NullReferenceException: Object reference not set to an instance of an object at KSP.UI.Screens.StageGroup.DeltaVCalcsCompleted () [0x0009f] in <9d71e4043e394d78a6cf9193ad011698>:0 at EventVoid.Fire () [0x00127] in <9d71e4043e394d78a6cf9193ad011698>:0 [EXC 15:23:38.537] NullReferenceException: Object reference not set to an instance of an object KSP.UI.Screens.StageGroup.DeltaVCalcsCompleted () (at <9d71e4043e394d78a6cf9193ad011698>:0) EventVoid.Fire () (at <9d71e4043e394d78a6cf9193ad011698>:0) UnityEngine.Debug:LogException(Exception) EventVoid:Fire() BasicDeltaV.<WaitForPanelRefresh>d__10:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) [ERR 15:23:38.538] Exception handling event onDeltaVAppInfoItemsChanged in class StageGroup:System.NullReferenceException: Object reference not set to an instance of an object at KSP.UI.Screens.StageGroup.DeltaVCalcsCompleted () [0x0009f] in <9d71e4043e394d78a6cf9193ad011698>:0 at EventVoid.Fire () [0x00127] in <9d71e4043e394d78a6cf9193ad011698>:0 [EXC 15:23:38.538] NullReferenceException: Object reference not set to an instance of an object KSP.UI.Screens.StageGroup.DeltaVCalcsCompleted () (at <9d71e4043e394d78a6cf9193ad011698>:0) EventVoid.Fire () (at <9d71e4043e394d78a6cf9193ad011698>:0) UnityEngine.Debug:LogException(Exception) EventVoid:Fire() BasicDeltaV.<WaitForPanelRefresh>d__10:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) [ERR 15:23:38.538] Exception handling event onDeltaVAppInfoItemsChanged in class StageGroup:System.NullReferenceException: Object reference not set to an instance of an object at KSP.UI.Screens.StageGroup.DeltaVCalcsCompleted () [0x0009f] in <9d71e4043e394d78a6cf9193ad011698>:0 at EventVoid.Fire () [0x00127] in <9d71e4043e394d78a6cf9193ad011698>:0 [EXC 15:23:38.539] NullReferenceException: Object reference not set to an instance of an object KSP.UI.Screens.StageGroup.DeltaVCalcsCompleted () (at <9d71e4043e394d78a6cf9193ad011698>:0) EventVoid.Fire () (at <9d71e4043e394d78a6cf9193ad011698>:0) UnityEngine.Debug:LogException(Exception) EventVoid:Fire() BasicDeltaV.<WaitForPanelRefresh>d__10:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr)

Don't worry so much! Unity, especially the new 2019.3 Unity, has a way different internal architecture and much improved runtime. The physics system is entirely new (and was renewed at least twice over since the KSP 0.2) The original KSP architecture was for Unity 4.x, then upgraded to 5.x, which is ~3 generations past, written by someone who didn't know the scale that the game would have. The Engine usually isn't the problem with performance, it's your architecture and what you are trying to do with it. Also, Unity is becoming more and more Data-Oriented (with its new DOTS architecture that came from ECS, but now has DOTS-Audio, DOTS-Physics, etc.), which basically scales to better and better performance when many many objects are involved. The fact that KSP2 will have large colony structures is great. This is also again almost exclusively an architecture question, meaning you need a bunch of really clever code to make everything semi-physical while it is static, and then physical when impacted. This is specialist game developer work, and would be tremendously difficult to add to KSP1, same as with multiplayer. Architecture changes are usually expensive to build into an existing game, and with users of KSP1 feeling so entitled they are asking for KSP2 for free already, you can see how such an expensive change makes no economic sense in KSP1. However, for a new game by an experienced studio, this is an amazing opportunity to make things right. Now here are some reasons why Unity is GREAT for KSP2: - existing mods can quickly port their assets, animations and materials to KSP2. I cannot stress enough how important this is! It practically seeds the KSP2 mod pool to ~30-50% the size of KSP1s pool within mere weeks of the release. - same goes for UI layouts, textures, scenes, etc, even though the new game will also be moddable via Lua, which will probably do away with Module Manager and allow for much more intelligent "parts" without having to ship DLLs that are compiled against a specific version of the game - they can base the game and its calculations on the original calculations; even though they basically tore it all the way down, that is the way to go if you want a sequel that feels the same - Unity 2019 physics is really good, and it's kind of what people expect from KSP. - Unity 2019's new render pipelines are much more performant where shadow casting and physically based rendering (PBR) is required. We are already seeing some benefits of this in KSP 1.8.x - Ever since KSP moved to Unity 2019.2 I basically had no performance issues; most of them seemed to come from Garbage Collection. - Unity 2019 allows for different physics worlds and scenes, so that means it is in theory possible to keep simulating vessels in atmosphere while you switch to another vessel, even on rails. Again this is a change that is not feasible for KSP1, but I will eat my hat if KSP2 doesn't use this feature of the engine. Sources: - my experience as a long time game developer (25+ years), also with Unity, but also built my own engines, worked with UnrealEngine, etc. - newest Unity features in Unity 2019:

Just wanted to say that I love Strategia :-) It really adds a nice extra dimension to the game.

I have mad respect for you linuxguru, and hope you find some way to automate the build process for these mods with each new release, and then offload the testing effort to us here.

Strange, doesn't for me; but for Editor Extensions and Better Time Warp I needed to manually bring in the right dependencies, so... I'll try a bit more.

With the KURS camera not being available, does this at least work in 1.8.x? Probably requires a recompile against Unity 2019.2 ... CKAN doesn't even let me install, will try some other ways to get the mod. (binary releases on Github would be awesome, Linuxguru) EDIT: Spacedock seems to be down, another good reason to host releases on Github. Which I see you are already doing, but CKAN is trying to pull off of Spacedock's shoddy hoster.

The thing is, Lua is great for this and works at scale and performance. All the stuff that Module Manager does? Basically for free with Lua, and you can add code to change behaviours, not just data.

From what I understand, KSP2 multiplayer will be a friends experience, for up to four players. Time Warp has been ingeniously and intuitively solved ever since Dark Multiplayer (DMP), and you should seriously give Luna Multiplayer (LMP) a shot. As limited as these mods are, the experience of seeing other players, usually friends, fly missions in your game world is amazing. The orbits map is so much more alive! Competition is intrinsically constructive, because you want to out-do, not oust, your friends when you see them finishing contracts or placing shiny new Landers on Duna. As a long time game developer myself, I can also say that multiplayer is hard to add onto a game, but the architectural prerequisites needed for solid MP also make for a much more stable and moddable single player game, because it requires you to keep your data structures and stuff that affects your sim state in consistent locations. This is extra work is usually too much for small or inexperienced developers, and is a significant cost of change, which is why KSP1 never got multiplayer after it's release. star.theory however are very experienced! They're the people behind Planetary Annihilation and Monday Night Combat, and their Founder Jonathan Mavor is the technical genius behind Total Annihilation, Dungeon Siege and Supreme Commander - each a seminal game that pushed the technical envelope and was built with the future in mind. Moddable, extensible, large scale, and extremely robust. Re: Griefing - I assume ship controls will be lockable, which is easy to implement and done in several multiplayer mods already. Under this assumption, griefing at the very least requires you to design and build a mission, and fly it, rendezvous and all, to do any damage. This is not compatible with the griefer mindset, which is an instant gratification, destructive mindset.

I downloaded and installed the game.

There is a limit to the precision of the floating point numbers used that KSP utilizes to display dates. At some point, the precision will be very jittery and that will cause orbital calculations to go haywire. Onrails stuff will break once the seconds in the game are above 100000000000000 seconds, which is a crazy long time. 12 million kerbin years, give or take. Could happen 10x or 100x earlier, but at some point the precision will just still be good enough for the game to work.

Thank you for the clarifications, JPLRepo!

You could ask on the LMP discord for some live and hands-on support from the many players.

I have no idea then, very sorry.

Do you click on the little "Play" icon? Or just on the server name?