Jump to content

Bug Status [7/28]


Recommended Posts

6 hours ago, Alexoff said:

Oh yeah, I forgot the main rule of IG - fans should use their imagination to paint the whole picture. What is the answer to my question? Am I right or not?

Don’t think you’ll get an answer, we’re now at the “under promise and either underdeliver or never deliver” stage.

Back in April they said the update cadence was slowing down to provide “more robust” updates, and (paraphrased, read the April 28th dev update “shine on you crazy planet” for original source) that it would allow for more resources for science and to progress down the roadmap quicker.

Since then they’ve released an update with a game breaking bug that should’ve been found immediately  but somehow wasn’t and… have provided no shown-to-the-community progress on science or any pictures or gifs or anything to show us what it will be like. Let alone thermals. A whole dev update on them with no in engine videos or even images. 

The patience is running thin even here “negative” comments are getting more likes than “positive” ones. Discord is still majority positive, but I think that’s the last place and that’s where they interact with the community the most. 

They say they want honest feedback and then ignore any feedback that isn’t singing their praises.

Edited by moeggz
Spelling. It’s impossible to not find at least one mistake after posting
Link to comment
Share on other sites

6 hours ago, Alexoff said:

Oh yeah, I forgot the main rule of IG - fans should use their imagination to paint the whole picture. What is the answer to my question? Am I right or not?

 

23 hours ago, nestor said:

It usually means we were able to reproduce it, it is tracked and it is going through the process. It will eventually be scheduled to be worked on depending on a lot of factors. 

 

Link to comment
Share on other sites

23 hours ago, nestor said:

It usually means we were able to reproduce it, it is tracked and it is going through the process. It will eventually be scheduled to be worked on depending on a lot of factors. 

 

On 7/28/2023 at 12:20 PM, Intercept Games said:

Note: this report is not fully representative of the work our team is focused on. This is just to provide insight into our progress on the most concerning issues to our community. Additionally, the lack of a status update does not imply a lack of importance or general progress - we just do not have anything to share at this time.

These do not say the same thing. The comment on the post implies that even those bugs without a status update have had “general progress”

Nestor’s comment implies they have been confirmed, but have yet to be scheduled to be worked on. It’s still not clear. A simple “yes” or “no” to @Alexoff question would have cleared it up. This is the forum and the place to get clarity, I don’t think it’s ridiculous to ask for clarification.

Link to comment
Share on other sites

10 minutes ago, moeggz said:

 

These do not say the same thing. The comment on the post implies that even those bugs without a status update have had “general progress”

Nestor’s comment implies they have been confirmed, but have yet to be scheduled to be worked on. It’s still not clear. A simple “yes” or “no” to @Alexoff question would have cleared it up. This is the forum and the place to get clarity, I don’t think it’s ridiculous to ask for clarification.

Sure, but...
What does that have to do with patience running thin? You can ask for more clarity and be patient simultaneously?

Link to comment
Share on other sites

On 7/28/2023 at 3:07 PM, Darrin H said:

We do actually - and we have a great relationship with AMD where they've sent us cards for testing.

However, this bug does not occur on every AMD gpu, and in fact we've narrowed it down to a specific series and have a card on the way to confirm that.

AMD 6900xt Founder edition.  It makes the visuals behave sooooooo weird just after V0.1.3

Link to comment
Share on other sites

On 7/28/2023 at 9:07 PM, Darrin H said:


However, this bug does not occur on every AMD gpu, and in fact we've narrowed it down to a specific series and have a card on the way to confirm that

Never had an issue where my software bugs out due to specific hardware. How are such issues even handled? Here's another topic for an in depth dev post... 

Link to comment
Share on other sites

2 hours ago, cocoscacao said:

Never had an issue where my software bugs out due to specific hardware. How are such issues even handled? Here's another topic for an in depth dev post... 

 

2 hours ago, The Aziz said:

It's more common than you think. And with thousands of possible configurations on the market, the chance of something going wonky isn't zero.

This is especially common with Bethesda games when it comes to GPUs. The only time specific hardware isn't a possible cause is with Macs and other iOS products. Say what you want about Apple products, but the reason their stuff works so reliably is because their software only needs to function for a few very specific hardware configurations.

 

