The Elite Dangerous ingame reputation system thread

.

  • .

    Votes: 32 100.0%
  • .

    Votes: 0 0.0%

  • Total voters
    32
  • Poll closed .
O

As much as I love your videos man, I ve learned to take with a large pinch of salt your criticisms. You tend to gratuitously read too much into things. The above is just one example more and it doesn't help your own rep to avoid decay either I reckon ;)

Quite this, some of us got to know Titus back in eve-o and learned to bring some salt even then when he started forum posting.

still <3 Titus.
 
Just my tuppence worth, might it not be a good idea to open up each major release to all Gamma backers for a week after Beta? That way a much greater number of ̶l̶a̶b̶ ̶r̶a̶t̶s̶ Commanders could help track down some of those last bugs and game-play balance issues before it hits the public servers. I'm sure people would not mind an extra weeks wait if it meant a more thoroughly tested release.

Oh, and as for Friday patch releases, no, just no.

No.
 
Just my tuppence worth, might it not be a good idea to open up each major release to all Gamma backers for a week after Beta? That way a much greater number of ̶l̶a̶b̶ ̶r̶a̶t̶s̶ Commanders could help track down some of those last bugs and game-play balance issues before it hits the public servers. I'm sure people would not mind an extra weeks wait if it meant a more thoroughly tested release.

Oh, and as for Friday patch releases, no, just no.

No.

Probably not. The strange phenomenon that i have noticed is that aside from the bugs that don't get fixed in Beta. the release always seems to add a few new ones that are even more consequential than what we saw in the beta.

Additionally, myself and a few of my fellow PB2 friends have made the observation that each upgrade has seemed to re-visit bugs that were fixed in previous versions. It often feels like the development team doesn't use the most recent version to build on, but goes back a version to old code base that hasn't had the last round of fixes integrated into it and old bugs tend to resurface with each release that then have to be patched again.

The reality is that ED moves forward in fits and starts and as outlined in my previous post, the best approach is to just learn the cycle and plan accordingly. We'll see the real 1.3 in about two weeks and it's best game play will be about a month before they announce 1.4 beta.
 
Just a thought.

Still a bit odd that the FCS release had Alpha, Beta and Gamma, but each major update only Beta followed by (in effect) full public Gamma. So all players, old and new, end up play-testing until, as you say, about a month before the next major release.
 
Unfortunately, while i disagree with reputation decay, the merit decay is a necessity. It is the chosen method on determining how much effort players of different powers have put into the progress of their power recently. (And awarding nominations accordingly, not to mention the weekly payout. )

Their decay is essential for this mechanic to work.
 
I have a lot of respect for Titus, he does tend to state things logically without undue emotion. Those that rally against his arguments generally tend to "reach" to demonstrate their own usually erroneous conclusions.

It seems the evidence points towards the change request - development - test - release cycle where there is a tail wagging the dog. And it isn't the players.
 
Decay is necessary. If it wasn't there, someone could amass the 10k merit threshold & quite happily rake in 50m CR each week by doing nothing at all. Not to mention nothing would get done (preparing,expanding,fortifying) because once everyone got to the magic 10k limit there would be no incentive to do so.

This.

Plus, decay is a safer way to get out of a Power if you've had enough. Wait until you're rating 1 then quietly slip out of the front door.
 
Probably not. The strange phenomenon that i have noticed is that aside from the bugs that don't get fixed in Beta. the release always seems to add a few new ones that are even more consequential than what we saw in the beta.

Additionally, myself and a few of my fellow PB2 friends have made the observation that each upgrade has seemed to re-visit bugs that were fixed in previous versions. It often feels like the development team doesn't use the most recent version to build on, but goes back a version to old code base that hasn't had the last round of fixes integrated into it and old bugs tend to resurface with each release that then have to be patched again.

The reality is that ED moves forward in fits and starts and as outlined in my previous post, the best approach is to just learn the cycle and plan accordingly. We'll see the real 1.3 in about two weeks and it's best game play will be about a month before they announce 1.4 beta.

