Bug Status [3/11]

[dandoesstuff]

this is a certified bug report classic

[Scarecrow71]

The fact that bugs were reported for issues 7 (Signals go through planets and moons (CommNet/Antennas not affected by occlusion) and 19 (Can't create a maneuver node within another SOI) tells me several things.

1. The developers made changes to the core game loop from KSP1 to KSP2 that were not needed.
2. The developers made these changes without assessing impact to the community or gameplay.
3. The developers made these changes without talking to the community about how these changes would affect their enjoyment of the game.

I'm not sure why the blanket statement "Working as intended/designed" was put out there for these other than for the developers to simply say "We don't want to change these things because that's how we like them".  And the fact that the community has created the bug reports and upvoted them (52 upvotes for #19; #7 is in the archive for some reason and we cannot see how many upvotes it originally got) tells me that the community has given the developers the feedback on these issues that they say they want.  Anything less than acknowledging that they made a bad decision and it will get fixed is simple tone-deafness to the community.

With that said, I don't care about issue #7 personally...but that doesn't mean it shouldn't get attention.  The game is (mostly) modeled on real-life physics, and the plain fact is that celestial bodies IRL do in fact occlude antenna signals.  If the planets and moons block out the light, why don't they block out comms?  And if they don't block comms, then why don't they block the light?  Heck, even way back in 1996, Jeff Goldblum and Bill Pullman were talking about line-of-sight and taking the curvature of the Earth into account as it related to the aliens need to use our own satellites to communicate during their planned invasion.  And nothing in the last 30 years has happened that makes LOS obsolete.

I personally dislike everything about the new maneuver nodes, including issue #19.  The nodes are fidgety, hard to deal with, and simply don't work properly.  The fact that we can't plan additional maneuvers outside the current SOI - such as long-range/long-term gravity assists, or setting up intercepts - is just stupid.  This is core gameplay functionality in KSP1, and is a critical factor in real life space travel (or would be, if we as a species could ever get over ourselves and work on this).  IRL, there would be no way we wouldn't have computers that could do SOI change maneuvers or set up gravity assists for probes months - nay, YEARS - ahead of time.  We wouldn't simply plot a course for Alpha Centauri and says "We can't plan for an orbital path until we get into the star's SOI".  That node would be created and tweaked every single hour of every single day until it was time to do the burn.

I'd like to add something to the SOI maneuver node thing.  Why can't we time warp into another body's SOI?  Why do I have to zoom in and time warp as close to the intersect as possible...and then wait until the SOI change happens?  Why can't I just time warp from LKO to Low Jool Orbit?  What's the point of time warp if we can't do that?  And if we can't do that, how do you expect us to be able to go interstellar?  Or are we going to be able to time warp into another stars' SOI?

Edited March 12 by Scarecrow71

[jclovis3]

Regarding #6 on time warp restrictions... I understand that maybe part of this lies in lessons learned from KSP1 where an auto time warp has to be able to increment and decrement the time scale as you get closer to celestial bodies (CB) because when you get below a certain altitude, say the height of the tallest mountain, you need time to calculate the terrain mesh to see if there will be an impact. But, IMHO, if your Pe is greater than the height of the tallest mountain AND there is no atmosphere, THEN the time warp restriction should be raised. There is but one reason I can think of to have a relatively lower time warp within a small body SOI and that is for how quickly you can run into and beyond the Pe marker if the player doesn't have enough time to react and abort or slow it down manually. For this, I would say that the time warp restriction should at the very least force the player to observe the active vessel passing through the SOI for at least ten seconds if an escape is trajected. For stable orbits however, there should be no limit, or at least not while the CB itself is the center of the camera focus. I can see maybe setting a limit when the ship is the center of focus as it can be near impossible to see where the ship is in relation to it's Ap/Pe markers when the camera is moving around rapidly. The other reason I think time warp scales were meant to slow down at higher altitudes is because they didn't just jump directly from 10000x to 4x but had to decelerate smoothly over time, which could lead to an overrun of the expected stopping point if there wasn't a way to force a step down in warp speeds getting near it. This though I feel can be overcome with a calculated curve similar to the trajectory curve where the rate of time warp can be reduced  as you approach the intended stopping point just as smoothly as the rate of altitude change slows as you approach the Ap of a suborbital trajectory. For LOD settings on CB assets, you can use the lower resolution textures while at higher warp speeds to improve performance. LOD need not be reserved for distance.

[NexusHelium]

What day is it?! FRI- wait hold on…

[Filed.Teeth]

Ya think NASA etc. doesn't plan maneuver nodes in future SOI's?

Doubt if they say "ok, we'll come into Ceres at 50k and then figure it out when we get there...."

(said by others in different wordings, this is just what's in my head)

Edited March 13 by Filed.Teeth

[Superfluous J]

Note: You CAN put a maneuver node at Mun's SOI when you're in Kerbin's SOI.

You just have to do it on the portion of your projected path that is in Kerbin's SOI, not Mun's.

...which is enough of a PITA that it's not really worth doing, but still it's POSSIBLE.

[Fizzlebop Smith]

20 minutes ago, Filed.Teeth said:

Ya think NASA etc. doesn't plan maneuver nodes in future SOI's?

Doubt if they say "ok, we'll come into Ceres at 50k and then figure it out when we get there...."

(said by others in different wordings, this is just what's in my head)

This is one of the chief things bugging me about orbital maneuvers, there are some work arounds. Most of the time it is more beneficial to perform a maneuver as far out as possible, for maximum distance for DV, but what about a capture?
One of the work arounds i employ is to create a maneuver and move it ahead in time via MNP. The in-game GUI will let you slide it ahead but i don't know if you can slide it into another SOI.

The also changed the node burn mechanics. It is so similar yet so different in the way that it no longer splits the burn. For some reason the split made much more sense to me for calculations along the tangent.


Time Warp is insanely infuriating. I HATE the works as intended rhetoric when something is clearly not functioning in a way that is conducive to play. Putting along a celestial body for 10 minutes in real time while waiting to execute next action is atrocious. It may be functioning as intended with obvious tweaking.
I know the physics models need to drastically change when Atmo is encountered, and the game is queued to switch how it crunches these physics at a certain point. Let's continue to refine the formula applies until we can visit other bodies without brain bleed.
 

 

7 hours ago, Scarecrow71 said:

The fact that bugs were reported for issues 7 (Signals go through planets and moons (CommNet/Antennas not affected by occlusion) and 19 (Can't create a maneuver node within another SOI) tells me several things.

1. The developers made changes to the core game loop from KSP1 to KSP2 that were not needed.
2. The developers made these changes without assessing impact to the community or gameplay.
3. The developers made these changes without talking to the community about how these changes would affect their enjoyment of the game.

I'm not sure why the blanket statement "Working as intended/designed" was put out there for these other than for the developers to simply say "We don't want to change these things because that's how we like them".  And the fact that the community has created the bug reports and upvoted them (52 upvotes for #19; #7 is in the archive for some reason and we cannot see how many upvotes it originally got) tells me that the community has given the developers the feedback on these issues that they say they want.  Anything less than acknowledging that they made a bad decision and it will get fixed is simple tone-deafness to the community.

With that said, I don't care about issue #7 personally...but that doesn't mean it shouldn't get attention.  The game is (mostly) modeled on real-life physics, and the plain fact is that celestial bodies IRL do in fact occlude antenna signals.  If the planets and moons block out the light, why don't they block out comms?  And if they don't block comms, then why don't they block the light?  Heck, even way back in 1996, Jeff Goldblum and Bill Pullman were talking about line-of-sight and taking the curvature of the Earth into account as it related to the aliens need to use our own satellites to communicate during their planned invasion.  And nothing in the last 30 years has happened that makes LOS obsolete.

I personally dislike everything about the new maneuver nodes, including issue #19.  The nodes are fidgety, hard to deal with, and simply don't work properly.  The fact that we can't plan additional maneuvers outside the current SOI - such as long-range/long-term gravity assists, or setting up intercepts - is just stupid.  This is core gameplay functionality in KSP1, and is a critical factor in real life space travel (or would be, if we as a species could ever get over ourselves and work on this).  IRL, there would be no way we wouldn't have computers that could do SOI change maneuvers or set up gravity assists for probes months - nay, YEARS - ahead of time.  We wouldn't simply plot a course for Alpha Centauri and says "We can't plan for an orbital path until we get into the star's SOI".  That node would be created and tweaked every single hour of every single day until it was time to do the burn.

I'd like to add something to the SOI maneuver node thing.  Why can't we time warp into another body's SOI?  Why do I have to zoom in and time warp as close to the intersect as possible...and then wait until the SOI change happens?  Why can't I just time warp from LKO to Low Jool Orbit?  What's the point of time warp if we can't do that?  And if we can't do that, how do you expect us to be able to go interstellar?  Or are we going to be able to time warp into another stars' SOI?

Often i find Scarecrow a bit aggressive in approach with sometimes what i am convinced is hyperbole to illuminate a point. But often i agree with the point. This time you have summed up so very much of what i feel.
If a couple elements from KSP1 were already incorporated into the base game i feel i would already have the replay value to silence me until significant updates arrive.

They have completely killed the original gameplay loop without offering anything substantial to replace it. Many of the UI changes and tweaks are a result of feedback that i feel could have been polled from various community resources before the game ever even hit the ground.
If communication was truly what was desired, they would have had a series of feedback opportunities on things at the early development stage.

Things like asking for a write up about what people like about maneuver nodes and how they could have improved.
Which are your favorite mods from KSP1
Which core gameplay features are a MUST

I could go on... there are examples of other companies with close ties to the community that actually foster that communication early enough on for it to matter most.

Just think about what could have happened with a CM in predevelopment  with a select group of people and prominent streamers previewing videos and doing interviews and funneling the feedback of their base.
Monthly KERBs about feature they want to emply with opportunities to steer them in a more community friendly direction from the onset.

I still think this will eventually shape up to be one of the greatest games of all times, but im becoming more and more convinced that this will solely be due to the amazing efforts of the modding community.

My tirade is over... props to scarcrow-domus for maintaining objectivity where i let my hope and excitement often overrule my usually stoic sense of realism.  KSP always gets me in the feelz and i get so excited about the littlest things only to be sad.

 

[Superfluous J]

14 minutes ago, Fizzlebop Smith said:

Time Warp is insanely infuriating. I HATE the works as intended rhetoric when something is clearly not functioning in a way that is conducive to play.

I don't see where they said time warp at lower altitudes being too slow was working as intended.

However, I actually think, as the industry defines it, that's exactly what it is.

"Working as intended" isn't rhetoric, and it isn't an excuse. It's a description of the state of the bug report. i.e., you don't like something, you report it as a bug, and they classify it not as a bug (because it isn't) but instead as a request for them to reconsider a design decision (which they should). The system is working exactly the way they intended it to work. That intention, however, is wrong/bad/whatever and needs to be reconsidered and changed. This is fundamentally different than "we thought for sure we wrote it to do something else so now we have to figure out what's wrong" (i.e., a bug)

You're complaining that they're giving excuses, when all they're doing is categorizing what we've told them we don't like.

[Fizzlebop Smith]

17 minutes ago, Superfluous J said:

I don't see where they said time warp at lower altitudes being too slow was working as intended.

However, I actually think, as the industry defines it, that's exactly what it is.

"Working as intended" isn't rhetoric, and it isn't an excuse. It's a description of the state of the bug report. i.e., you don't like something, you report it as a bug, and they classify it not as a bug (because it isn't) but instead as a request for them to reconsider a design decision (which they should). The system is working exactly the way they intended it to work. That intention, however, is wrong/bad/whatever and needs to be reconsidered and changed. This is fundamentally different than "we thought for sure we wrote it to do something else so now we have to figure out what's wrong" (i.e., a bug)

You're complaining that they're giving excuses, when all they're doing is categorizing what we've told them we don't like.

Essentially you are arguing semantics to agree with me. I am not familiar with the nomenclature of the industry.  I was trying to mention my frustrations in about the mechanic. Not the bug.

Rhetoric
Noun
1. the art of effective or persuasive speaking or writing, especially the use of figures of speech and other compositional techniques:
'working as intended' means that the base mechanics involved are crunching the way they were intended and for the uninitiated masses is a figure of speech regarding the state Timewarp Mechanic

This is supposed to be the place that the community comes to voice its frustrations. Instead of disagreeing or voicing a different point a view, it feels there are a couple people that try to enforce a policy on focusing on a semantic quibble. 
 It needs tweaks. The outreach of the dev team often feels as rhetoric. Things thrown our way to appease, and often without sincerity. 

They may not have said It works as intended. The core of my post revolves around things i have and issue with still and this is one of the mediums that are provided to voice my frustrations. 
Not incorporating core Game Loop Mechanics that i loved so much about KSP1 and Timewarp are by biggest gripes... and {my  perception] of how community communication is currently being handled.

 

Edited March 13 by Fizzlebop Smith

[Superfluous J]

33 minutes ago, Fizzlebop Smith said:

Not incorporating core Game Loop Mechanics that i loved so much about KSP1 and Timewarp are by biggest gripes... and {my  perception] of how community communication is currently being handled.

Amusingly, time warp works about the same in KSP2 as it does in KSP1, so at least that core game loop mechanic was incorporated.

But seriously, I do understand you are frustrated. I'm merely suggesting you be frustrated that things aren't working the way you want, NOT that the developers don't think your concerns are valid due to "hey we wanted it this way so ,,|, "

[ShadowZone]

22 hours ago, ShadowZone said:

It hampers more complex trajectory planning, same as the choice to limit maneuver nodes to stop working when exceeding the calculated dV of the active vehicle (which can be demonstrably wrong often times).

I just want to add that with mods like Flight Plan you can still create maneuvers that exceed the displayed dV of your vehicle. So the functionality IS in fact still in the game, just blocked when manual user input is applied.

Again, please change this. It's fine to show "vessel will run out of fuel" or some other kind of warning, but straight up preventing people from doing something that in fact does not hurt their gameplay is just wrong. I know it was said this is because something with interstellar later down the line, but even then I cannot imagine what this might be.

[magnemoe]

17 minutes ago, ShadowZone said:

I just want to add that with mods like Flight Plan you can still create maneuvers that exceed the displayed dV of your vehicle. So the functionality IS in fact still in the game, just blocked when manual user input is applied.

Again, please change this. It's fine to show "vessel will run out of fuel" or some other kind of warning, but straight up preventing people from doing something that in fact does not hurt their gameplay is just wrong. I know it was said this is because something with interstellar later down the line, but even then I cannot imagine what this might be.

This, and I had an bug there listed dV was 40% of the actual one on my Duna lander. Some bug with side tanks. Used flight plan to circulate as could not do it manually. Now I could just burn prograde at Ap but prefer nodes. 

[The Aziz]

2 hours ago, ShadowZone said:

just want to add that with mods like Flight Plan you can still create maneuvers that exceed the displayed dV of your vehicle. So the functionality IS in fact still in the game, just blocked when manual user input is applied.

How does it look like then if it can't take change in ship parameters into account? The planned trajectory bends according to changes in velocity at given  maximum thrust (which can be altered by changing thrust limit), but once out of fuel, there's no change in velocity possible, with no thrust applied. What does it show then?

[magnemoe]

1 hour ago, The Aziz said:

How does it look like then if it can't take change in ship parameters into account? The planned trajectory bends according to changes in velocity at given  maximum thrust (which can be altered by changing thrust limit), but once out of fuel, there's no change in velocity possible, with no thrust applied. What does it show then?

Not sure how it work, I assume mass stays the same for calculations. For my bugged Duna lander the estimated burn times was way to short even i dry and actual mass was correct. K2-D2 calculated correct burn time. 

[Fizzlebop Smith]

7 hours ago, Superfluous J said:

Amusingly, time warp works about the same in KSP2 as it does in KSP1, so at least that core game loop mechanic was incorporated.

But seriously, I do understand you are frustrated. I'm merely suggesting you be frustrated that things aren't working the way you want, NOT that the developers don't think your concerns are valid due to "hey we wanted it this way so ,,|, "

 

I tried to make it clear from the onset that my frustration was exactly that. But I will add weight to thay by saying it is not working the "many of us would like"

I try not to devolve into personal attacks and try to step away when frustrations mounts. I don't like tp be argumentative.

My perception regarding the forum causes frustration too. It seems a number of people will post a particular view regarding a bug / unfavorable mechanic.

My thoughts seem to tell me others would either respond with,

"OH I agree, that mechanic is quite irksome"

Or alternatively

People may say some variation of,

"So wrong, I like that," / "No! Don't change that"

 

But it often does not proceed thay way.. With members providing opinion about other factors.

It often involves quibbles of verbiage, syntaxes, or heaven forbid the OP was not native to english.

A quantitative sample should be able to be gathered from various feed backs.

LUA training on a LLM to parse the  digital tonnage.  The feedback provides value to the development team, not specific choice of language.

I am not talking about the Toxic vitriol spewed across much of reddit, just a general tendency to not actually discuss the elements highlight by an OP in favor discussing various qualifiers used to support the stance.

I really try to disagree by posting supporting reasons for my view instead of trying to minimize the other other person's view.

 

I do not feel that the core gameplay loop was maintained, not as a career player. I even feel the science returns don't full support a realistic approach to the tech tree.

 

KSP1 could approach the tree without missions. KSP2 does not have that. In KSP1 the contracts supplemented the gamelplay "loop" of the game with 2 having no actual loop.

 

By loop I mean replayability.  There is no replay excitement with completing the same missions in perpetuity. I understand they may add more missions... my quibble is the lack of a loop. No replay. I want unique missions.

From my perceptive lensing this means they did not maintain something that KSP1 nailed. In essence the distilled sum of my frustrations.

Taking something thay worked in favor of something else that is untested. 

 

[Tooch__]

Quote

Can't create a maneuver node within another SOI  Working as intended. Evaluating as feedback

Seriously??? I gave KSP2 another try recently and 30 hours in that is easily number 1 or 2 on the list of things that have been annoying me the most. Whole maneuver system needs a full overhaul in my personal opinion.

Maneuvers were really clunky and obnoxious to use without mods in KSP1. I was really hoping that KSP2 would be improving the system but somehow its even worse

[Tooch__]

On 3/12/2024 at 12:51 AM, Darta01 said:

Ah yes! The maneuver planning tool that does not allow you to plan maneuver!

This is a terrible design choice

Seriously. They took a system that was already kind of clunky to use in KSP1 and rather than improving it, they managed to make it worse.

[Tooch__]

On 3/11/2024 at 6:09 PM, The Aziz said:

As for the node creation, whose idea was this? We can create one on the main path when it goes through another SOI, far away from camera and everything, but not on the cut piece when we CAN focus the camera for better accuracy? I want to know in advance if I need additional early correction burn that will make orbital insertion cheaper or not.

The whole basis for the maneuver node system is incredible annoying. Why do I need to somehow pan my camera over to the part of the main trajectory in order to place a node rather than just doing it when im focused on the target? Why does the maneuver node even need to be on my screen when im adjusting it- I dont care whats happening at the node, I care whats happening to the trajectory im trying to influence, give me a menu in the bottom left to tweak. Also why physically stop me from planning the entire maneuver just because the game thinks I dont have enough fuel?- Even when the game is actually correct about how much deltaV I have (which it often isnt), it can be helpful when designing stuff to see how much more deltaV I would need.

Maneuvers were clunky and annoying in KSP1, and rather than improving them they made them worse. 

[kdaviper]

2 hours ago, Fizzlebop Smith said:

 

I tried to make it clear from the onset that my frustration was exactly that. But I will add weight to thay by saying it is not working the "many of us would like"

I try not to devolve into personal attacks and try to step away when frustrations mounts. I don't like tp be argumentative.

My perception regarding the forum causes frustration too. It seems a number of people will post a particular view regarding a bug / unfavorable mechanic.

My thoughts seem to tell me others would either respond with,

"OH I agree, that mechanic is quite irksome"

Or alternatively

People may say some variation of,

"So wrong, I like that," / "No! Don't change that"

 

But it often does not proceed thay way.. With members providing opinion about other factors.

It often involves quibbles of verbiage, syntaxes, or heaven forbid the OP was not native to english.

A quantitative sample should be able to be gathered from various feed backs.

LUA training on a LLM to parse the  digital tonnage.  The feedback provides value to the development team, not specific choice of language.

I am not talking about the Toxic vitriol spewed across much of reddit, just a general tendency to not actually discuss the elements highlight by an OP in favor discussing various qualifiers used to support the stance.

I really try to disagree by posting supporting reasons for my view instead of trying to minimize the other other person's view.

 

I do not feel that the core gameplay loop was maintained, not as a career player. I even feel the science returns don't full support a realistic approach to the tech tree.

 

KSP1 could approach the tree without missions. KSP2 does not have that. In KSP1 the contracts supplemented the gamelplay "loop" of the game with 2 having no actual loop.

 

By loop I mean replayability.  There is no replay excitement with completing the same missions in perpetuity. I understand they may add more missions... my quibble is the lack of a loop. No replay. I want unique missions.

From my perceptive lensing this means they did not maintain something that KSP1 nailed. In essence the distilled sum of my frustrations.

Taking something thay worked in favor of something else that is untested. 

 

When discussing a topic, semantics are often very important. It is vital for any discussion to ensure that both sides are actually discussing the same thing, and discussing the semantics is a good way to make sure both parties are on the same page.

For example there was quite a bit of discussion in the one year anniversary thread about the accuracy of maneuver nodes. Sure there was some dismissive responses to Herbal's concerns, and I presented some skepticism to his initial comments, but after some back and forth I was able to see his point and agree that there could be ways to improve them.

Perhaps there needs to be a KERB for gameplay mechanics that work "as intended" but could be altered to improve gameplay or QOL.

[Dakota]

Hoping to quell some of the frustration about #20 by stating that the status is about whether the issue is actually a bug or not, as this is the K.E.R.B. It's working as intended in the sense of "there's no issue causing this to happen" - not "this is how it is and will never change."

The current functionality is how it was implemented, but - as the status says - we are evaluating the report and your responses as feedback, which may lead to changes in the future. Our development process is iterative and we're constantly listening so we can target player pain points.

We'll look to be clearer about this when bug reports pop up that are based in implementation/design choices instead of actual technical issues.

18 minutes ago, kdaviper said:

Perhaps there needs to be a KERB for gameplay mechanics that work "as intended" but could be altered to improve gameplay or QOL.

I do think more comms about design decisions would help in this area. Something I'll bring up to the team.

Hope that clears things up.

[magnemoe]

13 minutes ago, Dakota said:

Hoping to quell some of the frustration about #20 by stating that the status is about whether the issue is actually a bug or not, as this is the K.E.R.B. It's working as intended in the sense of "there's no issue causing this to happen" - not "this is how it is and will never change."

The current functionality is how it was implemented, but - as the status says - we are evaluating the report and your responses as feedback, which may lead to changes in the future. Our development process is iterative and we're constantly listening so we can target player pain points.

We'll look to be clearer about this when bug reports pop up that are based in implementation/design choices instead of actual technical issues.

Hope that clears things up.

That is correct, like the communication are not blocked by bodies who they said they would not focus on at this stage. 
Communication is also that kerbals on larger capsules can direct probes locally as they could in KSP 1 even if not in contact with Kerbin, mothership release an probe who land on Eve on the other side of Kerbin.
Still they should say we fix that after all the critical bugs and all would be happy. 

[Biggen]

I honestly can't hardly even be bothered to do low gravity bodies like Bop or Pol because the low time warp is just horrendous to deal with.  This really needs to be fixed in  my opinion.

[Scarecrow71]

2 hours ago, Tooch__ said:

The whole basis for the maneuver node system is incredible annoying. Why do I need to somehow pan my camera over to the part of the main trajectory in order to place a node rather than just doing it when im focused on the target? Why does the maneuver node even need to be on my screen when im adjusting it- I dont care whats happening at the node, I care whats happening to the trajectory im trying to influence, give me a menu in the bottom left to tweak. Also why physically stop me from planning the entire maneuver just because the game thinks I dont have enough fuel?- Even when the game is actually correct about how much deltaV I have (which it often isnt), it can be helpful when designing stuff to see how much more deltaV I would need.

Maneuvers were clunky and annoying in KSP1, and rather than improving them they made them worse. 

I'll add that I'm tired of having to pan the camera every which way possible in order to get to the actual controls for the node.  Those prograde/retrograde handles inside a planet?  Good luck using them!  Oh, you need the normal/anti-normal, but they are literally hidden inside the rest of the node?  We meant for that to happen!

1 hour ago, Dakota said:

The current functionality is how it was implemented, but - as the status says - we are evaluating the report and your responses as feedback,

Based on this comment, @Dakota, can you help explain why the bug report for issue #7 was moved to the archive with no post or explanation in the bug report given as to why?  If the intent of the statement "Working as designed" is to illicit feedback from the community, then why was the bug report closed without addressing the fact that the community wanted this changed?

[kdaviper]

1 minute ago, Scarecrow71 said:

 

Based on this comment, @Dakota, can you help explain why the bug report for issue #7 was moved to the archive with no post or explanation in the bug report given as to why?  If the intent of the statement "Working as designed" is to illicit feedback from the community, then why was the bug report closed without addressing the fact that the community wanted this changed?

Because KERB is a place for bug reports, not discussion on changing mechanics that are working as intended.

[The Aziz]

7 minutes ago, Scarecrow71 said:

 

Based on this comment, @Dakota, can you help explain why the bug report for issue #7 was moved to the archive with no post or explanation in the bug report given as to why?  If the intent of the statement "Working as designed" is to illicit feedback from the community, then why was the bug report closed without addressing the fact that the community wanted this changed?