15 hours ago, regex said:

 I wonder how many others out there aren't bothering with the pedantic circular arguments around here and are instead just in waiting mode?

Me. I've pretty much resigned to just waiting till next year to really be able to enjoy the game. I personally prefer smaller patches with 3 or 4 fixes than large sweeping patches, but they've likely chosen their current path for reasons I'm not privvy to. No point in complaining any further if all it's going to do is make progress slower.

 

Link to comment
Share on other sites

Thanks for the up! It's great to see this approach to bug reporting take off.

As one of those affected by #5, I can assure you it impacts the AMD RX 6800 XT - which (ironically) I bought because it was the recommended AMD card when EA first came out. That said, from what I've seen this bug is mainly just annoying. I think #1 - 4 are all much more important - and especially 1 & 2, but I'd imagine different skill sets are involved in fixing those so work on 5 presumably doesn't delay or impact work on 1 - 4.

I've noticed a maneuver node creation bug (which I've reported) that I hope makes it onto this list. Did you know that the order of node creation can result in a situation where editing the earlier node does not cause the later node to follow along with the patch from the earlier node? It's easy to reproduce. Just create a node some way ahead of your craft on your orbit, then create another node between that one and your craft. If you edit the closest node (the second one created), the later node stays on the old orbit and doesn't follow along on the patch resulting from the earlier node. If you create them in the opposite order all works fine, but creating them out of order makes this issue occur.

This video shows what I'm talking about if you'd prefer a visual.

https://imgur.com/a/1BgZ8r3

 

Edited by schlosrat
Added note about video
Link to comment
Share on other sites

1 hour ago, schlosrat said:

it impacts the AMD RX 6800 XT - which (ironically) I bought because it was the recommended AMD card when EA first came out.

Which is even funnier when you consider they confirmed not having any of these on the studio and having to ask AMD for samples.

15 hours ago, regex said:

Steam user numbers be damned. And seriously, why the hell do those numbers matter? It's an early access game.

People move on. Numbers might not matter to you, and that's fine, but they sure matter to them. If people move on KSP2 is stuck with whatever is funded until now.  Considering that the loyal-est fans already gave them their money, that means all the sales they have left to possibly make will come from 2 places:

Convincing the remaining people on the edge/refunders that EA will work, or create new customers. For the later (as the first one is still failing), they've stopped advertising because the game is a wreck and was doing more harm than good to attract new customers. The numbers matter because that's literally what decides the future of their investment: post 1.0 support, DLCs, 1.X+ versions with new stuff and so on.

 

Link to comment
Share on other sites

On 7/28/2023 at 1:48 PM, kicka55 said:

1. I think the main problem in KSP is that if you stack 20 tanks they are all the same. In reality bottom tanks are much thicker and more sturdy than upper tanks. A solution I would be happy with in KSP is if you add a new tool that shows all the rocket nodes, and by clicking on a node you can enhance the strength of it by adding mass to both parts connected to the node. Maybe it sounds simpler to implement than it is but I'd really dig that. Not sure how beginner friendly that is but you could well ignore this option until you grow into it some day. 

  

Personally not a big fan of this idea, I feel like for a video game predictability is key and this seems to make it way more complex than it needs to be. I can’t imagine launching over and over and increasing the “thickness” by one every time for every node to find the optimal weight and strength for each tank, and then having to redo it with every other size every rocket. 

Link to comment
Share on other sites

On 7/30/2023 at 9:47 AM, schlosrat said:

I've noticed a maneuver node creation bug (which I've reported) that I hope makes it onto this list. Did you know that the order of node creation can result in a situation where editing the earlier node does not cause the later node to follow along with the patch from the earlier node? It's easy to reproduce. Just create a node some way ahead of your craft on your orbit, then create another node between that one and your craft. If you edit the closest node (the second one created), the later node stays on the old orbit and doesn't follow along on the patch resulting from the earlier node. If you create them in the opposite order all works fine, but creating them out of order makes this issue occur

I believe this is intended as it could be really computationally expensive to update all subsequent maneuver nodes based off the first in the chain in real time. I believe if you try to adjust the next node in the chain that it will update immediately however I don’t believe this can be fixed due to the fact that there can be many nodes after the first. 

Link to comment
Share on other sites

3 hours ago, Nicrose said:

