ID:1222249
 
Keywords: builtin, cpu, proc, stat
(See the best response by Dariuc.)
Code:
mob
Stat()
sleep(2)
statpanel("Stats")
if(statpanel("Stats"))
stat("Name: [src]")
stat("~~~~~~~~~~~~~~~Vitals~~~~~~~~~~~~~~")
stat("Level: [level]")
stat("Level Points: [src.levelpoints]")
stat("Race: [race]")
if(usr.race=="Arrancar")
stat("Number: [espadas]")
if(usr.combat2)
stat("Clash: [combat2]")
if(usr.squad)
stat("Rank: [status]")
stat("Health: [health]/[mhealth]")
stat("Wounds: [wound]/100")
stat("Rei: [rei]/[mrei]")
stat("Attack: [mattack] (+[attack-mattack])")
stat("Defence: [mdefence] (+[defence-mdefence])")
stat("Reiatsu: [mreiatsu] (+[reiatsu-mreiatsu])")
stat("Experience: [exp]/[mexp] ([round(exp/mexp,0.001)*100]%)")
stat("Flash Step Uses: [flashuse]")
if(usr.thits)
stat("Memory Hits: [thits]")
if(usr.bringerblast)
stat("Bringer Blasts: [bringerblast]")
if(usr.getsugaring)
stat("Getsuga Rings: [getsugaring]")
if(usr.shielduses)
stat("Shield Uses: [shielduses]")
if(usr.kicks)
stat("Critical Hits: [kicks]")
stat("~~~~~~~~~~~~~~~Miscs~~~~~~~~~~~~~~")
stat("Money: [money]")
stat("Event Points: [eventpoints]")
stat("Kills: [kills]")
stat("Deaths: [deaths]")
stat("Location: [src.x],[src.y],[src.z]")
if(usr.race=="Arrancar")
stat("Ressurection Drain: [ressdrain]")
if(usr.race=="Shinigami"||usr.race=="Vaizard")
stat("Shikai Drain: [shikaidrain]")
stat("Bankai Drain: [bankaidrain]")
stat("Flash Step Uses: [flashuse]")
if(usr.race=="Vaizard")
stat("Mask Time: [maskuses]")

if(statpanel("Kills"))
statpanel("Kills")
stat("PVP Kills: [kills]")
stat("Hollow Kills: [hkills]")
stat("Arrancar Kills: [arrkills]")
stat("Shinigami Kills: [shkills]")
stat("Vaizard Kills: [vkills]")
stat("Lost Vaizard Kills: [lkills]")
stat("Final Shinigami Kills: [fkills]")
stat("Quincy Kills: [kkills]")
stat("Sado Kills: [kskills]")
stat("Fullbringer Kills: [kfkills]")

if(statpanel("Story"))
statpanel("Story")
stat("Story Completion: [storycom]%")
stat("Current Part: [curpart]")
stat("Current Story Mission: [curmis]")
var/list/T=new

for(var/obj/O in src.contents)
if(!T.Find(O.type))
T+=O.type
var/count=0
for(var/obj/o in src.contents)
if(o.type==O.type)
count+=o.stacked
if(o!=O)del(o)
O.stacked=count
O.suffix="[count]"
if(O.suffix=="1"||O.suffix=="0")
O.suffix=""


Problem description:

The "mob/stat" is 3rd most CPU aggressive thing when I profile the world. Am I doing something wrong or is that natural?
Best response
Using stat panels is pretty outdated. You could most likely get away with not using one at all by updating a grid with the information you want-and placing it into the Stat() .

However to answer your question- Stat() is called every tick or so I believe,which boils down to constantly.
I couldn't help but notice that you're creating a new list every time Stat() is called.

If I were in your position, I'd do something like this:

mob
var
stat_loop_active
level = 1
experience
kills

Stat()
if(stat_loop_active)
return

stat_loop_active = TRUE

restart_stat

var
current_level = level
current_experience = experience
current_kills = kills

