Xelo

Enjoying the new parts! Sadly loading saves is still incredibly unreliable, a mission has to be completed all in one go, else you highly risk your craft suddenly losing half its physics joints and being RUD'ed with no external force, incorrectly serialized or worse.

There's also the distant notion of colonies and the amount of surface daylight varying seasonally across the year. Maybe one can see unique challenges with say, a polar colony running off solar power. The axial tilt may require the colony to be seasonally abandoned/unoperational for the months-long polar nights, but on the other hand, have uninterrupted solar power during summer.

Reading through the rest of the comments, I dont get it. The only difference between the timelines of people being ok with KSP 2 and people being angry at KSP 2 in this forum, wouldve been if T2 had just shut its month until late 2022 and started with EA. No changes to development time, nothing extra promised, nothing. To me it seems people that are angry literally took time and scope guesstimates as prophecy, and now blame the game developers for the publishers misguided PR strategy? Has the fact that its a professional game studio or big publisher ever guaranteed game quality on launch in the lord's year of 2023? I feel like even small indies have a better track record. Why on earth is the art director (Nate) the only one chosen for doing interviews on the game's programming progress ? What happened to the other 3 directors? Like where do these expectations for the devs come from? Shouldnt yall be angry at the publisher for setting those expectations, (and the inflated price) up in the first place? I guess only in the games industry can you expect people to complain about the dairy farm when the grocery knowingly sells expired milk.

I believe in this 2021 interview, Nate mentions being in the final stretch for release (near the beginning) https://www.youtube.com/watch?v=6RHbvphmnyE&ab_channel=GamerHubTV Yes, while I dont doubt the game is in questionable shape, this would be the reason I wont trust any predictions of completeness in software development in future. I'll believe it when I see it. The projects with accurate predictions tend to be the outliers and most projects blow their time budget internally. This is why most studios don't release dates at all until they are nearly done. But not to fault Nate, such is the PR reality of trying to predict software and he is not a programmer or a veteran game PR guy but the creative director (that is in charge of the art). And to his credit, the art side of things is fairly 'complete'! He did his job well. The game visually looks great and the art assets are top notch and carry a strong identity. Most of the updates shown pre-release, were spearheaded by the art and vfx department. So something happened in the software side of things, where Nate was less privy perhaps and it was understandable that he had a overly optimistic prediction. But there are clues. ✨Speculation time ✨ There is an old adage in software development that "90% of the work happens in the predicted last 10% of the project". Now picture yourself in Nate's shoes in 2021, riding off the covid era. In the video, Nate mentions the 'all these larger portions being sewn together'. We can infer these portions to be separate systems of the game being developed in isolation. One programmer may be doing the PQS, one may be doing the rocket physics, one the save serialisation and so on. You are told these pieces are nearly done, and pieces like the colonies and science are going along a good pace. Surely, one thinks, once the pieces are brought together, we would have a functional game in no time right? And you can see where the problem of prediction starts... while the planned schedule suffers a slow death by a thousand additions that no-one could've predicted looking at features in isolation. But it doesn't matter, in hindsight the warning signs were all there with tangible gameplay only being shown less then a year before release. And I guess if its not there it might as well not exist.

This post was badly worded. A pr blunder. People here can see through corporate word fluff like its glass so why bother. Instead of: "On the subject of updates: our update cadence is going to slow down a little bit. There are a couple of reasons for this, not least of which is that every time we release an update, we divert resources that would otherwise be focused on continuing to improve the game. We are always balancing our desire to improve the current Early Access experience against long-term goals that involve more time investment." It should've been framed as something like: "Our updates from now on are no longer going to just be bugfixes. They will have meat [0] in them; meaning extra time is needed to prepare them. While our first 2 bugfix updates have been released as soon as we could based on our monthly(?) sprint cycle, such a cadence is less viable for some future content updates as releasing half a feature is worse for expectations then releasing none at all. " [0] content and QoL , Src. Discord I feel people would have taken that significantly better. The original line is a vague apologetic that frames the development team as a victim of resource constraints, while the alternative framing holds the value that community should expect from this negative change in update scheduling. Both are true, but obviously what the community wants isn't another veiled apology, but rather confidence in this game's direction. Aka. the goal of good communication.

