Allow use of pre 3.3 Advanced Discovery Scanner

[S3B4ST13N]

Funnily enough, you are the first developer I've ever spoken to who thinks that. Like, literally the only one.
No sensible company, in my experience, maintains legacy unless they absolutely have to.

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.

 

[Factabulous]

Funnily enough, you are the first developer I've ever spoken to who thinks that. Like, literally the only one.
No sensible company, in my experience, maintains legacy unless they absolutely have to.

Yeah, plenty of books about the cost of legacy code, not finding as many on the benefits of maintaining opposing functionality. Just the ongoing cost of explaining to all new CMDRs why there are 2 ways to scan systems

 

[Duck & Jenny]

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.

I think you are misusing / abusing the term "legacy" as it relates to software development. A proper example of legacy code is supporting 16 bit applications in a 32 bit operating system. An ED-specific example of legacy would be supporting older graphics APIs so that Beyond would run on Apple computers (this too being a contentious issue).

By your usage of "legacy", Frontier should remove pulse lasers because beam lasers are better. Having to code around pulse lasers wastes time, after all. In fact, it could be argued that it takes Frontier more work to remove code for a feature like ADS than to just leave it in there. But as you say, we are all speculating now.

FWIW, I do get what you are trying to say. If Frontier were to introduce a unified limpet controller (PLEASE), I would expect them to remove all the specialized controllers. If for some reason somebody demanded to have those specialized controllers back, I'd be first to reserve them a room in Arkham Asylum. I'm just not sure the ADS fits into the same category.. But I'll let the pro-ADS people fight that fight

 

[lenna]

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.

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?

You are making a few false assumptions here.

1. That a revived ADS would need to be implemented EXACTLY the same as the old system and thus require separate and notionally identical test cases and require the same level of effort - some additional testing but may be required but it should pale in comparison to the level of effort notionally required for the FSS based tests due to the more complex implementation of the FSS UI
2. That the FSS has only one test path - it needs to be tested/retested in VR too where visual elements are concerned - an auto-scan version of the FSS (aka revived ADS) would not have any new VR/non-VR visual elements to consider
3. The revived ADS would necessarily completely subsume the FSS functionality - not even close, more the revived ADS would partially subsume the FSS.

Some additional revived-ADS specific testing may be required but the scope should be rather limited in terms of differences - at least if Frontier are following best practices regarding code modularity and re-use.

 

[S3B4ST13N]

I'm not.
You have legacy code, and legacy systems. What you described is a legacy system (we have a few of those too). All because management didn't think it was a big deal to keep them around (the cost over the last decade or so kind of proved them wrong).

In our flagship product, we have legacy code. Old features that still exist; even though they have been rendered obsolete.

For example, we have two Account screens in our app.
We kept the old account screen because some clients refuse to move to the new one; they even told us they would cancel if we took it out.
Despite our protestations, management went "keep it in."
We kept it in.
The result?
When we work on the Account front-end or back-end, or SQL queries, we need to make sure what we are doing does not break the old account screen. In many cases, we had to duplicate code, or duplicate queries, or have excessive amount of conditionals on the server side. Things take twice as long to do. We are limited in some aspects by what we can do so as not to break the old screen. And every time we make a change, our testers are required to test both screens to ensure they both work as expected.
Then comes other work, we needed to make a change to the Address screen. A developer did that, and what happened? The old account screen could not display the addresses because the changes were no longer compatible. So we had to go back, undo the changes and plan again. What should have taken half a day, took a whole day.

Nice definition by a user on SO:
Q: What makes code legacy?
A: By using hardware, software, APIs, languages, technologies or features that are either no longer supported or have been superseded, typically combined with little to no possibility of ever replacing that code, instead using it till it or the system dies.

I think you are misusing / abusing the term "legacy" as it relates to software development. A proper example of legacy code is supporting 16 bit applications in a 32 bit operating system. An ED-specific example of legacy would be supporting older graphics APIs so that Beyond would run on Apple computers (this too being a contentious issue).

By your usage of "legacy", Frontier should remove pulse lasers because beam lasers are better. Having to code around pulse lasers wastes time, after all. In fact, it could be argued that it takes Frontier more work to remove code for a feature like ADS than to just leave it in there. But as you say, we are all speculating now.