statpanel("Stats")
stat("Level: [level]")
stat("Experience: [experience]")
stat("Kills: [kills]")

while((client.inactivity > 3000) || current_level == level && current_experience == experience && current_kills == kills)
sleep(5)

goto restart_stat


At least in this case, it wouldn't update if it didn't need to.

As for the inventory part: I doubt that stuff has to be called so frequently. I'd take that out of Stat() and make it its own function, then have it called when it's appropriate.

Falcon lazorz wrote:
Or you could just not use Stat().

or goto

I thought goto was worse. Are you sure?
They both suck.
In response to Dariuc
Dariuc wrote:
Using stat panels is pretty outdated. You could most likely get away with not using one at all by updating a grid with the information you want-and placing it into the Stat() .

However to answer your question- Stat() is called every tick or so I believe,which boils down to constantly.

Isn't updating a grid every tick the same as calling Stat() every tick?
In response to Critical172
There is no need to update the grid every tick. Just update every time it's changed.
In response to Critical172
Critical172 wrote:
Dariuc wrote:
Using stat panels is pretty outdated. You could most likely get away with not using one at all by updating a grid with the information you want-and placing it into the Stat() .

However to answer your question- Stat() is called every tick or so I believe,which boils down to constantly.

Isn't updating a grid every tick the same as calling Stat() every tick?

Yes it is. By placing your update inside of stat it automatically handles updating your grid.

This is useful for things like regenerating health over time, poison or burn effects, but if you don't want it called constantly, then just make the grid update when the player performs certain actions, like when they get items, or lose health,etc.
In response to Luchasi
Luchasi wrote:
There is no need to update the grid every tick. Just update every time it's changed.

That's not always true. It depends on what you are doing, there wouldn't be a Stat() proc at all if that was the case.
In response to Dariuc
Oh I see. In what cases might there be a need to update a grid every tick? Like a timer?
In response to Luchasi
Luchasi wrote:
Oh I see. In what cases might there be a need to update a grid every tick? Like a timer?

That's one example.
A countdown as well.
It also depends on what you have in your grid, from a programming standpoint it's more efficient to change something in one place than 5 places. So say you have 5 types of items in your game. Rather than placing code to update each item every time it is handled you could do it the way I described, especially if you wish to sort your items out into different windows, say weapons,armors,skills, inventory, 4 grids. All of that automatically updated, anytime you grab an item it is placed into the correct place if you code one proc correctly.

Also as I mentioned you can use it for regenerating health, energy,stamina or a few other things such as status ailments effects.

Aside from that just because it's set to run every tick, you can easily edit it so that it only runs once every few seconds if you wish, or that the update only runs under certain conditions, case in point being poisoned would only occur every few seconds, and only if you have been poisoned. The benefit of doing it this way is that you only have to set a variable or two when you want a player to be poisoned.
In response to Dariuc
Dariuc wrote:
Luchasi wrote:
Oh I see. In what cases might there be a need to update a grid every tick? Like a timer?

That's one example.
A countdown as well.
It also depends on what you have in your grid, from a programming standpoint it's more efficient to change something in one place than 5 places. So say you have 5 types of items in your game. Rather than placing code to update each item every time it is handled you could do it the way I described, especially if you wish to sort your items out into different windows, say weapons,armors,skills, inventory, 4 grids. All of that automatically updated, anytime you grab an item it is placed into the correct place if you code one proc correctly.

Also as I mentioned you can use it for regenerating health, energy,stamina or a few other things such as status ailments effects.

Aside from that just because it's set to run every tick, you can easily edit it so that it only runs once every few seconds if you wish, or that the update only runs under certain conditions, case in point being poisoned would only occur every few seconds, and only if you have been poisoned. The benefit of doing it this way is that you only have to set a variable or two when you want a player to be poisoned.

Can you do that for Stat() also?
In response to Critical172
What I was saying is that it's possible to do this:

mob
var
burning=0
poisoned=0
proc
getpoisoned()//call this to poison.
poisoned=1
spawn(600)poisoned=0

