Used in a lot of places? Are you retarded? It's not used in a lot of places lmao And how is it not a fully working method? Please explain? Cause any person that's not a moron can make sure that it can't be abused. There's absolutely no reason on earth to use os.time for something that's probably not even over 20 seconds for the reset, and on top of that, depending on the script, a person may not just want a storage set back to 0, they may need other results as well. So your beloved os.time is only productive for this specific use. It's by no means better, and achieves nothing better. The functionality of it provides much less options.
player:setStorageValue(70065, os.time() + 120)
if player:getStorageValue(70065) > os.time() then
local function doSomething(cid)
local player = Player(cid)
if player then
player:setStorageValue(70065, 0)
end
end
addEvent(doSomething, 120 * 1000, cid)
My point is not that os.time() shouldn't be used in setting storages, it's the fact that when it comes to setting storages it's circumstantial. I have scripts that need to read particular storages aswell as get particular values for that storage and that storage can be a range of number. Therefore it can't be set to os.time otherwise how else would you check the storage for what you need. Ex:I use os.time() for everything that is a timer.
You can use os.mtime() if you want to go into miliseconds even.
You basically have 3 choices.
Clearly, the best option is #1. If you can explain a better way, then let me know.
- Set a storage as os.time() or os.mtime(), then check to see if enough time has passed (simple subtraction). **Crashes, restarts, deaths, logging off, etc will not be broken with this method**
- Set the storage as true (or 1) then use an addEvent to set it back to false (or -1). Then make a creaturescript for onLogin to set it back to -1 (for when players die, or log out before the addEvent completes, or the server shuts down) **You can simply relog to reset your cooldown, which in some cases is game-breaking**
- Set the storage as the cooldown (such as 5, for a 5 second cooldown). Then use a globalevents that runs every second to subtract the cooldowns of all players online. **Has the same benefits as #1, but also you have a globalevent or onThink running for all online players setting their storage values.
But from my experience using os.time() is not only easier, but its better, avoids possible exploits, and saves computation power from other methods.
If im not wrong os.time stores the time in seconds not milli seconds, so os.time is not optimal for low cooldown stuff like a 5 seconds cooldown. (because accuracy is +/- 999ms).
But for anything else, os.time rocks. There is no harm in storing a big timestamp value as a storage.
For instance an age system / online played time counter is stupid to make with addevents, it is way better to do it with os.time storage calculations.
storage onlinetime = duration_player_been_online
storage onlogin = os.time
storage ondeath/logout = os.time - onlogin = elapsed time.
onlinetime += elapsed time.
Sounds perfect,My point is not that os.time() shouldn't be used in setting storages, it's the fact that when it comes to setting storages it's circumstantial. I have scripts that need to read particular storages aswell as get particular values for that storage and that storage can be a range of number. Therefore it can't be set to os.time otherwise how else would you check the storage for what you need. Ex:
if get storage(z) = 1 then do x elseif get storage(z) = 2 then do y(not a code just example) and this could go on for 4-5 storages values. but yet these storages need to be set to 0 after a certain amount of time. How could I use os.time() without adding more storage holders and further complicating things? From an organizational standpoint it doesn't make sense. Where as I can just make a onLogin script that contains every storage value I want set to 0 on a players login which lets be honest, doesn't compromise the performance optimization anyways. So lets think here, do I want to rush things and compromise how things are organized on my server, or take a little time and do things in a way that will be more constructive in the long run? Don't get me wrong I use os.time for storages every now and again, but as I stated above, it's circumstantial.
My point is not that os.time() shouldn't be used in setting storages, it's the fact that when it comes to setting storages it's circumstantial. I have scripts that need to read particular storages aswell as get particular values for that storage and that storage can be a range of number. Therefore it can't be set to os.time otherwise how else would you check the storage for what you need. Ex:
if get storage(z) = 1 then do x elseif get storage(z) = 2 then do y(not a code just example) and this could go on for 4-5 storages values. but yet these storages need to be set to 0 after a certain amount of time. How could I use os.time() without adding more storage holders and further complicating things? From an organizational standpoint it doesn't make sense. Where as I can just make a onLogin script that contains every storage value I want set to 0 on a players login which lets be honest, doesn't compromise the performance optimization anyways. So lets think here, do I want to rush things and compromise how things are organized on my server, or take a little time and do things in a way that will be more constructive in the long run? Don't get me wrong I use os.time for storages every now and again, but as I stated above, it's circumstantial.
Yea well obviously something with a long term cooldown can't be used with addEvent, other wise players would just log off and then back on. I'm talking about things that are under a 60 second cooldown, even under a 30 second cooldown. Things that even if they logged off and back on, isn't gamebreaking.Sounds perfect,
Except... you give a player a cooldown, but they can reset it anytime they want by logging off and on.
THAT is not a solution. The entire point of a cooldown is to limit the player from using something too often, if every player can just bypass the cooldown then just remove the cooldown and let them spam it.
Hey dickhead, shut the fuck up. You're annoying. I wasn't even talking to you. My method isn't wrong. It works best for me while maintaining organized. Obviously a system that is done over the course of an hour can be abused with an onlogin script. Do you really think the majority of storages that are reset after x time are done over a long period of time? Cause if you do you're a bigger idiot than I thought.You have a thing on your keyboard called "Enter" use it when you write a dot. Please.
I'm surprised you still haven't admitted that you were wrong, 4 people with alot of experience have now said that os.time in a storage value is the best way to go.
And as some of us have explained your way can be abused while our can't be.
Just take @Ninja who wrote the script I linked to, if he had used addEvent a player could do warzones at 9.00 (server save at 10.00) and then get the reward 1min after that again.
And that is if you go with a startup script, an onLogin script would make it posible to make it how many times you want per day.
This can be closed IMO, the best solution to reseting / increasing etc a storage value after a certain amount of time is to use os.time() or os.mtime().
Yea well obviously something with a long term cooldown can't be used with addEvent, other wise players would just log off and then back on. I'm talking about things that are under a 60 second cooldown, even under a 30 second cooldown. Things that even if they logged off and back on, isn't gamebreaking.
Hey dickhead, shut the fuck up. You're annoying. I wasn't even talking to you. My method isn't wrong. It works best for me while maintaining organized. Obviously a system that is done over the course of an hour can be abused with an onlogin script. Do you really think the majority of storages that are reset after x time are done over a long period of time? Cause if you do you're a bigger idiot than I thought.
Oh okay, use os.time when a storage contains a string. Let me know how that works for you. Yet you still need to reset that storage. Oh wait you can't. I by no means claimed to be good at lua, I'm average at best. I just really learned it 8 months ago for the most part. It's pointless talking to you because ever since I originally proved you wrong, and "owned" you (ref to "owned") on the other thread you just try to come around riding my ass on every other thread like a 10 year old girl. You've proven in your posts that you are by no means intelligent and can't even use proper English half the time. So have a good day and stop dick riding me kid.Really dude how old are you? I know 6 year olds that act better then you lmao...
You method is wrong as have been proven x amount of times now.
But you know some people with mental problems have problems understanding and learning when they do something wrong.
So ill just stop responding to you, since there is no reason "owning" (ref to "owned") you at what you seem to think you are so good at.
Yea well obviously something with a long term cooldown can't be used with addEvent, other wise players would just log off and then back on. I'm talking about things that are under a 60 second cooldown, even under a 30 second cooldown. Things that even if they logged off and back on, isn't gamebreaking.
Hey dickhead, shut the fuck up. You're annoying. I wasn't even talking to you. My method isn't wrong. It works best for me while maintaining organized. Obviously a system that is done over the course of an hour can be abused with an onlogin script. Do you really think the majority of storages that are reset after x time are done over a long period of time? Cause if you do you're a bigger idiot than I thought.
local libStorages = {}
libStorages[cid].quest1 = 1
libStorages[cid].poisonSpell = 5
libStorages[cid].itemExhaust = 10
Why use storages at all if you are going to do it that way?
Just make a table
Then any time you want to save some sort of cooldown do:Code:local libStorages = {}
Code:libStorages[cid].quest1 = 1 libStorages[cid].poisonSpell = 5 libStorages[cid].itemExhaust = 10
With this, you can still use addEvent to set it back, but you don't have to make an onlogin script to reset it.
Storage Values are for things you WANT to save. For when the server shuts down, for when players log out or die, etc. The entire point of storage values is that they save to the SQL. If you want to save information, but not save it to the SQL. Just make a table.