0111narwhalz

This indicates that the variable name has exited the scope. If you look at the curly brackets, the variable BPManagedResourceValueHelper was defined inside the function OnLoad. If you try to use it outside of that function, there's no way for the compiler to know what variable you're talking about (since there might be other functions with variables with the same name in them, or indeed none at all). Instead, you need to define BPManagedResourceValue in the class scope, as you have, and then set it in the function scope (since that's where […]Helper is defined). Order shouldn't matter here, but it's considered good practice to put your class variables ("fields") above your class functions ("methods"), so you can immediately see all the fields of a class.

woah… I don't spend as much time on the forums as I used to. KSP isn't my main game anymore and KSP2 hasn't succeeded it yet. But this reminds me of why I was here in the first place. Welcome back.

KSP2 kind of fell flat for me, back in February. Between the performance, stability, and gameplay (by which I mean a near total lack of any), there just wasn't much to bring me to play it. I clocked just six hours in 0.1.0 through 0.1.4, and didn't bother playing 0.1.5. But that has changed. The performance is still bad, but tolerable. I don't trust the game to be stable, but it does not fall to pieces the instant I touch it. And, for now, I am willing to brave these because 0.2 brought gameplay. It's a bit thin for now—I really want colonies, please don't make me wait another year—but it exists, and it produces goals and challenges. I never really engaged with KSP1's science or career modes, probably because I modded like mad and my saves had a lifespan of about a week, so KSP2's exploration mode offers an opportunity to have progression and a force to get me out of Kerbin's atmosphere for once. To be frank, I still wouldn't recommend KSP2. It does not justify its price tag today. However, I have more confidence than before that it will reach its goals eventually. Maybe, if the milestone update cadence is something like four to six months instead of ten, it won't even take five years to get there. One can hope—and I am hoping.

Out of curiosity, what is the point of a launcher in the first place? The launcher bypass command option works fine for me.

I might speculate that joints between physicsless parts and certain small child parts get culled incorrectly upon decoupling, but the part is not removed from the vessel tree. I'm almost certain that your camera issue is a result of this bug—if you then stage the decoupler or destroy the part, the part which had erroneously fallen off is removed from the vessel tree and the camera returns to normal.

Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Kubuntu (via Proton Experimental, up to date at time of post) | CPU: Ryzen 5 3600 | GPU: Radeon RX 5700 | RAM: 32 GB Title: Rovemax M1 (medium rover wheel) steers the upright instead of the hub. Specs: Severity: Low (visual only) Frequency: High Description: The Rovemax M1 wheel rotates the wrong mesh, causing significant visual distortion of the suspension mechanism. I think Bill just put two bolts in where there was only supposed to be one. Included Attachments:

Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Kubuntu (via Proton Experimental, up to date at time of post) | CPU: Ryzen 5 3600 | GPU: Radeon RX 5700 | RAM: 32 GB Title: TD-06 (extra small decoupler) or TS-06 (extra small stack separator) will, when attached to ST-Micro-1 (tiny cube strut), fall off at any decoupling event. Specs: Severity: Medium (breaks certain vessel designs, otherwise invisible) Frequency: High Description: Place a cube strut (ST-Micro-1) on a part, either surface attach or node attach. Place a TD-06 (arrow pointing either direction) or TS-06 on the cube strut's node. Then place a decoupler anywhere else on the vehicle (again, arrow pointing either direction). (My test vessel includes some other structural parts.) The extra parts on each decoupler are not necessary (though see next caption regarding arrow direction of the trigger). I've pointed the arrow on the TD-06 towards the beam on this craft to disambiguate "decoupler fires" from "decoupler just falls off." However, I believe every permutation of arrow direction exhibits the same behavior, so long as the "trigger" decoupler actually causes a part to fall off the craft. Take it out to the launchpad, fire the "trigger" decoupler, and the TD-06 falls off. Note that there is no ring, in violation of the expected decoupling behavior (because it didn't decouple). Additionally, the part is still considered to be a member of the vessel, as demonstrated by the fact that it appears in the PAM and can be triggered. When multiple instances are involved, the parts which fell off are seen to not collide with one another (further demonstrating that they are still members of the vessel). So far as my testing has revealed, this behavior occurs only between the ST-Micro-1 and either the TD-06 and TS-06. It appears to be triggered by the activation of any decoupler or separator, but not when the vessel is modified by a part exploding on impact. Included Attachments:

Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Kubuntu (via Proton Experimental, up to date at time of post) | CPU: Ryzen 5 3600 | GPU: Radeon RX 5700 | RAM: 32 GB Title: When in the VAB, the camera can be zoomed "in" past the orbit focus point. Specs: Severity: Low Frequency: Certain Description: Enter the VAB. Use the scroll wheel to zoom in. Continue to use the scroll wheel to zoom in, passing the vessel. You can go all the way to the wall on the far side of the VAB. You can even go past the wall of the VAB, but it's just a white void so I don't see much point in including a screenshot of that. The camera resets to a vaguely reasonable minimum distance as soon as you use RMB or MMB to orbit it. If you zoom past the wall and into the white void, you cannot zoom back out of it; the only way to return the camera to usability in this case is by orbiting it. Included Attachments:

Perhaps wings should have more additional nodes displaced "up" and "down" depending on their thickness.

An update: I tried it on a Windows computer with almost identical specs and got the following performance in flight at 1440p high: Looking up at the sky: 60 FPS Looking down at the ground: 30 FPS Looking at the horizon: 15 FPS This is much more tolerable and softens my view of the performance issues. It is merely a Linux Gaming Moment.™ All the same, I look forward to reaching parity with the game on Windows, either through improvements in performance with Proton or through a native Linux build.

Have you considered that the answer might instead be a secret third option? Something like "we haven't put in the time to stabilize it yet." I think KSP1's physics engine is a reasonably straightforward implementation based on Unity's basic tools. KSP2's physics engine might be a port of KSP1's, but I think "also a straightforward implementation based on Unity's basic tools" is adequate to explain the origin of certain similar issues.

I know Factorio has extensive automated tests, but that is a game about automation. A bit of a different situation. All the same, there are potential automated tests for some things, like the dV calculator. It's just a matter of what is worthwhile.

No, that was because the early EULA had an insane clause that promised all future content for free. They were legally obligated to give future DLC for free, but as soon as they acquired legal advice that clause evaporated (which is why the cutoff is when it is).

This goes a long way towards building my trust, but I'm going to need to see the patch live before I can go all in. I want to believe you can do it, Intercept. Give me a reason.

That should do it.

Huh. Alright, I'll start there. Thanks for the experiments. (And there's no need to delete your comments.)

I have no idea. I just pasted it in from a plaintext editor, and it looks fine on my mobile browser. I'll investigate it when I get to my desktop.

I played stock KSP1 and KSP2 for about an hour and a half each to understand where these titles stand with relation to one another. Unfortunately I was in a bit of a rush to get everything done, so I didn't get any screenshots of KSP2. Let's get the system information and performance out of the way. My playtest consisted of two parts: a small plane and a Mün rocket. The Plane My intent for the plane was to try out the aerodynamics and inspect the terrain. Design of the plane was reasonably straightforward. The procedural wings are on par with KSP1's B9 Procedural Wings, without needing a weird hotkey to access the wing parameters. However, I did have an issue selecting certain wing parts after they had been placed. I speculate that this is related to the collider not being regenerated with the new wing shape. Luckily, I was able to tune a different wing part to suit my needs. It seems that the thickness of a wing part has a notable effect in its lift characteristics. Without changing the other parameters, I increased the thickness of the foreplanes, and the pitch authority increased markedly. I flew it to the mountains west of the KSC and was favorably impressed by the terrain quality. Where KSP1 has a jagged Perlin noise ridge with terrain polygons a hundred meters across, KSP2 has a pretty well detailed hillside. They seem a bit further away now, or at any rate don't loom on the horizon like they used to. It's a bit of a shame losing the landmark, but the quality is much better. Terrain scatter was distributed a bit oddly, with trees in weird clumps and massive open spaces between them, but I don't really expect too much from a low priority feature like ground scatter right now. Suffice it to say, I look forward to exploring this terrain by rover in the future. SAS was a persistent issue in my play. It feels massively overtuned and has a difficult time converging. The twitchiness makes it consume a lot of RCS fuel (during the Mün rocket component of the playtest) and I spent most of my time with the plane flying with it off. Unfortunately I crashed the plane during the KSP2 test, while trying to land it on the mountains. Rather than flying back east and over the KSC, I reverted to launch for the flight across to the island. Still, the trip was long enough to really appreciate what has been done with physics timewarp. Apart from exacerbating the twitchiness of SAS, there was no apparent loss of sim quality. The wings stayed on with maneuver and the plane stayed on target (with SAS off). I flew over to the island runway. They really did it dirty, I think. Gone are the ruins. Now there are two small tent-like buildings and a… water tower? I think it would have been more suitable to preserve some of the history of KSP with the structures there. Or maybe one level of memorial objects is enough? Still, it seems a step backwards compared to the KSC's massive leap forwards, in terms of story. There's not even decaying pavement, it's just a dirt strip. And here I will talk about a bug I encountered, not in KSP2 but in KSP1. The island was flayed open, a torn-up chunk of terrain hovering over the runway. I think it's only fair to acknowledge that KSP1 is not perfect either. Anyways, I "landed" the plane on the island runway and concluded the test. The Mün Rocket My intent for the Mün rocket was to examine the rocket launch experience, rendezvous and docking, landing, rovers in reduced gravity, and the terrain of the Mün's poles. I wasn't able to achieve all of these goals in the time I allotted myself, running out of time by the Mün intercept. The design of the rocket exposed a few more issues with the editor. First, I wasn't able to build a fairing to my requirements, because it refused to allow me to add segments except under circumstances I didn't understand. Then, while designing a bellylander with a cargo bay, the center of thrust indicator failed to appear. Finally, parts seem to be "sticky" and really do not want to be placed into "scratch space" as single-part assemblies if they have ever touched another part. As for editor ergonomics: I don't particularly like the way mirror symmetry is on the same "cycle" as the other symmetry modes. I'd much prefer to be able to toggle it. Additionally, I'm not sure how to grab the entire assembly from an arbitrary part. In KSP1, this is done by shift-clicking a part. The reroot tool ("anchor") is sticky and I have to select the transform tool to get rid of it. Regardless, I was able to build a rover, a lander, a transfer stage, and a lifter. The lifter served very well (once I put some fins on the back), though the per-stage dV tracker did not function and I had to use the global dV tracker. Orbit was straightforward enough. I fought the SAS most of the way up, but with RCS and thrust vectoring it went fine. Rendezvous as well: a textbook high-energy intercept. Turns out you can pin intercept data, but it closes as soon as you open the maneuver node. Docking was a bit more exciting than it needed to be, what with the SAS misbehavior, but I encountered no new issues. During the transmünar injection burn, my transfer stage ran dry and I discovered while burning with my lander that burning under warp did not work. Fuel went down but my velocity did not increase. I'm not sure if this was also to blame for my transfer stage running dry, or if I simply failed to calculate the requirements correctly. Finally, I set up a low Mün periapsis, and a maneuver to capture into orbit. I pressed the autowarp button and… immediately crashed into the Mün at high timewarp. Perhaps the SOI transition knocked something off? Either way the auto timewarp needs to be more conservative. I suspect it would have overshot my node even if the collision had not occurred. Conclusion That was 98 minutes of playtime, so I concluded the test. In KSP1, I completed all objectives, including landing on the Mün and driving/jetpacking to its south pole, in 107 minutes. I probably could have managed more in KSP2, but I'd like to keep some margin open for refund if I choose to use it. I encountered nothing truly gamebreaking, no crashes, and no major krakens. My rocket design was conservative, but even so there was no excessive floppiness. Performance was… well, it was bad, but from what I hear there are Big Issues, and those are always easier to deal with than a myriad of small issues. I found that my personal limit to performance is somewhere around 10–12 FPS. If I get that, I can consider it playable. Below that, it is not playable. So I'll be stuck with upscaled 1080p until performance improves. Again, not breaking, but not good either. I mentioned that I might want to refund the game. I want to keep this option open. Based on my test, I do not think that Intercept cannot make KSP2 into something great. However, I am not yet ready to invest my trust in this team and this project. If Intercept proves themselves to me, then I will put forward my trust and fully commit to KSP2. They can do this in one simple way: Release a patch, within my refund period (i.e. on or before March 14), which addresses at least one glaring performance issue and provides a genuine attempt at transparency into the development process. I understand that not every indie or "indie" developer is on the same level as Wube, but I do not think it is out of line to expect this much from Intercept.

Do not confuse my statement for a defense of KSP2's poor performance.

Rendering terrain is always going to be expensive. That these two examples of rendering terrain are expensive is not much evidence that they are otherwise related.

I'm excited for a lot of things. I'm excited for new challenges, and new opportunities to take on old challenges. I'm excited for new sights and new perspectives. But in more concrete terms, I am excited for a new, better documented modding API; continuous collision detection; native, minimally jank multiplayer; colony-building; the new VAB. Interstellar stuff is nice enough too, and I'm curious about how science will look when it's designed in almost from the start.

I'm going to keep it to "cautiously optimistic" for now. Don't let us down, Intercept.

Winchell Chung, alias @nyrath, is in the hospital with a life-threatening illness. If Atomic Rockets or any of his works touched you, I invite you to write something to him in this doc.

Anti-mush.

How can I work inertially in a rotating reference frame? Is there a sane way to convert between the rotating frame near a planet and the inertial frame above it? How do I even tell whether the present reference frame is inertial or rotating? For context: I'm trying to operate on things stored as orbital elements, and I want them to interact with worldspace in a sensible and consistent way. I'd like to keep it all inertial.