Timed storage value?
- Thread starter strutZ
- Start date
Most servers ive seen scripts from uses the time as the storage value, the ORTS project has 37 functions that does it the same way.
How am I retarded? If you can't explain why you would use that way then just stop responding, there is no reason to continue this if you IQ is that low.
It isen't a fully working method if it requires patches at onLogin or onStartup and as ive explain it can be abused.
But in that case explain how you would do it so it can't be abused, because what you have showed CAN be absued as ive explained now 2 times.
I really think you should learn abit more lua if you think your way the superior one.
And it's funny, you have been registerd since 2008 but still haven't learned that it isen't allowed to double post?
But yeah I think that is for the best but IMO if you fail at an easy task as this then you must have failed at even bigger things haha
The function os.time() gets the time in seconds, it can be used for dates, but it's also really useful to use with storage for an exhaustion for a longer time.
Since os.time() gets the time in seconds, it will be a big number. This number increases every second with 1, so it becomes bigger.
For example os.time() = 1432143850, 10 seconds later it will be 1432143860, so 10 more.
Now when you use os.time() with storage, you add os.time() as storagevalue + the time of exhaustion.
This will add 120 seconds to the time os.time() returns, so if os.time() is 1432143850, the storagevalue will be set to 1432143970, so 120 more.
To check if the 120 seconds have passed, all you have to do is compare the storagevalue with os.time().
This checks if the storagevalue is higher than the time from os.time().
The storagevalue will stay 1432143970 untill it's set to a different value again. The time from os.time() will increase 1 every second.
So when the 120 seconds haven't passed, the storagevalue will still be bigger than os.time() and this way you can use it as a time based storage.
The function addEvent executes an other function after a certain time. Using a creatureid as 1 of the parameters of the function you wish to let addEvent execute can have some cons.
If the player logs out, no matter if this is from relogging, dieing, a crash or a server restart, cid won't be the same anymore once the player logs in again (it's possible it's the same after a restart/crash, but then the event won't run anymore so it doesn't matter).
To prevent errors and bugs after a player logged out or died, you can check if cid is a player, in old versions this was done with isPlayer(cid), in TFS 1.0+ you can use Player(cid).
Now if a player logs out, it won't give errors, but it also won't set the storagevalue anymore.
If the storagevalue should always be set to 0 after you relog, you can add player:setStorageValue(70065, 0) also in login.lua.
If it should be set to 0 after a certain time, or should decrease after a certain time, you can use 2 storages, 1 with os.time() and the other one that should have specific storagevalues.
Since os.time() gets the time in seconds, it will be a big number. This number increases every second with 1, so it becomes bigger.
For example os.time() = 1432143850, 10 seconds later it will be 1432143860, so 10 more.
Now when you use os.time() with storage, you add os.time() as storagevalue + the time of exhaustion.
Code:
player:setStorageValue(70065, os.time() + 120)To check if the 120 seconds have passed, all you have to do is compare the storagevalue with os.time().
Code:
if player:getStorageValue(70065) > os.time() thenThe storagevalue will stay 1432143970 untill it's set to a different value again. The time from os.time() will increase 1 every second.
So when the 120 seconds haven't passed, the storagevalue will still be bigger than os.time() and this way you can use it as a time based storage.
The function addEvent executes an other function after a certain time. Using a creatureid as 1 of the parameters of the function you wish to let addEvent execute can have some cons.
If the player logs out, no matter if this is from relogging, dieing, a crash or a server restart, cid won't be the same anymore once the player logs in again (it's possible it's the same after a restart/crash, but then the event won't run anymore so it doesn't matter).
To prevent errors and bugs after a player logged out or died, you can check if cid is a player, in old versions this was done with isPlayer(cid), in TFS 1.0+ you can use Player(cid).
Code:
local function doSomething(cid)
local player = Player(cid)
if player then
player:setStorageValue(70065, 0)
end
end
addEvent(doSomething, 120 * 1000, cid)If the storagevalue should always be set to 0 after you relog, you can add player:setStorageValue(70065, 0) also in login.lua.
If it should be set to 0 after a certain time, or should decrease after a certain time, you can use 2 storages, 1 with os.time() and the other one that should have specific storagevalues.
Flatlander
Species Developer
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.
But from my experience using os.time() is not only easier, but its better, avoids possible exploits, and saves computation power from other methods.
You can use os.mtime() if you want to go into miliseconds even.
You basically have 3 choices.
- 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.
owned
Excellent OT User
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.
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 we got mtime for that]
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.
And you could easily make a talkaction that tells the user how long they have played with a character in total, along with their current play session.
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.
And you could easily make a talkaction that tells the user how long they have played with a character in total, along with their current play session.
Last edited:
owned
Excellent OT User
Well of course, a system like that, it wouldn't even be logical to consider using an addEvent for due to the fact that it would require constant checks indefinitely.
Flatlander
Species Developer
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.
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().
owned
Excellent OT User
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.
Last edited:
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.
owned
Excellent OT User
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.
Flatlander
Species Developer
Why use storages at all if you are going to do it that way?
Just make a table
Code:
local libStorages = {}
Code:
libStorages[cid].quest1 = 1
libStorages[cid].poisonSpell = 5
libStorages[cid].itemExhaust = 10With 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.
Nothxbye
Banned User
- Joined
- Jan 22, 2012
- Messages
- 1,124
- Reaction score
- 173
You dont get the point of this topic
Considering you cannot use addEvent to reset a storage unless you also lock the player from logging out I think that it is far inferior to using storages and os.time.
If you want to store a state in addition to the cooldown you can just use a 2 storage to handle that information.
I would rather have 1000 storages in use than 500 storages and 500 events which the scheduler has to maintain.
If you want to store a state in addition to the cooldown you can just use a 2 storage to handle that information.
I would rather have 1000 storages in use than 500 storages and 500 events which the scheduler has to maintain.
sircurse
Curseria RTG - TFS 1.1
It should work if you get the player ID and pass it inside the addEvent call, and on the local event to remove the storage id do it by calling over sql too, so if the player is on simple use the setStorageValue, if not update on sql directly.
Curse.
Curse.
Xagul
deathzot.net
- Joined
- Jun 30, 2008
- Messages
- 1,294
- Solutions
- 3
- Reaction score
- 1,037
There are 2 "good" ways to do this, each has its own benefits.
1. set a storage value to os.time()+cooldown_in_seconds > check if storage value < os.time() and if it is then the cooldown has ended.
2. create an exhaust condition with a unique subid > check if creature has exhaust condition with subid and if it does then it is on cooldown
The main benefit of option 1 is that it persists through logout.
The main benefit of option 2 is that it doesn't require a storage value. (Note: does not persist through logout)
Using addEvent not only requires the addEvent but it also requires a storage value anyway so for the sole purpose of a cooldown this would be extremely redundant.
In addition, if using os.time or exhaust condition you can tell a player exactly how long they have left before the cooldown expires, this is something you could not do with an addEvent unless you make the addEvent -1 from a storage value every second which would be far less efficient than just using one of the other 2 options above.
That is my 2 cents. Have a great day!
1. set a storage value to os.time()+cooldown_in_seconds > check if storage value < os.time() and if it is then the cooldown has ended.
2. create an exhaust condition with a unique subid > check if creature has exhaust condition with subid and if it does then it is on cooldown
The main benefit of option 1 is that it persists through logout.
The main benefit of option 2 is that it doesn't require a storage value. (Note: does not persist through logout)
Using addEvent not only requires the addEvent but it also requires a storage value anyway so for the sole purpose of a cooldown this would be extremely redundant.
In addition, if using os.time or exhaust condition you can tell a player exactly how long they have left before the cooldown expires, this is something you could not do with an addEvent unless you make the addEvent -1 from a storage value every second which would be far less efficient than just using one of the other 2 options above.
That is my 2 cents. Have a great day!
