WalkerDown (DayZ)

The current dayz numbers are nothing if compared with the old days... anyway you are correct, I should have specified: the rampant cheating is what killed DayZ for me (or the experience of it), since by running some servers i figured how big and disrupting was the cheating, so i stopped to play all together.

I think it isn't enabled yet (and it makes sense, since it's the first day...)... since now you can run CE without even being kicked. A3 in example didn't had any anticheat on for some weeks.

Inception... at the moment you don't even need programmer skills (the code obfuscation i was talking about) to load an offline script ... as you may swap the screen init sqf with your own script.. apparently there's no anti-cheat preventing it. You will find all the details on MPG .. i won't post the link here of course.

I know.. and i hope so. I was just a little "worried" on how easy it is *today* ... i'm confident they'll find a solution in the next weeks.

Honestly: if you are doing nothing but admitting being active in hack-communities and trying to hack the game that just came out in early access - what exactly do you want here? Do you want me to show you the door or may I drag you out personally? You mean the opposite.. i "work" for the opposite faction (the anti-hack part of it..), and the way to "fight" em is to understand what they are doing. Do you want show me the door? Grow up....

Exactly.. this is what i believed.. because of the net bubble the cheating possibilities would have been limited, but unfortunately they are not AT THE MOMENT .. this is why I asked if the current situation is just temporary or if i'm missing something here... because a stupid code obfuscation is NOT going to work you know? :)

Are you a developer or what? Rocket knows already what's possible and what's not.. at this point (nor that is too hard.. there's a whole cheating community that have already hacked it, and personally i'm starting right know to give a look at the data structure, it doesn't look the tree have changed much, so it's pretty easy to apply a simple ESP and godmode atm).

