Jump to content

rocket

DayZ Hero
  • Content Count

    2004
  • Joined

  • Last visited

Everything posted by rocket

  1. And it would have to be encrypted locally, which would mean the process used to encrypt it would be available locally. The game has to RUN realtime, to obfuscate that data locally while encrypting it while obfuscating the encryption. Nobody does that. If it was a good idea, then MMO's would do it. This is an alpha, the purpose of the alpha is to identify these issues and fix the bugs. The community has been helpful in this instance in identifying areas of problems, usually related to unique side cases. We've come a long way already, this is not the time to go off on crazy misadventures. Stay the course, fix the bugs,.
  2. Really need to know provider, and IP. Certainly we have verified that the core servers that we run perform normally (not a single ticket raised for those servers) - therefore problem servers have to be manually checked by us then we need to contact the provider and work with them to find the solution. We are going to build in a check into the server that will stop the server running if it cannot get an authorized connection through to the central server.
  3. Roger, I'll pass that on to Brian and try and find out
  4. From what I understand, and I might be vastly oversimplifying the issue here, is that big problem related to the complex way the database (which is a cluster) is load-balanced, authorized, and then communicated with different servers. Our central server conducts loadbalancing to ensure it can handle thousands of requests a second. It also checks to see if it is dealing with an authorized server. Every maintenance we further improve this. The main issue that remained until very recently related to providers who have very large numbers of IP's. All the IP ranges needed to be whitelisted, as DayZ server doesn't have the ability to be bound to a specific IP directly (it requires it's box to do that for it). Outside of the USA, IP's can be quite hard to come by and so most aren't used to having a great deal around. Thanks to a very tough effort involving the central server hosters, the game server providers that were having problems, and our tech staff - the problem was solved. We simply whitelisted as many of the floating IP's as were required to authorize the servers. The issue brings up important considerations for us around how to deal with US hosters who might have a large pool of IP's, and how that affects us in terms of managing them, and in terms of our whitelisting process. Above all, it highlights just how complex the environment is that dayz is currently operating in. It's really like running a large MMO but distributed amongst a bunch of different hosters. For this reason, I certainly feel a great deal of sympathy with server hosters as it is not an easy environment to operate in. They are probably hoping that longterm they can make money but I would doubt many of them are making much money right now. It's really great the issue was solved, and it also looks like the database maintenance that occurred today has also had a positive effect on the whole situation.
  5. Because that's just the way it's ended up, the migration to the sharded hive system is not super-clean and data issues have been experienced by many. Sorry you had trouble, and I'm sure it won't be the last time there are data issues.
  6. It's also important to note... while most server providers are not having this problem, it is not exclusively happening to a single provider.
  7. Hey I totally understand, I also feel bad for hosters - it's a big update and we dramatically tightened up security. They're aware of the issue and by forcing hosters to turn "bad" servers off we're fully exposing the problem and I'm sure everyone will be very motivated to fix it ASAP. It's a very hard game for servers to host for at the moment, as it is constantly evolving. So my plea would be to give everyone a little bit of breathing space here. We tested with the configurations available to us here, so these routing issues weren't exposed to us during development and don't affect most providers.
  8. My plea would be for people to give the hosters a bit of leeway here. We just released a big update, it's very complex. I know they are working REALLY hard. Give them a bit of time and I am sure they will fix things and put it right.
  9. When posting IP's, would be helpful to include the server provider if possible.
  10. Because the SKS description has been added to the SKS, but it has not been added to the loot table yet because it wasn't finished.
  11. The only remaining serious issue appears to be complex routing. When routing is complex the central server cannot securely communicate with the server(s) and the messages get lost. If we allowed public hosting of servers right now the problem would be orders of magnitude worse, because we would have no control over the servers at all. Right now, we can order the providers to stop/start as needed and we only have to liaise with a handful of people to do such a thing. The problem is not as simple as "server hosters" screwing up or anything, the hosting of a dayz server is constantly changing. This is a good education why we have not allowed private servers to be hosted. It's so complex at the moment that even major hosting providers are having problems. While you might be awesome enough to manage these, when we make private servers possible we don't get to screen who has access to it and who does not - we have to make it available to everyone. And people who's job it is to host game servers are having trouble, just how easy will it be for the public? Once we have resolved all this in the future, then we can look at these things.
  12. How does one "roll back the characters"? Character data is stored in a database, centrally, across all servers. There are three databases, one massive cluster (Stable), two small (Experimental & Internal Development). When you character updates, that update is saved to the database. It does not log previous states, only current states. To log previous states for every change would result in terabytes of data being stored constantly. Even if such a thing were possible, we would not only be rolling back the characters on that server, but everyones characters - because characters are not specified to a single server. Furthermore, we can't do such a thing live, so we would have to stop the whole network and all game servers, do the update, and then roll the network back up. The moment the network is dropped, the fastest we have been able to get it back up is three hours.
  13. It appears the majority of this problem is now restricted to one provider. We are not 100% sure why this happens, it could be an issue on our end or an issue on their end - we don't know. But in the meantime, I have asked our Producer to get the game provider to shutdown all their game servers until the issue can be isolated and fixed. Will keep everyone posted about this.
  14. Agreed, it was actually a surprise to me as well. I've discussed the process with the team responsible and we will make sure that in future, database maintenance will be properly scheduled and involve a complete shutdown so people don't loose their characters etc... I'm not quite sure who thought it was a good idea to shutdown the database but not the game servers, but rest assured that won't happen again. I've made that very clear.
  15. The people who work on new content are not the people who work on these other things. I could send them all away on holiday, but instead of that, we are having them continue working while the other people are working on the bugs. For example, the SKS requires no effort from programmers. Artists are currently not involved in fixing server stability (and you would not ever want this).
  16. This is already in progress and has been for some time. Either we continue with the current system and wait for it to be finished, or we stop the whole game and hosting until it's finished. We opted to keep going with the current state until the work is finished.
  17. Look, honestly, I'm getting a little sick and a bit angry around attitudes like yours. We've just spent a very difficult few weeks working on exactly what you are asking for. The issues we are having with the hive are because we are introducing systems that will allow us to do this. For goodness sake, get off your soap box for just a minute and you will look and see that me and the entire team have been working late nights and exposing ourselves to a great deal of difficulty and tough work - just so you can do what you want eventually. You say there is no "rocket science" behind all this, then I challenge you to go out and actually do it. Because we are. And because most of the companies who have released games with complex server architecture have had disastrous releases, with far more money and experience than we have. I'm not switching on "ignore mode", I'm switching on "angry parent telling a child to grow up mode".
  18. We provide the central server architecture, which approved server hosters are allowed to access and provide servers. The servers that are paid for by Bohemia (Multiplay Servers) are all working correctly, and we ensure this as we have direct access to them. If you are particularly disappointed with any server provider, I'd recommend you contact them directly. Certainly, we've identified server ranges and we've notified the providers. In nearly all cases remaining, the reason for the servers not saving has nothing to do with DayZ, for some unknown reason the servers are not talking directly to the central server app.
  19. I really wanted to fix it now, but it involves a wildcard search of a text column in the database. It's outside the risk profile of what we're allowed to do outside of routine maintenance so our database team (quite rightly) told me it needed to wait until maintenance time. I'm quite sure that you're not the only one affected by it. The rough number that Brian told me was about 1:15000 people might be affected but most probably die via some other means without noticing. Perhaps take comfort that your (unusual) plight has highlighted a rare issue and thus will allow it to be fixed.
  20. I realize a list of IP's is not friendly or easy. The only way for us to provide more info would be to manually check it ourselves and write it down, the same as you would. We are currently auditing over 2000 servers, so the time is spent checking those and not logging a great amount of details. Internally we had a list of IP's that would then be screened, I simply grabbed that list and made it public to help people. The option was either to not publish the list, or publish it.
  21. We will fix this issue for your characters (and others who might have it) during database maintenance this weekend. Unfortunately it is too risky for us to attempt a fix during the database going live, as it is very complex for us to find the blood value. I investigated and I believe the issue is that on some very rare occasions, a players blood value gets so incredibly low that the method for dealing with blood lowering stops working. I.e. when you blood is very low, the floating point value of the blood reduction is so low that it is considered zero for calculation, therefore you never loose blood. Sorry for this, I will make sure that system is changed to deal with this situation.
  22. Yeah - good point. this whole change of the steam name thing I wasn't aware of, I'll check with Brian and let you know.
  23. By the time we would write such a thing, we could have fixed the problems themselves.
  24. "Most of the servers in this list, however, have OS problems that are causing interruptions to HTTPS communication with the central server : thus they are not correctly saving/loading." I.e. they are not properly connected, therefore not saving/loading.
  25. Servers can be set to work on a shard (a "walled garden" of the main database). This means that the server, in effect, is running on a separate hive (database) - even though that hive exists in the same database as all the others. It allows us to "support" private hives without the difficulty associated with running multiple databases. Currently we are running two shards, regular and hardcore. If the server hoster incorrectly configure their server, it will screw up and create it's own shard. Most of the servers in this list, however, have OS problems that are causing interruptions to HTTPS communication with the central server : thus they are not correctly saving/loading.
×