I have also noticed this. Not so much with 1.3 (though I'm yet to try the full release version), but certainly with previous releases.

It is probably a matter of them working up updates on whatever was the most recent build at the time, then the version they're working on not being compatible with the live server version after changes are enacted (not knowing what the repercussions could be of just dumping new code into an untested environment). They presumably intend to re-implement all the fixes to the updated release, but for whatever reason don't appear to do so.

My gut feeling is that they need to improve the tools they're using to do their work, though that might cause more problems than it fixes, at least in the short term.


As to the person describing existing customers as cost, and new customers as revenue... yeah, you are exactly right, though I hope not too many people working at Frontier see it that way. I don't doubt some do.
 
It is probably a matter of them working up updates on whatever was the most recent build at the time, then the version they're working on not being compatible with the live server version after changes are enacted (not knowing what the repercussions could be of just dumping new code into an untested environment). They presumably intend to re-implement all the fixes to the updated release, but for whatever reason don't appear to do so.

The usual way this is done in software development is a process called branching. At the start of 1.3 development say, a branch is created from a copy of the current 1.2.x codebase (whatever it is). All the devs working on 1.3 only add code to this branch, while devs working on 1.2.x (assuming they are different people, a big assumption) only add their changes to the 1.2 branch. Before 1.3 goes to beta, the changes added to the 1.2.x codebase should be rolled into the 1.3 branch. When 1.3 goes live, that becomes the new "head" or main codebase. Rinse and repeat.

The problem is when changes made to 1.2.x to fix a bug that may not be compatible with the new code in the 1.3 branch, so those changes don't get rolled in, or require a complicated process called merging, which usually requires a dev to manually figure out line by line the code conflict and merge the two - for each such conflict. It is quite possible that they made a decision to go to release without some of the 1.2.x fixes rolled into the 1.3 branch yet, if there were major code conflicts that would require extensive dev time to figure out, and they were not "show-stoppers". Just like they seem to have postponed fixing many of the bugs identified in beta, and went to release with them still present.

This is all speculation on my part, and every dev shop is somewhat different in terms of process, but generally that is what is done, and would explain some of the problems people are seeing.
 
Last edited:
Logged into PowerPlay last night to check everything out. Keybinds and Joytick configuration nuked again. Logged back out. :(
 
The usual way this is done in software development is a process called branching. At the start of 1.3 development say, a branch is created from a copy of the current 1.2.x codebase (whatever it is). All the devs working on 1.3 only add code to this branch, while devs working on 1.2.x (assuming they are different people, a big assumption) only add their changes to the 1.2 branch. Before 1.3 goes to beta, the changes added to the 1.2.x codebase should be rolled into the 1.3 branch. When 1.3 goes live, that becomes the new "head" or main codebase. Rinse and repeat.

The problem is when changes made to 1.2.x to fix a bug that may not be compatible with the new code in the 1.3 branch, so those changes don't get rolled in, or require a complicated process called merging, which usually requires a dev to manually figure out line by line the code conflict and merge the two - for each such conflict. It is quite possible that they made a decision to go to release without some of the 1.2.x fixes rolled into the 1.3 branch yet, if there were major code conflicts that would require extensive dev time to figure out, and they were not "show-stoppers". Just like they seem to have postponed fixing many of the bugs identified in beta, and went to release with them still present.

This is all speculation on my part, and every dev shop is somewhat different in terms of process, but generally that is what is done, and would explain some of the problems people are seeing.

So then we need a thread debating the definition of "Show Stopper."

As FD seems to not have a working definition based on recent reports of server downtime...
 
When you do set them up again, simply rename the custom binds file and make a copy of it somewhere.

Problem solved.

Edit: In Win 8.1 you will find it at he following location.. C:\Users\yourname\AppData\Local\Frontier Developments\Elite Dangerous\Options\Bindings
 
Last edited:
I fired the game up today, which is the first time in a long while. I went straight into the game with no problems (open play). Performance was its usual great level (for me), +110-120fps in a station, lots more in space.
While I understand players having issues, telling the dev's how to run their business is not going to get the game anywhere.
.
For me the severe lack of credibility that I hear from players I speak to (I play group play in other game series), is regards the content or lack of it. Pushing for the next 'big' step and not concentrating on the trivial content, that is coming out at present.
.
Bugs, yes, game released too early, well I'm not sure. Its pc gaming, when have any of us had a pc game that performs well for all players. Its part of pc gaming, naïve to think its not. The game will not work for everyone, too many variables.
So as for releasing at weekend, which doesn't really matter, because there's always next weekend to play. That for me doesn't seem to be the problem, lack of content and tools to play with, is (for a sandbox, which at present it really isn't).
.
Problems with the game, for which many are home grown (players home systems), is not a major concern unless they have thousands of complainers, which I don't see here. The thread here should really have been about the content that needs to start being put in and get this very shallow game-play a little deeper..
 
When you do set them up again, simply rename the custom binds file and make a copy of it somewhere.

Problem solved.

Edit: In Win 8.1 you will find it at he following location.. C:\Users\yourname\AppData\Local\Frontier Developments\Elite Dangerous\Options\Bindings

Backing up your keybinds file and dropping it back in every time the bug occurs is not a fix - it's a workaround. The problem itself still remains - FD is overwriting people's custom files, and should stop doing so.

- - - Updated - - -

So then we need a thread debating the definition of "Show Stopper."

As FD seems to not have a working definition based on recent reports of server downtime...

I think you will find that definition varys depending upon who you ask - the dev, the dev project manager, QA, the producer, or marketing. Throw in beta testers and end users if you want some more variation to it. ;-)

Edit: And soon Microsoft QA and Microsoft Certification processes.
 
Last edited:
Backing up your keybinds file and dropping it back in every time the bug occurs is not a fix - its a workaround. The problem itself still remains - FD is overwriting people's custom files, and should stop doing so.


For people who don't know about renaming the custom binds file, I would argue that it is indeed a fix when compared to entering all the controls again manually ( it takes 5 seconds ). Also, until FD do fix the issue, it is the only way I know of avoiding re-entering the settings.

Fyi my controls have never reset.
 
For people who don't know about renaming the custom binds file, I would argue that it is indeed a fix when compared to entering all the controls again manually ( it takes 5 seconds ). Also, until FD do fix the issue, it is the only way I know of avoiding re-entering the settings.

Fyi my controls have never reset.

I know - I just meant in terms of software development process. It is still a bug, so it is not fixed.

Edit: And the fact there is an easy and quick workaround means it is likely a low priority bug, which explains why it has not been fixed. That said, it keeps cropping up again and again for many, and it would seem such a trivial fix I am not sure why they have not implemented it. Pick the low-hanging fruit first.
 
Last edited:
Because you can't catch all bugs during Beta, especially those triggered by lots of users hammering complex systems.


I don't think anyone expects a version release to be bug free, but after seeing a consistent pattern of server crash as a predictable consequence of an ED update, one would begin to wonder if there isn't a better way to do an update.

Just sayin...
 
Back
Top Bottom