Vanishing lash

Page: 1 2
ID:138931
 
Sep 5 2011, 10:17 pm
Code:
The Var
obj/var/tmp
    lash = 0

The code
mob/verb
    LashingWhip()
        set category = null
        if(safe) return
        if(se < 100)
            src << "<b>Your Energy is to low wait for it to recover!"
            return
        if(!firing)
            view(8) << "<b>[src]: Lashing Whip"
            firing = 1
            src.contents += new/obj/whip
            New()
             Whip1()

The Proc
obj
    proc/Whip1()
        if(lash) //infinite ticker loop
            src << "You have called your Lashing Whip."
            lash = 1
            src.contents -= new/obj/whip
            sleep(5)


Problem description:
What I wanna do is make the whip vanish after so many seconds in this case 5 but it just stays in the inventory no vanishing at all it just stays there
Sep 5 2011, 10:42 pm
Wrath69 wrote:
Code:
The Proc
obj
>   proc/Whip1()
>       if(lash) //infinite ticker loop
>           src << "You have called your Lashing Whip."
>           lash = 1
>           src.contents -= new/obj/whip
>           sleep(5)
>


[EDIT] if(lash) means that if lash is true or equal to one. You are trying to check if it isn't true I guess. If yes, use if(!lash).

First of all, your proc code makes no sense. You are calling sleep after the item has been removed from the inventory. Use sleep before an event.

Next, sleep(5) wont make it wait for 5 seconds, you need to use sleep(50) to make it wait for 5 seconds, since its in 1/10th seconds.

Lastly, you cannot remove the item from an inventory the same way you are adding it. src.contents -= new/obj/whip makes no sense, you are creating a new obj with the path /obj/whip and then trying to removing it from src inventory.

Use locate() to first find a certain obj inside a container then if it exists, remove it.
Sep 6 2011, 8:18 am
In response to Hashir
I did not think it made any sense either procs give me the most trouble you do happen to know of a demo that would show a better way of doing this or a byond article
Sep 6 2011, 8:35 am (Edited on Sep 6 2011, 10:10 am)
In response to Wrath69
Use this instead of:
usr.contents -= new/obj/whip



usr.contents -= obj/whip


or use this
for(var/obj/whip/A in usr)
    del(A)


Hope it helps
Sep 6 2011, 9:44 am
In response to Dj dovis
Dj dovis wrote:
for(var/obj/whip/A in usr)
>   del(A)

Hope it helps

That will delete all whips in contents. For an easier to change code, I'd suggest handling this with some sort of loop that you break.
Sep 6 2011, 9:46 am
In response to Lugia319
Yep sorry for that code but I was just showing a simple example.Anyways thanks for pointing that out lugia
Sep 6 2011, 9:55 am
In response to Lugia319
Lugia319 wrote:
Dj dovis wrote:
for(var/obj/whip/A in usr)
> >     del(A)

Hope it helps

That will delete all whips in contents. For an easier to change code, I'd suggest handling this with some sort of loop that you break.

for(var/obj/whip/A in usr)
  del(A)
  break


Like that. It will delete 1 whip. If you need to delete multiple, you could set a variable outside the loop and remove 1 every iteration until it's 0, then break.
Sep 6 2011, 10:05 am
In response to Robertbanks2
Should have place that there but I am careless
Sep 6 2011, 10:06 am
Also, I wanted to remark on the "Logic" behind what you're doing and what you're trying to do, as well as make a few notes.

Objective: Remove a whip from inventory.

Read your code aloud.
obj
    proc/Whip1()
        if(lash) //infinite ticker loop
            src << "You have called your Lashing Whip."
            lash = 1
            src.contents -= new/obj/whip
            sleep(5)


1. Do not have "infinite ticker loops." What you have is not an "infinite ticker loop," it is a conditional expression. But just in case you ever get the idea, "Hey, let's check if this is true every second of the day," avoid it. You can run into infinite loops (which are not the most fun things to have.) It is better just to have a variable and check if it's true every time a proc is run (which is what you have up there, good job!)

2. Your player will never see the message because the output is going to the src. Not sure if this is intentional, but I'm guessing it isn't.

