Cron-less Energy/Will/Brave/HP Regen + Admin Panel

[Cronus2]

I just jumped back into script writing and this was the first thing I added to my base MCCodes so things can regen without crons.
This also includes the ability to adjust the regen settings through the admin panel.

This script adds ZERO new queries to page loads, unless something is updated.
It also adds 6 new variables to the game settings table in the database, so that you can adjust the regen amounts through the admin panel.

1. Add "lastupdate" to your users table as INT.
2. Add the following to your settings table, the ID values are not important:
    
3. Add the following code to your globals.php around line 138, right after the Force Logout function:
 

You're unable to view this code.

Viewing code within this forum requires registration, you can register here for free.

This updates each as expected and will not let any of them regen over 100%.

4. Replace this section of your admin.php:

With this:
 

You're unable to view this code.

Viewing code within this forum requires registration, you can register here for free.

You will also need to add the following link to your staff admin panel menu under the area where only $ir['user_level']=2:
 

You're unable to view this code.

Viewing code within this forum requires registration, you can register here for free.

If you have any questions or if you think something is incorrect, let me know.

---------------------------------

Also, if you carry the $timediff variable into your header function in header.php, it can give you the seconds remaining until the users next regen.

I put it in the menu bar kind of like this, though it would probably look nicer as mins/secs:

Edited June 14, 2022 by Cronus2

[AdamHull]

Would this work if nobody was on the site? Would it loop through and update for the missing time?

 

This is the reason I hate timestamps 

[Dayo]

Not by the looks of it, but if no-one is on your site why use resources. Calculations like these can be done in nano seconds so it wont impact performance much.

[Cronus2]

1 hour ago, AdamHull said:

Would this work if nobody was on the site? Would it loop through and update for the missing time?

 

This is the reason I hate timestamps 

It does not update if no one is on the site, and also it only updates the user loading the page instead of the entire users table.

Once the user comes back online, it catches them up though.

[Uridium]

I like it 🙂

[Cronus2]

Updated, now comes with easy admin panel for updating the regen settings.

[WarMad]

I might play with this for a couple different things thank you

[Rooster]

Nice, anything to make MCCodes a little more economical is always a plus. 

[Ob4j4]

How do I add the timediff variable in the header?

[KyleMassacre]

1 hour ago, Ob4j4 said:

How do I add the timediff variable in the header?

The timediff would be an exposed variable so you would be able to place it anywhere. It’s been a while since I looked at global_func.php so I am not sure if there is a function that will convert to min:sec.

Bottom line, you should be able to slap that variable pretty much anywhere

[Ob4j4]

I've added the code into the header. Just don't know what line of code to add to view the regen counter.

[KyleMassacre]

All you need to do is add the $timediff variable wherever you would like it to be displayed 

[Ob4j4]

[KyleMassacre]

I would have to really look and see what’s going on. It looks like maybe something didn’t update properly 

[Ob4j4]

You're unable to view this code.

Viewing code within this forum requires registration, you can register here for free.

This is my header file.

And this is my globals:

You're unable to view this code.

Viewing code within this forum requires registration, you can register here for free.

 

I'm getting really big numbers, in some cases minus ones. 

[Inveteratus]

You know, if somebody at work posted two files totalling over 400 lines with the simple "I'm getting big numbers" complaint, my response would not be unkind, but I'd suggest that perhaps they went back to the drawing board, tried to find out what the problem was themselves, better yet, explain what the problem is with screen grabs where appropriate, and provide description of what is happening, where it is happening, and what the expected behaviour is.

A lot of the people here are lucky enough to work in the industry, but looking through poorly formatted code, without a clue as to what the issue is strikes me as being more work, less play!

Saying that, the whole delta updates i.e. timestamp based rather than cron based updates looks very messy, especially as it can be done in a couple of queries and not within a loop. If you had for example a user that hadn't logged in for one month, that loop could run over 8,000 times, generating over 1,500 queries when 2 would suffice.

