ID:1494971
 
(See the best response by Ter13.)
Code:
turf
school_floor
name="Floor"
icon='turf.dmi'
icon_state="school_floor"
Enter(atom/O)
if(O != usr)
return O
if(usr.onfloor==1)return..()
usr.onfloor=1
return..()
Exit(atom/O)
if(O != usr)
return O
usr.onfloor=0
return..()


Problem description:
When the user is on the floor, it sets a variable to 1 so it won't shoot up the CPU like my old game's source did. However, I did not think it through. When I made a drag verb, I've gotten a proc error. Well, I fixed that...But, every time someone drags and interacts with another object, or when dragging multiple objects(which won't be allowed once I am done with it) the CPU shoots up depending how many objects are being pulled. The reason I care even if I won't allow more than one thing being pulled is because if other mobs are pulling objects, then the CPU will plus its size.

The onfloor is just the information for mob.Move() when if onfloor is one, it'll play a certain footstep noise. But the CPU was just perfectly at 1-2% so it couldn't be that, right? It has to be the object interacting with turf.Enter() which I want it to just bypass...I really have no clue on what to use.

I don't know if I should do a different step code, but I have no clue what else would work. So...

Also, this is the CPU when I drag multiple objects: http://prntscr.com/2rqmsr

P.s. never used Enter() before... ;c


IF YOU HAVE A BETTER FOOTSTEP CODE THAT KEEPS CPU EXTREMELY LOW, THEN SHARE IF YOU WANT!


Best response
You really shouldn't be using usr in Enter() and Exit()

Since you haven't shown us any of the code related to dragging objects, I can't comment on any of the CPU issues at all.

Second, you should be using Entered(), not Enter().

My advice would be to not define this behavior under the turf at all, but rather, tie it directly into the movement functions of the mob. What if you have an NPC that makes squishy slimy noises when it walks? What if you want to have the player able to run, jump, swim, and fly? You would have to account for special cases that don't apply to the turf in every turf. Thus, this behavior should belong to the mob.

turf
var
footstep_type = 1


The footstep_type will give the mob more information about what kind of footstep noise their steps should make.

mob
Move(atom/NewLoc,Dir=0,step_x=0,step_y=0)
var/atom/oldloc = src.loc
var/osx = src.step_x
var/osy = src.step_y
var/odir = src.dir
. = ..()
if(.)
src.Moved(oldloc,odir,osx,osy)
proc
Moved(atom/OldLoc,oDir=0,ostep_x=0,ostep_y=0)
if(isturf(OldLoc))
Footstep(OldLoc)

//everything to do with footstep sounds
Footstep(turf/t)
var/soundfile
switch(t.footstep_type)
if(1)
soundfile = 'footstep_grass.wav'
if(2)
soundfile = 'footstep_pavement.wav'
//these are just examples
if(soundfile)
view(3,src) << sound(soundfile)


The above snippet demonstrates setting this kind of thing up under the appropriate type, which is the mob. We simply detect whenever a movement was successful (in the Move() override), and then we create a Footstep() proc that is called from Moved().

Since Moved() is only called when the mob actually succeeds in moving, we don't get the errors your approach will. Among them, your approach will play multiple sounds per step if you have pixel movement enabled. Second, your approach abuses usr and doesn't allow NPCs to have footsteps. Third, your approach embeds the behavior in a manner that makes it borderline impossible to address and update on a per-object, per-case basis.

My approach, on the other hand, allows us to quickly and easily extend, override, and manipulate the behavior.

Like I said, though, you haven't shown nearly enough information to diagnose your other issues mentioned in the OP.
Don't use usr in Enter(). O is the atom entering src, so use that to reference it.

Also, Enter() and Exit() should return either 1 or 0 to allow or disallow entering/exiting, and as such you should not be returning O.

If you want it to only do something specific for players, a simple check like this should do fine:
if(ismob(O)) // blah blah


EDIT: Ninja'd
@Albro1, erm...Yeah, I've tried that but it did the same...but thanks! XD

@Ter13

I love it. I never knew that Dream Maker used switch. It's sort of like Game Maker. :) Anyways, thank a lot. Everything looks self-explanatory.
Eh, also, my jaw dropped when you posted that because it was so good and clean. xD