Gotmachine

Members
  • Content Count

    239
  • Joined

  • Last visited

Community Reputation

328 Excellent

About Gotmachine

  • Rank
    Spacecraft Engineer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. That's much less relevant than what people usually think. No matter if you use 32 or 64 bit floating point precision, the distances in KSP are so huge that you have to adopt a floating origin system, and potentially even more complex implementations. It's a typical case of "if you're doing something special, you can't expect the simple generic solution to work".
  2. Yes. My main worries comes from the whole interstellar scope of the game. KSP 2 will have to deal with interstellar travel time scales. Meaning they will need to run the simulation at even higher timewarp factors than what is used in KSP 1. Timewarp is a huge technical constraint. In KSP1, almost every feature is either disabled, or doesn't work consistently when you timewarp and even more for inactive (unloaded) vessels. The few system that are actually somewhat handled in timewarp, like the resource system, the thermal system or commnet have a special, barebone or inconsistent (to not say broken) behaviour. Simulation algorithms that work consistently at varying, arbitrary time steps are orders of magnitude more complex. They require more processing, and they severely constraint what you can do. And no matter how smart that code is, there is the issue that the simulation entry variables aren't constant. The whole point of a discrete simulation is that you evaluate every external variable continuously, at an interval that is faster than a significant change in those variables. If you have, for example, an algorithm that depend on whether the vessel is in sunlight or in the shadow of body, you need to have at least a couple sampling points for each situations. At 100 000x and 50 ups, it mean a simulation step is done every ~30 min of real time. It's already a quite low "resolution", a lot of things can change wildly during 30 minutes. From my experience, the maximum time step that still work reasonably accurately is on the order of 1-2 minutes, which at 50 ups, correspond to a timewarp speed in the order of 5 000x And you can see that in KSP. Going from 1000x to 10000x is the threshold at which everything start working weirdly. Now, in stock KSP1, it doesn't matter much. First because almost every gameplay feature is only enabled in the physics, real time (4x timewarp max) bubble. Second because the few features that are actually enabled in non-physics warp (main example is the drills/ISRU/core heat system) are quite shallow, and simplistic enough so the inconsistencies don't matter much. But KSP2 apparently intend to have several core features for which that issue is applicable. They have mentioned the ability to run engines during timewarp/in the background. And there is the whole colony building thing with supply chains, ISRU, etc. Those are great ideas on paper. But by enlarging the scope of the game to interstellar timescales, and consequently to even higher timewarp speeds than KSP 1, IMO, they shoot themselves in the foot if they intended to make any non ultra simplistic and more or less physically accurate subsystem, like resource chains, thermals, comms, radiation, life support, or any time based game mechanism (science, scanners...) In KSP1 (or in KSP 1 mods), those features have tons of issues with timewarp, but the 100 000x limit still is more or less manageable. And on top of that, there is multiplayer, which add another huge range of constraints, although it will all depend on what is actually KSP 2 multiplayer. Since we've got zero information on that, I won't go into technical details about what those constraints could be, but they are potentially non-trivial as well. And finally, on a more conceptual level, and it is more my personal opinion than a technical issue, I have a problem with the whole interstellar aspect they are introducing. IMO, the core concept of KSP, what make it an unique game compared to all other "space" games is that it is a relatively accurate, and realistic physics sandbox. It is exactly in the sweet spot between a pure simulation (like Orbiter or MS Flight Simulator) and a "enjoyment focused" game. It has a few simplifications, like 2 bodies orbital physics, abstracted fuel types, less constraints on engine usage (throttle, ignitions...) for the sake of gameplay, but not much. By going into the realm of pure hypothetical, science fiction technologies, it breaks that fundamental contract. On a surface level it doesn't change much, but it make all the dimension of attempting to model the actual, known, physical challenges of space travel and exploration almost pointless. What's the point of a physically accurate thermal simulation if you introduce engines and energy sources of such magnitudes that they don't have an actual realistic solution in that regard ? What's the point of a communication network with a range system when you work on distances for which there is no realistic solution ? What's the point of a somewhat realistic ISRU/colony system when it is producing structures and technologies that are so enormous and advanced that all the current industrial capacity on earth couldn't do it ? What's the point of representing any current space technology or goals if we are put in the realm of science fiction after a few hours of gameplay ? Something that made me realize that is the interview with Nate Simpson and Scott Manley, where Scott Manley made the remark that SRBs can gimbal. Why would they care ? They are focused on the color of science fiction engines exhaust plumes that make SRBs an irrelevant and obsolete technology. That interstellar scope clashes fundamentally with anything we can relate in the current age of space exploration. They could have done everything they are doing but with staying in a single planetary system. There are tons of "near future" technologies they could have implemented, with actual real science and physics to back that. So yes, I'm not thrilled. I fear a lot of things will be very shallow, both because of the unrealistic interstellar scope, and because of the technical constraints. I fear they are trying to much to have "exciting" features, and that in the process they will both fail at making a good game and a good space exploration simulation that is appealing to people that have an interest in relatable, current space technologies, programs and prospects. It might be a better "wide audience" commercial strategy, and maybe they expect the modding scene to provide what they won't on that aspect. But on the other hand, all the (speculative) technical issues I talked about might get in the way of that. Modding is hard, it's time consuming and the difficulty increase exponentially when the features you're trying to implement have no solid ground in the base game. Future will tell.
  3. https://forum.kerbalspaceprogram.com/index.php?/topic/194258-large-info-dump/&do=findComment&comment=3793267
  4. Well, KSP isn't that bad. It just isn't programmed in an optimized way that scale well when there is a large amount of things in the game. And on the other hand, most of KSP systems try to be quite physically accurate, with varying degree of success, but that's one of the main reasons why they are so CPU intensive. A big issue in KSP is that almost everything is done in the main physics engine cycle, which has a fixed budget of 20ms (50 ups). KSP performance bottleneck mostly comes down from the fact a lot of things that aren't related, or needed, for physics are done in the physics cycle. It's like this because in Unity, it's the default, easy, fastest dev time way of doing it. But for a lot of the most CPU intensive simulation features of KSP, there is very little justification in having such a rapid 20 ms update cycle. KSP is not a game were there is a need for "instantaneous" interactions between everything, like in a FPS or a RTS. Introducing a separate custom loop that work on a larger timestep, lets say 100ms for example (and ideally on a separate thread) would allow to take out a good chunk of the CPU load from the physics loop. The resource system, the thermal system, the orbit solver, all that doesn't need to be on a tight update cycle. The only things that really require it are the aerodynamics and the control/thrust providing modules, because they directly interact with physics and need to react quickly to player inputs. It's indeed an area where Unity DOTS could provide a better infrastructure, as the "legacy" Unity gameobject system is firmly tied to the "standard" Unity update cycle. But it could be done without DOTS. Unity is a graphics engine that provide a "general purpose" game loop framework (and a ton of other features), but there is nothing preventing a developer to use it only partially and implement a more specialized system that better fit specific purposes. That's kinda what DOTS is about, to provide some less constrained tools for specific performance intensive applications that require a custom approach, without having to implement a completely from scratch custom solution. But a specialized game that require performance intensive computations has to implement custom solutions. You can't expect a general purpose framework made to fit any game from 2D platformers to 3D FPS to perform specialized tasks in an optimal fashion, and this is a valid point for every single game engine. An over the top example is Principia : it's a completely custom N-body engine written in C++ that interface with Unity and KSP, but implement a high performance, multithreaded chunk of code with it's own independent update cycle, made for a highly performance constrained specific feature. But don't underestimate the amount of work that is needed to make all those, and how complex those things are. One of my main worries for KSP2 is that instead of implementing high performance solutions, they dumb down some subsystems/features. Or worse, for the sake of their multiplayer or interstellar timescales ambitions, which add an order of magnitude of complexity for solving those issues.
  5. The performance difference between aero and space situations 100% comes from KSP in-house implementation of aerodynamics and thermodynamics, which are incredibly CPU hungry. It has indeed absolutely nothing to do with the physics engine that handle joints and rigid bodies. I could go on for hours. For example, every partmodule in the game is an isolated system that does it's own thing and consume a lot of resources to do so, and in a lot of cases, all partmodules of the same type on your vessel are doing a computation that could have been done once for the whole vessel. It also mean that a lot of things that are vessel wide can only be analyzed by querying all individual partmodules. But it's a very specific example, and maybe not the best one, since the PartModule model is also great because it allow a lot of flexibility and is dead easy to work with. But that's the general problem of KSP. A lot of core systems are built in a kinda "brute force" way, using the simplest implementation, usually the one that require the less work. There is very little consideration for performance at the heart of all those systems. And it shows. KSP has received a lot of "after the fact" micro-optimization, but there is so much you can do without starting from scratch. I'm not saying the physics engine isn't a bottleneck, it is. But there are a lot of low hanging fruits in everything else in KSP.
  6. There are probably people that are much more knowledgeable on the subject than me on the matter, but I don't think there is much to be gained from the unity engine. On the gameplay side, KSP isn't really a data intensive game. So while there is probably some ways to optimize a few things trough DOTS I don't see a major impact. Although it could be quite relevant for a few things, mainly rendering bodies (PQS system, terrain features...). As for addressing the current performance bottlenecks of KSP, people are usually focused on the physics engine, but the reality is that the physics processing barely account for a third of the CPU usage of KSP, and that proportion tend to go down with the part count. The part-count dependent lag actually mostly comes from huge inefficencies in the PartModule system and also from the thermal, aerodynamics and resource systems. So contrary to the PhysX engine that is very optimized, and actually multithreaded to an extent, there is a huge margin for optimization in the KSP specific core systems, and that just comes down to the skills and effort from the dev team, it has very little to do with Unity. PhysX is being updated from v3 to v4 in unity 2019.3, but that doesn't change much. If there is any performance improvement on that front, it's likely we will get it in KSP 1 too. Edit : I'm mostly talking about gameplay / performance here. Graphics is an entirely other matter, and I haven't got much to say about that. Edit2 : There is zero reasons to not update to the latest bleeding edge Unity versions while they're in development. Migrating to newer versions of Unity is quite easy and usually doesn't break anything.
  7. I agree with @mcwaffles2003 Such core systems are very hard to implement through mods, first because that mean hooking in a lot of places, and consequently because of inter-mod compatibility issues. While it's sometimes possible to extend the existing code, doing such deep modifications often require replacing the existing code. And even on the conceptual level, if you extend or alter the fundamental gameplay mechanics (ex : by introducing a funds system in a game that is designed to work without), you're almost certainly breaking the core assumptions that every other mod is built on. Which mean specific compatibility for each mod, which mean a never ending source of bugs, limitations and balance issues. I don't buy the "eventually, everyone converges on a single standard." argument. I've seen quite a lot of modding scenes, this absolutely NEVER happen. It can happen for modding tools (think ModuleManager or ContractConfigurator), but not for actual game altering core features. That's what such mods are usually in the "total conversion" class, which mean they are a closed ecosystem, independent from the base game and it's mods. Think RO/RP-1 for example. Edit : And also, side note : people seem very confident that KSP 2 will be the holy grail of modding. I certainly think they will implement a nice system for config modding (something like MM), perhaps even some sort of light scripting features. They will probably give us out of the box planet modding trough configs (something like Kopernicus) As for plugin developmement, I am quite skeptical. KSP 1 is one of the easiest game to mod, ever. The combination of it being an Unity game (which are intrinsically highly moddable because of C#), of the few hooks implemented by Squad, and of the relative simplicity of overall implementation make it quite an easy game to plug into. There is certainly some awkwardness here and there because of the uneven and complex dev history, but nothing too bad. But KSP2 will be a multiplayer game. Now, it all depend on how that multiplayer aspect is implemented, but if it is a real full client-server stack, this introduce quite a bit of complexity, especially regarding the implementation of complex core systems trough modding, like for example a funds system.
  8. There is nothing in that article that says that funds aren't a part of that "adventure mode". Everyone is loosing their excrements on pure speculation. I suggest people read the full transcript of that article before drawing any conclusion : https://forum.kerbalspaceprogram.com/index.php?/topic/194258-large-info-dump/&do=findComment&comment=3793267 If you ask me, that article was obviously written by someone that has never played KSP, and that barely know what he's talking about outside of what he's been told during that interview. There is actually very little factual information in that article. There is no mention anywhere that funds don't exists. The exact quotes are : Simpson says adventure mode has a lot in common with the first game's science mode, which gave you unlimited funds but made you earn science points to advance the tech tree. and a bit further : The campaign is "explicitly designed to be non-punitive" so you'll never reach a fail state where you've run out of money and have to start over. You can choose to interpret that as you wish, but to me there is only two facts here : - Adventure mode is different from what we have currently. We already know from Nate Simpson's mouth that it was "something in between current career and science modes", so nothing new. - You can't "loose" by running out of money. Frankly it's something really hard to do in KSP1 too, even as a brand new player. But it can imply that there is actually a currency in the game. The "which gave you unlimited funds but made you earn science points to advance the tech tree" part doesn't say anything in my opinion, it just describe what is KSP1 science mode, and is probably entirely a precision coming from the journalist, not related to anything in KSP2. The whole article is really elusive as how that adventure mode actually works. There is a mention of "making discoveries and unlocking new technologies", but not of an actual tech tree like we know it, or of science points like we know them. Then it says that these actions will trigger "boom events, which kick off various effects across your civilization". I'm not sure what to make of that. Regarding contracts, it says "The structure will include specific missions", which imply there will be some sort of mission system. Everything else is just talk about how some contracts in KSP1 felt grindy and not very good, and how they want to adress it, and I certainly agree with that. If you ask me to take a guess, my bet would be on a system based on some sort of "progression score" that you increase in many different ways (science, missions, achievements...), with no complex tech tree like we currently know, but just a few "tech tiers", and no science points. The complete exclusion of funds seems unlikely. It could work as a regular income based on that progression score, as well as being completed by some missions/contracts.
  9. It isn't said that funds don't exist. You (and other people) are doing a big interpretation on that specific point. The only factual information is "Simpson says adventure mode has a lot in common with the first game's science mode", which pretty much give no additional clue, especially since the last statement we heard in a previous interview was that it was a something different, in between career and science modes. The rest of the sentence explain what is KSP 1 science mode : "[...] first game's science mode, which gave you unlimited funds but made you earn science points to advance the tech tree" It isn't a statement from the developer, so I wouldn't read too much into it. It might be a way for the journalist to hint something, or not. Edit : Same for life support. What they mention is that bases will have greenhouses. There has been multiple mentions that those bases are handled more or less separately from vessels and have some sort of separate "colony management" aspect in regard to on site ISRU, vessel construction and kerbal "reproduction". That doesn't mean we will get life support on vessels, in fact, if I were to make a guess, I think all the ISRU system we currently know will be moved from "vessel parts" to that base system, with vessels providing a few "colony supplies" you will need to transport from the homeworld.
  10. GetWorldPos3D() return the position of the vessel CoM (it just return the Vessel.CoMD field), not the position of the vessel GO transform. As for the differences in various states, that is quite normal due to the floating origin system, the rotating/non rotating frame, the physics easing, etc There is zero guarantee that the absolute position of things will be the same for a given point in time. Not sure what you are trying to do in the first place, but as a general rule you can only compare relative positions.
  11. Any mod that use it's own attitude controller instead of the stock SAS will indeed not benefit from the craft reaction wheels (MechJeb, TCA, kOS...) Not sure how the RT flight manager does it, so I can't say for sure but it is probable that it will run into the same issue as those mods. So yep, try to use the stock SAS as much as possible.
  12. No, there is no way for the emitter module to know the state of another module. If you're willing to add code support from your partmodule, what you can do is find the emitter module on the part and set its "running" bool field depending on whatever conditions you see fit. See https://github.com/Kerbalism/Kerbalism/blob/master/src/Kerbalism/Modules/Emitter.cs This said, we are in the middle of some major changes regarding vessel-local radiation handling for the next major Kerbalism version. Maybe I could consider a way to define from configs a "module listener" for the emitter module.
  13. Well, something to point out : the "part physics is the major performance hit" statement is mostly a myth. This is the unity profiler results for a single frame for that 500+ parts vessel (without PrunePhysics) : (20 ms / 47.45ms ) * 60 fps = 25.28 fps Physics processing is in orange, we have : - Physics.SyncColliderTransform : 2.73 ms - Physics.Processing : 4.10 ms For a total of 6.83 ms, so less than 15 % of the total. In comparison : - FixedUpdate : 23.18 ms (48%) - Update : 7.17 ms (15%) Details of fixedupdate : Granted, that vessel has a lot of radiators used as decoration (grabbed a random craft from kerbalx). But the point is : the performance hit comes in large proportion from non-physics related things.
  14. I highly doubt this could bring any performance improvement, but would love to be proved wrong. So I did a silly test : added ".*" to the whitelist, loaded a 500 parts ship, saved, edited the save to change all 500 instances of "ModulePrunePhysics.PrunePhysics" to "True", reloaded the save. Tested in a fresh sandbox save, no mods, mid range hardware, in sun orbit, no celestial body in the screen Got a couple of unity "A joint can't connect the body to itself" errors on load, and the vessel indeed dislocated in a few places. But my point is : 25 fps with PrunePhsyics, 25 fps without. So I'm quite skeptical disabling a couple joints on the few parts that will end up whitelisted is gonna make any difference. And on the other hand, unless I'm mistaken, turning parts to physicless will have a significant impact on drag calcs accuracy.
  15. The issue is that Kerbalism introduce custom restrictions and situations, and the stock survey contracts aren't aware of those. This mean that a significant proportion of the contracts that are generated can't be done.