Raid Queue

[r8rsfans75]

You know when you go to a bar and on the pool table, there is numbered slots for you to put your quarters, to hold your spot, so when the people playing on the table now are done, they know it is your turn. I'm wondering how difficult it would be to set up raids the same way. I have seen a few issues since I turned OL135+ with multiple groups going after GoBB or the Master in the bowl at the same time. Usually not a big deal, whichever group gets the kill usually (stress usually) gets the loot and if there is something that somebody else needs they will leave it out there. But there are occassions where it seems the same people are camping the same raids over and over again. I'm wondering if we can't set up a queue system to handle this issue. Possibly set up an NPC at the various stations near the raid sites, (QAR for the controller, Paramis station for GoBB, Chernevog for the RD base, etc). Maybe attach some cost to starting a raid, each player in the raid group can only do each raid only once a day, or every 12 hours, or whatever the dev's decide is an appropriate time for each raid. A raid leader would go to the NPC and pay their fee or bring some comp or whatever. It would set up like a job, the boss would only spawn when the raid leader's group approaches the area, the boss spawns, the group kills it, loot, give away whatever, give like a 15 minute or 30 minute cooldown time or whatever before another group is able to start another raid. Each person that goes up to the NPC to try to start the raid while one is going will be put into a queue and be told they are 2nd, 3rd, 5th, 19th in line whatever, so they can plan accordingly.

I say any toon that is within a certain distance of where the boss is killed is locked from starting a new raid for a certain period of time, possibly tie it to the accounts, so that the same person couldn't log on an alt and start it again. This might prevent some of the spawn camping. Just an idea, let me know what you think.

Edited December 21, 2010 by Grendwal

[Marlee]

I think instancing the bosses would be better. Multiple copies of the same zone.

Not sure how it would work in this game, if there would be a set number of copies or if it would be dynamic.

Probably locking someone to an instance would be good also so u couldn't kill the same boss in all the copies of the zone in a row.

I know that in live the starter zones did have multiple copies in the beginning when population was high in those zones.

[Hexersup[IS]]

You know when you go to a bar and on the pool table, there is numbered slots for you to put your quarters, to hold your spot, so when the people playing on the table now are done, they know it is your turn.  I'm wondering how difficult it would be to set up raids the same way.  I have seen a few issues since I turned OL135+ with multiple groups going after GoBB or the Master in the bowl at the same time.  Usually not a big deal, whichever group gets the kill usually (stress usually) gets the loot and if there is something that somebody else needs they will leave it out there.  But there are occassions where it seems the same people are camping the same raids over and over again.  I'm wondering if we can't set up a queue system to handle this issue.  Possibly set up an NPC at the various stations near the raid sites, (QAR for the controller, Paramis station for GoBB, Chernevog for the RD base, etc).  Maybe attach some cost to starting a raid, each player in the raid group can only do each raid only once a day, or every 12 hours, or whatever the dev's decide is an appropriate time for each raid.  A raid leader would go to the NPC and pay their fee or bring some comp or whatever.  It would set up like a job, the boss would only spawn when the raid leader's group approaches the area, the boss spawns, the group kills it, loot, give away whatever, give like a 15 minute or 30 minute cooldown time or whatever before another group is able to start another raid.  Each person that goes up to the NPC to try to start the raid while one is going will be put into a queue and be told they are 2nd, 3rd, 5th, 19th in line whatever, so they can plan accordingly.

I say any toon that is within a certain distance of where the boss is killed is locked from starting a new raid for a certain period of time, possibly tie it to the accounts, so that the same person couldn't log on an alt and start it again.  This might prevent some of the spawn camping.  Just an idea, let me know what you think.

I know you don't want to hear it, but you know how it was in live?

If a queue then it must be player made.

If we would do that, we could as well give every mob in game a sign for every player. So no one can kill a mob which is signed for another player.

In live we had for fishbowl and RD base a queue. In Roc the V'rix bosses for example was pure competition. First come;) first gets the boss.

That would be the end of fun i'm sure.

But as a:)ays, just my opinion.

greets

Hexergirl

[vampirebat]

but you know how it was in live?

most bosses in live were first come first serve.

that's true however toward the end they were moving away from the open boss free for all.

that intention on their part is made apparent with the fishbowl and the zeke's machine events.

i don't think all bosses/events should be privatized cause wheres the fun in that but the fishbowl for example was instance based only those at the entrance when the person with the device talked to ole booney were teleported into the instance (thus giving the raid leader some control over who gets in and who doesn't)and you could have multiple fishbowls going on in different instances at the same time.

granted this is an emulator and it has limitations.

not all raid encounters added late in the game were privatized but clearly they did try to give guilds/raids a chance to have some fun without outsider interference.

from my own personal perspective as someone who helped lead countless public raids on peggy(we used an open auction/public raid system for for gate/controller/general and occasionally fishbowls...RD base was generally rotated among the larger guilds on the server)it just worked...some guilds may have whined that they didn't get to do these raids as a guild but they were all welcome to join and bid same as everyone else and if you got outbid so what you got paid to be there helping and the next time you came back with more credits and bid for it again and again til you won.

