Hello Bukkit, I've been assigned a task; create a bounty plugin. Within the specification it states that the bounties must still be there even after a reboot (save the Hash Map to file, then load it) and there must be a configurable time limit to as when the bounties are removed. Saving and reading these from a config file will be very unstable and will cause lag (500 player server), so what is your advice, how to save the bounties? Also, how would I go about removing the correct bounties are the correct time, add a time stamp to the data that is saved? I really am stumped; that's why I am asking for some help, Thanks in advance, Thomas.
Store it in an SQLite database and put a Unix timestamp and how many milliseconds untill the bounty should expire, then check the database every so often and check if the timestamp now - the timestamp >= the length of the bounty and if so remove it. If you can't be bothered with SQL then YAML/whatever is the way to go.
thomasb454 No, it won't be very laggy unless you flush the file often. Using getConfig().getInt() and .setInt() that often will be completely fine, as long as you don't call saveDefaultConfig() too often. Even if you have doubts, just try it and see how laggy it really is. It honestly should be fine if you just put one saveDefaultConfig() in your onDisable().
I'm going to need to check if x player killed y player, if so x player gets x amount which z player has pre-defined, so whatever way I do this will be intense. I can't even think of a way to give them a unique ID
No no no. If I player X place a bounty on player Z, then player Y kills player Z how would it know to remove me too (I think I am confusing myself, this is probably really easy ._.)
thomasb454 when someone sets a bounty on someone, add that players name inside the config section for that bounty.
thomasb454 Doesn't matter, it won't be any more intense than using a HashMap. Because that's probably what's saved for use when you load a config file in. Why are you complaining so much without having tried it? Just implement it like that and if it's too laggy, then use the previous method. But I can almost guarantee you it'll be just as fast.
