Jump to content
FlareGames

thomas239

Members
  • Content Count

    204
  • Joined

  • Last visited

1 Follower

About thomas239

  • Rank
    Paladin

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @Madlen, in you wrote "At one point the Alliance storage buildings will be full. Then the button would blink forever (well until the next Conquest) because you would have no chance to donate once the buildings are full." It is obvious that this blinking should be implemented as: blink_stronghold_button = ( player_can_send_stone_resources and alliance_storage_building_for_stone_is_not_full ) or \ ( player_can_send_wisdom_resources and alliance_storage_building_for_wisdom_is_not_full ) or \ ( player_can_send_troop_resources and alliance_storage_building_for_troop_is_not_full ) Then you don't need to gate that function with conquest is active or not. It would just blink whenever a player can really send some resources, and stay silent when resources cannot be sent, either because they are not ready, or the alliance storage is already full.
  2. In cof look for the blue "i" icon. Click it and you can see the probabilities for your next draw in cof. (Scroll down to see all entries in the list!) It is updated after each draw, btw. The "i" icon also appears when you're asked if you want to quit or pay 15 gems to continue. Only after paying in the later case, gems are added as possible win. Before paying, gems are not even listed as possible win.
  3. There is an easy solution if you want to prevent abuse of building in the background with alternate designs: Let upgrades proceed only in the active design! If you start upgrades in design A, and switch to design B, all upgrades in A are frozen (countdown will stop) until you switch back to design A. Then the upgrades will continue from where they were stopped. PS: You can forge undeployed towers and obstacles in the inventory. That was always possible as long as I remember.
  4. The problem with this as well as other similar ideas is that similar to now, when teams can make peace treaties, then they can make cooperation treaties like "you attack me, I attack you, and we both earn big score/points/gold/chests/... that way." There is a fundamental problem with conquest, and that is that there are only four teams on the map, located are the very far corners of the map. As a result, every team in practice has only 2 relevant opponents, the diagonal one is √2 away. Flare tries to compensate this by placing important tiles equidistant between teams, trying to stimulate fights for these tiles. But in reality it makes the problem only worse. The team who fails to acquire these tiles cannot compete in total, because of lack of resources. IMHO, this tendency to inactivity in conquest needs to be fixed by a total rework of the map design. [Just an idea: Every team could have its stronghold in the center of a big square, which has like 40x40 tiles size (that would give team bases the same distance as now). Such square would contain mine, village and library tiles somewhere within this square. The map can then contain 9 teams in a 3x3 grid of such squares. When walking through the map, you'd wrap around from top to bottom, and from left to right edge. In other words, every team would have 4 direct opponents, and 4 diagonal opponents. Treaties will be very difficult with so many teams, but there are also more possible opponents to choose from.]
  5. The time when the tower upgrade is deployed counts, that is when you click on the floating green up-arrow. When you can't deploy an upgrade because the tower is under attack, and another tower is deployed first, the other tower wins.
  6. @Madlen, last conquest I noted that the base number of skulls in conquest wars (without war bonus, without skull bonus gear) is not calculated from the simple formula 350+7*min(Leveltarget, 95) anymore(?). Can you disclose the exact calculation used in conquest now? I've asked for skull results in my alliance, but the data points I've got are very few. From that I guess that the formula is somewhat like: 350+7*min(max(min(Levelme, 95)-50, Leveltarget), 95) In other words: Mine and the target's levels are capped at 95, and then if the capped target's level is more than 50 levels below mine, my capped level minus 50 is used for the calculation. Please correct me if I'm wrong!
  7. No, you're wrong. Forum members who do not participate in forum polls / discussions should not be counted - that's correct. But 99.9% of all players don't even know that this forum exists, nor can participate because of English language only. Again, a forum poll is what it is - a forum poll. Its relevance for decisions affecting all players is like 0.1%, aka "non existent".
  8. Indeed it is very dangerous for Flare to take the comments in this forum as "player Votum". I mentioned this already some time ago, and in the meantime they also added an in-game poll, that can provide a more relevant result for game development decisions. I just mentioned this because of your hope that this poll and its result can "close this discussion and accept the result as it is". PS: "ignore" - no, Flare should not ignore the result, but it should be given the correct relevance. At this time there is 1 "yes" and 4 "no" votes. This does not mean that 20% of the players vote "Yes" and 80% "No", but (for the ease of calculation, and because I don't have any exact number, so let's assume 100k players of RR2), that 0.001% of the players voted "Yes", and 0.004% voted with "No". Let's hope your poll gets 50k votes, and then still the player participation is only 50%. So much for the relevance of this forum votings.
  9. "players" != this forum community. Such a poll here should be irrelevant for Flare's decisions.
  10. It seems you don’t get my point at all. I’ll try to explain in more detail… Flare says that they believe some are using “fishy” methods (as you called them) in dungeons. They mention “farming” and “bots”, so let’s assume someone recorded the movements when playing a dungeon level, and can then replay them via bots, over and over. Now my first question was: For what? Is there something else than gold, XP, and tournament medals that you can gain by repeatedly playing the same dungeon level? If it is just for gold, XP or tournament medals, than these you can get from attacking any regular player, too. So the cheater that is now using a bot to replay dungeon level, can do the same with a regular player, too: Record how to beat the defense, and replay it until someone notices. The 3 attack/hour limit is not helping in this case, because if you can record defeating one player’s defense, you can do that for 10 players too, and you’ve 10*3 attacks/hour, ad infinitum. So my point is that it seems this type of cheating cannot be addressed by restricting access to dungeon levels. It needs to be addressed by detecting the bot/farming activity itself, as this can be applied to levels other than dungeon levels, too.
  11. Well said! So why is attacking the same player not an exploit, but attacking the same dungeon level is becoming one? Once completed with three crowns, you gain nothing special anymore if you replay dungeons, just the same as you get from any other player (gold, XP, tournament medal). Why do they need special handling?
  12. Re #1: When we have even more Ninja events in future, can we hope for some variety in the Ninja islands/ships? A few different sets of them, which alternate for each Ninja event, would be nice. And maybe add some more gate towers again. And I’m sorry about the reduced conquest frequency. That’s the most interesting event at the moment, in this game. Re #2: This sounds great. Looking forward for more information. Re #3: I understand Flare doesn’t want to disclose any details about the “exploits”, but @Madlen , can you please tell me what benefit is gained by them? I’m worried that if you don’t address the problem of farming or using bots itself, but just close down the dungeon for repeated use, what would stop someone using these exploits against other players? Some players are already attacked dozens of times by one and the same player, each day! For weeks. Flare seems to think the 3 attacks/hour limit is enough to mitigate this for players, so why the same limit isn’t sufficient for dungeons levels? Or can we expect a similar “fix” to these “exploits” for players too, like once you’ve beaten my defense with 3 crowns, you can’t attack me anymore? (E.g., until I modify anything in my defense?)
  13. Same issue as here: This bug happens because you've let the boost expire at the same time when the new one should get activated. A race condition between these two exists, and if you're unlucky, you get the activation first, and then the expire action immediately turns all off.
  14. That's part of the problem: When you always skip Phoebe bases, you don't practice beating it. Beast stats are scaled with the hero level of the base. Look for bases that have Phoebe, with a hero level 10+ levels below your level. Look for low level alliances, those most likely don't have high level Phoebe beast, nor high level beast boost. Use these bases to practice what was suggested above how to deal with Phoebe. Also avoid bases with boosted Werwolfs, until you're experienced how to kill them first or how to separate Phoebe from them.
  15. I can confirm that this is a real problem, and it is not because of inferior resources on the phone. I see the same problem with blocking chat every few seconds, but the phone has plenty of resources and can otherwise handle raids with a huge amount of troops and animation smoothly without any problem. The problem started only with one of the recent point releases. Before that, never had a problem there. I think it started with the tripple chats, or the longer chat history. However, I don't use my phone to play RR2 regularly, even less often use chat there. So I'm not exactly sure. I just tested it, and it seems that the blocking happens whenever a new message or status update is received in chat. Either receiving the data or rendering it for the chat window seems to be done in a bad way that blocks the UI for a notable time. The more chat activity you have, the more unusable is the chat.
×
×
  • Create New...