Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by Ext3h

  1. Just my two cents on that topic: Sickness should never have been able to kill eggs and hatchlings owned by an active user. Give users a bold warning next time they log in. Give them actively a chance to react / fog / whatever. Only apply death mechanics if the user is either inactive, or chooses not to take any immediate actions. As it is, the sickness mechanic is broken by design. It's meant to protect the server from being overloaded, but the design is so broken that it is instead more commonly used for grieving rather than actually ensuring system stabili
  2. EATW is gone forever. Someone did pay quite a decent amount of money for the attacks during the Christmas event, and I am not going to deal with this any longer. (Just for the order of magnitude: Someone had the resources to deploy ~1000-1500 concurrent users/bots for 3 days straight during the attack. That is far beyond just being a little prank, most likely someone used a real botnet for this.) The API access to dragcave.net (required for accessing scrolls etc.) was already shut down by TJ09 during the attacks, and I have terminated the webspace and the domain. The do
  3. Not glitchy, "just" under attack. Some 500-1000 additional fake users on the auto viewer turning into an mass view bomb. EATW is diisabled for now, but it's quite possible that now other hatcheries will take the hit instead. Just keep everything you have fogged, and only unfogg at the 4 day mark. No other chance for now.
  4. Whoever is trying to "help" is still certainly doing so. I'm sorry for all of you who lost eggs and hatchlings due to that attack, that was certainly never intended to happen. I have just added a global limit to the number of open autoviewers. While the hatchery is still quite hot at the moment, this should at least get it down below the "deathly" levels, back to where the regular sickness protection starts working.
  5. Looks like someone tried to be extra helpful and added the whole EATW site into a visitor exchange site. This has happened before, but not at this magnitude. If this continues, I will have to add counter measures to EATW tomorrow. Need some time to figure it out. Unfortunately this can happen to any other hatchery as well, all of them turn into view bombing if someone adds them to a visitor exchange.
  6. Great, that's still pointing to the old server. Contacted TJ, something needs to be updated. For the meantime, I have to deactivate the login verification.
  7. eatw.net is back online. I'm sorry for the inconvenience, the old server finally decided to die so I had to move to a different server. It should be accessible to everyone again within the next 6 hours or so.
  8. It's not any different right now, at least not when using the truly fully automated hatcheries. I mean the ones already containing sickness monitors. Viewbombing and the resulting deaths mostly only affects people who are being targeted, newbies make that mistake only once and then steer clear from high traffic sites.
  9. Of course it can. And one possible solution would be asking users to confirm that they actually posted their dragons on a specific site. And only accepting views/clicks from sources with confirmed referrals. That would be on TJs half. Also yet another possible solution: Simply getting rid of sickness. It's nonsense when TJ claims that this would be required for server stability, it's actually quite simple to turn of the logic for a while and to serve static and forcefully cached images once the requirements for growth have been met. Traffic is cheap, and pure statically resol
  10. Well, and now he is mandated to make this real.
  11. Indeed, that was one awesome episode. I can't even believe that Moffat wrote it, for one time one of his stories actually made sense and was fully resolved.
  12. Lowest stats I've ever seen: Views: 930 Unique: 197 Clicks: 9 Growing with less than 1k views or less than 200 UV isn't that special when looked at individually, but together? And a second candidate (almost as impressive): Views: 426 (!) Unique: 331 Clicks: 34 And for the highest records: Views: 26726 Unique: 4411(!) Clicks: 429
  13. Well, the EATW version does check all generations by default (not only the first 7 or so) and I will replace it with this version soon: http://dc.makegames.de/lineage.php (Inbreed checker (not only duplicates, but shows you where the inbreeding actually occured), lineage viewer for up to 15 generations).
  14. Apart from the fact that you are not allowed to do page scraping anyway (since it causes way more load than performing API requests, if you have a specific issue with the API, like missing informations, contact TJ09), you are performing way to many individual requests. This has probably triggered the firewall on the Dragcave server, DoS protection rule. This type of rule kicks in, when an individual IP causes more connections than usual and will lock you off for a certain time. When the IP ban is removed, you are able to connect to the dragcave for a few seconds / minutes before the ban i
  15. Sure, that would help. At least while the Cave is lagging. Issue is the combination of an increased number of eggs and hatchlings with dragcave lags. And I wouldn't use the ER at all right now, the autocleaner is broken too, so your eggs won't get removed and might die from sickness.
  16. And what would be the reason in your opinion?
  17. Because they are all served by the same server and generating them costs a lot of time, compared to any regular page. It has only limited resources, so increased activity on the forums will also increase load on the server. Turning of the extra goodies would help if they were the sole reason, but they are probably not. EATW has overcome the same problem by putting a server side cache in front of the API which also reduces page load times by a significant amount. AoND has yet to take that step.
  18. It's an issue with the server capacities, trust me, I know that error message. You have to many users online and some of your scripts need to much time. Since you are using Apache, EVERY script running at the same time requires its own apache thread, so if 80 scripts are executed in parallel (and they are, since they take so long, btw.: downloads, like the forum sigs count too), 80 apache threads are all blocked. Be default, only about 100-120 apache threads are allowed, once they are all used up, users will start seeing 503 errors. You could increase the maximum size of the thread p
  19. It's not the number of dragons which causes the capacity problem, but the number of users online. Which is odd, since there are only ~80 users are currently using the page (which is already peak), but there are also the forum signatures which put additional load on the server. Last but not least, the server is using Apache, that works quite fine while the load is reasonable, but performance degrades when pushed to the limits. Nginx or lighthttpd could take the load much better. If a user uses the (inefficient) lineage viewer or inbreed checker, things will go completely upside down.
  20. The quality of episode was surprising for sure, after the mess Moffat caused the last time (not only once...), I honestly didn't expect that he could have written this episode. Maybe not the most original idea (as DarkEternity noted, the ideas are not so new), but still a decent resolution to the mystery about Clara. But while I like the resolution, the ending makes it way to easy to predict the whole next season John Hurt is probably next incarnation (timewise) and will serve as antagonist for the next 1-2 seasons. Final of next or after next season is probably going to be reincarn
  21. Ads never stopped to make viable profit. While there are many users who use adblock, most don't. They don't even know about the existence of such plugins.
  22. Guess i know what happened... The API has a "bug" which will cause eggs which are in the AP (or the AP backlog) not to be included in mass requests. The hatchery however depends on mass requests to determin whether eggs have hatched or if they became ER. To avoid the bug, Derek decided to remove all dragons from the hatchery which had not been in the list returned by the API. So far so good, thats the same what I have done on EATW and it's the only way to deal with the bug. But Derek forgot about another bug, the infamous lagmonster (It's not dead!). Sometimes the API will return onl
  23. There is no problem with the code, the frame loads fine. You are just not getting served any ads. Most likely reason: Due to the bad placement of the ad (ads should ALWAYS be placed in such way that they are inside the viewport on page load!) you have dropped to a CTR (click trough rate) of ~0. Google will disable ads for domains where the ads are shown (and you have quite some impressions every day), but never clicked to protect themselfs from "hidden" ads. You must generate a new banner, place it in a more visible place and you will be fine. Consider placing 1-2 728x90 banners on p
  24. It's just the default 30 seconds timeout. Have you tried calling set_time_limit(0) to turn off time limit? Besides, I'm not surprised that your script runs into the time limit. API calls actually ARE your problem since they consume a lot of time. If you want, I can give you an alternate script for rendering lineages which will do dragons like Rovlf in less than a second (<100ms if just checking for inbreed status, not rendering the lineage), including inbreed check on all (including invisible dragons), generation counter, (better) hidden cells (not just hidden per CSS, but excluded, ju
  25. Mailed with TJ today, and yes, the massview is kind of broken right now. It's not eggs from hidden scrolls which refuse to show though, but dragons which are currently in the AP or the AP backlog. For now you must test if the returned result matches the request and consider any missing dragons as abandoned and not yet picked up. There is also a slight caching issue which might cause it to return results which have been outdated for a few hours, so you need to trick it by randomly shuffling the request to bypass the cache. But if that isn't even used for the lineage viewer, uhm... Did