It may be to do again with the serialization (in the background the game converts the entire craft into a special format in memory) , I've also noticed the lag creeps unusually early with adding parts in the VAB. So it could be that the expensive serialization process needs to be repeated from scratch everytime a part is added, making it slow ontop of the usual serialization bugs todo with vessels not saving/loading/seperating/docking correctly and etc.

Amazing work :O

Games are rather difficult to write automated tests for, compared to 'business logic' especially for a sandbox game where the possibility space is large enough that edge cases are nigh impossible to completely cover. Things like graphical and physics bugs are also difficult to cover as the underlying systems are rather opaque to unity's scripting code ontop of the possibility space being too big, writing an assertion that the sky is blue is not worth the dev time a qa tester can discern in half a second for example. Which programmer would think of the test case where the KSC follows them around? How does one automatically test for a bugged animation? Many things can only be reasonably validated by humans in games. One thing that may see good use of automation tests is the serialization bugs that are prevalent in the game, but from what I saw these bugs are all edge cases with difficult patterns of reproduction, likely automated testing would cover the most obvious ones, but beyond that has to be the QA's job of finding the specific series of interactions that'll break a thing.

In the ksp2 logs does spacewarp or this mod show up?

https://github.com/Xeloboyo/NotEnoughShips Source code, license (MIT), and installation instructions in above link. Uses Spacewarp 0.2+ Does what it says on the tin, that is, spawn any saved vessel or loaded part in the current active campaign. Disclaimers: The vessel position serialization when in orbit is strange in ksp2 currently. This results in when spawning a vessel in orbit locally, spawned vessel will have a rather large offset at times. Features coming: - Ability to select a part and spawn it as a derelict vessel for testing. - Ability to spawn vessel next to a selected ship as opposed to the only active ship. - Ability to replace a vessel with another. - Ability to spawn a vessel next to ground structures like flags. Feedback: reply to this post with a mention or raise an issue on github.

https://github.com/X606/SpaceWarp Edit: ah wait, the source code link was already posted. Apologies.

The modloader is fairly straightforward to use and develop within, which is quite a welcome aspect.

Pretty hyped to tour the new planets! ^^

How do we know for sure its the physics thats lagging and not just extra parts being drawn? 0:

Ksp 2 is the only game that can overcome my procrastination at upgrading my computer from a laptop with a damaged keyboard to a proper workstation.

I wonder how fast a performance mod will appear when the game is released.

I can finally count the days until ksp 2 on my digits

More in the sense that it should all be shadowed from the dense cloud layer, but it was in jest anyway.

Ah, just in time to be angry about the eve clouds not casting shadows or something.

They probably haven't hooked the clouds to a 3d noise texture, and are just using a 2d one for now (maybe unity being fussy? curvature of the planet shenanigans? who knows). I wouldn't worry about its shape shader-wise, its a pretty simple change.

While I dont disagree with the last part, I feel that's more due to a failure of marketing then part of the strategy, in that the main ones interested are just diehard fans. If they wanted to onboard as hard as they claim, and use EA primarily as a time for feedback as they also claim, the best feedback comes from new players, not veterans. This marketing for this game is also nothing unique holistically, again its a odd claim to make, along with the claim that the game is so niche it deserves special treatment. Don't get me wrong, I'm all for this game, but I want a more objective view of this.

Yeh I definitely agree there's a balance. I just feel the veterans here keep downplaying the notion that the graphics are a part of the 'gameplay' experience. Like you can detach graphics from game play so easily. Why travel to other planets if its just recolored spheres kind of deal? Raw physical gameplay cannot cannot sustainably support sales alone. People explore for the cool vistas :D, make excessive ships bc it looks cool, and for that you obviously need graphics to sustain the immersion. The graphics alone provide a significant chunk of this gameplay incentive! I also think you underestimate the importance of graphics in organic marketing like 'word of mouth'. If you think about it, visually unimpressive games dont make for good thumbnails for creator videos (meaning sharing it with friends would accrue less interest), get skimmed over in steam, etc. Your friend may simply forget if it looks bland over other games they may wish to buy. People tend to think space is pretty, and if the game contradicts that expectation, people may think twice. :3 Why bother with marketing at all then, why not just a closed beta with prominent members of the community? To say EA is not for general purchase is quite an assumption to make I think, and a radical departure from how its typically used to sustain funding for remaining development.