FWIW, I do get what you are trying to say. If Frontier were to introduce a unified limpet controller (PLEASE), I would expect them to remove all the specialized controllers. If for some reason somebody demanded to have those specialized controllers back, I'd be first to reserve them a room in Arkham Asylum. I'm just not sure the ADS fits into the same category.. But I'll let the pro-ADS people fight that fight

 

[S3B4ST13N]

Sooo... you want them to not just put the ADS back, but rework it (probably from scratch)?

Bruh..

You are making a few false assumptions here.

1. That a revived ADS would need to be implemented EXACTLY the same as the old system and thus require separate and notionally identical test cases and require the same level of effort - some additional testing but may be required but it should pale in comparison to the level of effort notionally required for the FSS based tests due to the more complex implementation of the FSS UI
2. That the FSS has only one test path - it needs to be tested/retested in VR too where visual elements are concerned - an auto-scan version of the FSS (aka revived ADS) would not have any new VR/non-VR visual elements to consider
3. The revived ADS would necessarily completely subsume the FSS functionality - not even close, more the revived ADS would partially subsume the FSS.

Some additional revived-ADS specific testing may be required but the scope should be rather limited in terms of differences - at least if Frontier are following best practices regarding code modularity and re-use.

 

[Sylow]

I think you are misusing / abusing the term "legacy" as it relates to software development. A proper example of legacy code is supporting 16 bit applications in a 32 bit operating system. An ED-specific example of legacy would be supporting older graphics APIs so that Beyond would run on Apple computers (this too being a contentious issue).

Legacy code is anything which is not in use any more. A classical example is just to switch the UI style. There's plenty of people out there for many applications, which are like "but I liked the pointy corners more, rounded corners are ugly, undo that", etc.

It's just a small thing, right? Why don't companies supply versions of the same software with pointy and round corners? Yes, this is oversimplified, but you know what I mean. I hope.

You are making a few false assumptions here.

1. That a revived ADS would need to be implemented EXACTLY the same as the old system and thus require separate and notionally identical test cases and require the same level of effort - some additional testing but may be required but it should pale in comparison to the level of effort notionally required for the FSS based tests due to the more complex implementation of the FSS UI
2. That the FSS has only one test path - it would need to be tested in VR too - an auto-scan version of the FSS (aka revived ADS) should not have any new VR/non-VR distinct visual elements to consider
3. The revived ADS would necessarily completely subsume the FSS functionality - not even close, more the revived ADS would partially subsume the FSS.

Some additional revived-ADS specific testing may be required but the scope should be rather limited in terms of differences - at least if Frontier are following best practices regarding code modularity and re-use.

A lot of text, nothing of which contradicts what I wrote, except that you skipped things.

On point 1: That's not a wrong assumption. People demand the old ADS to come back in exactly the way it formerly was. Optional module or not, they want exactly the same functionality back. If you claim anything different, please tell me on which basis you would do so? This thread does not support your claim.

On point 2: Indeed the new FSS requires more testing. Indeed what I wrote is simplified. But the basis of what I wrote still is true: when there are two systems, who basically do the same in a different way, you have to not only test these two systems, but also check all possible connections between them.

And that's only the positive test. When you go for negative tests, which any good tester does, you have to do checks on all aspects where they should no affect each other to be sure that they don't do that. There might always be the one pointer or variable which was taken from the code from one line and still is used on the other line and they affect each other. Stuff happens.

As you mention best practices: It's a simple as that: have libraries with some basic functions. If you are what you claim to be, you might already have heard of that. Now imagine that the update of one feature requires the adjustment of a library. Which can, under specific circumstances, now break the other function. Not only do you have to locate the problem, it also means yet another packet of test cases in your test suite, which will have to be run at every major build.

It's such things which make testing really interesting, but also a lot of effort. As anybody who already worked on any bigger and longer running project knows.

And your point 3 is again point 1: people want the complete ADS of old times back. They are ready to discuss if it would again be the ADS module or not. But the return of the ADS is core of this thread.

So really, come again.

 

[Duck & Jenny]

Legacy code is anything which is not in use any more. A classical example is...

I think you are oversimplifying this, especially when applied to ADS because it was indeed something that was in use and would continue to be in use if Frontier hadn't taken the time to remove it from the game. Now let's consider a classic example of legacy in ED itself - legacy engineered modules.

