Gotmachine

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

I've never seen a null entry in FlightGlobals.Vessels But yup, beside asteroids, it also have all debris, flags, breaking grounds surface parts, etc...

@Silent1_87@Athur Dent@angelatthetomb Just released 3.7, with a fix to the antenna ec consumption : https://github.com/Kerbalism/Kerbalism/releases/tag/3.7 Should be available on CKAN shortly.

Ha, so people actually *do* read the wiki I did a bit of fixing, but that will be for next release. I usually update the wiki as soon as I do something because otherwise I have a tendency to forget about it. Kerbalism is very far from what it could ideally be. At least that's my personal opinion. My immediate plans are the habitat/pressure system rewrite. Also as @Sir Mortimer said, we have some very cool parts in the pipeline, and some new radiation related features. Some kind of heat management system is also on the table, but probably not for next update. The rates were very wrong, probably since quite some time. Specifically, the "TransmitterPassiveEcFactor" that you can set in the Settings.cfg file was applied twice. Since it is normally set to 0.2, the effective factor was 0.2*0.2 = 0.04, so EC rates were five times less. But I fear that this bug has been here for so long that the configs have been balanced against it. In the meantime, you can adjust it to 0.04 by editing the Settings.cfg file, which shoudl probably be the new default value.

@Beetlecat It's likely that it will cause issues, but maybe not. I never tested it. If you want to try, let us know if it works or not.

@Atlessa You need to use the fixed, non deployable antennas (the RA-X). But also, yes, some experiments require big hard drives, which you get further in the tech tree (base drive sizes get upgraded).

It's antenna part info hack override the Kerbalism one, and doesn't work because it round values. And it's antenna EC consumption thing also conflict with Kerbalism handling of antennas EC. You can put fixed antennas in a fairing or in a cargo bay, they should work. That's how it's done IRL.

Yes it is supposed to. You don't need water storage. Set the H2/O2 fuel cell to "dump" water (there is a button for that in the PAW).

@grrrnet I'm not very familiar with FMRS, but judging by how it operates there is a high chance of it causing issues with Kerbalism. Using it to recover stages / vessels at KSC might maybe work. But using the feature that patch back a staged vessel into your main save has a very high chance of failing quite hard. In any case, I'm 100 % sure that any file/sample that you would have stored on a staged vessel drive patched back to the main save would be lost.

Quoting myself : And later : There are indeed several candidates for processes already present in Kerbalism that could be changed to require a coolant input : exothermic chemical converters, nuclear reactors, drills, some experiments... Eventually liquid hydrogen tanks from mods. As I said, it's something I consider quite high priority, but there are other even more pressing matters, like rewriting the habitat / pressure system.

And that's exactly the problem. Our current solutions and workarounds aren't good enough, solar panels handling is very far from reliable at high timewarp speeds. The real solution is quite complex to implement, may come at some point but not on the table currently. I'm basing what I'm saying on an previous implementation that wasn't merged into Kerbalism because it proved that : - Having a reliable environment dependent thermal evaluation isn't possible without the above mentioned solution. - The gameplay consequences of that unreliability are much more visible and problematic than for solar panels - It is very hard to plan for the radiator capacity needed since the needs and outputs will vary widely depending on where your vessel is There was a lot of discussion, work and playtesting that was done at the time, and the conclusion was that this realistic implementation (which wasn't far from what you propose) wasn't desirable. See https://github.com/ShotgunNinja/Kerbalism/pull/105 and https://github.com/ShotgunNinja/Kerbalism/issues/83#issuecomment-293413231 And yup that previous implementation actually had a tweakable coolant temperature for better efficiency at the cost of higher EC cost (compressors). This is something that could still be part of a different implementation. As well as scaling output with the sun distance, and radiator orientation. All other environmental conditions (sunlight/shadow, albedo flux and body flux) are too unreliable to be used.

@Dragon01 A thermal control system is one of the things I wish to implement since quite some time. See https://github.com/Kerbalism/Kerbalism/issues/383 One of the reasons it hasn't been done yet is that there are some technical difficulties with doing what you describe : having radiator output being based on the external conditions (sunlight, temperature...). This is very problematic to handle at extreme timewarp speeds, like the the issues we have with solar panels output evaluation, but even more complex. So if that comes, the implementation will be quite simple : - Radiators produce "coolant" by consuming a bit of EC independently of the external conditions. - Some processes have a "coolant" input and won't run if that input isn't satisfied. Having a more complex system isn't desirable IMO. It would just add more complexity and micromanagement, we have enough of that as it is. This simple system have the following advantages : - It achieve the main goal : make radiators relevant - It is reliable technically - It is easy to make it auto-configured for all parts from mods and stock without having to create and maintain specific configs - It is easy and clear to plan for from a player POV : in the editor : check coolant/s needed -> add radiators in consequence - It still could be extended to have radiator coolant output vary with external conditions if we someday implement the technical stuff needed for that to work.

@Atlessa Try toggling the compatible KSP versions (under the settings menu of CKAN). Not sure why it happens but I've seen that issue before and that usually fixes it.

@mcwaffles2003 Something is making the Breaking Grounds DLC crash, very likely causing Kerbalism to crash too. [ERR 06:19:07.136] Exception loading ScenarioModule DeployedScience: System.NullReferenceException: Object reference not set to an instance of an object at Expansions.Serenity.DeployedScience.Runtime.DeployedScience.OnLoad (ConfigNode node) [0x0007f] in <9d71e4043e394d78a6cf9193ad011698>:0 at ScenarioModule.Load (ConfigNode node) [0x0000e] in <9d71e4043e394d78a6cf9193ad011698>:0 at ScenarioRunner.AddModule (ConfigNode node) [0x0005e] in <9d71e4043e394d78a6cf9193ad011698>:0 [ERR 06:17:03.018] D:\Games\KSP instances\Interstellar + planets\GameData\SquadExpansion\Serenity\serenity.kspexpansion: Unable to load the Expansions Master Bundle. Hard to say what causes it, could be a mod or a broken KSP installation. Try to delete and restore GameData\SquadExpansion from a backup if you have one. why are surface samples treated like sensor readings and not like actual samples? Because your game is broken ?

Kerbalism replace EVA monoprop by normal monoprop, taken from your vessel when going out. Your EVA kerbal won't get any if your vessel doesn't have any MP.

@mcwaffles2003 In the vessel UI > "auto" tab > there is a "data transmission" toggle