poison()
if(poisoned)//if they aren't poisoned no need to call this.
hp-=2
burn()
if(burning)
hp-=5
Stat()
poison()
burn()
..()

//now anytime the player is burning or poisoned they automatically lose hp


slowing down the rate of poison is a bit more coding but it can be done.


Basically all you're doing is updating those stat() so really what you need to do is update them only when you have to. I also suggest that you break down them into different procs when you use stat(). Because im pretty sure they all don't need to be called at once and in the same situations. Sadly any loop is terrible on the CPU especially if it does a lot like yours does.
In response to BornASaiyan23
BornASaiyan23 wrote:
Basically all you're doing is updating those stat() so really what you need to do is update them only when you have to. I also suggest that you break down them into different procs when you use stat(). Because im pretty sure they all don't need to be called at once and in the same situations. Sadly any loop is terrible on the CPU especially if it does a lot like yours does.

This is tested and used in quite a few games. No slow down, no glitches. Some things you need to test to make sure they only run when needed , that's correct- I also already mentioned that in both of my posts.

an example of how that would work is:
mob
var
burning=0
poisoned=0
proc
getpoisoned()//call this to poison.
poisoned=1
spawn(600)poisoned=0

poison()
if(poisoned)//if they aren't poisoned no need to call this.
if(poison_time<=world.time)//
poison_time=world.time+25// only get poisoned every 2.5 secs,etc.
hp-=2
burn()
if(burning)
hp-=5
Stat()
if(!dead)//if the player isn't dead.
poison()
burn()
..()

//now anytime the player is burning or poisoned they automatically lose hp



You could also easily set it to only update inventories every 2-3 seconds or longer.
LOL! Why would you make a continous loop instead of just calling the proc with a while loop. And args to past the time.

mob
proc
Burn(var/time)
while(time)
--hp
--time
Sleep(10)


All you would do is just spawn it. When it's needed so why do we need to do continous loops that you will eventually start putting other uneeded things in it. Sure all loops aren't bad and you can make Stat() sleep but it's still dangerous IMO.
In response to BornASaiyan23
BornASaiyan23 wrote:
LOL! Why would you make a continous loop instead of just calling the proc with a while loop. And args to past the time.

> mob
> proc
> Burn(var/time)
> while(time)
> --hp
> --time
> Sleep(10)
>

All you would do is just spawn it. When it's needed so why do we need to do continous loops that you will eventually start putting other uneeded things in it. Sure all loops aren't bad and you can make Stat() sleep but it's still dangerous IMO.


A better question is why use a loop?
Stat happens naturally, whether you want it to or not, even if you don't use it it runs CONSTANTLY-yet the game doesn't magically crash on it's own-why is that?). I use this system in a few games with NO visible slowdown at all. Angel Falls for instance and this one.

A while loop is one of the worse ways to handle this for the simple fact of , it's fine for a single status element, but what if you have 7 different kinds of status ailments?
If you get hit with 4-5 different ailments at once, what do you think will happen?(Hint, fire up your dream maker and run 5 simultaneous while loops with a 1 - 3 second sleep in each one and see what happens)


Not to mention, when you use SLEEP, it sleeps the character that is being used- meaning you won't be able to move for the one second that while loop is spinning.

You don't really seem to know what your saying, which is funny since you're trying to hard to make it seem like I don't know what I'm talking about. *shrug*


Also I never once said anything about sleeping inside of Stat()- not once. :)
If you use spawn() then you will still be able to continue through with the while loop running. I believe I said that. Im not trying to say you were wrong about anything and you don't know what you're doing im just saying I don't think the method is necessary and also... If nothing is in Stat() it's ALOT better than having something in it. And if you have more status effects then sure make a bigger proc. But the point is not to keep it in a constant loop.
In response to BornASaiyan23
You have little to no experience using the method you are prescribing, you are theorizing and there's a big difference between theory and what actually works.
They both work. I thought we were debating on which was more efficient.
Page: 1 2