The amount of coding added to the game in order to allow a small group of players to keep their LEMs is way more than what it would have taken to keep the ADS in the game, at least that's the way it appears at first glance. Frontier had to program new UI to deal with these LEMs. To add insult to injury, this entire legacy system only benefits players who owned the game before Beyond. Anyone who purchases the game today gets absolutely zero benefit from the complex LEM system.

Compare and contrast this to the ADS, which a player who buys the game today could benefit from, if it existed. Legacy Engineering is truly "not in use" any more, but the ADS would definitely be in use if it had remained in the game. Not by me, mind you, I have zero interest in the ADS, but it seems a fair share of people do, maybe even more than those who care about LEM.

 

[ThatSmileyGuy]

Gentlemen, please let's not all go into outright war against each other.
Allow me to explain a few points that i believe have been misunderstood in the course of this thread.

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.

To be fair, there is always a cost of keeping additional code in the application. However what i'm asking to be taken into consideration to be brought back(explained further in this post) still does exist within the game albeit with minor alterations. See post #142 for this.

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.

Regarding my remark above the feature mentioned in this thread already existed for longer than FSS does and I believe it has been extensively tested over that period of time.

Just one simple example: Both the ADS and the FSS can be used to locate a mission target.

I think You misunderstood the point of this thread. My request is to bring map reveal on initial system honk(Nowadays the honk is just added time before one can use the FSS).
I'm representing the matter from explorers' point of view. To have the map reintroduced as a means of new exploration gameplay. FSS should not be altered in any way. I, along many others would only love to see the return of system map reveal. Proper scanning and, POIs reveal or mission target detection should remain FSS domain. Only the system map is a feature is what We would like to see reintroduced.

There are many different ways to approach problems and re-introducing something akin to the ADS need not be a major undertaking.

As mentioned in post #142 system map with as little detail as possible still exists within the game. Only seems to have been altered in a minuscule way.

Sooo... you want them to not just put the ADS back, but rework it (probably from scratch)?

Not from scratch. Please reffer to my remark above.

Optional module or not, they want exactly the same functionality back. If you claim anything different, please tell me on which basis you would do so? This thread does not support your claim.

Please reffer to to my remark above. All we want is one functionality of the game reintroduced. The one that still exists within the game albeit in slightly altered form.

 

[Sylow]

I think you are oversimplifying this, especially when applied to ADS because it was indeed something that was in use and would continue to be in use if Frontier hadn't taken the time to remove it from the game. Now let's consider a classic example of legacy in ED itself - legacy engineered modules.

Which interestingly enough are:
1. The very same RedPaintedPaw above describes, that they keep it in game as they fear that too many people would quit about those things being removed. (Which is not that unlikely, considering how much of a grind these things were to get. )

2. Indeed in my eyes still an issue. I have several modules and weapons which in the new system can not be re-created. (E.g. I just the last days I stumbled over a lightweight beam laser with boosted damage. ) And yes, you are completely right: it's unfair that they exist. A new player can never get anything like that, no matter how hard he works for it. I fully support converting all the legacy weapons to the new system. Some of my equipment would be nerfed. (E.g. my Courier would be hit badly. It's absolutely impossible now to get a powerplant with the same combination of power, heat efficiency and low mass. ) But while the nerfs would affect me, they'd be beneficial for the game and should be done.

Compare and contrast this to the ADS, which a player who buys the game today could benefit from, if it existed. Legacy Engineering is truly "not in use" any more, but the ADS would definitely be in use if it had remained in the game. Not by me, mind you, I have zero interest in the ADS, but it seems a fair share of people do, maybe even more than those who care about LEM.

It's not about in-game legacy. It's about legacy code. And the high probability that parts of the old ADS code and the new FSS code rely on the same functions and libraries but maybe already are and certainly at some time will be incompatible to each other. It would increase the code base, maintenance and testing.

It's just a lot of work for very limited benefit. I'd rather have FD invest that development time on other aspects, be it bugfixes, development of actually new features, which would actually expand the game or even environmental activities like saving elephants from being killed by leather gatherers.

 

[Duck & Jenny]

I'd rather have FD invest that development time on other aspects, be it bugfixes, development of actually new features, which would actually expand the game or even environmental activities like saving elephants from being killed by leather gatherers.

Now you're just trying to get me to buy you a drink down at the local pub

I, of course, approve of this message.

 

[lenna]