I think @Vl3d's point is more graphics are the fancy packaging on products. It gets the product noticed, and gets people to try it for the first time. With a focus towards onboarding this is more essential then in KSP1 and thus needs more attention/effort given. Obviously the product itself (i.e the game play) is what gets what people to come back and that's not disputed. But better graphics would help sell the game better initially, pay dividends to the publisher in proving KSP2 is a viable product, and ultimately allow more resources to develop the game in the long term. Its not an either or thing, a candy bar with a blank packing doesn't exactly sell, and neither does a bad tasting candy in fancy packaging. It is generally of my opinion that people here are deemphasizing the graphical aspects too much in a game about engineering to explore, whereas they should be considered holistically and an essential part of the experience of the game. c:

Apologies, in your original comment, I misinterpreted it as you getting to ignore 'the ground' completely, as opposed to the cloud shadows on the ground which is probably what you meant. On that point I still stand by sampling the global cloud texture as the cost is small. Im going to assume you are talking about the indirect lighting from the terrain onto the ship, otherwise known as 'planet shine' at high altitudes, in which yeah, but I wasn't arguing about that bit. I had even shoddily drawn said texture in my previous, previous comment! (I assume we're ditching the light probes) If you were talking about that level of terrain indirect lighting, where the orange glow of a mountain indirectly illuminates my craft, then I would be talking about cubemaps or raycasting. And I would then note that youve interpreted this whole debacle as me debating how to light the craft and its immediate surroundings and not the terrain as a whole, viewed from a distance. The latter of which wouldn't work with that approach, the mountain simply isnt there even 2km out, or even just behind the mountain you wouldn't have that glow in the cubemap, but you can still see those places. It wouldnt do to see the entire landscape flash with orange just because i happened to drive past a particularly bright rock in the sunset. If you were talking about how the mountain itself is shaded, then would just cutting the scattering ray towards the sun when it hits terrain within the shadowmap suffice as a explanation? :p HAHA, if I have a free weekend you're on!

I wasn't talking only about the ship passing through penumbra in that diagram. I was talking about you viewing a sunset on the ground from like 30km above, parts of the terrain is sunlit (1) , part of the terrain in orange sunset in a narrow band (2) , part of the terrain shrouded in darkness (3) . The cloud's sunset is delayed from being higher up in the atmopshere (4) . Something above the atmosphere (5). A single cubemap or probe or what-have-you cannot account for (1) (2) (3) (4) (5) viewed at the same time, or even just (1,2,3), especially as it moves across the surface. very fast. :c Having the scatterer shade surfaces would solve the issue of sun-lighting no worries, but the ambient sky light is not practically dealt with a single lightprobe across all the surfaces you can see typically (unless you simply never left the ksc or something. Like in most games with limited kilometer-wide maps in which this technique is viable.) I don't think you can just dismiss it because of cloud cover unless kerbin is permanently overcast like eve. You can still very much see the ground above the cloud layer. This would also not apply to Duna. Clouds are usually generated from a b&w texture heightmap[1] , you can sample that once to get vague blurry shadows and etc, there is little performance hit from it. This is also I figure how they have cloud shadows right now. The warp isnt like normal speed or maximum overdrive with no in-between though. Simply having an absurdly fast velocity is also a thing you do regularly in this game and few others. KSP by nature doesn't leave alot of room for shortcuts that don't feel obvious. As per the previous comment, you aren't building a single low res sky box once, you are building it every frame in which its only valid for rendering the immediate area on the surface. This is ok if its just literally just your vessel (see footnote [0] in previous comment) and/or you are just computing blurry reflections. This 'skybox' isnt valid 10km,20km,50km away, a distance you can very much see. esp as you rise higher. I also did not suggest raycasting for diffuse surfaces (which would require multiple rays), either, only reflective ones, which would just continue the existing ray in a different direction. Thus assuming the 'sky is clear' seems the most practical to me, and considering your case of clouds, just using a cheap sample of the cloud texture for checking overcast areas which can be integrated into the cheap ambient light. if the terrain/ship underneath is under a brighter area of a pre-blurred cloud texture, the light renders this area greyer to compensate. [1] the blocky shapes of the ksp2 clouds heavily imply texture sampling with bilinear blending. Here, upscaled noise as comparison. Eve redux also uses pre-made 2d textures. Was asking about using sdfs for the clouds.