rocket

Please post the servers that you are experiencing character saving issues on.

Good luck :) Those Russians are pretty tough :D

As I understand it, you can only join US4&5 with the beta, but I could be wrong.

I thought so too, so I stopped using that (closely followed by lots of emails and jokes about talking to oneself). But I reintroduced it when it became apparent it wasn't working. I even tried attaching your initial body, which has no visual geometry, to your new body. Still no joy. I'm hoping its something in my hackery that is causing and thus can be reasonably easily fixed if it can be identified among the swathe of errors, bugs, and general hackness.

Tents disappearing are a result of the server admins (those providing and running the server), restarting the connecting application when it gets "hung" on startup. This then kickstarts the server into carrying on, but skipping vehicle and tent generation. On busy servers this can happen quite alot as the server is trying to create items and it cannot create them fast enough. So your tent is not lost, vehicles are not lost, but if server administrators don't restart the whole server, and just restart HIVE, then the vehicles and tents won't initialize properly and you get the situation you have described above.

Careful now :) What I have actually said, was that I no longer directly target DC with my code. However, I use selectPlayer which I believe could have an effect as this is a relatively new command and has many issues that have been well explained and explored by Kju and others. I also group everyone in one group. What I said was that IF it is either of these issues, then there would not be much I could do short of either it being changed in code or in me reversing that functionality (in one large group, using selectPlayer). However, we have reports that when the mod is activated that DC doesn't work even when not on the DayZ server, just on another mission - so its entirely possible that there might be something causing it. Either way, the solution is not an easy one and needs testing. Identifying the problem then results in me either fixing it in my code, or getting good reproduction steps and including it at a ticket on dev-heaven. But I can't jump to any conclusions now, and given the hackery involved in the mod any speculation on the source is wild at best.

Thanks so much for the speed sickboy. I am sorry I haven't been able to get in touch (I will add you on skype). literally every moment I am either coding, or opening up a new server :(

The disabled input was actually caused by selectNoPlayer. 1.5 is in final testing now. Its a bugfix build with some minor new things to do.

Here's the explanation for long loading times on full servers: HIVE (the connecting application between the server and the master system) currently runs asynchronously, but on one thread. It has to do ALL updates sequentially and each update can take about one second. With fifty players, moving constantly, currently this means that the thread spends nearly all its time processing player updates. The whole system was working "okay" until I split login into two parts, which means two transactions for the server. I had to do this, because ArmA2 has a limitation on string size and loading in data for inventory for heavily laden characters was breaking this. It also meant I could add no more data. A new transaction means at least twice the length of login, as they aren't timed together and are in competition for a chance on HIVE's thread. The system prioritizes those already in game to provide the best playing experience. The best advice I can offer is to either wait, or visit a server that is not overloaded. Disconnecting and reconnecting will do nothing except place you lower in the que and also increase the loading by adding another transaction. Anyone who has seen HIVE's output window will know, that the poor application is pushing well beyond its limits. It needs multiple threads. I will be splitting this out into two parts, one thread will be dedicated to logins and deaths, one will be dedicated to player and object updates. This will double the capacity and the speed.

My zombies are animals, spawned in from "createAgent" and managed in a scheduler. They have no formation, no FSMs, no groups, no targets. This is all done manually by a much more efficient method, doing the target acquisition and processing on for each client rather than each zombie (who can see me?). The problem with using individual FSM's and Scripts is that you either clog the system up, or invoke a script scheduler overload. To overcome this problem I simply ripped everything out engine wise. Each client themselves figures out when and how a zombie might see them, regularly, using a scheduled environment. The servers do only two things: 1. All the stuff they do normally 2. Sync everything to an external data repository, again done in a scheduled way

Would love to have people mirroring and/or launchers - but with the need for updates and bandwidth requirements I don't think they can keep up. One of our guys wrote a launcher actually, but it became a real pain updating it especially for critical hotfixes. A new issue is bandwidth, I've churned out over 500 GB in four days, off my (paid) mediafire account. Do you have the Bandwidth to cover that? We've had over 3000 unique players in a week, logging over a year in gametime - assuming no growth in players beyond this, it could creep into the terabytes for a month.

To clarify: Not going to remove or even restrict PVP. The intent of this whole mod is to provide you choices, the intent of the planned change (humanity) is to provide some impact of those choices. There's not "punishment" for PvP, but doing alot of PvP will cause your character model to become a "bandit" model. This will make you recognizable as the type of role you have taken on. Your choice in the world is whether you want to retain your humanity, or whether you want to survive. The two are not mutually exclusive, but sometimes you come to a situation where you will need to make a choice. My whole intent, with the entire game mode, was to make a situation where real human emotions are forced out and experienced - both the good and the bad. My experience in the military taught me sometimes the most rewarding moments come when things were the hardest, when terrible things happened, but they were overcome. My key intention was to make something very brutal, almost cruel, for those like me (I'm the kinda guy who always turns the difficulty right up to max) who want to experience real human emotion (be it absolute frustration, defeat, anger - through to happiness and excitement). I guess what I am saying, is it has not been about "gameplay balancing" (which is not my best area), but about forcing the player to make choices, some of which are cruel, some of which are not balanced at all, and some of which can easily lead to no win situations. In fact, I didn't even intend it to feel like a game. I prefer the term "anti-game" because I've broken many of the "rules" of gameplay. But personally, I think that's why it is enjoyable even in its very broken and basic state.

515 concurrent players now. Slots are very full, please don't sit of the system AFK and hold other people from gaming :) Remember you can log on to any available server with the same character. 2 new US 50 slot servers have just opened up.

Morality system, now named "humanity" is currently in local dedicated testing. It will be released for a single public dedicated test within 12 hours, assuming no showstoppers. When your humanity drops to a certain level, you become a "bandit" and your character model is changed accordingly. Humanity is persistent across all your characters.

Yes the tent can be robbed, choose a secluded spot. This is not really a game as such, its more a social experiment. It's very brutal, when you die, you start again in a new character. You cannot packup another characters tent, only the character who pitched it can. Players can setup as many tents as they find.

Pitch a tent, the cargo is synchronized with the database but will only be loaded on THAT instance (ie that server).

Anyone interested in setting up a server can email dayzdevteam@gmail.com As I said earlier. It's not just a mod, there are a number of external applications that go with it. And if EVERYONE tried to setup their own server, the central server wouldn't be able to handle the requests. It's not a matter of "releasing" it, in order to setup a server, a detailed and careful process needs to be followed to install it. If the settings are not right, then your expeirence will be even worse and your previous saved characters could be corrupted and deleted.

Only clean kills are recorded as a kill. Which involves a fatal shot (head or in terms of damage). If you incapacitate them and they bleed out, you don't receive the Kill.

In the future - time permitting (and once I have completed the project) - I intent to release a "DayZ lite" which is just the scripts and framework for mission designers to use. As it stands, they could actually use most of these as it is by studying the files themselves and reverse engineering how I put together the Zombie AI and the approach I took to the scheduling dilemma usually faced by servers in particular. It's not a "home user" system. There is a central server controlled by a central database and application (EXE). Then there are child nodes, that communication through an EXE also. This connects with ArmA2 and populates the world inside it. This "extra-net" uses ArmA2 as its canvas, but paints from its own memory. Even if I were to release all of the source for the EXE application, the EXE itself, you would need to map out the IP schema in the database to authorize the child nodes, configure the database to your requirements, populate the world. I don't think this would run very well on one computer, certainly not with the >600 zombies and fifty players on the USA server tonight.

Not sure what you need? the mission pbo is available when you download, and is very small. Its about 10kb. I think you might misunderstand what this system is, its a persistent world system, when you login - you character is saved not just in that server, but all servers. What happens to that character, down to which weapon you have selected, and which animation you are currently in, where you are bleeding from, total kills, headshots, distance traveled on foot, to name but a few... is all synchronized to a central repository. None of that is done through the mission file, which contains only player slot data, five markers, and an init.sqf file. The rest is scripts and configuration in the addon, together with two external EXE applications that perform various interrogation and communication roles with ArmA2 and utilize databases for storing, sorting, and reviewing data.

Please note: Previously you created a new character on each region (europe, usa etc...) which you joined. This has been removed for your characters. Any server you join will have the current details of your character... HOWEVER - tents, vehicle locations, are specific to that region (Europe, USA, NZ). Some people might find a previous character has been loaded - if this is the case, email dayzdevteam@gmail.com to have your other character, ermmm, "put down" as it will always return your latest character.

You don't need PMC or Carrier Command. I apologize for the confusion - us kiwi's sense of humor runs deep! I just think people should buy them because they're awesome :)

It's a total conversion for ArmA. A "lite" version will be released later that will allow the elements to be used separately. When you play it once, you'll realise why it needs a specialist server setup, and why ACE is not necessary nor could it be integrated very easily.

Automatic Respawn currently has some issues. If you go to the lobby and come back in when you die, then it will work okay :) ArmA2 needs to be connected to a standalone application and database in order to run a DayZ server.

SaMatra, i think you experienced these on the DayZ server - not on the DZS server?