RedgeZat

Monty Python postulated it was after you read what they called 'the funniest joke on earth' So here is the question, if you survive that joke, do you have an uber weapon?

Books in game, what a Novel Idea. And something to do at night. A simple thing to add in, with some relevance to society, and no reason to be upset if you don't read. Since it is something to do.

If the game has crafting, it would make sense to gather resources during day, shelter and craft at night. Although in reality they should have a realistic day night cycle. 2 hours day, 30 minutes night, since most people sleep at night, and that is not modeled if it is 2 hours day, 2 hours hours night, and I don't know, I haven't played the game. And having players online while having to sleep would be comically unworkable, although it could be presumed that everyone would sleep for 1:30 min of the 2 hour night, and emulated with faster night, slower day.

I understand that, However there are many situations where there is no real hack that can occur. For instance. 100 zombies in a town, you spot when on outskirts of town. What good would a hack be, they are all out of range, and non aggro. Then when they aggro, they become server zombies (interaction), and are validated as not moved or hacked, on your client. You could also have Client Side Zombie followers that act off of 'Server Zombie' until aggressive, or attacked, adding an exponential growth to number of zombies. But I do understand the concern, it makes it, because the OS does not have In Process Protected Memory Access, Locked Memory, possible for some to hack. If the OS added a way for a program (with user permission) to lock a few megs of memory supported by chip architecture, that whole problem would be solved. It used to be that one process had to open a named pipe to access memory of another program, that is how it should have stayed, and should be chip defended. So that programs can set what is secure to the program, and what is able to be moved around accessed by other processes. although then some 'agencies' could not read all the work products, papers, and items on every computer, so they don't want computers secure. And of coarse much of those hacks done by those same contractors would then not be able to be used to try and defend some feudal system where some want to control some sector of some market, and only have those that submit to there controls allowed to have hack free interactions, although that is a long story.

Thats the way I see a zombie game should be also, When did 'other survivors' become the biggest threat in any zombie movie. (other then the bikers, the governor, and the soldier in 28 days) Honestly people would be using bows and arrows till somebody figured out how to make shells primers, and quality gunpowder, and even the machined M16 jammed in Vietnam, so home made shells? Automatic pistols and rifles would be jamming all the time.

Well that is why you don't point weapons at people. As far as involuntary trigger pulls to balance encounters. I haven't played the game, and think it being mostly guns is unrealistic. But that is a really good idea. It basically lessens 'who shoots first wins', and that makes KOS not as often.

Although the only reason the Hud hack and such things exist, is the OS was built to be insecure. That and chip architecture should have been where security started, but insecure systems can be profitable to those that make them.

The real problem is the Hud Hack, since the client would know where the zombies would be. Although there are ways to do that. Dynamically updated code injections in real time. If someone was reading the mem location of 'output' of 'zombie location' they could create a hud. However that location would be algo based on a time based changing algorythm, that would have to be rehacked, everytime the mem location and algo is changed. Plus a few red hearings. They could figure out where zombies were, at some previous cache time, but they might not be in the same place next time.

Obviously not, when they can't make zombie hordes. And I am not trying, I typed that up in a few minutes, it is obvious, hence the original question. Where is the logic flaw, and why the limit on loot and zombies?

I understand that, It creates more security, in exchange for server load. I am pretty sure I could still secure a system while still using client processing. The server always knows where the character is, The server always knows where the zombie should be. The server does not process the movement, until an interaction occurs though, and only then as a check to make sure it is in the right place. It doesn't matter if the player, 'moves a zombie' because the server would know it when it reported the 'detection' or 'kill' or whatever. and it would flag as a cheat.

I am saying moving anything other then player interaction that could form a gain or lose, client side. (And the player detection by a zombie.) Any actual interactions would be moved to server before a loot drop or combat occurred. The Game devs still have access, however the scrips are stored on the client(that is the algo), and at time of interaction, location is validated on server. And could be changed and downloaded at anytime, and would be a good idea actually. And if a player hacked the script, as soon as he attacked the zombie, or got within view, it would be in the wrong place, or wrong type, when elevated to server zombie, and it would be detected. the idea is the movement scrips don't need to be processed on server, then new waypoint sent to client, as long as when an interaction occurs, there is a check to see if that is the right place for something to be. I understand, when it moves to client side, it is hack visible. Although could easily be encrypted and changed regularly. However the only time a hack matters is when a player gains, or avoids a loss, so the 'position' at that moment could be checked, and only then, to validate that a cheat is not being used, and server would not have to manage every movement every time for every zombie movement. When a zombie gets elevated to a server zombie, (only time it interacts with a player), the server would check to make sure it was where it was suppose to be, if it wasn't the player can be checked for hacks. Loot drop would not be on the client, since anything killed would have been elevated to a server zombie, before it was attacked. As far as macro scripts If that is what you meant by scripters, as long as the center node moved, and spun, and algo was changed occassionally, it would not be possible to figure out a 'script' to match a location. If you mean a script to hack the hex code, it would show up as a cheat.

