"Not a bug" discussions

[BenSeidel]

I have noticed a few threads where the posts go along the lines of "I have noticed this inconsistent / unexpected behaviour" and then the reply is simply "not a bug". What exactly does this mean? The most common interpretation is that it must mean "Intended behaviour", which causes people (myself included) to try to argue that it's unintuitive or inconsistent, therefore how could it be intended?

Instead of simply classifying it as being a bug or not a bug, I would suggest using a few different terminologies, that are clearly defined, that may help with dealing with such threads and hopefully reduce the amount number and duration of such arguments. I would also suggest defining these terms and supplying the link when replying to the issue.

So bug stays, if it's a bug it's a bug. All bugs get fixed given enough funds and time.
Not a bug could be broken down into a few categories, an example being:

• Intended behaviour: This is the way the game is intended to run. It was part of some design process where the decision was made for it to operate like that.
• Implementation behaviour: This behaviour occurs this way because of some implementation detail requiring it to be this way. While not part of the game design process, the side effect was know and thought about.
• Unforeseen implementation behaviour: This behaviour occurs this way because of some implementation detail requiring it to be this way, but it only came to light once the feature was released.
• Unforeseen behaviour: Unforeseen behaviours that "just are". This category should usually be used as a placeholder before it gets recategorised after some research, possibly into the bug category

Basically it's allows the specification of whether or not its intended while at the same time if it's required to be that way. It also allows for issues to be "promoted" up the list to a stronger category as time goes by, especially when unforeseen behaviours become desired results.

The list is not canonical, but one version that may be used. Other versions may include Merging "Implementation behaviour" and "Unforeseen implementation behaviour", but I hope that you get the idea.

tldr; Saying "not a bug" seems to cause friction between the community and the developers, using different language could appease the situation, even if its a copy-paste of a standard answer.

[DaveMcW]

First, I want to thank the developers for reading every thread in the bug forum and responding in some way. This is rare for popular games.

Now, there are actually 7 forums where bug reports go to die:

Not a bug
Pending
1 / 0 magic
Known issues
Minor issues
Desyncs with mods
Won't fix.

I think some threads in "Not a bug" belong in one of the other forums. But from a practical standpoint it makes no difference. There are currently zero developer resources allocated to fix stuff in any of these forums.

[HurkWurk]

bugs: the code says Y should happen, and X happens. or the code says Y should not happen and Y happens.
pending: probably a bug, we are checking.
1 / 0 magic: the code doesnt work and we have verified the code is right.
Known issues: bugs we know about.
Minor issues: maybe bugs, maybe not, but issues that are more nagging than breaking.
Desyncs: mods break the code even though they shouldnt.
Won't fix: it may or may not be a bug, but we want the behavior to be that way.


the number one complaint i see is about things that are consistent, but not expected. (north east working differently than south west facing resources).
these may not make much sense, but in a very complex gameplay meta, its actually valuable to understand why and how to exploit those consistent effects.
for instance, it changes how advanced play can work to time slice effects. remember the server operates at 60 ticks per second.

[ssilk]

• Intended behaviour: This is the way the game is intended to run. It was part of some design process where the decision was made for it to operate like that.
• Implementation behaviour: This behaviour occurs this way because of some implementation detail requiring it to be this way. While not part of the game design process, the side effect was know and thought about.
• Unforeseen implementation behaviour: This behaviour occurs this way because of some implementation detail requiring it to be this way, but it only came to light once the feature was released.
• Unforeseen behaviour: Unforeseen behaviours that "just are". This category should usually be used as a placeholder before it gets recategorised after some research, possibly into the bug category

Intended behavior: What is "intended"? What is an intension? What is unforseen? That all implies, that every aspect of a piece of software is planned ahead.

Software development doesn't work like so.

Software is planned, something is implemented, cause it was planned. Then there is something. Is it a bug? Or not? It doesn't have anything to do with intension. It's more like writing a book, writing sentences. Sentence one says "Leaveas are green". Then another programmer writes "Leaves are brown". Is it a bug? Intension? Accident?

The only thing you can say is: Does it match the former plan or not? Everything else is opinion.

