All Greed on Alliance loot

[Tridus]

The resources you are talking about are actually miniscule. It's a simple flag. A few bits of information (bits as in binary unit) for piece of gear. Whenever you type a full phrase in chat you are using more resources than doing that for an entire raids drop list.

No it's not. Storing it as a flag requires creating a value to flip the flag bit in, and you'll need a flag bit for every piece of loot this applies to (a frequently growing list). That also provides you with no audit trail for when the item was acquired in the first place, making it hard for GMs to respond to support tickets about it without a secondary audit log being created somewhere.

You then need that value loaded for every player in every instance. You'll need to persist it back out every time someone wins an item. You'll need to communicate it to every client so that the client knows if they can hit need or not (when client/server communication load is already an issue). You'll need to know which bit corresponds to which item, so the item database will need a value to use to correlate those.

Meanwhile, a chat message is sent from one client, relayed to some others, persisted to logs for enforcement purposes, and promptly forgotten about. The server doesn't have to refer to it again, doesn't have to keep it in memory, and doesn't have to keep it in sync with the client.

Also, someone has to spend the time developing and testing that, as opposed to something players actually want.

That's not a fix. That's returning to a state that was broken for different reason. And there are many things that worked "pretty well" for all sorts of thing. Bikes worked pretty well for few centuries. Were our ancestors supposed to stay with bikes? Pretty sure you're glad they didn't, and invented cars, trains and the like.

No, it wasn't broken. It worked fine at what it was intended to do: support the etiquette that came about in MMOs over the years where someone on the job in question gets priority over someone who wants to gear an alt. That worked fine. There weren't tons of threads complaining about how bad it was (in fact ,there was none). It's still the default system in every other roulette in the game.

If it's good enough for nearly the entire game, it doesn't sound very broken to me. Not to mention that your proposed fix is to put it back to how it was, except in a more complicated way. Your proposal lets people need again, exactly how it was before, except they can't do it twice, which was hardly a problem in the first place.

Meanwhile, this change has done something that almost never happens: get the community in multiple languages to agree on something in overwhelming numbers. SE decided to find a problem that didn't exist, fix it by reinventing the wheel, and apparently thought that wheels would work better if they were triangular and there was seven of them.

[kikix12]

No it's not. Storing it as a flag requires creating a value to flip the flag bit in(...)

Of course the feature will need to be programmed. Since everything is stored on server (inventory and class data), client will have a function that checks the flag for given character and a function for turning the flag on. That's very little resource. That's why flags are used everywhere possible. They are the least resource intensive means.

(...)and you'll need a flag bit for every piece of loot this applies to (a frequently growing list).

Um...Sure, you could make it like that. But why?! Instead of making it part of every item, just make it check the flag as part of the drop. Item drops, check the flag. Whatever item that is. Will also help people like me that don't remember whether we already have that minion or orchestrion roll.

That also provides you with no audit trail for when the item was acquired in the first place, making it hard for GMs to respond to support tickets about it without a secondary audit log being created somewhere.

Not really sure what you mean here. A time-stamp for when the flag was turned on?! If yes, then why would you really need it?! What support ticket could you send that requires it?!
"I never got that item before but I cannot need on it!"
That's about the only one I can imagine. But that actually doesn't require any information on when the flag was created. It requires information on whether a player aquired that item, and that is readily available already. They have logs that save what player obtains, when, from what source. That's how they check whether the item was obtained legally, whether a claim that there was agreement for player X to get drop Y in a party with player Z saying he's fine with that but then rolling for it anyway and so on. That relevant information is already there.

You then need that value loaded for every player in every instance.

And?! Eight bits is still just eight bits. And you know...again...it's all server-side (well...between the main server and the instance server). The only information between the server and the player is "You can/can't choose Need." and "I choose Need/Greed/Pass.".

You'll need to persist it back out every time someone wins an item.

Not really. If a player won by "Need" just flip the flag. That's, again, very little information. Yes, it's additional information, but small one and done between servers.

You'll need to communicate it to every client so that the client knows if they can hit need or not (when client/server communication load is already an issue).

Again, that's just a 1 or 0. You can need or you can't need. The client does the rest.

Also, someone has to spend the time developing and testing that, as opposed to something players actually want.

Like everything. And you can say only for yourself. You cannot say how few or many players would prefer the system as I suggested it. And compared to some of the other stuff that players ask for (like making gender-locked glamour unisex) a flag is a very basic function don't purely with a limited amount of text. The workload is nowhere near the same.


You also seem to be forgetting something very important in what you said. Checking whether you can Need an item based on class is actually...checking flags. Yeah. It needs to check whether you can need it as well. And it needs to do that for every class that can equip the item. Obviously, towards all players. And then, once players roll, it needs to deal with the Need/Greed priority. A necessity that does not exist if everyone rolls greed for whatever reason.
Sure, there is no turning the flag on upon winning, since the flag is changed based on players changing of class (which cannot happen in instance). But that's just about the only real difference in how the two checks work.