everyone was welcome and we all got something out of it be it loot or credits and more importantly we had fun

but im straying away from my point my point being that numerous guilds on peggy at least wanted to do some raids alone...just as a guild and they were giving that opportunity once the fishbowl came along and tho the servers probably cant handle that at this point in live it was instanced so because it isn't possible to make it how it was in live some form of informal queuing system between guilds would be a good idea imo to save on drama.

no one likes to feel left out so share...who knows next time you may be the one feeling left out huh?

[Hexersup[IS]]

most bosses in live were first come first serve.

that's true however toward the end they were moving away from the open boss free for all.

that intention on their part is made apparent with the fishbowl and the zeke's machine events.

i don't think all bosses/events should be privatized cause wheres the fun in that but the fishbowl for example was instance based only those at the entrance when the person with the device talked to ole booney were teleported into the instance (thus giving the raid leader some control over who gets in and who doesn't)and you could have multiple fishbowls going on in different instances at the same time.

granted this is an emulator and it has limitations.

not all raid encounters added late in the game were privatized but clearly they did try to give guilds/raids a chance to have some fun without outsider interference.

from my own personal perspective as someone who helped lead countless public raids on peggy(we used an open auction/public raid system for for gate/controller/general and occasionally fishbowls...RD base was generally rotated among the larger guilds on the server)it just worked...some guilds may have whined that they didn't get to do these raids as a guild but they were all welcome to join and bid same as everyone else and if you got outbid so what you got paid to be there helping and the next time you came back with more credits and  bid for it again and again til you won.

everyone was welcome and we all got something out of it be it loot or credits and more importantly we had fu;)

but im straying away from my point my point being that numerous guilds on peggy at least wanted to do some raids alone...just as a guild and they were giving that opportunity once the fishbowl came along and tho the servers probably cant handle that at this point in live it was instanced so because it isn't possible to make it how it was in live some form of informal queuing system between guilds would be a good idea imo to save on drama.

no one likes to feel left out so share...who knows next time you may be the one feeling left out huh?

Fishbowl was timed, 3 hours if i can remember me correctly. After 2:30 raid was over, regardless if you killed the master or not.

greets

Hexergirl

[Orga1]

Fishbowl was timed, 3 hours if i can remember me correctly. After 2:30 raid was over, regardless if you killed the master or not.

greets

Hexergirl

3-6hrs depending on server lag and broken stuff. I remember a few of us calling out a GM or Dev in Live just to help boot up the entire fB raid so that the gate would open and the raids be rolling again. I agree with Hex, that individual boss spawns is not worth the time and effort to handle or try to implement.

Sense were on the topic of trying to fix this issue with uber players soloing boss's. A logical suggestion could be that sense the combat functions by who dmg more, by default in or out of group. Then by doubling or tripling a boss's amount of a HP, Does not that soloing player fail to extinguish with all his might in 30min or less? Causing that experienced player to look for more help, thus interacting with other players.

Giving unto us all a new purpose to share and care with the community of this emulator. I think its a brilliant idea. Just tampering with the cl 66 mobs, no need to deal with the normal ones. If you wanted to you could increase all mobs, or reduce amount of dmg given by current end game weapons/turbo could be the OP here that were all not seeing. That in it's self might help prevent the soloing and start the raiding once again. Yay

What do you think?

[fuulishone]

In general a system managed raid queue over a contested mob is counter-intuitive. Contested mobs are like that for a reason, to increase the perception of their value and rarity, and incite the desire to do what's necessary to get him. This is what creates the need for folks to camp a spawn.

The real issue you're trying to fix is that mobs are on a schedule, and that simply shouldn't be the case. Ideally you want to implement the escalated mob system that was in live, coupled with a minimum respawn timer as well as a good randomization method to make it variable enough to be unpredictable, but not so punishing that folks give up in frustration.

What I mean is something like this...

Boss XYZ is a CL66 mob and drops a bunch of interesting uber things. To get to him you must initiate the escalating spawn cycle and complete the chain. Once you nuke the final spawn, the next spawn has a chance to be his spawn, or a chance that the cycle restarts. If he spawns and he's beaten, then an internal minimum timer starts which prevents his eligibility in that final wave...

So an example:

1. You find and beat the trigger spawn, 3x CL60 Minion ABC mobs. They need to be beat within 30 seconds of each other.

2. Roughly 10-20 seconds later, 3x CL63 Minion DEF mobs spawn and they too need to be beat within 30 seconds of each other.

3. Another 10-20 seconds go by, and 3x CL64 Minion XYZ mobs spawn, and again they need to be beat within 30 seconds of each other.

4. One more time, 10-20 seconds, 3x CL65 Minion PDQs spawn, same restriction, 30 seconds total time of death.

5. Now 10-20 go by, maybe some system broadcast text appears announcing the boss. 1x CL66 Boss XYZ spawns, along with some helpers, say... 1 each of the CL63, CL64, CL65 mobs.