Given you know the current time, you know the time the user was last updated, that gives you a time difference in seconds. Assuming that is greater than some small figure (say 300 seconds) then you can update the user's fields: will, brave, hp and energy with the time difference multiplied by the increase per second of each field which is simple to calculate.

The problem with doing this, is loss but this is only addressed by using real numbers for the four fields; the maximal values can remain integers; which in turn does cause a couple of other minor issues.

Nothing against the original author of this, conceptually it's a neat trick, but anytime you have a query in a loop, you need to start asking questions. With the default DB schema, even a simple SELECT operation will lock the entire table for all other operations, so this method will quickly limit the amount of simultaneous users you can have on any system, and has the potential to cause unpredictable and difficult to debug timeouts.

Finally, it's great to update your own player like this; I use a similar technique, but what happens to other players? NPCs being the obvious example. If you have a number of NPCs that people can fight against, how do their stats regenerate? I simply pose the question, I don't offer a solution here, though it is simple to implement.

[Uridium]

8 hours ago, Inveteratus said:

You know, if somebody at work posted two files totalling over 400 lines with the simple "I'm getting big numbers" complaint, my response would not be unkind, but I'd suggest that perhaps they went back to the drawing board, tried to find out what the problem was themselves, better yet, explain what the problem is with screen grabs where appropriate, and provide description of what is happening, where it is happening, and what the expected behaviour is.

A lot of the people here are lucky enough to work in the industry, but looking through poorly formatted code, without a clue as to what the issue is strikes me as being more work, less play!

Saying that, the whole delta updates i.e. timestamp based rather than cron based updates looks very messy, especially as it can be done in a couple of queries and not within a loop. If you had for example a user that hadn't logged in for one month, that loop could run over 8,000 times, generating over 1,500 queries when 2 would suffice.

Given you know the current time, you know the time the user was last updated, that gives you a time difference in seconds. Assuming that is greater than some small figure (say 300 seconds) then you can update the user's fields: will, brave, hp and energy with the time difference multiplied by the increase per second of each field which is simple to calculate.

The problem with doing this, is loss but this is only addressed by using real numbers for the four fields; the maximal values can remain integers; which in turn does cause a couple of other minor issues.

Nothing against the original author of this, conceptually it's a neat trick, but anytime you have a query in a loop, you need to start asking questions. With the default DB schema, even a simple SELECT operation will lock the entire table for all other operations, so this method will quickly limit the amount of simultaneous users you can have on any system, and has the potential to cause unpredictable and difficult to debug timeouts.

Finally, it's great to update your own player like this; I use a similar technique, but what happens to other players? NPCs being the obvious example. If you have a number of NPCs that people can fight against, how do their stats regenerate? I simply pose the question, I don't offer a solution here, though it is simple to implement.

Some people learn things differently than others what's right for me and may not be what they had envisioned, Ever had something in your head that you cant quite explain to others how to picture it ?? This is the same thing. Its the correct format for them but we see it differently. but either way the end result works...

[SRB]

15 hours ago, Uridium said:

Some people learn things differently than others what's right for me and may not be what they had envisioned, Ever had something in your head that you cant quite explain to others how to picture it ?? This is the same thing. Its the correct format for them but we see it differently. but either way the end result works...

I'm sure everyone has done that, however....

"Here is all the code because I can't be bothered to debug shit myself", is a bullshit approach.

Even a basic var_dump of the variable, so it would at least return (string "") or something, would be more research than it feels has been done.

Feed a man a fish and he'll eat for a day, and all that shizzle.

[lucky3809]

To put my 2 cents into it, he just gave people mmcodes for free, posted all the main pages ones plus database sqls. 

My advice is LEARN PHP, no one is going to do it for you, if you can't learn it you will never be able to have a game and control the bugs and whatever happens in it. Or be able to update it. Unless you are loaded with cash and pay someone to do it all for you.

Edited November 30, 2022 by lucky3809