I won't respond to the rest of your post because it shows your conservative nature. You seem to assume that things cannot be made better and every change is for the worse, unless you asked for it, so there really is no point in discussing it, seeing as I believe in that everything can be made better.

I'll be blunt and say this is a piss work analogy. Cars are an objective improvement while bikes shifted to a more recreational activity. The current Greed only change does nothing but hinder progression, directly punishing players who only want a specific few pieces. While flawed, the old system was objectively better because it allowed some degree of control from the player. Now we are at the mercy of RNG entirely.

That analogy was not about greed only and the old system. That analogy was between old system and a system where need is accessible for a given item only until you get it for the first time. I'd appreciate it if you did read the actual beginning of a discussion instead of responding out of context.

And cars have tons of negatives. They are more convenient and faster. And that's about all. There are also drawbacks. They cost more to use, they are more dangerous when used improperly, they cause pollution, they are loud. they need a lot more space, they increase distances between point A to point B because they need sizeable enough roads to divide the locations etc. So no, the analogy is not a bad one. You just don't realize how many negatives cars have.

[Bourne_Endeavor]

That analogy was not about greed only and the old system. That analogy was between old system and a system where need is accessible for a given item only until you get it for the first time. I'd appreciate it if you did read the actual beginning of a discussion instead of responding out of context.

And cars have tons of negatives. They are more convenient and faster. And that's about all. There are also drawbacks. They cost more to use, they are more dangerous when used improperly, they cause pollution, they are loud. they need a lot more space, they increase distances between point A to point B because they need sizeable enough roads to divide the locations etc. So no, the analogy is not a bad one. You just don't realize how many negatives cars have.

I am aware of the context. It still doesn't work because, as Tridus pointed out, you're essentially replacing the old system with a convoluted variation of the same thing except it necessitating more coding to flag whether the players has seen the item before.

Convenience is a broad term, which encompasses significantly increased space, multiple passenger transportation, security from harsher climates and etc. Sprouting off only negative aspects ignores the objective practicality. Regardless, for someone accusing me of not reading their post, perhaps you should re-read where I specifically mention biked shifted to a recreational utility not dropped out of existence. Either way, the analogy doesn't work.

The simple fix is to revert back to how things were or implement a token system.

[BillyKaplan]

The simple fix is to revert back to how things were or implement a token system.

I rather see the systems co-exist much like they do in Extreme Trials. Your weapon dropped? Hurray! Need that sucker! It didn't? 10 runs and you still get it. It's hard enough to get the piece you want to even drop, and as we all know, even under the old system, non-tanks weren't guaranteed solo Need privileges. Healers had it worse by being guaranteed a rolling rival. The tokens would still make life easier for everyone.
The biggest coding challenge would be to make the purchase from the vendor count for the weekly lockout thing but that's adding logic that runs on-demand while the flag it changes already exists in the system. I'm not worried about getting around hiding the token in your chocobag or what not, they can just make those Key-items with expiration dates like Khloe's journal or wedding invitations.

[Bourne_Endeavor]

I rather see the systems co-exist much like they do in Extreme Trials. Your weapon dropped? Hurray! Need that sucker! It didn't? 10 runs and you still get it. It's hard enough to get the piece you want to even drop, and as we all know, even under the old system, non-tanks weren't guaranteed solo Need privileges. Healers had it worse by being guaranteed a rolling rival. The tokens would still make life easier for everyone.
The biggest coding challenge would be to make the purchase from the vendor count for the weekly lockout thing but that's adding logic that runs on-demand while the flag it changes already exists in the system. I'm not worried about getting around hiding the token in your chocobag or what not, they can just make those Key-items with expiration dates like Khloe's journal or wedding invitations.

Meant to comment on this earlier, however my ideal scenario would be a system as followed"

- You accept a quest each week ala Crystal Tower/Proto-Ultima which necessitates 5/10 runs
- Upon completing the required amount, you are rewarded with a token which can be exchanged to a separate NPC for a piece of your choosing
- If, however, you obtained something during Ridorana, this NPC is flagged as "completed"

This eliminates weeks where you'll be unlucky enough to spam 24 mans and get nothing you want. Unfortunately, they want us to spam it like that despite it being precisely what kills people's enjoyment.

[BillyKaplan]

- You accept a quest each week ala Crystal Tower/Proto-Ultima which necessitates 5/10 runs

My biggest gripe with a quest is that people are going to forget to pick it up, and then they'll complain about wasted runs. While this would be their fault for sure, we're trying to minimize people's discontent here. When you forgot the Dun Scaith quest, it wasn't THAT bad since you had to run it twice, and it was for an extra sure-get item, not one of the raid's drops. But for this, when you already need to run 5/10, that extra run could be lethal.
No other fail-safe mechanism that I know of in the game requires you picked up a quest, it's simply on as soon as you unlocked the content.