Now on to the logic. (Excuse me if I'm not too technical)

Now if I am using the new procedure, I'm probably making a new object. Your line src.contents -= new/obj/whip could be (awkwardly) read as, "Subtract a newly created whip from an object's inventory. (You used src instead of usr! This is an OBJ proc!!)

Ignoring the problems from before, you are trying to remove a newly created object from a place where it was never in to begin with. Think of it like this.

//First, define the object
var/obj/A = new /obj/Whip
// A = a newly created whip, without args to determine location, it is created in \
what I am going to call "Negative Space"

src.contents -= A
// You now subtract the newly defined object from a person's conents.

/* One small problem. The object is still in "Negative Space" and it is not in the person's contents.
So the computer will check to see if the
object is in the person's contents. It will see no, and assume that the job has
already been completed. */


Note: Feel free to correct my logic if it's wrong.
Sep 6 2011, 3:37 pm
In response to Lugia319
Ok so how would that be corrected
Sep 6 2011, 3:41 pm
In response to Wrath69
The answers have all been given to you in this thread, I just wanted to make a few notes is all. If you get anything out of that mess I wrote, it should be this; Read your code, Think like a computer.
Sep 6 2011, 3:45 pm
In response to Lugia319
Lol and I thought doin a skill tree was annoying
Sep 6 2011, 7:42 pm
In response to Lugia319
Lugia319 wrote:
(You used src instead of usr! This is an OBJ proc!!)

Instead of using usr, he can use arguments to determine who the mob is. Using usr in procs is bad isn't?


- Hashir
Sep 7 2011, 8:41 am
In response to Hashir
He certainly can use args to determine who the mob is. But I personally find that keeping track of references can get rather cumbersome and confusing. Using usr in procs isn't really "bad" (or at least, I have not had any issues thus far)
Sep 7 2011, 12:31 pm
In response to Lugia319
Lugia319 wrote:
He certainly can use args to determine who the mob is. But I personally find that keeping track of references can get rather cumbersome and confusing. Using usr in procs isn't really "bad" (or at least, I have not had any issues thus far)

In this case, because there will always be a usr, it isn't that huge of a deal. HOWEVER, it should be noted that in general, it's a bad idea to use usr in procs that could potentially be called by anything other than a client. It would also mean a minor overhaul of the system to accommodate arguments instead of usr should he choose to handle it any other way than he is now.

A similar example would be if you wanted a spell system, and you used usr in it. Obviously, you're going to want your monsters to have spells too, right? So you give them access to a few of the spells and find that the procs crash because of a bunch of "can't read null.var" runtimes and don't know what's going on. Well, that monster doesn't have a usr, so it can't read usr.var. So now you have 2 options, rework your entire spell system to handle arguments instead of usr, or make a new spell system specifically for monsters. Both are a pain in the ass, and neither was necessary had you planned ahead and not used usr.

Also, a quote directly from the reference:

"The only time usr is assigned for you is when a player (in Dream Seeker) executes a verb, clicks something with the mouse, or any other such action.
...
A good rule of thumb is to never put usr in a proc. Typically this is an unsafe programming practice, even when you know that a certain proc is only ever called by a verb, because it is common during development to change the way or time at which a proc is called. If src would not be the correct choice, it is better to send another argument to your proc with the information it needs."
Sep 7 2011, 12:42 pm
In response to Robertbanks2
Well Robertbanks2 has laid down the law lolz. I always assumed usr is okay as long as there will always be a user. I guess I'll just ask a quick question here.

Is there a general practice rule of "too many args" in a proc definition? I know that a few built in procs can have 6+ args. What does one do to handle such a situation?
Sep 7 2011, 12:47 pm
In response to Lugia319
Named arguments. These allow you to specify which arguments you're passing.

You should generally try to keep your arguments to a minimum for the sake of your own sanity, and this can usually be done by compressing similar arguments into a list. If you're passing tons of mobs, put them in a list, the same for objects or other similar variables.

But really, named arguments are your friend if you need to pass lots of arguments and not all of them are necessary all of the time.
Sep 7 2011, 12:48 pm
In response to Robertbanks2
Thanks for the tip!
Sep 7 2011, 2:54 pm
In response to Lugia319
ok arguments now i am confused
Sep 7 2011, 3:13 pm
In response to Wrath69
Wrath69 wrote:
ok arguments now i am confused

Arguments are the information and references passed when you call a proc. Allow me to demonstrate.

//The data inside the parentheses are the arguments
proc/DeleteWhip(var/mob/M,var/obj/whip/W,var/timer)
  sleep(timer)
  if(W.loc=M)
    del W

obj/whip/verb/Use()
  //Whip stuff here
  ...

  DeleteWhip(usr,src,50)
//This will call the DeleteWhip()
//usr will be associated with var/mob/M
//src will be associated with var/obj/whip/W
//50 will be associated with timer, and is used to sleep
//  for 50 ticks(5 seconds)

mob/monster/proc/Whip()
//Here we make sure that there is a whip in the mob's contents
  var/Whip
  for(var/obj/whip/W in contents)
    Whip=W
    break

  if(!Whip)
    return

//Whip stuff here
  ...

  DeleteWhip(src,Whip,50)
//Now src is associated with var/mob/M
//Whip is associated with the var/obj/whip/W
//And 50 is still associated with timer


As you can see, doing it this way allows the same proc to be used by both players and mobs, reducing repetition in the code and allowing more functionality and modularity than just using usr and src, because it allows you to also pass the delay in ticks until the whip is deleted and anything else you might need to send along, should you want to eventually add on to the system.
Page: 1 2