6. The group beats the minions and boss, and get their loot. The CL66 Boss' internal 3-6 hr holdback timer starts now. The trigger spawn mobs will come back in say 5-10 mins (again random and not on a schedule), but farming the waves to the final one while within the internal holdback timer will simply reset to the trigger spawn once the CL65s are down.

Wait out the holdback timer (3-6 hrs, random). Start the cycle over. At the boss wave, there should be some random chance that he doesn't spawn, and the trigger resets. Make it 20% chance for a spawn so it's not crushing, but variable enough to confuse whether it's the holdback timer, or sheer chance.

If during any wave, the mobs are not beaten within the timer, then the next spawn will be the trigger spawn again. This is how the players know they messed up and need to improved their dps or recruit more friends.

More fun, add a despawn timer on the CL66 Boss if he's not engaged/beaten within a certain amount of time. Each time he despawns, increase his internal change to spawn on the final wave. Eventually he'll be a guaranteed spawn if people keep failing to beat him within the despawn timer.

Even more fun, each wave's mobs should have different abilities, resist, damage types. The shield/hull hp values should increase significantly.

This should reduce the camping of bosses, prevent the solo'ing of bosses due to the timer restrictions, and allow for groups to have content. It also gives the content devs the future ability to introduce raid mobs, but maintain their mystery. It becomes an easter egg of sorts, and folks need to start moving around exploring to find the trigger mobs.

Out in space, mission activated bosses can be handled similarly, simply make the trigger spawn an npc/nav/deco you interact with. Either by targeting it and activating a device (Oni in XT style, Ascendant Voltoi), or talking to an NPC with a specific item in your cargo (FB style activation).

[Hexersup[IS]]

In general a system managed raid queue over a contested mob is counter-intuitive.  Contested mobs are like that for a reason, to increase the perception of their value and rarity, and incite the desire to do what's necessary to get him.  This is what creates the need for folks to camp a spawn.

The real issue you're trying to fix is that mobs are on a schedule, and that simply shouldn't be the case.  Ideally you want to implement the escalated mob system that was in live, coupled with a minimum respawn timer as well as a good randomization method to make it variable enough to be unpredictable, but not so punishing that folks give up in frustration.

What I mean is something like this...

Boss XYZ is a CL66 mob and drops a bunch of interesting uber things.  To get to him you must initiate the escalating spawn cycle and complete the chain.  Once you nuke the final spawn, the next spawn has a chance to be his spawn, or a chance that the cycle restarts.  If he spawns and he's beaten, then an internal minimum timer starts which prevents his eligibility in that final wave...

So an example:

1. You find and beat the trigger spawn, 3x CL60 Minion ABC mobs.  They need to be beat within 30 seconds of each other.

2. Roughly 10-20 seconds later, 3x CL63 Minion DEF mobs spawn and they too need to be beat within 30 seconds of each other.

3. Another 10-20 seconds go by, and 3x CL64 Minion XYZ mobs spawn, and again they need to be beat within 30 seconds of each other.

4. One more time, 10-20 seconds, 3x CL65 Minion PDQs spawn, same restriction, 30 seconds total time of death.

5. Now 10-20 go by, maybe some system broadcast text appears announcing the boss.  1x CL66 Boss XYZ spawns, along with some helpers, say... 1 each of the CL63, CL64, CL65 mobs.

6. The group beats the minions and boss, and get their loot.  The CL66 Boss' internal 3-6 hr holdback timer starts now.  The trigger spawn mobs will come back in say 5-10 mins (again random and not on a schedule), but farming the waves to the final one while within the internal holdback timer will simply reset to the trigger spawn once the CL65s are down.

Wait out the holdback timer (3-6 hrs, random).  Start the cycle over.  At the boss wave, there should be some random chance that he doesn't spawn, and the trigger resets.  Make it 20% chance for a spawn so it's not crushing, but variable enough to confuse whether it's the holdback timer, or sheer chance.

If during any wave, the mobs are not beaten within the timer, then the next spawn will be the trigger spawn again.  This is how the players know they messed up and need to improved their dps or recruit more friends.

More fun, add a despawn timer on the CL66 Boss if he's not engaged/beaten within a certain amount of time.  Each time he despawns, increase his internal change to spawn on the final wave.  Eventually he'll be a guaranteed spawn if people keep failing to beat him within the despawn timer.

Even more fun, each wave's mobs should have different abilities, resist, damage types.  The shield/hull hp values should increase significantly.

This should reduce the camping of bosses, prevent the solo'ing of bosses due to the timer restrictions, and allow for groups to have content.  It also gives the content devs the future ability to introduce raid mobs, but maintain their mystery.  It becomes an easter egg of sorts, and folks need to start moving around exploring to find the trigger mobs.

Out in space, mission activated bosses can be handled similarly, simply make the trigger spawn an npc/nav/deco you interact with.  Either by targeting it and activating a device (Oni in XT style, Ascendant Voltoi), or talking to an NPC with a specific item in your cargo (FB style activation).

Your ideas are not bad. It's just that we are not B)ady to realize all we want right now.

greets

Hexergirl