A lot of text, nothing of which contradicts what I wrote, except that you skipped things.

Actually, I have not...

On point 1: That's not a wrong assumption. People demand the old ADS to come back in exactly the way it formerly was. Optional module or not, they want exactly the same functionality back. If you claim anything different, please tell me on which basis you would do so? This thread does not support your claim.

Having been involved with various threads on this topic, what you are saying is only PARTIALLY true. What the OP seems to be proposing is essentially merely partial automation of the FSS - not necessarily EXACTLY the same implementation of the ADS (though the end result is likely to be the same). From the threads I have been involved with on this topic (and my own in-game experience), most seem to object to the manual aspects of the FSS, and while in essence the OP is saying re-add an equivalent of the previous ADS implementation I do not for one second believe the OP is necessarily talking about talking a 100% revival of the old ADS implementation (line by line code wise).

On point 2: Indeed the new FSS requires more testing. Indeed what I wrote is simplified. But the basis of what I wrote still is true: when there are two systems, who basically do the same in a different way, you have to not only test these two systems, but also check all possible connections between them.

Except you are equating them to the exactly same thing and there being potential conflicts neither needs to be the case.

As I have pointed out, if implemented in accordance with best practices the only ADS specific tests should be regarding the ADS itself. The ADS being essentially done implementation wise as a partial-automation layer on top of the FSS.

With the OP's suggestion of adding a power/weight build impact the revival of an ADS-like mechanic would mean the CMDR would have to make a choice in the context of exploration builds - convenience of the new ADS equivalent or fit something else such as additional fuel tanks or perhaps an AMU.

Most people that have objected to the removal of the ADS just don't like either the FSS UI, the FSS tuning mechanics, or both. Whether that dislike is based on purely on demo or personal experience is moot in the main. In my particular case, I knew from the pre-release demo it would not be well received from at least some quarters and I knew I would not like it personally either. However, I have given it a fair chance and still do not like it and can not blame anyone for not even trying it - sometimes you do not need to try something to know you would not like it, the FSS is one such case. There are some things that could be done to improve the FSS and make it more palatable but overall some are never going to like it regardless.

 

[Sylow]

I think You misunderstood the point of this thread. My request is to bring map reveal on initial system honk(Nowadays the honk is just added time before one can use the FSS).
I'm representing the matter from explorers' point of view. To have the map reintroduced as a means of new exploration gameplay. FSS should not be altered in any way. I, along many others would only love to see the return of system map reveal. Proper scanning and, POIs reveal or mission target detection should remain FSS domain. Only the system map is a feature is what We would like to see reintroduced.

I am sorry there. You are right, the OP only is about reinstalling that part of the functionality. I still think it would devalue the FSS, but you are right, it wasn't you who was all about "we need the complete old system back".

Now you're just trying to get me to buy you a drink down at the local pub

I, of course, approve of this message.

Hehe. I think that drink could get expensive if I'd have to travel to you.

But yea, for me it really boils down to what I wrote there. There's plenty of things in the game which still seem very barebone. At the functional minimum and sometimes even broken. The ADS for me also was very barebone, a minimum mechanic to do things, with very little gameplay on those bones. There's just too many other things this game needs done.

As I have pointed out, if implemented in accordance with best practices the only ADS specific tests should be regarding the ADS itself. The ADS being essentially done implementation wise as a partial-automation layer on top of the FSS.

You're speaking of best practice only on unit test level. It doesn't even reach integration test level, let alone anything beyond that. (Edit: had to correct the terms here. What I wrote was not correct according to official standards. My department has a "legacy" of wrong terminology. )

And on how it's best implemented: I very much doubt that what you describe would be optimal. For merely efficiencies sake, you'd not have the computer work the FSS, but use the shortcut of "received data -> system map", without the FSS being used in between.

More efficient, saves processor power and is a lot less code than a "now the game plays itself" package.

There are some things that could be done to improve the FSS and make it more palatable but overall some are never going to like it regardless.

I agree on this aspect. I can make a long list on improvements I want to be done on the FSS. Some being minor, some requiring a significant rework of the FSS screen Some I have posted at some time, many were done by other players and I would support those requests again, the moment they turn up again.

The FSS is far from perfect, there's a lot of things which can and should be improved. As long as we're thinking forward, on how we can improve what we have, that's all fine for me. But going back to what formerly (for good reason) was replaced by the new FSS is just no option.

