Fix your bug-ridden game Frontier
- Thread starter D3rv1sh
- Start date
Do you know how to make games? If so, give it a try!
Last edited by a moderator:
Crashes definitely have to do with 4K implementation. Switching to 1080p and no crashes so far.
Edit: Still crashes also in 1080p performance mode. It seems to involve combating skimmers. Crashes do occur less frequently though. I was able to complete the base raid. I'm not alone in experiencing these crashes I see. All after the update hit. Bug tracker is full with it also.
Last edited by a moderator:
Sadly they're not alone. I also use one of the train sims and many times in the past old bugs have suddenly re-appeared which were thought to have been squashed. I think the term is spaghetti code... The developer then gets all precious about it including the cliched invitation, "If you can do better..." Er, no, we're customers paying you to get it right!
No, the term is "Software regression" and has nothing to do with the quality of the actual coding. The codebase of any large project (like Elite Dangerous) is worked on by a number of engineers simultaneously, sometimes in the same code module. This is controlled by a source management system (Git, Perforce, TFVC). A typical scenario for reintroducing a previously fixed issue can go something like this:
Engineer 1 is assigned Bug A (a simple bug)
Engineer 2 is assigned Bug B (a difficult bug)
Engineer 1 forks the code repository and fixes Bug A
Engineer 2 forks the code repository and starts working on Bug B
Software released. Bug A fixed, Bug B still present.
Engineer 2 finally finds the cause of Bug B and fixes it. He merges his changes back into the main branch, because his branch still contains Bug A it is reintroduced.
Software released, Bug A is back.
Normally source control / version management systems are intelligent enough to compare all changes between the main branch and the branch being merged, realise that some of the code in the main branch is newer than that of the merging code and not overwrite that section. Sometimes it can't work out the change boundaries and requests that the engineer does a manual merge. This is where mistakes are made. It's sad, but true, than many engineers, when faced with the complexity of a manual merge merely just chose "use my code" and overwrite the main branch (including Bug A) with their own code. This is particularly true when said engineer has a manager pounding on their desk demanding "haven't you got that fixed yet?" a week from release.
Of course, the regression should be picked up in testing, but often isn't due to timescales. Or is picked up but it's too late to do anything about it before release and delaying release is not an option.
Last edited:
Can absolutely confirm, even small indie projects can suffer from merge conflicts. The real fun comes with maintaining a project that is intended to be a mod/downstream of another project.
It gets really really fun when these changes/conflicts are in binary files such as art assets and textures and the repo doesn't know how to automatically merge them.
It gets really really fun when these changes/conflicts are in binary files such as art assets and textures and the repo doesn't know how to automatically merge them.
Ha, yeah, binary assets are a real pain in the .
Had a project once which required an alert "beep" to be played under certain circumstances. The engineer who wrote that part of the proof of concept, for some reason, chose a wav file of a sea lion barking. It all worked fine and we were given the go-ahead.
You guessed it. Somehow the proper "ding" alert sound got overwritten by the bark during a merge. It wasn't picked up in testing because it wasn't a "bug" per-se (the test script just said "was alert heard?") and the software went live with the bark sound.
The really bizarre thing was that the customer actually liked it. The thought it got the attention far better than a simple "ding".
While I agree that we should keep the conversation civil, this is not a valid argument. It is the game developers' job to make good games, or at least games that are technically acceptable. Everything has a reason and every bug in Elite can be explained why it's there and why it's hard to maintain such a complex game. However, this doesn't relief the developers because it is their profession. Building a house is hard, but if the house collapses it has to be someone's responsibility. The builders can't say "well, build your own house if you don't like it, we can't help gravity".
It doesn't matter what the game is like. It's complex because the developers took responsibility to create such a game. They designed it to be like this deliberately. So it is their duty to make it work. And sadly a lot of parts of it don't work as intended. And it's not the first occasion - in fact, every single update that has ever been released for the game since 2015 has been full of new or returning bugs. We don't have to know how to make games. We are customers. We have not only purchased the game but we more or less regularly spend even more money on it. All we expect is that it works well and gets better with time. I think it is a valid expectation. And I am sure Frontier is trying hard to fulfill that expectation. But this argument "go and make games yourself" is not valid at all.
It makes a valid point, though. Most people outside of the industry have absolutely no idea how complex software engineering is, particularly on large projects (which ED is) and doubly so on a game where microseconds are important. This often results in compromises between best coding practices (i.e most maintainable code) and writing the most performant code. Designing and building of a game like ED is several orders of magnitude more complex than building a house.
You also need to bear in mind the price of the game. It's only £40. Which is as cheap as chips for a piece of software of this level of complexity.
Ever notice how this isn't an ED issue but a genre-wide issue? SC has been a non-stop mess, X:Rebirth and X4 had catasrophic launches and so on. The main issue is that people want more, better, faster and sooner; all bug free. While people demand bugs are fixed, they also yell that space legs and atmo is taking too long, powerplay need to be extended, scripted missions must be added, combat gameplay be re-balanced from scratch, new SRVs and ships must be added and so forth.
So people can take the "I dont care about reality, it is their duty to to this to my expectations!", or you can just accept that if you want a more bugfree game you should play simpler games, with less ambition and innovation. Rebel galaxy for example offers a fun, fairly stable 'light' version of ED/SC/X-series.
Sounds a tremendously inefficient system where fixed bugs are overwritten and have to be 'fixed' again. Presumably this can happen on multiple occasions, so the merging would seem to be just as important as the fixing?
if it's an ant farm, does that make it a bug or a feature?
Well, I noticed a red ant in the black ants’ farm the other day. That can’t be right.
Absolutely. Game development is harder and more resource-demanding than ever. Big games and modern graphics require more people, more time and more effort. This is why there are fewer and fewer big games and publishers. But it's still not an excuse for faulty software. Teams should produce projects that they can release at adequate quality. Don't bite more than you can chew, as they say. I'm afraid with all the different projects Frontier's workforce is spread thin and not focused enough. This materializes in all these bugs. Every single update. For years. It's completely understandable players are frustrated. I am, too. Development speed is glacial already, yet any time anything new arrives it's full of functional problems or it breaks already working features. As a regular player it's tiring after a while.
I'll do my best to keep it civil. Thing is this is not the first time, not the second, not the third. Many times where content has glaring issues when it is released. Instead of making sure you have a solid code base to continue working on, they build new content on top of content that has issues in it. I do understand the development process and how complex and big it can get. I never said that software engineering is an easy task.
Multiple SE working on a same branch of code should never be an excuse though. Before you can even begin to work on code you have to know where the bugged code resides. If a specific section of code is found out to be the source of multiple bugs, then multiple SE working and merging their changes in that branch without coordination is ludicrous. How are they going to make sure one SE is not going to mess with the changes made by another. There's a thing called mutual exclusion. The same thing that applies to threading. No thread has business messing with volatile variables when another thread is currently changing its content.
But seeing as these mistakes do happen and how how big this game is they should involve the community on all platforms to help in testing new content. But that's not happening also. But then again, PC players who test new content do report issues, but Frontier doesn't act on them before releasing it. That's also not uncommon unfortunately.
Multiple SE working on a same branch of code should never be an excuse though. Before you can even begin to work on code you have to know where the bugged code resides. If a specific section of code is found out to be the source of multiple bugs, then multiple SE working and merging their changes in that branch without coordination is ludicrous. How are they going to make sure one SE is not going to mess with the changes made by another. There's a thing called mutual exclusion. The same thing that applies to threading. No thread has business messing with volatile variables when another thread is currently changing its content.
But seeing as these mistakes do happen and how how big this game is they should involve the community on all platforms to help in testing new content. But that's not happening also. But then again, PC players who test new content do report issues, but Frontier doesn't act on them before releasing it. That's also not uncommon unfortunately.
Except that isn't true; people complained about this way back before they had any released other major projects. Then as time goes on recent developments are used as 'cause' for what people dont like. "They are spread too thin across all these projects!" or "it is because of consoles!" or some other random idea. And you provide a perfect example of what the problem is: while you are complaining they should work more on fixing bugs, you immediately jump to also complain about how the development is new stuff is far too slow.
Also, your 'they shouldn't release faulty software' is rather naively binary. Software isn't either bugfree or faulty, every software has bugs and faults to some extent. The question is how you want to balance speed, innovation and quality. And in this genre people often expect way too much of the first two, and then get upset about the third. Let me assure you; if you had asked to devs over at Double Damage Games to release Rebel Galaxy with a 400b star system, with properly modeled rotations and orbits, in 3D and with a 6DOF flight model, with VR and full HOTAS support, multiplayer, the ability to land on planets and so forth: I can promise you that Rebel Galaxy would have vastly more bugs. I can also promise you that if you had asked them to do that, they wouldn't have called your expectations 'glacial'.
And around here we just take all of the above for granted, while getting upset about the 'glacial development' (really?) while also being upset about bugs. Now, you can call it 'understandable frustration'. Fine. But with such an attitude you'll always be upset, because what you want simply isn't going to happen in the real world. And no amount of 'but they have the duty to do that!' has any impact on this reality.