dlsmizel

Interesting update.

Nice

Let me know what you guys think. ?

That will mess up the system. But I do get your point. I honestly feel that there's no need to do this whether a player wants to go AFK, change characters, etc. This reward system COULD BE developed for AFK players. ?

Idea: The rich gets richer and the poor gets poorer. Why not open an opportunity to small guilds that do their best to join and get castles in WoE? Every WoE, the active GMs will simply take note of the following guilds who get the last break or get the castle every WoE. ------ What's needed: - forum thread where we record the names of the guilds that get a castle (every WoE) - give points to the winning guilds - 1st to 3rd prizes to the winning guilds for the month ----- Points system: 3pts to guild claiming the castle 1pt to guild defended the castle (owns the castle from previous woe) The 2-3 guilds that have more total points get the monthly reward ----- Points tracker example: March 1, 2019 (European WoE) [Castle 1] [Guildname A] = 3pts : total 15pts [Castle 2] [Guildname B] = 1pt : total 18pts

Hey guys, Run the FRO patcher to get the latest updates. For more information >

Enjoy the new update everyone!

It’s been months working on this patch. Finally released! How I love Vera’s creative thinking to create such storyline. All original in FRO. ;)

best if you can post in suggestions and be as detailed as possible

Looking good as always!

I know it will be a daunting task so I'll leave @Genesis decide on this. :)

There might be a lot of problems if we implement this.

You got a point but this is just a script update. It will need a new patch for us to be able to update the description. FYI @Genesis

This happens to some people. It could be an internet problem. I asked the person who've had this problem to restart computer and router and solved the problem. Let us know if doing so helps you too,.

I can't pretend to what the hell are you saying? This is a suggestion.

Well I'm not changing anything, I'm adding more to properly guide a host on making a decision.

It's an additional rules so yeah everything stays the same. But this is like a proposed guidelines since the rules are very broad imo.

I'm writing this on my free time and will leave it here for the meantime. When you comment, please be insightful and informative. Let's help each other. OBJECTIVE To standardize the rules and regulations of bi-weekly events Battle Royale and Guild vs Guild. To be a guidance for hosting GM and players and avoid confusion to different scenarios To successfully agree on specific rules suggested here IDEA It's not an easy task to host an event especially when there are a lot of different scenarios to happen. I will post below the suggested improvements (including the implemented rules) for the rules and we can discuss further by commenting to this post. Implemented rules: 1) Teams will battle against each other until 60-minute timer runs out. 2) The last standing guild/party wins. 3) Extensive running and hiding from GM menu is prohibited. 4) The hosting GM will have the right to make an executive decision of who to call the winner after the 30-minute mark. Improvements on the items above: 1) Make sure that that 60 minutes will be covered all through out the battle. If the event started at exactly 20:13 server time, it should end 21:13. If parties/guilds are evenly matched, the GM will have to make an executive decision. (see item 4 for executive decision) 2) Just make sure that no other party/guild is still inside the map. (see item 4) 3) Extensive running and hiding means the player doesn't do any damage at all. It may be a strategy especially if it's 1 against all. A good example of this is a Stalker vs Champ, Pally, and Sniper. The Stalker will probably wait for a chance to Strip the enemies' equipment. So to make this rule clearer, the GM should give a count down of 10 seconds for every running a player makes. The timer resets if the solo player (for example) does reasonable damage to enemies. Reasonable Damage means a total of 10k+ damage. Let's say a Stalker hits a target and does 1k damage, the Stalker needs to do more until it reaches 10k+ damage. I know it sounds crazy but you guys should get the idea of a Reasonable Damage. 4) The hosting GM is always right. But it doesn't mean you can't question the GM's poor calls. As written in the implemented rules, the GM shall call a decision after the 30-minute mark. See scenarios written below and let me know if you agree or not. 1v1 (killers) - If both teams are left with one Champ, and the 30-min mark has been reached, the GM should still allow the fight to continue. One of each will die soon because one will run out of pots or gets out of focus. If both Champs die, the winner should be the one who died last in the kill log. - If a team has a Stalker then the other has a Sniper, the match will still move on. There's a bigger chance for the Stalker to win this fight. 1v3+ (killer vs killer) - If a Stalker/Bio is up against 3 random characters, the fight must still go on. The Stalker still has a chance to fight when FCP runs out. But the fight must be called off if the opposing team has a BIO. 1v1 (support vs support) - Let's say there are two Paladins left, and both can't make high damage, the GM will turn off PvP and call it a draw. - Funny idea, how about whoever has the most seeds/berries wins? 1v2+ (support vs killers) - This is a tricky one. If a Paladin is up against two Lord Knights for example, the fight should still go on if the Paladin is geared with Reflect. An LK can die easily to a Pally if it's a BB type because of Reflect What if the server disconnects while BR is running? - Hopefully the hosting GM knows who are left inside the room and spawn them back. - Postpone the fight and have a rematch next BR/GvG. What if it's a draw? - For BR, both teams can get half the prize. - For GvG, no winners will be called. TEAM Hosting GM Danger Dream, Genesis, and Veracity RESULTS Less talks if the call made was poor or not. Collaboration with other players to share more scenarios and better calls.