Jump to content

CedarFever

Members
  • Content Count

    4
  • Joined

  • Last visited

Community Reputation

0 Neutral

About CedarFever

  • Rank
    On the Coast

Profile Information

  • Gender
    Male
  • Location
    Austin, TX
  1. A lot of DayZ survival is about making trade-offs where you weigh risk and reward. Right now, if you choose to open a can of food with a sharp object other than a can opener you drop some food on the ground and end up with a partial container of food at 75% +/-. You eat, but you don't get as much as you would if you found a can opener. Suggestion: Give players the option of eating the spilled food but include a low chance that they will get an infection from doing it. Desperate players already eat rotten fruit even though that makes them sick. Why not throw in a little more risk & reward?
  2. CedarFever

    Way to prevent server hopping for loot

    @ Dchil - That's a fair criticism. To absolutely prevent something like that would require tracking at the item level. It could still be done but there would be more network traffic and DB overhead. It might not scale well considering they've already sold 1mil+ copies of SA already. I did search the suggestion forum before posting, but if you've seen a workable suggestion from someone else please point me toward it, I'd be interested in reading it (no sarcasm). @ Dale - When I make a suggestion I believe in providing more than just the basic idea. It can help a developer to have a basic framework for implementation, even if they totally gut it to make it work. As for your suggestion, I think that wouldn't work well for a number of reasons: Griefing - A player could just server hop in the military barracks wiping loot on one server after another. Newbs - It's hard enough for newbs to find the basic supplies needed to survive. Add in loot wiping from their spawn-in and all the other newbs and people will be resorting to cannibalism. Still exploitable - Players would just figure out what the reset radius was and make sure to move that far away from the loot spawns before server hopping. The smaller the radius the easier this would be, the larger the radius the worse #1 and #2 would be.
  3. CedarFever

    View Current Time (Day/Night cycle) in Server Browser

    I would certainly appreciate this. Though I don't know if it is a good idea to include the exact time of day. Depending on how loot respawn is implemented that might make it too easy to hit servers just as loot pops. What about using general terms for the time of day? Morning (6am-noon) Afternoon (noon-6pm) Evening (6pm-midnight) Night (midnight-6am)
  4. I don't see any suggestions here for reducing or preventing server hopping by people trying to maximize their loots. So here's my suggested implementation. I make a few assumptions since I don't have any visibility on the code, but I feel they are safe assumptions. Assumptions 1) Every loot spawn in the game has a unique identifier of some sort. 2) Every server has a unique identifier which is tracked in the same data center environment as the central hive. 3) Character records are stored on the central hive and are unique with a standard set of character data. 4) Loot spawns are tracked at the server level but when a character picks up, drops, consumes, modifies or transforms items, that information is sent to the central hive and the unique character data is modified. Implementation Add a table (call it LootHistory) to the character record on the central hive with three fields: LootSpawnID (key) ServerID Timestamp Add a value to the central server Settings for the amount of time that must pass between accessing the same LootSpawnID on different servers: LootCooldown TimeStamp value is provided by the central server. When a character accesses a loot spawn on any server the LootSpawnID and ServerID are sent to the central server. The server queries for that LootSpawnID in the character record in the hive with 2 possible results: 1) The LootSpawnID is not present. If so, the central server sends an "OK" to the game server and the character can access the loot spawn. An entry is made in the character's LootHistory table with the LootSpawnID, ServerID and Timestamp provided by the central server. 2) The LootSpawnID is present. This character has accessed that LootSpawnID in the past. The central server compares the ServerID in the entry to the ServerID sent by the game server with 2 possible results: a ) The ServerID in that entry is the same as the ServerID sent by the game server. In other words, the player is accessing a loot spawn on the same server where they last accessed that same loot spawn. This is common and acceptable behavior. The central server sends an "OK" to the game server and the player can loot items from that spawn ID. The timestamp is updated on the hive. b )The server ID in that entry is different from the ID sent by the game server. In other words, the player accessed a loot spawn on one server in the past and is now on a different server trying to loot the same spawn. There are two logical branches from this: i ) The (current Timestamp - record Timestamp) > LootCooldown. This indicates that the player did loot that spawn in the past but has passed the acceptable cooldown for accessing it again. The timestamp for this entry is updated with the new game server ID and a new timestamp provided by the central server. ii ) The (current Timestamp - record Timestamp) value is <= LootCooldown. This indicates that the player is server hopping and looting the same area (military barracks, anyone?). The central server sends a "Not OK" to the game server and the character cannot access the loot. Since they can't get loot, there is no need to update the character entry in the central hive. (edit) On character death/respawn the LootHistory table in the central hive would need to be cleared. I think an implementation like this is fairly straightforward and would do a lot to prevent server hopping. A better implementation would probably be to restrict the loot drawing in the world at all in addition to preventing looting in the 2)b)ii) case but that would probably be a bit more complicated and might require some client-side changes as well which might be exploitable.
×