Gotmachine
-
Posts
703 -
Joined
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Gotmachine
-
-
8 hours ago, dok_377 said:
The angle of the locked robotic part will reset to its original position, but the part that's attached to the robotic part will not move with it, completely offsetting the hierarchy. Disabling the RoboticsDrift patch removes the issue.
Game version: 1.10.1Thanks for the report.
I managed to reproduce this on KSP 1.10, but not on 1.12, so this is caused by some differences in the stock robotic code between those versions.
The RoboticsDrift patch is developed against KSP 1.12, I have a few other robotics related issue reports lying around, and I suspect at least some of them are caused by minor differences between KSP versions.I don't really have time (nor willingness) to investigate and fix such version-specific issues, so I will just disallow the patch to run on KSP versions prior to 1.12.
8 hours ago, stk2008 said:I have been getting this error started yesterday and I cant figure out whats causing it but I am pretty sure what ever adds this
The error you're getting is indeed caused by some mod uncorrectly managing resources, so "whatever adds this" is indeed the likely culprit.
I would suggest finding which mod it is and asking on the forum thread for this mod, or to post in the "Technical Support (PC, modded installs)" forum, this has nothing to do with KSPCommunityFixes. -
1 hour ago, 4x4cheesecake said:
Do you mind if I add this to my original post?
I encourage you to do so
-
Doing that will have the side effect of having KSP running from the wrong working directory.
In stock KSP, the only likely side effect will be that the KSP.log file will be generated in the "PDLauncher" directory, but this will definitely cause cascading side effects on various mods.While you can specify a different executable in the Steam command line, you can't set the working directory, which is hardcoded to the "PDLauncher" directory.
This being said, the proper workaround is to have Steam pointing at a shortcut instead of KSP_x64.exe :
- Open your KSP root folder (In Steam, right click on the game > Browse local files). Usually this will be "C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program".
- Right-click on KSP_x64.exe > Create shortcut
- Rename the shortcut to "KSP_x64_Steam"
- In Steam, open the game properties, and in the "Launch Options" field, put the path to the shortcut between quote, with :"C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Steam" %command%
This will launch the shortcut instead, with the correct working directory.
-
People are having that issue because they are trying to bypass the launcher by adding an extra command line option in steam to start a different executable than the launcher.
This is what I have seen suggested :"C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64.exe" %command%
This doesn't work because the executable working directory will still be set to the "PDLauncher" subdirectory, causing cascading issues all around.
A workaround is to make a shortcut to KSP_x64.exe, let's say I'm renaming it "KSP_x64_Steam". Then in the steam command line options, point to that shortcut :
"C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Steam" %command%
This will launch the shortcut instead, with the correct working directory
Said otherwise, the only issue here is people making a mess on their own by following random bad advice on the internet.
-
On 10/22/2022 at 11:25 PM, Rakete said:
QoL-Proposal: Offer an option to make the target time of the "skip to next morning"-button of Stock KSP adjustable.
Good idea. I don't have the time or motivation to implement this, but suggestions are welcome nevertheless
On 10/23/2022 at 3:43 PM, Rakete said:Back in the day, when it was designed (To take Ore as a "universal fuel" ressource to a big refuelerstation) it did not explode on launchpad - back in the day somewhere along 1.11 and the release of KSP 1.12... where KSPCF wasn't a thing... So maybe the launchpad krakenfix of KSPCF has downsides too... This is for debugging/improvement for you, if you wish.
Well, don't have much time either. The few "kraken fighting" patches in KSPCF are far from a definitive or reliable fix. KSP will forever stay prone to such events, and there might be indeed corner cases where KSPCF is doing more harm than good.
This being said, if you can reliably reproduce a case where the same craft has issues when the PartStartStability patch is enabled, and is working fine when the patch is disabled, please provide the craft or save file.On 11/1/2022 at 4:39 PM, stk2008 said:I only seem to get a CTD if I by mistake prematurely tap or click a button while I am doing a scene transition.
Please try to reproduce this in a stock install. There is a large probability this is caused by a mod. And if you manage to reproduce it, please provide your Player.log file (see https://forum.kerbalspaceprogram.com/index.php?/topic/83212-how-to-get-support-read-first/)
On 11/4/2022 at 1:05 PM, HB Stratos said:When copying a fuel tank with alt-click, the fuel flow enabled button is reset to on, no matter what state it was in previously. ,
would that be fixable with mods?
It is fixable with a mod, but it would be a behavior change that has a significant chance to affect other mods in unexpected ways, so KSPCF isn't the right place for that.
1 hour ago, ColdJ said:Before 1.11.1 Kerbals would swim at a fixed height and you could increase or decrease their weight to sink or make them neutrally buoyant, through a mod I made.
From 1.11.1 onward they follow the ground surface underneath and so if the ground slopes down then they swim down following it.
Same response. KSPCF doesn't change stock behavior like this one to avoid messing with what other mods are expecting. This is something that you can and should handle from your own mod.
-
22 hours ago, orionguy said:
I am trying to get what the game is actually seeing "right now"
This data doesn't exists, not under a serialized (ConfigNode) form.
KSP holds its data in various subsystems, most of it is easy to get from various static accessors or fields in singleton top level classes.
For vessels (and everything they are made of) and bodies, you have FlightGlobals, for Kerbals you have KerbalRoster.
Some other relevant top level classes are all subclasses of ScenarioModule, like ResearchAndDevelopment, ScenarioUpgradeableFacilities, Funding, Reputation, ContractSystem... -
2 hours ago, damerell said:
you're making some very definitive statements and I'd still be interested to know if you have a source for these. Apologies if it's common knowledge to everyone but me that you used to be a KSP developer, or something.
I'm just another modder. Lets just say that we have ways to see what is happening exactly under the hood.
-
1 hour ago, ColdJ said:
Would certainly like to hear more.
It's quite simple. Part.buoyancy is the per-part equivalent of PhysicsGlobal.BuoyancyScalar (which you can tweak in Physics.cfg).
In short, the formula for the magnitude of the force applied on a part by water is (physically "accurate" result derived from the drag cube and part mass) * PhysicsGlobal.BuoyancyScalar * Part.buoyancy.
Default value for PhysicsGlobal.BuoyancyScalar is 1.2 (to account for the fact that stock parts are way too dense).
Part.buoyancy default value is 1, and is sometimes tweaked up or down on stock parts to account for even sillier densities.In the context of rescaling a part, assuming both the drag cube and mass scaling are accurate, density is staying equal and nothing else is needed. Messing with Part.buoyancy mean that you're altering the part density, which is obviously wrong.
I haven't read the whole convo in detail, but part.buoyancy set aside, if as @damerell suggested TS is only scaling the drag cube area and depth (and not size), it's no surprise that effective buoyancy results are inaccurate, as the formula make extensive use of the drag cube size.
EDIT : to ensure a scaled part is keeping the same density, one can check the Part.partBuoyancy.displacement value.
This is the intermediate result of the drag cube/mass computations before any "cheat" is applied (BuoyancyScalar/buoyancy), aka the "physically accurate" density of the part. Ideally, it should stay the same no matter the part scale. -
Part.buoyancy is essentially a corrective factor applied over the part default buoyancy derived from the part estimated volume (itself derived from the drag cube) and mass.
Said otherwise, it's a factor to do an arbitrary final adjustment of the part density in the context of the buoyancy formula, which mean it doesn't make any sense to scale it when a part is rescaled. -
No responses because information is extremely scarce.
We know they are using Unity, so yes, Mono is involved. They have no reason to use IL2CPP unless they really want to kill modding.
We know that they have at least toyed a bit with Jobs/Burst for the new PQS system in combination with compute shaders (source).
Maybe other parts of the game are using Jobs/Burst. It would make a lot of sense from a perf standpoint, but the fact they had to contract a freelancer to make it happen for the PQS system isn't a good sign.Other than that, they talked about config-driven modding with vague ideas for MM-like features and some limited config-level scripting capacity. This was a "it's all in flux" comment from three years ago, so don't hold your breath.
If I were to speculate a bit, I'd say that the eventual performance optimizations (Burst, Jobs, GPGPU, multithreading...) and multiplayer feature are likely to increase the difficulty of making "complex" mods compared to KSP 1.
-
22 minutes ago, Nazalassa said:
At 24th August the problem is still there.
It isn't. It was fixed in KSP 1.12.3, you just need to update.
-
On 7/24/2022 at 2:59 PM, Krafpy said:
The position calculated from the true anomaly at the current UT looks correct (same as in first test). But the positions calculated at the offseted anomaly makes no sense.
To get back to your original post (because I actually didn't really took the time to read it before) : the results you are getting make perfect sense to me.
A +0.001 offset in true anomaly is absolutely not equal to 1s of orbital period, it's far, far more (something like 1400s), so of course you're getting a much larger movement.
Also, if you followed what I said before, comparing the absolute position magnitude like you do doesn't make much sense because you don't know where the origin is. -
I think we are lost in semantics.
To me, "origin" is the 0,0,0 point, anything else is a reference point, not an origin.
If your question is "are the positions returned by the various orbit methods consistent relative to each other and to a common reference point ?" the answer is yes.3 hours ago, Krafpy said:their coordinates would be calculated and expressed relatively to the sun (sun as origin), and for a satellite relatively to the planet its orbiting around.
There are two different set of methods in the orbit class.
Those prefixed with "Relative" return a vector expressing the position offset from the parent body position, but that vector is usually in a coordinate system where the y and z axis are swapped compared to world space.
The non-prefixed ones return an absolute position in world space, where the origin / (0,0,0) point can be anywhere.3 hours ago, Krafpy said:So the "AtUT" methods actually return the correct coordinates relative to the attractor body ?
No, for the methods that don't have "Relative" in their name, they return an absolute point in world space where the origin (0,0,0) point can be anywhere.
If you want a vector from the parent body, you need to look at the "Relative" methods. -
44 minutes ago, Krafpy said:
defined in a coordinate system where the origin is the Sun
No. If you use one of the "AtUT" method, the body position is computed recursively relatively to it's parent body using keplerian orbit parameters and equations. There is no need for a known absolute point of reference.
-
9 hours ago, OhioBob said:
could this be a stock bug worthy of inclusion in KSP Community Fixes?
@Razhan Sounds like it. Could someone create an issue with as much detail as possible (minimal repro steps, findings on what is happening...) on the KSPCF repository ?
-
9 hours ago, Krafpy said:
is it feasible with getPositionFromTrueAnomaly or a similar functions
I think so, but there are various shenanigans, the KSP methods don't always do what you expect them to do from their name.
10 hours ago, Krafpy said:If the origin can be anywhere, how does KSP compute the bodies' positions since the maths involve positions vectors with defined origins ?
The origin is irrelevant, everything's position is relative to another. All positions are consistent relatively to the current origin at any point of execution, that's what matter.
-
On 7/24/2022 at 2:59 PM, Krafpy said:
I thought intuitively that the origin of the world (= local space ?) coordinates would be where the Sun is, but it can't be according to these values. Where is the origin of the world ? Am I missing something in how the local space works ?
The origin (both in local and scaled space) can be anywhere, because it's a floating origin. To mitigate floating point precision issues, KSP occasionally move the origin so the active vessel stays near the origin. However, this isn't done on every frame and there are various exceptions.
The main consequence is that you can only compare relative positions at a specific point in the execution flow. Even within the same frame, there is no guarantee that the origin won't move between two separate calls. -
FileSystemWatcher events are called from separate thread.
Unity/KSP APIs are not thread safe and can't be called from another thread than the Unity main thread, that's why your ScreenMessages.PostScreenMessage() call in OnNewMessage_Handler is causing a crash.To make that work, you can instead set a flag from the event handler and check that flag from an Update() method in your plugin class.
But I assume you will want to pass more data than a simple flag around, so you will likely need to implement thread safety mechanisms (like a lock) to make that work reliably. -
On 8/19/2022 at 11:55 AM, TaintedLion said:
Whenever I install this mod, any in-flight craft I have that have switchable parts with a B9 module (like BDB parts with alternate colour schemes or engine types) will reset back to the first option.
Please provide logs, and ideally also your save file and module manager cache. Ideally use KSPBugReport for that.
I doubt this is directly caused by KSPCF as this would have been widely reported, in any case I didn't manage to reproduce it.
This is likely some peculiar corner case in your specific modded setup. -
20 hours ago, Papa_Joe said:
Interesting. it is crashing on the vesselName. I haven't seen that before. Can you tell me the name of the vessel, and is this repeatable with another vessel? I'm not getting an error. I even tried extra long names and got no error...
Stock vessel names are localized. You're supposed to use Vessel.GetDisplayName(), not the Vessel.vesselName field directly.
-
12 minutes ago, Master39 said:
Orbital mechanics make KSP an outlier among space games, it's the sole thing that puts KSP into the "niche, hardcore" kind of games and keep it nailed there.
No amount of simplifying or cartoon goofiness is going to change that.
Then you have clearly no idea about what makes a game a commercial success or failure. The success of KSP 1 comes from those factors :
- Being the first.
- Very low initial financial risks / investment.
- A handful of modders and hardcore users generating hype (and significantly contributing to the game development).
- The hype making tens of thousands of casual players buying the game because the goofy kerbals makes it not look like a hardcore simulation whose value as a game is basically non-existent past the initial discovery and first hours of gameplay.KSP 2 is made in a completely different context, this is NOT an indie game like KSP 1. And given the circumstances, they very likely need the game to be an immediate financial success for the studio and the creative people in it to stay vaguely in charge.
So far, the people actually deciding what KSP 2 is / will be are making the right choices to make such a miracle happen in the current game market : maximize the hype factor (visuals, interstellar/epic content, multiplayer...) and ensuring the game get good reviews and reputation by doing everything they can to provide a smooth learning curve and steady progression for the average player. 100% of what we heard is backing that, especially in the press interviews and promo videos, but also to some extent in the so-called "dev logs".
17 minutes ago, Master39 said:There's plenty of money to be made in niches.
No. That was somewhat true 10 years ago. Now for every vaguely commercially successful niche game, there are a few barely recouping costs and dozens of failures. The studios managing to survive in niche markets are either well established ones or small and agile independent teams. Intercept Games is neither.
55 minutes ago, t_v said:EC, thermals, kerbal professions, pods holding kerbals, ISRU, EVA reassembly, sat networks, etc.
Well, I don't have a crystal ball, but almost sure all of that will be either quite simplistic, mostly cosmetic or not present at all.
But don't misunderstand me. Yes, I don't expect stock KSP 2 to have in depth gameplay mechanisms. I think stuff like colonies, ISRU, resource and thermal management or life support will be very low complexity, casual game level of abstraction systems. Outside of the audience demographics argument, I doubt they have the manpower to deliver anything else.
What I hope they deliver is a good game that attract as many buyers and players as possible with an engaging but quick and simple progression system. I think the core creative and dev team are passionate, actually hardcore niche players at heart that want all those fancy systems. The way they can deliver that in the long run is by doing their best to ensure the core technical foundations are solid, so either them or the modding community can pick up over time with the actual "niche" content we are all longing for as long time (frustrated ?) KSP 1 players.
The worst that could happen is if instead of pouring all resources in a financially successful and technically viable long term product (that they actually end up delivering, something they obviously have been struggling with), they start dispersing efforts around niche features that won't get anywhere near enough resources to be good.
All I ask of KSP 2 at launch is to not be a bugged mess that suffer from the same chronic technical issues of KSP 1 and to deliver actually enjoyable, polished gameplay. And trust me, if they manage to do that, it will be a huge achievement. And once that's done, we can start to think about life support and other fancy features.
Personally, I'm pretty sure I won't like the stock KSP 2 content. Playing with speculative technology to perform even more speculative interstellar travel to establish science fiction colonies is something that I can't relate to in any way and that simply doesn't talk to me. But I hope it is something I will enjoy to play casually, as those other games that I enjoy but never touch again after a few dozen hours. Then hopefully, with time, either Intercept Games or modders will deliver what I'm actually waiting for as a hardcore, niche player.
-
1 hour ago, shdwlrd said:2 hours ago, Pthigrivi said:
Nate has said he doesn't want to see a system that punishes players for failure, but rather rewards players for doing things well.
Thanks for bringing this up Pthigrivi. Everyone seems to be ignoring this want from the devs in this discussion. If anything LS related is added to the game, don't expect Kerbals to actually die or become nonfunctional. So you're just debating the next LS mod at this point.
Exactly, that's why any kind of LS system is very unlikely.
The central point of a LS mechanism is to introduce a new constraint in the form of max crewed mission time, and gameplay loops revolving around mission planning, manned vs unmanned choices, supply and ISRU. Those can be interesting gameplay elements, but they are in direct opposition with the core intended gameplay loop which is to freely and goofily assembling vastly overpowered rocket components to play with the rocket equation, playing around with orbital mechanics, and landing on unreachable worlds. I'm quite confident that people expecting KSP 2 to have more in depth simulation/gameplay mechanisms than KSP 1 are going to be utterly disappointed. If anything, they will be vastly simplified.
It has been clearly stated that KSP 2 is about making a more accessible game but with vastly more content. Said otherwise, the stock game is all about exploring gorgeous planets, flying shiny interstellar engines and building humongous bases and stations. They will certainly put a lot of effort into making a smooth progression system to back that, but it's pretty certain that the "simulation gameplay" part will be simplified as far as they can without betraying too much the "grounded in real world/physics" premise.
Not only because such systems are getting in the way of the core gameplay loop, but also because they are very difficult to design, program and balance, especially if you want to satisfy the whole player base. No matter what the stock system is, there will be a bunch of mods proposing their own take on it, providing a much better fit for the various player demographics.
-
8 minutes ago, Pthigrivi said:
LS could dovetail very nicely into the same kind of engineering puzzles that rockets and heat management and power generation entail.
I fully agree with that, but the fundamental problem with LS is that any miscalculation on the player side results in a bricked mission, there is no real "counterplay", everything is happening at planning time.
On a larger level, such a system is restricting player freedom to do whatever they want and it doesn't meaningfully contribute to the core gameplay loop, which is building creative spacecrafts from various bits using real (to the extent that the average player can understand) orbital and rocket physics to explore and colonize the stars with goofy green humanoidsThat "planning must be done right" aspect is already a major weakness in KSP, and a major complaint made by most people trying the game. The "build-launch-crash-try again" loop is a entertaining for the first hours when you discover the game, but it quickly become a source of frustration for the average player. We have heard a lot from the team about how it was crucial for KSP2 to get around that issue.
"Non-hardcore" players are those that will make the game a financial success or not, and the difference between the game being supported for years or shelved a few months after launch. Not the people having poured thousands of hours in KSP 1 and posting on this forum.
Despite what the public facing people are trying to convey, this is no passionate independent game, KSP2 is a financial investment controlled by a huge game publisher that bought a relatively successful independent brand to primarily make money out of it, you can be sure that every single feature that will or won't be present at launch is carefully weighted in terms of player demographics and impact on potential sales.It is common knowledge that the majority of people having bought KSP are abandoning before even reaching orbit.
It's not what I want to hear, but the main point driving game design decisions is very likely : how to ensure the average player is able to progress steadily toward the mid-end game without too much frustration ? Especially since this mid-end game content is the selling point they are desperately trying to push forward.That doesn't rule out a very basic system existing as basic time progression limit mechanism, but I really don't expect anything beyond that. The fact that Nate Simpson refused to comment on the subject two/three years ago show that they at least were considering their options.
And if the game is successful and kept alive after launch, a middle-complexity LS system and associated mechanisms (habitat, radiation, repairs, kerbal specialization, ISRU...) could be an opportunity for a DLC, even though I doubt such "complexity adding" systems will ever be the focus. -
It has been strongly hinted in various interviews that life support on vessels won't be a thing at all.
The only thing that was confirmed was that "colony growth (but not survival) requires producing/importing life-support-alike stuff".
I highly doubt it will be a thing on vessels if it's not even a requirement on colonies, and in any case I wouldn't expect anything past a very basic system, probably even more basic than the simplest KSP1 LS mods.In the context of the "interstellar exploration" gameplay they are pushing forward for stock KSP 2, I can see why life support gameplay elements at the vessel level won't be a thing.
It adds a relatively tedious supply and mission time planning requirement for every single launch, introducing a whole new "micro" gameplay loop conflicting with the "macro" scope of the game, which is clearly large scale interstellar exploration and colonization.I always comes back to the same point : the intended large scale and speculative future scope of KSP 2 is in conflict with it being a game that takes the actual physics and challenges of spaceflight and transform them in gameplay elements.
Now, I'm sure there will be plenty of mods trying to implement said gameplay elements.
As mentioned in this thread, the main purpose of LS as a gameplay loop is to make mission duration a constraint. Another one is to give value back to unmanned missions.From there, there are various levels of detail and complexity possible.
But the issue remains that this will always be a "micro" gameplay level, where you have to manage things on a per kerbal, per vessel, per stage, per mission phase basis, doing careful planning, resource input, output and transfer management.
This can go quite far in terms of complexity or realism and make a good gameplay loop, but if the overall game scope is managing hundreds of kerbals, vessels, colonies and stations all around the galaxy, it suddenly becomes completely out of place.
[1.8 - 1.12] KSPCommunityFixes - Bugfixes and QoL tweaks
in KSP1 Mod Releases
Posted
That's a strong statement.
It's extremely difficult to make reliable performance measurements between different runs without automated benchmarks that reproduce exactly the same configuration and sequence of inputs.
This being said, I'm somewhat able to reproduce what you're seeing, although not as dramatic as the 27% FPS difference you're showing in your screenshot.
Using your craft file, I can reliably measure a 4-5ms per frame overhead on KSP 1.12 vs 1.10 (for a frame time of ~45ms). In practice, this mean a 0 to 20% drop in terms of FPS, depending on the baseline.
This can partly be explained by new features. With your craft, Part.FixedUpdate() call time has jumped from ~0.65 ms/frame to ~1.22 ms/frame due to the new kerbal mass system.
There are likely a few other methods that increased in complexity slightly, resulting in some fixed overhead in newer KSP versions.
More surprising, there is also a consistent and repeatable overhead (about 5% overall) in many top level method calls, including methods that haven't changed at all between KSP 1.10 and 1.12.
I'm not sure how to explain this apart from some global regression at the Mono/Unity level when KSP was upgraded to Unity 2019.4.18 for the 1.12.0 update.