That's only true when your architecture is poorly abstracted, Ian.
Last edited:
Why do bugs come back?
- Thread starter Kaocraft
- Start date
^^ This!
He is correct... coding isn't a simple task as one would believe it to be. One wrong misspelled or misplaced variable/string, logic hierarchy, function type and/or parameters, etc. can mess up the entire program your building. Also in a game like Elite there are thousands, if not, hundreds of thousands of lines of code to sort through to even find just one error. Its' like searching for a word in a dictionary that's not in alphabetical order.
Think of it like this... what if you could only make post in these forums when you have all of your spelling, grammar and punctuation correct. Most of us will still take hours to find what is causing that error and others will never be able to post. It might be a ";" to the tense of a word being used incorrectly. Same (sort of) holds true for code, it's a very precise format.
I'm a bit sorry, but that actually made me laugh...
You know, we've had tools to find those kinds of issues, called "syntax errors", since 1951.
I'd love to see an outline of a well-abstracted architecture that could scalably and automatically acceptance test that sort of thing, then.
That was fascinating to read. Thank you for taking the time to explain how bug checking works in a complex piece of software.
If you want to take it up offline, we can do.
Yes, most compilers have a syntax error report.
I'm still learning code but from what I understand so far... syntax errors points out errors preventing the program from running not some of the other erroneous issues within the program, from what I've experienced. In code, the syntax may be correct but the values one wishes to calculate/display may be wrong or not happen in the sequence that's required. Not adhering to the order of operations in math problems, for one, can produce incorrect results but may still be calculated without a syntax error. A second example would be if/else/elif statements. If you don't have one of these in the correct order then what you desired the program to do might not happen in the sequence you wanted it to or not at all, without a syntax error.
I've really learned a lot by playing around with the EDDI app and Voice Attack! I'm always sorting out my own errors when I mess around with the coding (I keep a backup just in case). I'm in no way saying I'm right but providing another perspective. Like I said, I'm still learning.
Sometimes it doesn't even have to be broken code but just weird cross-contamination of systems. Do you remember the NPC ramships of doom that appeared for a bit waaay back in the day? An NPC could run into your ship and cut it apart harder than a modern-era ramming vessel. I can't recall if it was restricted to just patrol fighters but it really was forever ago.
It turned out they had been provided a gargantuan fueltank stat to prevent them gassing out while on maneuvers and such when spawned in an instance; good job NPC ship stat table-filling person! Now these ships will never idle out and just stop randomly when deployed for an extended time in a player's presence.
Sounds good so far, right? But since fuel is treated as an in-game "object" and adds mass >__> , the NPCs with overclocked tanks using fuel-as-object also turned into incredibly over-massive smash-hammers.
You're correct. Syntax errors are compile time errors. There are runtime errors but bugs are not errors. When you see an old bug return it's usually a mix up in terms of code merging. They release version 1 while version 2 is still being developed. The bug fix from version 1 isn't merged to version 2 so it reemerges.
The other possibility is far more horrible. It's when things are so interconnected that fix 2 breaks fix 1. I think it's highly unlikely because the resulting bug rarely looks exactly like the original.
Last edited:
The simple explanation is that bugs coming back is often the result of someone reintroducing broken bits of code.
Yeah there are a million more uber complex ways things can go wrong, but in practice this is what happens.
Yeah there are a million more uber complex ways things can go wrong, but in practice this is what happens.
I remember reading a book called "The Pragmatic Programmer." There was a section in there about "Programming by Coincidence" It's basically the MEME you posted.
This can happen when your code is so complex (poorly structured) that you can't predict what the effects of a change will be.
My guess is the engine ED uses works by events. You write an event handlers to handle events. You change the game state in those event handlers. The complexity can come in if multiple handlers are changing the game same game state based on these events and overriding each other. It become very difficult to debug because certain error only occur depending on the order of events. I could be totally wrong about them using an event-driven approach. If someone has more insight, I'd love to hear.
Huh, is that actually what was causing the scan ramming? I've not heard that explanation before, but it seem like a reasonable error that could happen, lol!
Right on. Endlessly baying for updates and new features does not help either.
FD chose to ship a minimum viable product. They had no choice but to strap features on. Actually it was their plan.
You are right. I bet Planet Coaster doesn't have the Dav's Hope connection problem, or the mission ranking problem
And the airline baggage monitoring software (that still loses baggage) doesn't have these sorts of problems
Last edited:
You want to name some?
Not defending Elite as some these bugs do affect me.
Just curious what are these games?
Lets go check their forums.
it's part of the job. you as a test writer may well know that this part gets often shoved away, and know the consequences.
in the same way code needs to be written to be unit testable, software architectures need to be designed to be end-to-end (*) testable.
the scripters who made the scripts referred to in the recent "bot" thread did automate full mission completion and market operations just by 'reading' the screen and sending commands to the client, that's as bare bones as it can get. much more so can be achieved with an architecture flexible enough and proper tools to set up any arbitrary state and invoke the behaviours without human intervention. you only have to set that up once, and it's not that difficult once you have that. the only question is, are you willing to incur the extra cost and effort up front, and then run the full suite automatically almost for free on every code change if you wish, or would you rather pay the delayed cost of having to test manually, or not test and screw up a delivery, which is orders of magnitude higher?
of course then you might face combinatory explosion in a software piece like elite. well, that's a tradeoff and that's where real experts in qa come in handy. you also cannot avoid load or security testing. there is just no excuse for no testing, so better have it automated than manual.
but i'd also argue the comms panel bug could most probably have been detected with a unit test, it is clearly a problem with the component reacting badly to unexpected state or input: no matter who or what originated it, it shouldn't break. there are several other bugs in the list that show that even unit test coverage in the game has a few holes.
(*) imo 'acceptance testing' is always manual, since it is usually done by the customer to make sure a delivery meets expectations and fulfills the contract. i guess you refer to the automated tests you do to be run prior to submit to a real acceptance test.
Last edited:
Unfortunately, the same bug can often be triggered in more than one way. At the office, when we fix a bug, we first write a test (when possible*) to cover the problem, then fix it and verify the test now succeeds. The test is added to our test suite, so that the automated tests will catch it, if it's ever triggered again.
It's clear that FD needs more automated testing; you can NOT expect the QA to catch every reoccurrence.
I'm guessing that FD did not design ED for test. It can be really hard to add testability to code that was not designed with testing in mind. Just because it is hard and time-consuming does NOT mean that it should be skipped. That just adds to your "code debt".
* Some of our code is currently untestable via unit tests (some of it was written by other departments/teams); it will take many man-years to get some of that code under test (requires thousands of files to be reworked). It is MUCH better to design the code for testing in the first place and in many cases, it can SPEED UP development (since you are only running a few unit-tests, not the whole app). Even if it initially takes more time initially, it's worth doing, since it will pay for itself many times over during the lifetime of the app.
It's clear that FD needs more automated testing; you can NOT expect the QA to catch every reoccurrence.
I'm guessing that FD did not design ED for test. It can be really hard to add testability to code that was not designed with testing in mind. Just because it is hard and time-consuming does NOT mean that it should be skipped. That just adds to your "code debt".
* Some of our code is currently untestable via unit tests (some of it was written by other departments/teams); it will take many man-years to get some of that code under test (requires thousands of files to be reworked). It is MUCH better to design the code for testing in the first place and in many cases, it can SPEED UP development (since you are only running a few unit-tests, not the whole app). Even if it initially takes more time initially, it's worth doing, since it will pay for itself many times over during the lifetime of the app.
Last edited: