laramie

Yea, the ingame panel isn't ftp access you just upload a file and ask for it to be applied manually. You could never run something like BEC on it. It's just a restricted upload portal. For example of the ongoing issues, I logged on today to find all my logs unavailable and the dashboard no longer shows players on the server.

My friends and I decided getting a server a week ago, so we went about doing so. We decided on Multiplay due to it's high popularity and we felt that paying a bit more might mean higher quality. This is a log of our ongoing experience with the company; *Days are rough estimates though close-ish* Day 1: scripts.log doesn't include any data in it... file a ticket realize that the hosting service doesn't provide ftp access, feel stupid for not checking beforehand Day 3: the web admin tool updates to include scripts.log in a special location, because we are active admins we find it quickly. Patch 1.7.2.5 rolls out... Multiplay performs multiple unscheduled reboots, with no ingame message, to install and then rollback. The notification on the website portal consists of 'We rolled back' without any reason. End result they retain patch 1.7.2.5 but are on a baseline Arma2OA version. Day 4: Spend a few hours on live chat talking to someone as to why we are on the wrong arma version and why they rolled back, when asked if we can expect it to update I get the super helpful response of 'nope'. Try to explain why having the wrong arma version is bad to staff, end result is that the boss folk at multiplay want DayZ running on baseline because it's too hard to keep up with the updates. This means checking 'Hide wrong Arma2 Version' in DayZ Commander means you will never see a multiplay server. Not sure about six launcher as I don't use it. Server population dies, as does the population across all multiplay servers. Day 5: Multiplay notifies me of the location of scripts.log (answers the original ticket) Day 7: scripts.log reaches it's size limit and locks, still waiting for a response from Multiplay on if deleting it will start a new log. This means we are unable to use the most useful anti-hack tool a server admin currently has... the log file. Battle eye updates with new admin tools, Multiplay claims it's broken and does not implement it. Making Multiplay server the goto place for hackers since their scripts.log is locked and they don't use the Battle Eye admin tools. The only advantage is because the servers are generally empty this doesn't effect much. Day 8: Post on dayzmod and get flamed (I'm guessing). For your information, Both defcon servers and host altitude allow full ftp access and run the latest arma2 version allowing their servers to actually show up on server browsers. Thanks!

You are terrible, your software is terrible, your design is terrible and you should feel terrible. Kudo's to being the most famously ineffective anti-cheat system ever invented. Your company, your design and your engine is a fraud. The fact you get paid to implement it into anything probably ended the day DayZ actually became famous and people realized how impotent your systems are. You only survived beforehand due to the relatively low number of people playing the games you 'protected'. Thanks, you useless stain of a company. -A DayZ server admin. :D Anyone wishing to vent vitriol - [email protected]

It is pretty circumstancial, however given the current climate of hackers I think less leeway is a wiser approach. He logged in at one location, teleported to another, then everyone else on the server started dancing and teleported to a third location (not near him). One other player was near his starting location (a fellow server admin), no one was near his teleport location.

We confirmed this was not the case with scott. The debug area is not the first grid update when a player logs in, the first update is there actual ingame location.

Yea, we considered that as well - but felt the teleport coupled with the timing of his login and the hack was suspicious. I understand what your saying but scott was a new player to the server, that was his first log in - so if I have banned him wrongly he has lost nothing (no vehicles, tents, ect)

Bump, Anyone know the answer to this bit; I have no confirmation that the grid numbers sent in hive updates are coordinates - this is just my understanding of the RPT data file. Anyone know for sure?

Ok so, standard stuff - player joined and teleported everyone on my server and made them dance. Dropped the server immediately to preserve my players then combed the logs. This is what I came up with: RPT Log: Player "scott" logs in @ coordinates 4725.94, 2975.5 @ 19:29:20 Player "scott" next updates @ coordinates 8426.33,2851.02 @ 19:30:16 Suspect teleport, seems obvious enough. @ 19:31:20 all non-prone players on the server have the text "_dancingduoivan" appeneded to what i call their action string. This is the string sent with every update to the hive listed in the RPT log. It generally looks something like this: 19:31:13 "HIVE: WRITE: "CHILD:201:23710907:[]:[]:[]:[]:false:false:0:0:0:0:["Binocular_Vector","awoppercmstpsoptwbindnon_amovpercmstpsraswrfldnon",42]:0:0::0:" / 23710907" And with the hack: 19:31:25 "HIVE: WRITE: "CHILD:201:23710907:[189,[4725.79,2957,0.00208282]]:[]:[]:[false,false,false,false,false,false,true,11793,[],[0.604047,0],0,[656.122,381.648]]:false:false:0:0:10:1:["Binocular_Vector","actspercmstpsnonwnondnon_dancingduoivan",42]:0:0::0:" / 23710907" Since scott was the last person to log on prior to this event, showed what I would consider a teleport in the server log, I have banned his GUID. I have no confirmation that the grid numbers sent in hive updates are coordinates - this is just my understanding of the RPT data file. Anyone know for sure? If you would like to ban the GUID from your server - here it is; scott: cae3ad112cb5a10a9f469aedfc820311

Thanks and please do add him if you run a server.

This probably isn't enough proof, but other server admins can add the GUID. GUID = d5c95fe3108f434d972162cf09e64c25