That's a matter of personal prefference.
Allow use of pre 3.3 Advanced Discovery Scanner
- Thread starter ThatSmileyGuy
- Start date
The fact that its a done deal and the few inevitable objections were already ignored by the devs isn't though is it. Note the past tense.
This is something many people here, including some which keep smearing around that other people are just not intelligent enough to get things, seem to completely ignore, no matter how often you tell it to them.
Two separate systems but:
- Doing the very same thing in a different way.
- You have to maintain both.
- Any change you make has to be made for both of them.
- Any new design you do has to be made for both of them.
- Both should be balanced. If one is just a tad better than the other one, the second one is completely wasted time, from design over coding and testing down to merely harddisc space.
And all for the mere sake that a tiny minority of the playerbase refuses to adapt? While many players (among them even some of those who vocally demand that maintenance and coding effort is artificially bloated) keep complaining that development is too slow and not enough new content is implemented?
Guess it's really best for the developers to have this thread as dev0 equivalent.
I looked at the keybind screen for a bit and was like... "nope"
Damn me! If i would now write what i really think about you, at this very moment, my forum account would end up permanently suspended. So i don't. I rather just tell you that you right now in my eyes earned the reputation of one of the few posters on the forum, whose opinion is not worth the electrons used to write the posting.
I mean, seriously? You make all this fuss without even having any hands on experience? You go around screaming like a small child whose candy was taken away, but you never even tried the new FSS? You do all that posting based on a brief introduction video? Because you couldn't be bothered to set up the controls?
If you used just one percent of the time you wasted on writing non-informed postings here for setting up the controls instead, you'd have the best and most refined FSS setup of all players here. And if you spent another percent of that time using it, you would actually be well trained in using the mechanic and probably would not complain about it any more at all.
Last edited:
I brought this up before, but this whole thread is a rehash of old arguments, so here we go again.
What if the optional, separate ADS was a Guardian Tech module?
The original ADS has been retconned from the game. Someone traveled back in time and killed the ADS's grandfather and thus it never existed at all. But like the Terminator, this doesn't mean it can't come back in some different form. Guardian Tech is "magical" in many ways, so people bothered by the logic and ease of the ADS might be more willing to accept it if it's based on Guardian Tech. This would also require a bit more work to get, work that is surprisingly exploration-focused (traveling to the Guardian ruins is half the battle), so it's not like Harmless Sidewinders will have easy access to the "privilege" of an ADS. On the other hand, it's not impossible to get, either, as I bet most explorers have gone through the process of unlocking the FSD booster.
Anyway, just a thought of how theTerminator ADS can return to the current timeline without triggering the "But it's easy mode!" camp. Thoughts?
What if the optional, separate ADS was a Guardian Tech module?
The original ADS has been retconned from the game. Someone traveled back in time and killed the ADS's grandfather and thus it never existed at all. But like the Terminator, this doesn't mean it can't come back in some different form. Guardian Tech is "magical" in many ways, so people bothered by the logic and ease of the ADS might be more willing to accept it if it's based on Guardian Tech. This would also require a bit more work to get, work that is surprisingly exploration-focused (traveling to the Guardian ruins is half the battle), so it's not like Harmless Sidewinders will have easy access to the "privilege" of an ADS. On the other hand, it's not impossible to get, either, as I bet most explorers have gone through the process of unlocking the FSD booster.
Anyway, just a thought of how the
Doesn't change the fact that it's still more, unnecessary work for the developers. It's like expecting Nokia to continue to produce the 3310 because someone doesn't want to use a smart phone.
Plans change. Games evolve. Players need to learn to let go, move on and adapt. Or they can sit by the way-side, cry and make pointless threads that won't change anything.
Plans change. Games evolve. Players need to learn to let go, move on and adapt. Or they can sit by the way-side, cry and make pointless threads that won't change anything.
I am strongly against this.
The game will become messy and convoluted very fast.
The current method of exploration is what have should been in the game from the start.
The problem of FDev's slow development cycle is that some people get used to the lack of game mechanics, and then when mechanics are implemented they want the old game play void back.
This has been debunked several times - the two systems could have co-existed (and still could coexist) it is just the "crying and screaming" anti-honk crowd that refuse to acknowledge this truth.
This in essence is false reasoning, any additional "maintenance effort" is likely to be minimal wrt keeping something akin to the legacy Advanced Scanner. The legacy system was simple enough in general approach that the fundamental scanning and identification code should be largely the same. The only real difference would be the user interface to it, the ADS being the simpler of the two with notionally less capability from the perspective of "what" can be identified from a "honk".
As for it being "more unnecessary work", far from it - at least some of us have largely stopped playing ED because of this mis-step by Frontier. That is not to say stopped playing completely, but Frontier have dented their potential income from myself and at least some others because of their overall decisions regarding the ADS.
Last edited:
So even if the whole ADS code was completely separate from the new FSS code and they can install both of them at the same time, what i wrote just two postings before you still is true. It would be two redundant systems needing maintainance and all new content would have to be designed around both of them at the same time.
In the end design, coding and testing effort would usually not be double, but can end up a whole order of magnitude higher. (ISTQB certified tester here. With almost two decades of working in on tests or test support. I can for sure say that in any setup which does serious testing what you want will at least quadruple the testing effort. And i think that it's even worse on the design side. )
So come again: would that effort be really worth the benefit? Or could it potentially be that the effort spent to keep an engaging "press button for a few seconds" placeholder mechanic in game for the sake of a few people who refuse to adapt (some of them based on just watching a youtube video about it and deciding to never try) could better be invested in improving other aspects of the game or, god beware, new content?
So really, what's the priority? Fixing other problems, of which we have many? Creating new content? Or re-installing old placeholders for the sake of people who watched a youtube video and based on that decided that they would not try it, but write an endless stream of complaints about it?
You do realize that Beyond is filled with examples of Frontier improving the game based on "people crying and making
Citation please; bear in mind, the only acceptable source is from a Frontier staff member with access to the source code; who outright acknowledged that the two systems can co-exist.
I can assure you, having to maintain legacy features and entire applications myself for people like you thanks to poor management, it is most assuredly not minimal effort. EVERYTHING I do that even remotely touches on a legacy feature needs double the amount of testing, backwards compatibility testing, and additional regression testing. Legacy features are not just additional features that are ignored. Something that would take me a hour to do, will take me 2 hours simply because I need to code in a way that doesn't impact, or drastically change the legacy feature.
A lot of the stuff Elite does is through JSON packages. As does our application. We have entries in some of our JSON packages that can't be removed because if they are, legacy features break. That bloats the package unnecessarily, putting unnecessary additional bandwidth requirements on the client (a lot of our clients don't have uncapped lines).
By having the ADS and FSS in play at the same time, they would both likely share the same JSON package (it would be stupid to make a JSON package for each); meaning that down the line, properties in the JSON that the ADS uses that the FSS does not.. have to stay there. This creates huge issues, especially if you're trying to improve performance, or rework a feature.
It is a pain in the behind. You have no idea.
Thankfully, management is changing their tune, and those legacy features will be removed in a few months.
It is a monumental waste of my time.
It is a monumental waste of Frontier's time and is just plain bad practice.
Keeping legacy features sets a precedent. They add the ADS. Then what? What's next? Another feature is changed that somebody doesn't like; so they have to legacy that. Then another feature; and another feature, and another.
Hey, Frontier ... there's this feature from Alpha I want you to put back please cos I like it.
Let's make life difficult for Frontier by bloating their code and making it that much more complex, thereby making it that much harder to maintain and that much harder to make forwards compatible.
But sure, you want your ADS.. so, to hell with Frontier.
I can assure you, having to maintain legacy features and entire applications myself for people like you thanks to poor management, it is most assuredly not minimal effort. EVERYTHING I do that even remotely touches on a legacy feature needs double the amount of testing, backwards compatibility testing, and additional regression testing. Legacy features are not just additional features that are ignored. Something that would take me a hour to do, will take me 2 hours simply because I need to code in a way that doesn't impact, or drastically change the legacy feature.
A lot of the stuff Elite does is through JSON packages. As does our application. We have entries in some of our JSON packages that can't be removed because if they are, legacy features break. That bloats the package unnecessarily, putting unnecessary additional bandwidth requirements on the client (a lot of our clients don't have uncapped lines).
By having the ADS and FSS in play at the same time, they would both likely share the same JSON package (it would be stupid to make a JSON package for each); meaning that down the line, properties in the JSON that the ADS uses that the FSS does not.. have to stay there. This creates huge issues, especially if you're trying to improve performance, or rework a feature.
It is a pain in the behind. You have no idea.
Thankfully, management is changing their tune, and those legacy features will be removed in a few months.
It is a monumental waste of my time.
It is a monumental waste of Frontier's time and is just plain bad practice.
Keeping legacy features sets a precedent. They add the ADS. Then what? What's next? Another feature is changed that somebody doesn't like; so they have to legacy that. Then another feature; and another feature, and another.
Hey, Frontier ... there's this feature from Alpha I want you to put back please cos I like it.
Let's make life difficult for Frontier by bloating their code and making it that much more complex, thereby making it that much harder to maintain and that much harder to make forwards compatible.
But sure, you want your ADS.. so, to hell with Frontier.
Emphasis on "improving" .. the ADS is a step back; otherwise Frontier wouldn't have scrapped it.
As a developer with more than two decades of software development experience (a lot of which working on some very complex products) I call your assertion absolute and total tripe - especially in this case.
There is no doubt that some additional work may be required BUT we are not talking anywhere near double (or at least should not be). The level of testing notionally required for the FSS would be orders of magnitude higher than that for the legacy ADS mechanics due to the overall nature of the FSS user interface. Not to mention retesting of the FSS for VR too. Where the ADS is concerned, much of the underlying implementation would notionally be subsumed by the FSS code.
The way a revived ADS should essentially work is as a subset of the FSS, with certain parts essentially just automated. Power demand, weight, and slot usage would essentially make the choice of convenience of the ADS a player choice requiring compromise.
That's your opinion. There apparently are a lot of people who disagree with you. Now lest you think I'm arguing from a position of, "I want the ADS back now!" you may wish to run a search for "Old Duck FSS" and you'll see that I'm not your typical ADS apologist. Heck, I'm not an ADS apologist at all, but those who are should "get their day in court".
All that said, this "court case" has been going on longer than the OJ Simpson trial and Brexit debates combined... It would be nice if Frontier themselves declared a final ruling, thumbs up or down, like Caesars of old.
As I developer too... I call their assertion correct.
Legacy is bad. Having it in your application, is bad. Having to test it is a waste of time. Having to code around it is a waste of time. Having it there when it doesn't need to be is bad.
It bloats the system. It makes everything more complex. It makes maintenance more complicated.
Why should they do all that? Just because some can't get over it and just use the bloody FSS?
Legacy is bad. Having it in your application, is bad. Having to test it is a waste of time. Having to code around it is a waste of time. Having it there when it doesn't need to be is bad.
It bloats the system. It makes everything more complex. It makes maintenance more complicated.
Why should they do all that? Just because some can't get over it and just use the bloody FSS?
Citations are not required - there are some very simple truths about how things can or can not be implemented.
The only reason to remove the ADS is purely political is essence, anyone with any significant experience in actually developing software should be able to realise this.
A revived ADS would essentially be just a matter of automating part of the current FSS process and should be VERY simple to do for Frontier if their team has the level of ability they seem to have.
Really? Then I dare to tell you to be careful here, not to go the Burke way.
Just one simple example: Both the ADS and the FSS can be used to locate a mission target.
Old system: Honk, check if the mission was updated. Skip ship to the location where the mission update is supposed to be. (Location is only "near a planet", USS is not identified. ) Check if mission instance is there, enter, check for presence of mission target.
New system: Open FSS. Scan for mission USS. Skip to mission USS. Enter instance, check for presence of mission target.
Mix:
1. Complete path for the old system.
2. Complete path for the new system.
3. ADS honk. Open FSS. Locate USS there. Skip to misson USS, enter instance, check for presence of mission target.
4. Locate USS with FSS. Honk to confirm that the ADS mechanic does not mess up the location of the USS. Skip, enter, check for mission target.
(For anybody wondering: no, this is not how actual testing is done. This wouldn't even quality as a draft for test design. But I by now have the feeling that anything more than this is above and beyond the scope of some people here. )
Four -positive- test cases for what formerly was one. And that's not even looking at any negative testing to be done. So come again on your statement that the effort would not be anywhere near double. Please elaborate how you would cut that down to one test case without compromising the test result?
Mind you, it's your credibility as "developer with more than two decades of software development experience" on the line here. So go ahead, please tell me how you would reduce these still very simple lines of testing to be less without loosing quality?
Last edited:
Not really. When you replace something, it's because you have a better idea for it. Otherwise why would you spend dev time on it?
I know I wouldn't; and neither would any company I've worked for in my entire career. :3
There are some who disagree. There will always be some who disagree. "A lot" .. well, no way to really know without some kind of official poll.
This is the direction Frontier chose to take. They chose to replace the ADS. They chose to not include it with the FSS. They likely did it for a reason.. be it "no legacy crap" or "ads is rubbish" or "this new way is better" or whatever, they chose not to keep it.
I know you aren't; I'm just getting really frustrated with people thinking that development is some easy thing and that developers have all the time in the world that they can just add an old feature back and maintain it like it's nothing.
I know I wouldn't; and neither would any company I've worked for in my entire career. :3
There are some who disagree. There will always be some who disagree. "A lot" .. well, no way to really know without some kind of official poll.
This is the direction Frontier chose to take. They chose to replace the ADS. They chose to not include it with the FSS. They likely did it for a reason.. be it "no legacy crap" or "ads is rubbish" or "this new way is better" or whatever, they chose not to keep it.
I know you aren't; I'm just getting really frustrated with people thinking that development is some easy thing and that developers have all the time in the world that they can just add an old feature back and maintain it like it's nothing.
Again - false reasoning in this case. You are thinking too much along specific lines, a common mistake amongst developers in general. The case against "Legacy code" is fundamentally flawed and highly subjective/circumstantial. There are many different ways to approach problems and re-introducing something akin to the ADS need not be a major undertaking.