[Miscanth]

My biggest gripe with a quest is that people are going to forget to pick it up, and then they'll complain about wasted runs. While this would be their fault for sure, we're trying to minimize people's discontent here. When you forgot the Dun Scaith quest, it wasn't THAT bad since you had to run it twice, and it was for an extra sure-get item, not one of the raid's drops. But for this, when you already need to run 5/10, that extra run could be lethal.
No other fail-safe mechanism that I know of in the game requires you picked up a quest, it's simply on as soon as you unlocked the content.

As a solution to this there could be a window appearing every reset with priority quests showing like current "Recomendations" but once upon login after every reset. It could include Wondrous tails, , Raid quests for those tokens you're talking about. Also maybe savage weekly loot. Everything that is weekly.

So for Raid roulette and current 24-mans it would be a quest that you can accept from anywhere upon login, I mean, why not? It's once a week and you just click "No" every tuesday. It's not something annoying popping up every day like recommendations or player-guide (that you also can disable).

[Tridus]

Of course the feature will need to be programmed. Since everything is stored on server (inventory and class data), client will have a function that checks the flag for given character and a function for turning the flag on. That's very little resource. That's why flags are used everywhere possible. They are the least resource intensive means.

You say that, but SE gave us the glamour dresser instead of a glamour log, because sometimes they love the more complicated solution. But anyway...

Um...Sure, you could make it like that. But why?! Instead of making it part of every item, just make it check the flag as part of the drop. Item drops, check the flag. Whatever item that is. Will also help people like me that don't remember whether we already have that minion or orchestrion roll.

It's not a property of the item at all. It's a property of the *character*. Each character has to know if they've already won need on each item. So the only way to do this in an expandable way (because they'll be adding more raids with more items it applies to) is that every character has a value with X number of bits, and each bit corresponds to one item.

When a given item drops, you check each character who could need it to see if they're allowed to. That has to happen on both server and client.

And?! Eight bits is still just eight bits. And you know...again...it's all server-side (well...between the main server and the instance server). The only information between the server and the player is "You can/can't choose Need." and "I choose Need/Greed/Pass.".

It's not eight bits, unless there will only be eight items covered by this system. You do realize you need a flag for every item that it applies to, right?

Not really. If a player won by "Need" just flip the flag. That's, again, very little information. Yes, it's additional information, but small one and done between servers.

Depending on what back end data storage they're using, they likely can't write a single bit in an update. It's not a huge update, but it's an update that has to go out to persistent storage. Those aren't free, and no highly scaleable software developer wants to add more of them than is absolutely needed.

Again, that's just a 1 or 0. You can need or you can't need. The client does the rest.

With how SE currently handles communication in the game, it would send the entire collection over to the player and then need to keep it in sync. So it's more than that. It doesn't have to be, but that's true of a lot of things in this game right now.

Like everything. And you can say only for yourself. You cannot say how few or many players would prefer the system as I suggested it. And compared to some of the other stuff that players ask for (like making gender-locked glamour unisex) a flag is a very basic function don't purely with a limited amount of text. The workload is nowhere near the same.

Making gear unisex has absolutely no server impact whatsoever. It's strictly client side. They're not comparable at all. You are aware of how often "server limitations" come up as a problem, yes? Because it doesn't sound like it.

Adding more server load with an overcomplicated solution to a problem that only exists because SE created it isn't helping anyone. This was just a bad change and reverting it is the far simpler answer.

You also seem to be forgetting something very important in what you said. Checking whether you can Need an item based on class is actually...checking flags. Yeah. It needs to check whether you can need it as well. And it needs to do that for every class that can equip the item. Obviously, towards all players. And then, once players roll, it needs to deal with the Need/Greed priority. A necessity that does not exist if everyone rolls greed for whatever reason.

Checking if you can need something right now is based on your current job and the jobs that can use the item, which are already known values and are necessary to be in memory already. You're adding another one that isn't necessary and otherwise has no real use outside of this one roulette.

Sure, there is no turning the flag on upon winning, since the flag is changed based on players changing of class (which cannot happen in instance). But that's just about the only real difference in how the two checks work.

No, one is a check of "does your current job intersect the job list", and the other is "does your character state show that you've already won this item before." They're not the same thing. They're both straightforward checks, but one is using data that is already loaded for other reasons, and one is a new thing created just for this.

I won't respond to the rest of your post because it shows your conservative nature. You seem to assume that things cannot be made better and every change is for the worse, unless you asked for it, so there really is no point in discussing it, seeing as I believe in that everything can be made better.

I'm a professional software developer. We tend to like simple solutions over complicated ones, because needless complexity means more resources, more cost, and more things to break in the future. This problem has a very simple solution: the one that literally every other roulette in the game already uses successfully.

You sound like someone who has never had to implement something like this and then deal with the consequences five years later.