stop ripping us off on runestones ...
kiheikid
Posts: 2,168 ✭✭✭✭✭
i view a runestone as an admission ticket for a “fortress show” — regardless whether i win or lose UPON completion (and whether i received an exploration fragment or not, if i did achieve “victory”), i received the benefit of the bargain at completion. however, if the fortress show does not finish for any reason other than my voluntarily leaving (and, no, if the screen froze and the only way of leaving was to exit the app, that does not count as voluntarily leaving), then i did not get the benefit of the bargain. therefore, i should AUTOMATICALLY get my runestone back in such corcumstance, WITHOUT my having to ask for it via report-a-bug. put differently, the HPWU app should “hold” the runestone while fortress play is in progress but only take it from the player if the wizarding challenge is actually completed.
if we were talking about movie tickets and the film projection broke down mid-movie or even 10 minutes before the ending, what do you think will happen if the movie theatre kept the money spent on admission tickets with no refund and no make-up session to watch the movie (over entirely or just the part missed)?
it is the FAIR thing, and the RIGHT thing, to do, @HPWUTeam - please do NOT rip off our runestones if we cannot complete the wizarding challenge session for any reason (including these server errors that seem to be getting more commonplace) other than our truly voluntarily leaving the session.
thank you for listening.
Comments
by the way, i still think App Feedback is a better name for this section than Feature Request
Alternatively do what the rest of us do and suck it up, stuff happens, we deal with it
What you're describing is "unexpected behavior" and therefore is more suited for the "report a bug"-section.
The same issue has been repeatedly reported with explanations given, fake news
This happened to me on Community Day, reported in-app, 1 hour later was given back my L5 runestone, strong invigorating potion & 4 potent exstimulos.
Let's go with your movie theater comparison. It's happened to me. There was a process to be reimbursed. I had to wait in a line and explain that I was one of the people in the theater with the failed projector to get a free movie pass. Having been properly reimbursed, I was satisfied. I could have stood in the lobby and shouted that the FAIR and RIGHT thing would be for the movie pass to appear in my pocket AUTOMATICALLY, but it wouldn't have accomplished much. Other people in the lobby might notice the scene I was making, conclude that I'm obviously not playing with a full deck, and go on about their day. Which brings us here...
... especially since "automatic reimbursing" can be exploited.
In that context it needs to be noted that not all things that are "claimed to be bugs" are actually bugs.
In QA, Testers don't report bugs. They report ISSUES. They report FINDINGS. They report differences between the documentation, the "expected behavior", the "assumed behavior" and the actual behavior - which can be 4 different things.
From a Quality-Management perspective, testers have neither the responsibility nor the expertise to determine if an issue is a bug (except in very rare cases).
And the reason for that is this:
A "bug" is the colloquial word for a fault, something that is DEEP in the source-code. What the Tester (and user and client) can observe, is only the FAILURE. Additionally, in most cases the tester (and user and client) don't know enough about the requirements of the software to determine what the "correct result" is to identify an Error and therefore have to GUESS whether the observed behavior is actually incorrect.
To illustrate, I'll give you an example:
A user starts a conversation with the server - containing a long series of request-response pairs. During that conversation the connection breaks. When the client reconnects to the server, it is issued a new id and therefore can not accurately be identified as the same individual that had started the interrupted conversation. Therefore the server refuses to resume the interrupted conversation.
Is that a fault? Or is that intended behavior?
Do we even have the required insight into the software requirements to tell the difference?
(so predictable)
@HPWUTeam - HPWU gains nothing - except ill-will from many and apathy from others - by taking a runestone for a fortress encounter not completed due to non-player reasons
unlike in the movie theater analogy where you still have your ticket stub to get refund, the HPWU app already ate your runestone. better approach is for app to simply hold but not take (or deduct from player’s vault) the runestone until completion
@kiheikid ...which is exactly what I described as "exploitable.
To be more explicit:
There are several Achievements that require you to do certain things in Fortresses aside from "completing". For example:
(just to name a few)
So the "exploit" would then be:
Which is why the MANUAL reimbursing contains a validity-check by the Support-Staff.
How much did you pay for your Rune Stone?
what diff does it make whether the runestone was bought for gold at diagon alley or received via giftbox or earned via challenge rank-up ?!
OK folks this maybe a situation where we all need to agree to disagree. Everyone has different opinions on what is important to them and we all react differently when things don’t go the way they should go in life or in a game. I myself have lost many runestones to God only knows what. I get in my feels when it was a level 5 runestone and I just burned through like 30 spell energy and several potions but my PERSONAL OPINION is oh well I have like 300 more runestones. At the end of the day we are all entitled to our opinions and if you don’t agree and don’t have anything nice or supportive to say then just move on to the next thread. Just my two cents. So take it for what it’s worth.
But @ClairabusGryff, he started it! (Points vaguely at no one, then walks away, embarrassed.)
@Acumen you literally make me laugh out loud sometimes!! Thank you for that!! Good lord I need it most days.
Thanks for the feedback! Our team is continuing to investigate these Fortress issues. In the short term, we are working on ways to make Runestone reimbursements support inquiries quicker and easier for players since it is indeed a common issue. Automatic reimbursements are a neat idea but implementing that would be difficult and potentially could cause more trouble than solution. Please keep writing into support when you face this issue, and thanks for your patients with this one!
What? People report in app that the game ate their runestone and they were refunded.
I used to report lost runestones. I never received a reply or replacement runestone.
After many reports with no response I gave up reporting errors about November.
Now I keep a list of which runestones have bugged out on me. I just can't help but keep stats!
@Acumen Posted this a while ago, it worked for me:
@Dewin99 You are lucky to have received a response. When I've reported things in-game I have never had a reply. Yes, I know how to click all the buttons to get to the reporting page as you have.
[quote]How much did you pay for your Rune Stone?[/quote]
I paid time.
Time and opportunity.
Getting another opportunity will take more time, as each new one is harder and harder to get than the last one.
** I am already upset at all the times that I complete something and do not get a runestone when I should. Is that intended behavior? Unintended behavior? Should I report those? I've lost track of them, and frankly, each time I don't get an expected runestone, I'm upset. **
Is there any difference between "You did not get one that you expected to get for completing X", and "You lost one for a connection problem"?
---
[quote]There are several Achievements that require you to do certain things in Fortresses aside from "completing". For example:
...
(just to name a few)
So the "exploit" would then be:
[/quote]
Have you heard of database transactions? If the transaction is rolled back, the entire change is aborted -- each transaction group is an atomic all-or-nothing.
Get a connection error, and you abort? EVERYTHING in that challenge rolls back. You recover all your things, and you do not get any progress.
This is 100% standard for any reasonable database package. All your exploits are gone.
---
[quote]To illustrate, I'll give you an example:
A user starts a conversation with the server - containing a long series of request-response pairs. During that conversation the connection breaks. When the client reconnects to the server, it is issued a new id and therefore can not accurately be identified as the same individual that had started the interrupted conversation. Therefore the server refuses to resume the interrupted conversation.
Is that a fault? Or is that intended behavior?
Do we even have the required insight into the software requirements to tell the difference?
[/quote]
I will call that bad behavior from your web application framework.
If the browser/user combo connects, they will get a session cookie to identify them. If the browser has a clean exit, remove/erase the session cookies.
If they have a bad exit, and resume session, the session cookies are still there.
If I later connect with the same session cookie, even if it is not the same keep-alive TCP connection, and the data is still around, then it's the same session.
The whole "You changed connections, so it's invalid"? That kills TOR for me. And I've seen tons of sites that do this. Right? Wrong?
Am I safer using TOR to connect to a website for nearest neighbor spying protection? (Public wifi at a coffee shop. Local ISP grabbing data on who I talk to and selling it to advertisers or complying with "government or legal requests".) Is the trade-off of "We think someone elsewhere on the internet has stolen your session ID in real time and is spoofing you so we must stop what you are doing" really valid?
The web interface / http standard ** was never designed for long-term applications **. The design was originally nothing more than "Give me this object and tell me the data type of that object". Everything else is shoe-horned onto that, with complications from Microsoft and Mozilla fighting to add features to their servers and browsers tha t the other guy didn't have. Remember how HTML used to be SGML compliant, and all the SGML tools could be used?
....🤔🧐😶
Lol
@Keybounce
Have you heard of database transactions? If the transaction is rolled back, the entire change is aborted -- each transaction group is an atomic all-or-nothing.
I have heard. That being said, modern systems are built in such a way that everything is documented and stored. Nothing is ever "rolled back" - and for good reason. "Roll forward" is far more favored.
Additionally, systems nowadays are built modularly and distributed. Have you heard of "service oriented architecture" and "event sourcing"?
Additionally, systems nowadays are built modularly and distributed. Have you heard of "service oriented architecture" and "event sourcing"?
Nope. Please tell me.
Also, "Roll forward"? ...
I can understand the idea of "log all failed transactions, and keep them, for error logging / demonstrating attempts at compliance with laws and regulations", etc.
But I'm also used to the idea of atomic transactions. No matter how it's set up, you add something to the database in a block. Maybe it's added as "non functional historical failure tracking", maybe it's added as "live, adjust all these columns", etc -- but it's always added as a group that either succeeds or fails as a unit.
Anything that allows non-atomic updates is just asking for corrupted data.
@Keybounce Welcome to 2020, where you can google words/phrases to educate yourself and where there is no "ultimately optimal" way to develop software.
As for "service oriented architecture", that's a design principle separating the problem (and the code that aims to solve it) into different, strictly separated services. The idea is built on the "divide and conquer" principle and aims to reduce the scope of complexity that developers have to deal with.
"Event Sourcing" is a design principle structuring and cutting the business-flow-chart into atomic pieces which then are implemented as events / commands. The idea is to avoid DoS situations caused by a load-peak caused by large number of users - and is therefore quite common in systems that have several million concurrent users. It understands the flow of the data and computational logic as asynchronous.
Both of these principles are strategies to manage complexity.
Returning to the original topic, both of these design principles combined would transform a Fortress battle into a set of events (which individually are atomic but the set being non-atomic). Some events would be (if these principles are used) handled by the achievement service, others by the combat service and again others by the inventory service. Given the different nature of the data that these services have to handle (achievements being increment only, combat being temporary data that's only really needed until the encounter is over, inventory being both incremental and decremental), it would not be that good to have them be stored in the same storage or handled by the same code.
So ... reading up on Wikipedia:
SoA seems to be more buzzword, with no clear single definition. But the fundamental idea seems to be Object Oriented classes. You have a protocol definition / API specification for the class, and then how it works is a black box to the users.
Event sourcing ... Google search ... Oh, so an object stores not just it's current state, but a history of all changes. So built-in audit logs.
Which just means a database with audit logs / transaction history.
So we're back to the same thing. You keep a transaction history in the database of all attempted actions. You either commit the success when the fortress finishes, or the record of the failure when it fails. Which means you record each record/transaction line, and if it completes you update the "current state" as an atomic "this changed". Otherwise, you just note that the current state did not change and the new history is a failure record.
Unless I have misunderstood something here -- again, I'm using Wikipedia and Google as my source -- neither of these is fundamentally new. One is "black box / use the API for all changes". One is "Record/log all changes over time". Both fit just fine into a database application.
What did I misunderstand?
> Welcome to 2020, where you can google words/phrases to educate yourself and where there is no "ultimately optimal" way to develop software.
(I really hate this forum).
And this is why I asked. Much more direct to get information from someone that knows what they are talking about.
@Keybounce - well said.
remember the real audience for your comments is @HPWUTeam , who might be able to do something about how this app does stuff, rather than “DrNo”
@kiheikid Just curious, why would you go to a community forum if you don't want to talk to or listen to the community?
@Keybounce In the end it is irrelevant how it's implemented - my way of saying "agree to disagree".
If it is sub-par, it needs to be changed. And if change is necessary then the required state should be described without any regard to the curent implementation. So, this would be my suggestion:
Scenario 1: Singleplayer
[Given] A user is (alone) in a Fortress Battle
[When] A connection error occurs
[Then] The user is evicted from the Fortress
[and] The entire account (energy, achievements, inventory, stats, etc) is reset to the state from before the Runestone was selected
Scenario 2: Multiplayer
[Given] A group of users is in a Fortress Battle
[When] A connection error occurs for one of the players
[Then] The entire group is evicted from the Fortress
[and] The entire account (energy, achievements, inventory, stats, etc) of all group members is reset to the state from before the Runestone was selected
That would represent your suggestion, yes?
PS: if a player runs out of energy during a fortress battle and buys more energy via $$$ since he has too few coins, that would obviously also be reset - transfering the $$$ back to the Player
... Are you saying that a connection error for one player tosses the entire group out?
>[When] A connection error occurs for one of the players
[Then] The entire group is evicted from the Fortress
Yea, if the entire group is evicted, refund /restore everything.
... Are you saying that a connection error for one player tosses the entire group out?
Yes. The reason for that suggestion is that both difficulty and rewards are based on the number of players and invested runestones. If that changes during the battle, the safest way of avoiding exploitation is to reset it.
The exploit I'm thinking of is this:
1. enter the Fortress in Dark V with 4 other players
2. Let the other players use potions non-stop to overpower all enemies but one
3. Let all other players have connection errors (which then refunds energy, potions and runestone)
4. Defeat the last enemy
5. Get the reward for 5 invested runestones of which 4 were refunded