Please fix this, or remove it completely until a fix is available, this isn't acceptable even for a pre-alpha .. it's like crashing randomly and lose your stuff every X minutes (i mean it's not fun, neither if you just spend your time for exploring as you need to walk back again each time, respawning from the other side of the map).

1. Unconscious bug fix 2. Unconscious bug fix 3. Unconscious bug fix ...the game is unplayable now, you randomly pass out, so there's no reason to collect stuff or such as you're 100% sure that you will pass out randomly "soon".

I mean: the autoscroll should temporary disable automagically as soon you move the scrollbar up and reprise when you move it in the lowest part.

Small issue (it's not new tho): if you're looking at the server history, while connected, a new entry (line) will move your scrolling bar to the bottom.. so it's impossible to read the log window on a very busy server. Ideally the log window shouldn't move if you scrolled it up.

Six months reserve seems excessive to me, they keep the money for 90 days for our company... but i guess it's a matter of amounts: in our case it is hundred thousands euros each month.

The chat tab is returned to works for me, and the colors too. While i recognize that for certain ppl it could be hardly readable, especially for the side channel and its light blue / magenta .. we may need to have the colors configurable (even manually, inside the config file), or tweaking a little the colors making em darker than the original. Also, we may needs the colors even in the "All" tab, so with a single window you can control everything and follow the chat as well.

I'm trying to understand why the BE filters works sometime and sometime else it doesn't, especially with the filter trigger exclusion. Does anyone knows the magic? Example: Line in the log the users are being kicked for: RemoteExec Restriction #8 "Hit" 23:173 Survivor2_DZ - "_this spawn server_playerHit;" Line that matches the kick (the word "play"), but with the exclusion of the exact variable above: 5 "play" !="_this spawn server_playerHit;" I've also tried to remove the "=" (should it makes difference between names and contents?): 5 "play" !"_this spawn server_playerHit;" ...the users are still kicked. Does anyone know why? In other circumstances it works fine.

OFF TOPIC: dwarden you have a pvt msg .. not sure if you have PMs enabled (or the inbox full of msgs) so i'm writing here.

The first thing to learn about the BE filters is to understand that the kick #number refers to line number .. so a kick #58 means that the filter contained in the line 59 (because they starts from 0) has been triggered. So asking to help you about a script restriction #58 .. does mean nothing, since your "script.txt" file could be pretty different than mine. Easy solution: go to the line 59 and change the first number from "5" (kick) to "1" (just logging); Proper solution: examine the log file, see what's the word triggered, try to figure why it has been triggered, and exclude only that word from that line (!="keyword_to_exclude");

I can confirm that Panthera 1.8 is bugged, i'm not running it on dayz.st but on my own dedi server.. so it's not a dayz.st problem. It's also not compatible with dayz 1.7.6.1 it seems, so i have mine running on 1.7.5.1 atm.

That about this?: http://dayzmod.com/forum/index.php?/topic/88632-dayzst-30mo-for-50-slot-useu-servers-ftp-176-instant-setup-custom-panel-live-map-tool-private-hives-oring-rmod/page__st__2100#entry1200976 ...anyway you aren't kicked because the file is "too" large, but because the file exists = the size is set to ZERO (no mod allowed) so you can't really customize things that way on most dayz servers. The reason is because you can do bad things with it... nor that there isn't other million ways to do bad things on arma2.

Some of the keywords triggered from the remoteexec.txt filter list, are then logged into mpeventhandler.log (and not in the remoteexec.log as you would expect). Can't be more clear than this. :) Example: You put this into your remoteexec.txt: 5 "test" The user is being kicked for: MpEventHandler RemoteExec Restriction #0 "Hit" 23:173 Survivor2_DZ - "test" The above line is logged into mpeventhandled.log (but the filter, has mentioned above, has been read from remoteexec.txt).

Apparently BE logs the trigger in the mpeventhandler.log, whenever the filter is contained in the remoteexec.txt, because the complete line (reported) is: "MPEventHandler RemoteExec Restriction #" ... so instead of being logged in the respective log file (remoteexec.log) it goes to the mpeventhandler.log coz (im guessing here) it matches that event name. Whatever is the reason it's wrong: if a filter is contained into the "sometext.txt" .. it should be logged into "sometext.log" .. and not somewhere else, or you'll loose (like me) days to find what's wrong. The only excepetion is about the variables log.. but only because it has two separate files (for names and values...).

The "play" trigger logged into the mpeventhandler.log is read from the remoteexec.txt list, whenever a remoteexec.log exists too. That's why i've lost two days to figure what was wrong, i were adjusting the "mpeventhandler.txt" ...the reason of why it happens is beyond me.

And this time it won't start even using the old server files... it wants the correct mod files as well (i had to duplicate the folder on the server, like DayZCommander does now on your local PC, making a copy of "@dayz" to "@dayz_namalsk@dayz"). But unfortunately many users are loading the original "@dayz", and so after the update none can join the server anymore. Waiting for the update.. :)

I've found the strange behaviour, at least of that exact occurrence, while updating to 1.7.6 i spent some time to analyze every single filter and i've noticed that two of them were almost identical (well not exactly.. but most of the lines were the same). They were mpeventhandler and remotexec, and here's the strange behavior: some of the remoteexec matches (so that #8 "play" line) are logged into mpeventhandler.log ...for some exotic reason (it doesn't appears to be a bug, it's just how they decided it should works, probably for a matter of consistency).. so i were adjusting the line in the filter that matches with the log, while the filter were in fact in another file, and what add more confusion is the fact that those two files has that line at the exact same row.

Dwarden, if you read two message above, you'll notice that i've specified the line #8 "ACTUALLY ROW: 9" << :) ...plus "spawn" and "this" are much lower in the file, there's no way you can confuse it with #8 ..unless you lost 99.9% of your brain at poker, or you never learned basic math (actually counting) at school. :)

Oh ppl.. i love the fact you try to help, but please reading what i've wrote before? :) the line is the #8 and it's about the keyword "play" .. it has nothing to do with "spawn" neither with "_this" .. that are on very different lines. Thanks for have tried to help anyway. :)