In case of doubt, I just have to ask: what would have been less work for FD?

• Keeping the old ADS.
• Building the new FSS.

If the first one would've been the less work, why did they go the second way?

 

[[Diplomacy] Carnegie]

I see people are still arguing about 'legacy code' when there is none. The ADS code is STILL used for the honk, just with an added filter on 'already discovered'. The old-DSS code is still active. The only thing missing is the ability to buy the ADS module - which is just a config/database value.

The FSS is just a cosmetic layer slapped on top of the old mechanics - it's not a fundamental rewrite of the code.

Reinstating the ADS isn't going to have any noticeable impact on development or testing times.

 

[Duck & Jenny]

I see people are still arguing about 'legacy code' when there is none. The ADS code is STILL used for the honk, just with an added filter on 'already discovered'. The old-DSS code is still active. The only thing missing is the ability to buy the ADS module - which is just a config/database value.

Reinstating the ADS isn't going to have any noticeable impact on development or testing times.

Tag - it's your turn in the ring!

 

[[Diplomacy] Carnegie]

Tag - it's your turn in the ring!

So this IS the right room for an argument!

 

[Sylow]

I see people are still arguing about 'legacy code' when there is none. The ADS code is STILL used for the honk, just with an added filter on 'already discovered'.

You say "it's the same but..." which exactly means, it's not the same any more. And we don't know what else they changed internally. I couldn't tell if the code of the old and new system would be compatible. Only somebody from FD could really tell us that. (Unless we start decompiling the game, of course. )

I guess that's a dead giveaway here: you're actually a coder from FD, revealing secrets to us. Awesome!

Tag - it's your turn in the ring!

Hehehehehehehehehe!

 

[[Diplomacy] Carnegie]

You say "it's the same but..." which exactly means, it's not the same any more. And we don't know what else they changed internally. I couldn't tell if the code of the old and new system would be compatible. Only somebody from FD could really tell us that. (Unless we start decompiling the game, of course. )

I guess that's a dead giveaway here: you're actually a coder from FD, revealing secrets to us. Awesome!

The dead giveaway is the fact that the old-DSS still works. FDev didn't bother to take it out of the codebase which (along with the canceled Focused Feedback) indicates that they rushed the exploration changes through late with the absolute minimum of effort.

It's not like the FSS actually does any of the generation of the system composition and payout. It's just a GUI layer for changing 'unexplored' into 'explored'. This is completely separate from population of the Nav Panel and System Map.

There's no actual overlap between what the FSS does and what the ADS does

 

[lenna]

You're speaking of best practice only on unit test level. It doesn't even reach integration test level, let alone anything beyond that. (Edit: had to correct the terms here. What I wrote was not correct according to official standards. My department has a "legacy" of wrong terminology. )

Overall - not even close. Yes - there are different levels of testing BUT the implications are fundamentally the same. When considering the system level tests, you would be ill advised to waste time in engaging in demonstrably unnecessary tests like you are proposing for numerous reasons. There are times when running beginning to end tests would be justified but the impact of re-adding the ADS would not be one of them.

And on how it's best implemented: I very much doubt that what you describe would be optimal. For merely efficiencies sake, you'd not have the computer work the FSS, but use the shortcut of "received data -> system map", without the FSS being used in between.

More efficient, saves processor power and is a lot less code than a "now the game plays itself" package.

Typical rhetoric attributable to the ant-honk crowd - fundamentally given the ADS honk is essentially a momentary thing impacting only the user initiating the honk implementing CPU cycle level efficiency gains would be unjustifiable, better to re-use and therefore reduce testing impact and technical risk.

Anyway, as Drew has already pointed out - no significant additional code may even be necessary.

 

[Burke]

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

Thats cause its just some rubbish used by the troll brigade to tell people they cant have what they are asking for. You have no idea what goes on in fdev or how much work would be involved. Just the usual drivel cause you want to get in somebodys face and say "no".

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.

You dont like me or my opinion? Oh no! Well right back at you. And all those people who delight in shooting down the requests and ideas of other posters.

Really? Then I dare to tell you to be careful here, not to go the Burke way.

Im sorry it took so long to respond to your petty taunts. I was asleep

Its going to be terrible for you and the rest of the forum grinches if the ADS did come back isnt it? It will be great for me.