If I understood this right, here's a rather big flaw.
<Wowraiders> kill Nef on day 5 of their instance timer. Larry Lazyass was one of them.
2 days later, <Wowraiders> come back for a fresh instance. Since it's fresh, everything is fine and dandy. Larry Lazyass isn't there however, he's late, because of "internet issues". Tough luck, Larry.
<Wowraiders> kill Razorgore and Vael, and lose Stan Sleepyhead, because he's a Eurofag and has to go to bed, while clearing to Broodlord. Nighty night, Stan.
Meanwhile, Larry has resolved his internet issues and wants to take Stan's spot. <Wowraiders> are overly excited to get Larry back, invite him to the raid, and Larry happily zones in, only to be greeted by:
Ineligable RaidID Nefarian [2 days ago] 12:45am. G2EFT59
Larry is basically screwed for the entire instance timer, since he wasn't there when the raid opened the fresh instance and killed a boss.
Well, I think it would work, but I think it's perhaps overly complicated. Blizzard wants more transparency to the system, and I think that may be one of the reasons they came up with this idea.
Here's my alternative proposal:
Here is how you fix cascading:
If an instance has a reset timer of N days, there is no legitimate way that a player could have more than two unique raidIDs over a period of N days. It simply is not possible. Store a raidID history for each player for each instance. When a player is about to zone into an instance that would assign him a brand new raidID, check his history to make sure that it would not be his third raidID within a period of the last N days. If it would be his third, give an error, "Maximum unique raid identifiers exceeded; instance not found" and refuse to allow him to zone in.
That's it. No cascading will ever be possible again.
1) Hold onto all of the RaidID's a person has had for two times the Raid's duration.
2) The cannot enter a Raid where a RaidID's start date is inside a period where they have had a RaidId.
So as an example, Group A enters MC on the first day of a month, they clear it all in a day... they get RaidID 1337hax. The RaidID 1337hax has a start date of 12/1/05 and an end date of 12/7/05. Group B enters MC on 12/5/05 and kills Lucifron, they get RaidID OMGEPICS. The RaidID OMGEPICS has a start date of 12/5/05, and an end date of 12/11/05. On 12/9/05, 39 people from Group A go in with one person from Group B. The one person from Group B enters the OMGEPICS RaidID instance, the 39 Group A people get there own instance since the start date [12/5/05] is in the range set by the start [12/1/05] and end [12/7/05] date of their previous RaidID.
That idea is too restrictive. You want to allow flexibility. Maybe I have some RL friends in a smaller guild on the server and I want to help them out one week. I'm not doing it for the loot, and it's not "cascading." Any system that would stop that, or force a guild like ours with two MC groups to make them strict permagroups that people can't switch between as their schedule demands, is more trouble than it's worth.
My idea stops cascading but allows for flexibility.
Watch what happens if you try to cascade under my system
12/1 @ 8pm, MC timer abc12 begins
12/2 @ 8pm, MC timer xyz34 (cascaders) begins
12/7 @ 8pm, MC timer abc12 ends
[Raiders from abc12 jump into waiting instance xyz34. It's ok, they can do that!]
12/8 @ 8pm, MC timer xyz34 ends
Now, the abc12 people killed Ragnaros twice in the past week and they have no saved /raidinfo! Cascading ahoy! But wait, not under my system. Their MC raid history is saved for 6 days. If they try to zone in to MC on 12/9, the game will say "wait a minute, you had ID abc12 two days ago, and xyz34 one day ago! You can't get a third raidID!"
The players who were in abc12 will have to wait until 8pm on 12/13 before abc12 leaves their timer history and the game allows them to receive a new timer.
I challenge anyone to come up with a way to cascade under my system, and I think it's simple enough that you can explain it in one sentence: "For an instance that resets every N days, do not allow a player to acquire a third unique raidID over any N-day period."
I liked the initial per-boss system, but I'd modify it slightly.
Instead of the game cross-refrencing your personal boss kills as a means of determining whether you can enter the raid, it instead determines whether you can get loot from each of the mobs you killed.
Say you entered WBL on 12/1 and beat Razorgore, Vael and Bloodlord, but you had to go to sleep after that. Everyone else went on to beat Firemaw and Ebonroc before they all turned in for the night.
Next day, you all go in and finish Flamegor, Chrom and Nef. Your raid ID looks like this:
A few days later <Donkey Punchers> wants your help with BWL, and you don't really care about loot. You go in, and all the dragons are up since there's no singular raid ID configuring the whole dungeon. You kill Razor, Vale and Bloodlord and the game checks your boss ID, and sees you've already done those three. Thus, you can't lot on loot (even if you didn't plan on it, the game doesn's care). On Firemaw and Ebonroc you are given the ability to loot, but you demure anyway. On Flamegor, Chrom and Nef you can't loot again.
I think that's a decent system, unless I've missed some key factor. The only thing I could see being a flaw in this is that when you next run BWL with your own guild you wouldn't have loot access to Firemaw and Ebonroc. You could fix this by being able to add bosses to a raid ID yourself (obviously not remove, though) so everything is back to normal when you next go to BWL.
<08-07-09 02:09>[Velth] This is the behavior of a benefactor of the EJ forums?
"For an instance that resets every N days, do not allow a player to acquire a third unique raidID over any N-day period."
Bam problem solved, the only possible inconvenience under that system for "legitimate" playing for an individual guild hopping very often. But that is very minor and solves the cascading problem without the destroying the schedules of so many guilds.
Howdy Windsor. There are clearly half a dozen ways to fix cascading but I think Blizzard may have implimented this system in response to other problems as well. In any case you have to admire the simplicity of it, I can't imagine how many lockout problems pubbie runs have been having.
Fjord, you're right. Capping 3 timers every N days won't work.
It has to be 2N days, which is what I think I originally had in mind. So under your example above, after the 1/2 cascading, you'd have to wait until the 13th to start a new instance, which would be in keeping with the "proper" schedule of 1st, 7th, 13th, 19th, etc.
Originally Posted by Praetorian,November 22nd, 2005 @ 8:12AM
Well, I think it would work
Not really, as I've stated, you wouldn't be able to add people to an already running instance unless they haven't run said instance during the last time.
Your idea seems to be pretty flawless however, I can't really think of a scenario where it could be abused.
In your scenario, Gurgthock, you have two raid groups. abc12 and xyz34. abc12 finishes MC and piggybacks on xyz34's clear raidID. What if there were other groups, like def56 and ghi78? Couldn't you just keep on piggybacking on these other splinter groups? Or is your premise that every group has two open raidID slots for each raid and once both are full you can't access that raid again until one or the other clears?
12/1: MC run 1
12/2: MC run 2
12/3: MC run ...wait, GB2ORG, punk
12/7: MC run 3
etc
etc
Is that more or less what you mean?
<08-07-09 02:09>[Velth] This is the behavior of a benefactor of the EJ forums?
Right, the point is that you can only have had received two unique raidIDs over any 12-day period for MC if you are playing the game legitimately.
Normally, a legit player would start on 12/1, then the next instance on 12/7, then on 12/13.
But if you try to cascade or otherwise have circumstances arise that cause you to jump into a timer with 1 day left on it on 12/7, you won't be able to get a third MC instance until 12/13 regardless.
No I deleted my own post because there was a flaw with it. here's the new, final formulation:
"For an instance that resets every N days, do not allow a player to acquire more than two raidIDs that were created during a contiguous period of 2N days."
You have to tie it to creation date rather than date of acquirement, otherwise you screw the legit player who was away for a week, then joined his guild's old MC instance right before it expired on 12/6, then started a new instance with them on 12/7. When that instance expires on 12/13, if you only look at acquirement date as my original proposal would have done, the legit player is locked out of his guild's MC run until 12/18, which is dumb.
But if you use creation date, it recognizes that he joined an instance created on 12/1, then one created on 12/7... and by 12/13, the 12/1 date is 12 days ago, so a new instance is OK.
your amendment for the special case of someone joining at the end of already going instance looks that it woud work fine. The only issue I see and it is a very small issue but with blizzard you never know.
Guild A runs MC as soon as their instance resets.
12/1 Locked in at 8:00
12/7 resets at 8:01
12/7 locked in at 8:31 (assume 30 minutes to kill luci)
12/13 resets at 8:32
12/13 Zone in and start clearing new instance at 8:32
Guild B cascades
12/1 Locked in at 8:00 raidid XY
12/2 Locked in at 8:00 raidid AB (alts)
12/7 raidid XY resets 8:01
12/8 raidid AB is cleared by mains before 8:01 reset
Now guild B, by gurgthocks raidid rules, cannot make a new instance until 12/1 + 12 days. So
12/13 8:01 Zones in and begins clearing new instance.
Now yes im talking mere minutes, which hopefully is nothing, I strongly agree gurgthock's idea for raidids is much better than the current system or the one they plan to use. Hopefully an issue as small as this doesn't prevent Blizzard from adopting a system like this.
Originally Posted by Oof,November 22nd, 2005 @ 5:37AM
If I understood this right, here's a rather big flaw.
<Wowraiders> kill Nef on day 5 of their instance timer. Larry Lazyass was one of them.
2 days later, <Wowraiders> come back for a fresh instance. Since it's fresh, everything is fine and dandy. Larry Lazyass isn't there however, he's late, because of "internet issues". Tough luck, Larry.
<Wowraiders> kill Razorgore and Vael, and lose Stan Sleepyhead, because he's a Eurofag and has to go to bed, while clearing to Broodlord. Nighty night, Stan.
Meanwhile, Larry has resolved his internet issues and wants to take Stan's spot. <Wowraiders> are overly excited to get Larry back, invite him to the raid, and Larry happily zones in, only to be greeted by:
Ineligable RaidID Nefarian [2 days ago] 12:45am. G2EFT59
Larry is basically screwed for the entire instance timer, since he wasn't there when the raid opened the fresh instance and killed a boss.
yeah that does throw a wrench in it, i cant think of a way to prevent that from happening either.
but on the note of the other system suggested- what you could do that is very similar is this:
every character is allocated 2 raid id slots for each 6-day raid. These IDs never expire.
every tuesday, each person gains 1 new raid id slot, and loses their oldest.
this lets guilds float their own schedules ontop of the weekly "resets", and still stops cascading.
apparently i cant edit my own posts, but anyways i just figured the only real way a guild could take advantage of the aforementioned system would be if they were capable of completing the instance in a somewhat timely fashion.
guilds who were still 'trying' at bwl would get screwed just like they are under the blizzard proposed system, unless some sort of check was performed for empty flags, and not ereasing an ID if a person has an empty flag in their raid category.
Why not just let the indvidual set their own reset time by killing a boss. When you kill a boss your instance will reset the next week at that time. Give a slash command to clear your current reset time that also makes you unable to enter that instance for a week.
To clarify, the raid ID checks would also have to be there to stop cascading, but some way of letting you choose your reset time through a slash command of some sort is what I am getting at.
Originally Posted by Fjord,November 27th, 2005 @ 6:18AM
Honestly I prefer the tuesday reset to most of these crazy complicated suggestions.
My suggestion isn't complicated. :(
It would basically be the status quo, sans cascading. It would be completely transparent and you'd never even know the change existed unless you tried to cascade.
At this point I think most of us are resigned to our fates on this one. It'll be an inconvenience for learning AQ40, to say the least, but I have to admit for a guild like us that two-groups a lot of content being able to move people from, say, a Sunday group to a Friday group on consecutive weeks, is nice.
11/22/05, 7:37 AM
Similar Threads
