mob
verb
fly()
density = 0 //fly through air
set category = "techniques"
icon_state = "buku"
src <<" You begin to flying!"
Problem description:
how do i make my mob stop flying when u click fly again?
ID:142340
Jun 20 2008, 11:48 am
|
|
Code:
mob Problem description: how do i make my mob stop flying when u click fly again? |
Jun 20 2008, 11:54 am
|
|
add an "If" statement to switch it to the oppisite than what it is.
|
mob |
Your category setting should be the first line in your proc.
Have a flying var for mobs that can fly. Set this to one when the verb is used and then make them fly. When they use the verb again, check to see if the flying var is 1, if it is, set it to 0 and put them back on the ground. |
In response to Nickr5
|
|
mob You can better use the flying var like nickr5 said, not density. |
In response to Soldierman
|
|
thanx
|
In response to Jan90ster9
|
|
What is better about wasting a var? I see no reason for using the flying var, care to explain the benefit over checking the density? Secondly if(usr.flying == 0) is bad programming practice, it should be if(!usr.flying) instead.
|
In response to Soldierman
|
|
Also, you might want to set a old state var, so you can return them to the state that they had before.
|
In response to Soldierman
|
|
Their density could be set to 0 for other reasons, using a flying var is safer. And I doubt 'wasting a var' does much damage.
|
In response to Jan90ster9
|
|
Before the if, you'll want to put
flying=!flying |
In response to Nickr5
|
|
Yeah, I guess your right in the highly unlikely event he toggles his density for something else, in his DBZ game other then flying. Maybe he should use a flying var :) . But I wouldn't say wasting a var does not do much damage, because why not conserve resources whenever possible?
|
In response to Soldierman
|
|
You're barely saving anything. Yes, most of the time we should conserve resources, but here is a case where the code being robust is more important. If density is changed elsewhere, then rather strange bugs would start to appear. Not to mention that it's not that unlikely the mob's density could be changed.
|
In response to Nickr5
|
|
Look carefully, that would only screw up the flow of his code, it's okay without it. I don't really see the point of people using this and making opposite if() checks, though. There's nothing to be gained by it because you're checking the same variable _anyway_, so you can just set it accordingly in the if()-else that follows. In fact it's probably just slightly slower since it does execute an operator.
I guess people do it like that because they find the statement looks cool. :P |
In response to Kaioken
|
|
Oh yeah, I didn't read it closely enough. I do it because it's one line instead of two.
|
In response to Nickr5
|
|
But you still end up typing the var twice anyway. =P Also, not a big point for this case, but the code's efficiency is more important than its length.
|