[BenSeidel]

The only thing you can say is: Does it match the former plan or not? Everything else is opinion.

Yes, but it's about communicating the opinion of the Factorio team with the community.

here's an example, contrived as it may be:
Factorio 13.0 come out. My inserters are picking up two items instead of one that breaks my factory.
I raise a bug report describing that all inserters are getting the stack size bonus and not just the stack inserters.

Would a good response be "not a bug" or "It's the intended behaviour, one chosen during our design discussions". At least if you get the second response you know that they have already talked about it and weighed up the pros/cons of the decision.

Another example is:
"My robots travel across the entirety of my base to get an item instead of trying to complete a task that is right next to them."
A better response than "not a bug" would be "It's a side effect of the low cpu algorithm used to control the task allocation of the robots".

Anyway, if giving a reason for the bug is too much effort, then the standard response should be
"Not a bug, If further discussion is required please create a thread in the Suggestions forum". At least then you know you can continue to discuss the issue with the community without it being "case closed".

[steinio]

Why should the developers waste time with discussions here.
Also the reports repeat itself on and on each time some new users install the game.

Greetings steinio

[Koub]

Not a bug can mean several things to me :
- Intended behaviour that was planned and implemented,
- unintended behaviour or side effect that was unforeseen at the moment it appeared, but has been since considered "OK" and became part of the new intended behaviours,
- Behaviour that was not deliberate, but is a consequence of either two first lines.

Some examples of unintended "not a bug" :
- lane splitting underground belt
- land filler filling more than one tile at a time if used a certain way

[ssilk]

Would a good response be "not a bug" or "It's the intended behaviour, one chosen during our design discussions". At least if you get the second response you know that they have already talked about it and weighed up the pros/cons of the decision.
...
At least then you know you can continue to discuss the issue with the community without it being "case closed".

So the issue is not this suggestion but you miss a better type of communication from/with the developers?

A more transparent development-process?

[Deadly-Bagel]

YES we want them to stream their screens while they code and also any design meetings.

Actually I'm impressed with Factorio's developers, I work alongside them and the majority are just ugh. "We know that doesn't work but the code is just mashed together and fragile so we're not going to fix it" and "I'm not going to fix that because it's easier from my standpoint" are responses I've had literally today. Also a ticket I found today "Hi, we fixed this problem and will let you know when it's released" - this was the last entry before the ticket was closed without notification, user was chasing because it still wasn't working but ??? is it a release or standalone fix and has it already been applied but still isn't working?

DID YOU KNOW originally bugs were literally bugs. Computers were programmed with physical transistors and sometimes insects would get in and short-circuit something, causing a bug. (Not sure if this is actually correct, from one of my cooler teachers at some point and it stands to reason).

The definition of a bug is a tricky one. It's not something "unexpected" or "unintended" because that can be good, bad, neither, or either depending on your standpoint. A reasonable description might be "a function written in a way that results in behaviour contrary to requirement". Usually this would result in crash, such as returning/expecting the wrong type, or forgetting to dispose of an object causing a memory leak, or out-by-one error (year 2000 celebration is good example, the new millennium actually started in 2001).

Under this logic, a bug might be inserters moving items in the wrong direction or the wrong quantity of items, or trains saying they're at the wrong station, or refineries requiring petroleum to craft, and basically any non-hardware-related crash. If it's "A single Fast Inserter doesn't keep up with a T3 Assembler making Copper Wire with speed mods" then that's not a bug. Inserters aren't required to do that.

Something else commonly misused is "Glitch" - Some users call any problem a glitch, usually when something doesn't save properly or they get something they didn't expect. I would use this to describe a hardware malfunction due to wear, damage or misuse.

[HurkWurk]

"bugs" were literally. especially in punchcard machines. they would fill in the holes of the card and cause the cards to be misread.
and yes, early computers had a lot of mechanical components that could get gummed up by bugs crawling into the works. there is a reason most clocks are in sealed cases... to keep the bugs out. early computers were not air tight due to the amount of waste heat generated, so bugs got in all the time.

ever seen a copier jam because of a cockroach? its not pretty, and if they get to the fuser, the smell is pretty bad too.