I believe this is intended as it could be really computationally expensive to update all subsequent maneuver nodes based off the first in the chain in real time. I believe if you try to adjust the next node in the chain that it will update immediately however I don’t believe this can be fixed due to the fact that there can be many nodes after the first. 

I don't know if it's intended or not, though it would seem really odd to me if it were. My hunch is that it's unintended.

Also, I've found that it's actually not computationally expensive. I've already fixed this in the Node Manager mod where v0.6.0 of that mod now supports out-of-order node creation.  This fix won't help for nodes created manually, but for mods that do call NM, the fix works fine and is a proof of concept for one way to fix it. The fix itself is pretty simple. You can see a video of it working here:

https://i.imgur.com/bYK6xzk.mp4

Link to comment
Share on other sites

11 hours ago, schlosrat said:

I don't know if it's intended or not, though it would seem really odd to me if it were. My hunch is that it's unintended.

I think this would be intentional. If you adjust the first node in a 2+ node chain, how does the game know where to move subsequent nodes to?  Does it move the other nodes so they occur at the same time as before? Move them to the closest position to where they were? Maybe to give the closest final trajectory to before? Basicly, by moving the first node you are introducing a variable (where to move subsequent nodes), and you should resolve this variable manually. Anything else is a guess.

Link to comment
Share on other sites

13 minutes ago, Turbo Ben said:

I think this would be intentional. If you adjust the first node in a 2+ node chain, how does the game know where to move subsequent nodes to?  Does it move the other nodes so they occur at the same time as before? Move them to the closest position to where they were? Maybe to give the closest final trajectory to before? Basicly, by moving the first node you are introducing a variable (where to move subsequent nodes), and you should resolve this variable manually. Anything else is a guess.

Try KSP1. It does that.

Link to comment
Share on other sites

1 hour ago, The Aziz said:

Try KSP1. It does that.

I'm playing KSP 1 as I write this, and can confirm that KSP 1 moves all subsequent nodes keeping them at the same time. I'm not saying you can't do it that way, or even that it's a worse option, I'm just saying that there is an element of guess work going on and that may be a reason it's intentional with KSP 2. KSP 1 is probably a better way of doing it, as it works fine for minor corrections, which is normally the case. Either way, I usually check all nodes after a change.

Link to comment
Share on other sites

26 minutes ago, Turbo Ben said:

KSP 1 moves all subsequent nodes keeping them at the same time.

Never thought about this... What happens if you change it so much that your trajectory crashes somewhere, making subsequent nodes nonexistent?

Link to comment
Share on other sites

  • KSP2 Alumni
On 7/30/2023 at 2:32 AM, cocoscacao said:

Never had an issue where my software bugs out due to specific hardware. How are such issues even handled? Here's another topic for an in depth dev post... 

Hardware issues can be tricky because sometimes a problem can only be replicated on certain pieces of hardware (even within the same product line) - and also could be the result of a specific piece of a hardware, let's say an AMD 6800XT GPU, combined with another specific piece of hardware, let's say an Intel i5-12600k. (this is just an example)

The team collects bug reports and telemetry data, and then uses that information to try to replicate the issue internally using hardware available to us. Our QA team has a wide range of test machines, all the way from low-end GPUs to top-of-the-line-omg-why-is-this-so-expensive GPUs - but it's impossible to be able to have every combination of possible components. 

So we work with external partners, whether it be the manufactures themselves (AMD, Nvidia), or with hardware consulting companies, to investigate further, either by letting us borrow hard-to-find components or using their own testing setups.

Once we're able to replicate the issue, that's when we can start to investigate the real cause. And since the issue is rooted in components, we keep our hardware partners up-to-date on progress just in case the issue is caused by something on their end (drivers). 

Link to comment
Share on other sites

Technically not a bug, but I'm wondering if there is any timeline yet for the new terrain rendering system?  My biggest gripe since day one has been planet-side performance, and it's essentially still the same (i.e. really bad) as it was in the first EA release.

I'm just looking for a ray of hope here...

Link to comment
Share on other sites

  • KSP2 Alumni
26 minutes ago, Ashiepoppy said:

Is there a way I can be sent emails or notis about new updates concerning KSP2?

You can use the forum's activity feed and notification features to "follow" certain subforums or users, yes.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...