I agree with you. Losing your gear to lava or your base to a purge or even another player, is not a GM issue, it’s part of the game. That is not considered losing anything to a bug, which is totally different.
It’s going to happen, you will lose something to a bug. If, and it’s a big if, a GM is available to look at what happened and can interpret that this is a loss due to a bug, maybe they can find a solution, maybe all they can do is say “That’s sucks, I’m sorry, I’ll bring it to the attention of the Devs.” GM’s are not teachers for noobies, they are not babysitters, they do not get involved with game play.
The absolute worst thing a GM could do is help a player gain any type of advantage.
Maybe a GM would not be available to help the player, 100 tickets in que and yours is number 99. You may not get an answer the same day you put the ticket in. Too late to help with the bug, but not too late to document the issue for you and send the info to the Devs. This is not bios, this is work load.
Funcom would have to make a list of what they (Funcom) considers a violation, and a list of recommended actions for those violations. They would also have to make that public, so there is no question by the players.
The only interpretation a GM can make is “Could this be an honest mistake?” If the GM answers “Yes” then just warn the player and explain this is a violation and they need to correct the issue.
In the case of Under-meshing and building outside the green wall, those are blatant violations. Funcom has already stated this. So anyone doing it can not claim it is an honest mistake. The recommended action should be, in my opinion, remove the base. The player is still in game, the account is still active. They are still the same level, they still have the inventory they were carrying. The base is removed along with all thralls and chests. Seems harsh but, I feel if people know it’s a violation and do it anyway, they should understand there are consequences.
You are also correct, there are three types of servers with three different play styles.
What may be considered Abuse and a violation on a PVE server, may be considered a war strategy on a PVP server.
Under-meshing and building outside the green wall is a violation on any server I believe.
In the case of a Newly dressed thrall falling through your base floor to Oblivion:
On a PVP server, that may be considered hands off, by Funcom.
On a PVE server, it may be okay to help the player retrieve that thrall if a GM has the time.
If you lose a thrall to lava, the only response a GM could give for that, no matter what server you are on, is: “This is not a bug” and if the GM were feeling particularly snarky, they may add “LOL - Learn anything”
A player base being destroyed by a purge: “Learn anything”. Ticket closed.
There would be variables depending on the type of server the GM was called to.
@Shadoza Has legitimate concerns. I am am not discounting those concerns at all. In fact I have the same fears. That is why I would hope that some safeguards and a good application and screening process would precede any implementation of this type of system Also, a good outline of violations and recommended actions regarding those violations would be essential. Violations would pertain to GM’s also. A GM caught playing the game while logged into their GM account would be considered cheating, however, the penalty for a GM cheating would be even more severe than a player caught cheating. The actual penalty would be up to Funcom and GM’s would be made aware of those penalties prior to accepting the position. While logged into a GM account, your actions and locations would need to be logged. My recommendation to a GM would be never enter a server you have a game account on. Refer the ticket to another GM or a Lead. This will prevent any misinterpretation that the GM is cheating, or showing any bios.
In my opinion, cheaters are where a GM system would make the most difference. On all Official servers.
@Kapoteeni You are correct, Volunteer GM’s would work the hours they want as many hours as they feel comfortable with. I recommended 4 to 6 hours because more than that and the GM’s head would explode. GM would not be given specific schedules that they are required to follow.
There would undoubtedly be times when no GM was on or no GM was available to answer a ticket.
There would most likely be too few GM’s to handle everything.
However, if a GM could successfully handle one or two tickets during their time spent in the GM system, then that would be a success for the system and would be a success for the entire game community.
Handing out Deputy badges is a good analogy, and that would destroy the system. You are correct. That is why I suggested an application and screening process. Not everyone that applied would be a good fit. Funcom would have the headache of trying to weed through the applications to hopefully find a few that would be a good fit.
I know it puts another load on Funcom in the beginning but I feel it would reduce their load in the long run and be worth the initial time invested.
It also gives Funcom Devs a powerful tool in that they can then request GM’s gather certain information regarding bugs to help them determine the priority in which they deal with those bugs.
So even if a GM was unable to assist a player in recovering from a bug, the player would know that the GM is gathering information about that bug, forwarding that to the Devs to help them determine the best approach in addressing that bug.
@SilverxCloud My opinion is, GM’s should come into this knowing there is 0 compensation. They get nothing. They do it to help further a positive gaming experience for all. That is not to say that Funcom can not look at the GM’s and say, this particular GM has really stepped up and provided a positive experience for the players lets reward them with a DLC. But the GM should not expect anything in return for their service.
I apologize for the late response guys, but when I logged in and tried to respond, the system told me I had to wait 6 hours. I’m not sure what I did wrong but, sorry about that.