[ssilk]

Sorry, but the last two posts go definitely into direction of off-topic cause it is here totally irrelevant, what a bug is or what not.

[Deadly-Bagel]

The whole topic is off-topic, this should be in GD.

[ssilk]

Hm. Moved from Suggestions to General.

[Mooncat]

tldr; Saying "not a bug" seems to cause friction between the community and the developers, using different language could appease the situation, even if its a copy-paste of a standard answer.

[copy-paste]
Hi <name>, thanks for your report. Sorry for this unexpected behaviour but it is by design. We may improve it in the future so please bear with us.

[Deadly-Bagel]

No, the only problem here is that many players seem to have an incorrect idea of what a bug is. Rather than try to understand the term (which would help the devs because topics would be correctly sorted between bug reports and suggestions) you want the devs to use different wording? Sorry but I don't promote ignorance so I don't agree with you.

[ssilk]

I think (I'm guessing, but that is my impression from watching it) many players have this problem with the current way:

- They are interrupted from game. That is always bad.
- They found, that this interruption is caused by a "bug".
- They invest some work to report this bug (Perhaps they are also proud of this find).
- And then it is told, that it is not a bug.
- Which it is obviously not, cause it interrupts from playing as they want to play the game. Or maybe better: As they are used to play the game.
- And now they fear, that their beloved game keeps like so: Buggy and with behavior, they don't understand, how others can play with.
- Which makes them angry.

Maybe I'm wrong. But when I think back to similar situations when I reported bugs that where not a bug, I can say it was exactly like so.

[Deadly-Bagel]

Yeah, I was tempted to say something about the players feeling like their report was shot down but wasn't quite sure how to put it, even that doesn't quite say it. The point is I think regardless of the wording of the response it wouldn't help, people will still dislike it.

I think the best mitigation that could happen is rather than being labelled and moved to "not a bug" some threads could be put on the Suggestions board. For example this controversial 'issue' with tons of speed modules on a Copper Wire assembler, could be put on Suggestions for review of the behaviour, then separately decide if it's worth adding the functionality or not. However some reports wouldn't need this, such as that spawned resources arent collected by idle miners because it affects a small number of players and would reduce optimisation to resolve it.

[Carl]

I think the problem with a lot of the not a bug examples i've seen that fall into the type the Op is talking about is:

It doesn't matter if somthing is a bug or not if it's detrimental to overall gameplay experiance. Most people tend to assume that a lot of examples of the later are also the former, particularly if it represents a change in existing behaviour that wasn't spelled out as a desired change by the devs.

Those which are detrimental to gameplay that are a result of deliberate action to achieve that effect on the devs part are balance issues.

Those which are detrimental to gameplay that are functioning in a way that dosen;t fit the devs vision of how the aspect in question should function are bugs.

Those which are detrimental to gameplay that are an unforeseen changes which don't go against the dev vision are "not a bug"

The problem is some of those not a bug examples are detrimental and sometimes it would be nice to hear a dev comment on how/why the change fits into the dev vision.

[BenSeidel]

So the issue is not this suggestion but you miss a better type of communication from/with the developers?

No, its specific to the frustration that seems to be evident in some bug posts, especially after the "not a bug" post, I only outlined an alternative that may or may not work.

Why should the developers waste time with discussions here.
Also the reports repeat itself on and on each time some new users install the game.

Firstly, when developers and software designers mingle with us common folk they get a better understanding of the issues that we are facing, and ultimately produce better software. Far too many companies have the "god complex", sitting atop their tower of gold completely detached from what users want. These companies usually go broke, or close to before learning their lesson (Lego is a great example).
Secondly, sslik & the other global moderators do a FANTASTIC job of dealing with the double posts, so repeated reports are not much of an issue (for the developers anyway) on these forums.


Anyway, it's an issue that I have seen and I wanted to bring it to light, hopefully bringing a better experience for all involved.

[ssilk]

Well, maybe I'm too hasty, but we could continue some weeks longer. On the other hand I would say the most important points are made.

And I'm more or less sure most of the devs read this topic.

What else could be said or could be done?