Thanks for the reply, Although actually it wouldn't, it would be either client side for everyone, where its location is known from a computed pattern on every client based on timestamp algo, and owning node. Or anytime the server AI took over, it would be Server side for everyone in its range, where the server starts broadcasting its 'AI governed actions' Think of it this way, every zombie not 'attacking someone' would always be at a algorythmic location on every client. All the client would need to know is zombie node location, and a timestamp, and zombie number. It could compute where it should be at any 'moment in time' and it would look random since it would be algorythmic. (zombies that get stuck could get bumped to server status by a client in the area, or by themselves from any client if to far from 'there node' when the node moves on a vector.) Then when it attacks, or sees someone, the client it 'sees' (detection is also a client algorithm) sends a message to the server, Zombie (some number, AI Active) then every player in the area starts getting that zombies 'server directed actions' even if it is only attacking one player. Every client stops rendering it as a Client Zombie, and starts rendering it as a Server Zombie, with AI movement commands. And the zombie would be at the same place on every client, when all there clients started getting the 'server zombie' AI commands with way points or attack commands. (including the person that initiated the start of the sequence.) Summary The zombie would be at the same location on every client, until a 'client' reported that a player was sighted, or it was shot or interacted with, Client of player reporting the doing of the interaction. Client sends message, activate zombie Server then broadcasts change to server zombie to everyone in that 'area' Client stops rendering based on algorythm Server also sends with that its new waypoint or vector of movement to everyone in that area. <- *that solves the problem you mentioned Server moves zombie, broadcasting changes to everyone in that 'area' as new paths are decided. <- *that solves the problem you mentioned When combat 'detection' is over, zombie is pathed to where it would be in the client algorithm, when it gets there, a message is sent back to everyone to make it client zombie again based on client side algos. If someone left the area, the 'return to client status' message would have a fresher time stamp, then there older cached message of zombie node at that location, (that had it as a server zombie), and so they would get the server message to refesh its location when returning in range of area. I think it would work, but I want to hear possible problems with the approach. For security all interactions get que'd on a server idle thread, to then be double checked at sometime to locate anomalies (cheats on a client since server would know where they should be also) And also some checks during idle time to make sure 'detection' on client is not hacked.

Can't you clip out details and swap out textures, that would make gamma change useless. At night, surface illumination < some value, flip to texture dark no details. Put a check in the rendering cycle for ambient light and total light. add a global 'dark texture' if at anytime light is to low, texture is swapped with dark texture. You would not have to check every polygon being texture every render cycle, since if you checked 1% every render, in 3 seconds it would adjust all the textures to dark, or back to normal. And the checking would only have to be done at night, when there is less rendering occurring anyways. If a mobile light source, such as a player light is in the area, bump it up to 100% for close polygons since then it would have to flip based on a point source light moves Note the 'light reflective properties would have to be copped over to dark texture in the case of reflective surfaces, so that it would stil accurately illuminate things around it with what little light it does get, however it would solve gamma hack. Or something like that.

I can postulate a reason. In society groups of people that communicate cause information exchange and organization. Organization among the peasants leads to learning and exchange of ideas, sometimes against some feudal system. So making games with less and less chat, or circumstances where you don't chat with others, can create a limit on the abilty for society to learn or interact with each other. The safest society for a ruling security state is everyone in a cell, not able to speak or be heard by anyone else. It is a common method in prisons, and a trend in some gaming. And training hostile actioins to others could keep the peasants fighting amongst themselves in work and other enviroments in life also, if the mentality transfers over to real life. If a game wanted to solve that, where it was not where everyone was out to steal from everyone else, The easiest way would be to lessen the one shot kill, or first strike as the way to win a battle, and make 'using ammo' a decision, make it expensive, so there is a cost reward to such attempts. Such a game could create a lessing of the KOS pvp, but if that was the intent, I would be at the taverns right now.(long story) RedgeZat Although with the voice chat, that probably is not the intent, but if there is reward for asshat behavior, and punishment for civilized behavior, society can move that direction, including in a game.

Well technically making shells with primer caps would be rare in post apocolyptical enviroment. As would making granulated high quality gunpowder However people would be making muzzle loaders with home made black powder, easier to make. So a smoke, to lite the fuse on a muzzle loader while in combat, would make sense. Although I understand people like guns in games, even if it is not realistic, so meh, whatever. Modern Guns with working reliable ammo would be top tier weapons.