Anecdotal, but 3/4 failures at 85+%. 2/4 before that. Seems even worse than before.
I ran 3x shuttles at >93% with 3* timers for 4 days with only 4 failures, my other shuttle was 79% so I used a 3* DIP boost to get ti to 87% and had 8 failures.
I finished 37th overall.
I thought that the failures were about the same that they always are, balancing the right crew per mission helps achieve the % success rates projected. If there is an AND then the left hand skill takes the priority with the right hand skill giving an additional 25% to that specific characters contribution.
Based on this last event the And shuttles still require the main trait to be the highest.
When DB announced the AND missions they stated the left hand skill gave 100% of the characters total for that skill, the right hand skill would give an additional 25% of that characters skill.
200 DIP AND 100 SEC = 225
100 DIP AND 200 SEC = 150
This has always been the case since the OR/AND were introduced
Based on this last event the And shuttles still require the main trait to be the highest.
When DB announced the AND missions they stated the left hand skill gave 100% of the characters total for that skill, the right hand skill would give an additional 25% of that characters skill.
200 DIP AND 100 SEC = 225
100 DIP AND 200 SEC = 150
This has always been the case since the OR/AND were introduced
No. DB Said the higher skill was full and the lower skill was 25%. That was asked and confirmed. That also reflected what the UI has always shown. Players were able to prove that the server was likely doing 1st + 25% 2nd instead of max + 25% min. But the official DB statements were always max/min not first/second.
Again, @SHAN there is significant confusion: How are the shuttles intended to work? What is the outcome of the bug ticket? Have there been any changes incorporated re: this critical bug issue into the shuttle update....
Based on this last event the And shuttles still require the main trait to be the highest.
When DB announced the AND missions they stated the left hand skill gave 100% of the characters total for that skill, the right hand skill would give an additional 25% of that characters skill.
200 DIP AND 100 SEC = 225
100 DIP AND 200 SEC = 150
This has always been the case since the OR/AND were introduced
No. DB Said the higher skill was full and the lower skill was 25%. That was asked and confirmed. That also reflected what the UI has always shown. Players were able to prove that the server was likely doing 1st + 25% 2nd instead of max + 25% min. But the official DB statements were always max/min not first/second.
Based on this last event the And shuttles still require the main trait to be the highest.
When DB announced the AND missions they stated the left hand skill gave 100% of the characters total for that skill, the right hand skill would give an additional 25% of that characters skill.
200 DIP AND 100 SEC = 225
100 DIP AND 200 SEC = 150
This has always been the case since the OR/AND were introduced
No. DB Said the higher skill was full and the lower skill was 25%. That was asked and confirmed. That also reflected what the UI has always shown. Players were able to prove that the server was likely doing 1st + 25% 2nd instead of max + 25% min. But the official DB statements were always max/min not first/second.
When DB announced how Faction events with the AND option was introduced this is how I always understood it to work, I'm sure that in their initial announcement in communications it stated that the left hand skill would be the priority. Otherwise why have
DIP AND SEC
SEC AND DIP
as only one of these 2 possibilities would be needed?
We need DB to dig out the original communication on how the AND option would be calculated @Shan
Again remember, what we tested is that the client side was not using the same calculation as the server side. 2 different tables.
Dax=1093 Security no CMD
Pike=1072, no security
So while the display looked similar for both, our testing showed the server was indeed calculating security first, always. So since Pike has CMD only, it was treating his primary skill first as shown on our client side, but server was only calculating 268; 25 percent of his shown points. This lead to the false fails as we proved. Now they did a steath update because based on our testing, either sec or cmd can be the primary skill on the server side since that's what the client showed.
So Dax and Pike are now treated equally but it wasn't the case last week.
This one is still the best example, both equal percents, but her on the 3rd slot would lead to a lot of fails.
Her in the middle slot=1529. Her on the end =870. Almost half of her power was lost by moving seats according to the old server calculation despite what was displayed.
Based on this last event the And shuttles still require the main trait to be the highest.
When DB announced the AND missions they stated the left hand skill gave 100% of the characters total for that skill, the right hand skill would give an additional 25% of that characters skill.
200 DIP AND 100 SEC = 225
100 DIP AND 200 SEC = 150
This has always been the case since the OR/AND were introduced
No. DB Said the higher skill was full and the lower skill was 25%. That was asked and confirmed. That also reflected what the UI has always shown. Players were able to prove that the server was likely doing 1st + 25% 2nd instead of max + 25% min. But the official DB statements were always max/min not first/second.
When DB announced how Faction events with the AND option was introduced this is how I always understood it to work, I'm sure that in their initial announcement in communications it stated that the left hand skill would be the priority. Otherwise why have
DIP AND SEC
SEC AND DIP
as only one of these 2 possibilities would be needed?
We need DB to dig out the original communication on how the AND option would be calculated @Shan
So, to reiterate something I said in one of the linked threads there:
It doesn't really matter how it was 'supposed' to work. There is (was?) a discrepancy between what the CLIENT was reporting for "expected success" and the observed success rates provided by the SERVER.
If it's supposed to be FIRST + SECOND/4, then the front end crew sorting algorithm and expected success% are NOT taking that correctly into account.
If it's supposed to be HIGHER + LOWER/4, then the back end SUCCEED/FAIL check is NOT taking that correctly into account.
I'm not seeing where Shan admitted there was a problem? only she created a bug report so it could be investigated as to if DB could corroborate that there IS/WAS an issue.
I think people are equating a bug report to admittance of fault.
I'm not seeing where Shan admitted there was a problem? only she created a bug report so it could be investigated as to if DB could corroborate that there IS/WAS an issue.
I think people are equating a bug report to admittance of fault.
No admittance of fault, but there was a commitment to share information and provide findings back as soon as it was investigated. There is no way that the issue wasn't investigated before this release (especially since limited evidence suggests it was fixed). (edit: or if it wasn't investigated, there is an appalling lack of taking the communities concerns seriously). They are failing to follow up on their commitment to the community regarding transparency and honesty.
I think people are equating a bug report to admittance of fault.
Indeed, they are.
I would imagine most of them like me don't want an admittance of fault (the data is pretty solid on that) what most people want is a acknowledgement of fault. While the difference is subtle, there is a difference
Shan indicated that a bug report was going to be submitted, most of us just want the status on the bug report that was submitted. Since DB does not public publish bug reports (rightly so) we are using the only forum (literally) we have to voice our concerns and gather information.
Hi all, I have no update to share on this - I am sorry.
However I will continue to gather your feedback and observations and relay them to the team.
I know you are in a tough spot here, since you can only share approved language, but this is a blatant non-answer. How about these simple questions that the team MUST have an answer for:
1) Has the bug investigation been closed or is it still open?
2) If it is open, can we get a committed date that it will be closed?
3) Has this been specifically tested for and validated as performing correctly in the current shuttle environment or is there still risk that the current shuttles are performing incorrectly?
4) If it is closed, I understand it can take a while to align internally on a public communication on something like this (I live this pain in my job). Can we get a commitment that there will be a response on this in the near future (1-2 weeks)?
P.S. Thank you for responding, was starting to feel like we were being completely ignored on this.
Hi all, I have no update to share on this - I am sorry.
However I will continue to gather your feedback and observations and relay them to the team.
I feel like I need to start this off with this is not personal BUT...Isn't there someone who can/will say something on this topic who can post? As in "We really don't care about this problem and are not actually going to look into it", "We would like to look into it but it is low priority and we don't know when we will get to it", "This is such a huge issue that even though it is a high priority and weeks of research, we don't have an answer", etc.
I'm not sure how an issue that has been going on for months and was acknowledged (as heard) weeks ago is still at the "We heard that you think this a problem" stage.
I have a (hopeful) hunch as to why “the team” has not given @Shan any answers yet:
They have too much other work in production to finish Episode 9 or the new “persistent” Distress Calls, to be introduced this summer after the DS9/Augment Mega Event.
I’m basing that hunch mostly on the 9 “Undiscovered” planets on the Galaxy Map, along with the April Q & (lack of)A and a healthy dollop of wishful thinking. 🖖🏻
"In the short run, the game defines the players. But in the long run, it's us players who define the game." — Nicky Case, The Evolution of Trust
Hi all, I have no update to share on this - I am sorry.
However I will continue to gather your feedback and observations and relay them to the team.
I feel like I need to start this off with this is not personal BUT...Isn't there someone who can/will say something on this topic who can post? As in "We really don't care about this problem and are not actually going to look into it", "We would like to look into it but it is low priority and we don't know when we will get to it", "This is such a huge issue that even though it is a high priority and weeks of research, we don't have an answer", etc.
I'm not sure how an issue that has been going on for months and was acknowledged (as heard) weeks ago is still at the "We heard that you think this a problem" stage.
I know the answer, but management has instructed me not to communicate anything with you, so I will provide a vanilla non-answer.
Comments
I ran 3x shuttles at >93% with 3* timers for 4 days with only 4 failures, my other shuttle was 79% so I used a 3* DIP boost to get ti to 87% and had 8 failures.
I finished 37th overall.
I thought that the failures were about the same that they always are, balancing the right crew per mission helps achieve the % success rates projected. If there is an AND then the left hand skill takes the priority with the right hand skill giving an additional 25% to that specific characters contribution.
When DB announced the AND missions they stated the left hand skill gave 100% of the characters total for that skill, the right hand skill would give an additional 25% of that characters skill.
200 DIP AND 100 SEC = 225
100 DIP AND 200 SEC = 150
This has always been the case since the OR/AND were introduced
No. DB Said the higher skill was full and the lower skill was 25%. That was asked and confirmed. That also reflected what the UI has always shown. Players were able to prove that the server was likely doing 1st + 25% 2nd instead of max + 25% min. But the official DB statements were always max/min not first/second.
When DB announced how Faction events with the AND option was introduced this is how I always understood it to work, I'm sure that in their initial announcement in communications it stated that the left hand skill would be the priority. Otherwise why have
DIP AND SEC
SEC AND DIP
as only one of these 2 possibilities would be needed?
We need DB to dig out the original communication on how the AND option would be calculated @Shan
Wasn't it already posted in the other thread?
EDIT: There it is https://forum.disruptorbeam.com/stt/discussion/comment/73732/#Comment_73732
Dax=1093 Security no CMD
Pike=1072, no security
So while the display looked similar for both, our testing showed the server was indeed calculating security first, always. So since Pike has CMD only, it was treating his primary skill first as shown on our client side, but server was only calculating 268; 25 percent of his shown points. This lead to the false fails as we proved. Now they did a steath update because based on our testing, either sec or cmd can be the primary skill on the server side since that's what the client showed.
So Dax and Pike are now treated equally but it wasn't the case last week.
This one is still the best example, both equal percents, but her on the 3rd slot would lead to a lot of fails.
Her in the middle slot=1529. Her on the end =870. Almost half of her power was lost by moving seats according to the old server calculation despite what was displayed.
So, to reiterate something I said in one of the linked threads there:
It doesn't really matter how it was 'supposed' to work. There is (was?) a discrepancy between what the CLIENT was reporting for "expected success" and the observed success rates provided by the SERVER.
If it's supposed to be FIRST + SECOND/4, then the front end crew sorting algorithm and expected success% are NOT taking that correctly into account.
If it's supposed to be HIGHER + LOWER/4, then the back end SUCCEED/FAIL check is NOT taking that correctly into account.
I think people are equating a bug report to admittance of fault.
Second Star to the Right - Join Today!
No admittance of fault, but there was a commitment to share information and provide findings back as soon as it was investigated. There is no way that the issue wasn't investigated before this release (especially since limited evidence suggests it was fixed). (edit: or if it wasn't investigated, there is an appalling lack of taking the communities concerns seriously). They are failing to follow up on their commitment to the community regarding transparency and honesty.
I would imagine most of them like me don't want an admittance of fault (the data is pretty solid on that) what most people want is a acknowledgement of fault. While the difference is subtle, there is a difference
Shan indicated that a bug report was going to be submitted, most of us just want the status on the bug report that was submitted. Since DB does not public publish bug reports (rightly so) we are using the only forum (literally) we have to voice our concerns and gather information.
However I will continue to gather your feedback and observations and relay them to the team.
Thank you
I know you are in a tough spot here, since you can only share approved language, but this is a blatant non-answer. How about these simple questions that the team MUST have an answer for:
1) Has the bug investigation been closed or is it still open?
2) If it is open, can we get a committed date that it will be closed?
3) Has this been specifically tested for and validated as performing correctly in the current shuttle environment or is there still risk that the current shuttles are performing incorrectly?
4) If it is closed, I understand it can take a while to align internally on a public communication on something like this (I live this pain in my job). Can we get a commitment that there will be a response on this in the near future (1-2 weeks)?
P.S. Thank you for responding, was starting to feel like we were being completely ignored on this.
We can't ask much more from you. Hopefully the team decides the transparency here is worth the short-term PR hit.
I feel like I need to start this off with this is not personal BUT...Isn't there someone who can/will say something on this topic who can post? As in "We really don't care about this problem and are not actually going to look into it", "We would like to look into it but it is low priority and we don't know when we will get to it", "This is such a huge issue that even though it is a high priority and weeks of research, we don't have an answer", etc.
I'm not sure how an issue that has been going on for months and was acknowledged (as heard) weeks ago is still at the "We heard that you think this a problem" stage.
They have too much other work in production to finish Episode 9 or the new “persistent” Distress Calls, to be introduced this summer after the DS9/Augment Mega Event.
I’m basing that hunch mostly on the 9 “Undiscovered” planets on the Galaxy Map, along with the April Q & (lack of)A and a healthy dollop of wishful thinking. 🖖🏻
I know the answer, but management has instructed me not to communicate anything with you, so I will provide a vanilla non-answer.