evil background

ID:161803
 
Mar 30 2008, 6:07 am
I'm kind of new to byond and things such as 'set background' are new to me as well. I heard that setting background makes the call sleep, then recalled again, something like that. I just don't know where it's correct to place it.
mob
 proc
  AutoSave()
   set background=1 // is it a good idea to use set background here?
   src.Save()
   spawn(600)
    src.AutoSave()

  Followtheotherguy(mob/M)
   set background=1 
   src.loc=M.loc
   sleep(1)
   src.Followtheotherguy(M)
Mar 30 2008, 6:22 am
Takoma wrote:
I'm kind of new to byond and things such as 'set background' are new to me as well. I heard that [...]

Well, did you look it up in the DM Reference, since it's new to you? You don't need to count on what you've heard/what you remember you've heard, the documentation is right there. It explains it pretty well, but, no, both your procs don't really need it. They have other problems, though.
Mar 30 2008, 7:19 am
In response to Kaioken
They do o.o? Mind pointing some out for me?
Mar 30 2008, 10:23 am
In response to Takoma
Takoma wrote:
Mind pointing some out for me?

Of course not.
Well, both your procs call themselves recursively to achieve a loop. There isn't an advantage in using it just like that, and it is better to just use a looping construct like for() or while() to loop the whole thing without calling new procs all the time. Remember, you can use 'infinite loops' (they'll loop without conditions, like your code does now) with them too; using while(TRUE) ('TRUE' is just a macro for '1') will loop indefinitely because, of course, 1 will always be a true value every time the loop checks it. Using for(), just like that, with no arguments, also quickly creates an infinite loop, that doesn't need to check any condition.

In your second proc there are much larger problems though.
Firstly, the implementation of making a mob follow another by repeating a simple src.loc=M.loc every single iteration (!!!) is, no offense intended, very very bad. It should definitely NOT be done this way to make a movable automatically follow another, and you should also usually refrain from forcing setting the 'loc' variable when dealing with movement, since it's not as "complete" as using the full fledged Move() proc or similar. If you're familiar and used procs like Enter() Exit() Entered() etc, forcing setting loc will not trigger them, as only Move() will call them, so your code there will not run.
Also. In the 2nd proc you forgot to put a spawn() before calling a new instance of the proc. This means, the current, 1st proc, will wait until the new 2nd one finishes, but it never will because it creates a 3nd one and waits for it to finish, etc etc, calling new procs over and over until a crash error. Using spawn() stops the procs from waiting for the procs they've called to finish, so they exit gracefully and not remain.
Mar 30 2008, 6:37 pm
In response to Kaioken
"In the 2nd proc you forgot to put a spawn() before calling a new instance of the proc."

Like this?

mob
 proc
  Followtheotherguy(mob/M)
   set background=1 
   src.loc=M.loc
   spawn(1)src.Followtheotherguy(M)
Mar 30 2008, 8:11 pm
In response to Takoma
That will technically work, but it's still the wrong way to do things. It should be the job of the thing that is moving to have any followers follow it:

mob
  //must be temporary, never save references to other players
  var/tmp/list/followers
  proc/addfollower(var/atom/movable/M)
    //if we haven't initialized the list, initialize it
    if(!followers)
      followers = list(M)
    //otherwise, just add to it
    else
      //don't add duplicates
      if(!(M in followers))
        followers += M
  proc/removefollower(var/mob/M)
    //only try to remove from an initialized list
    if(followers)
      followers -= M
      //if the list is empty, uninitialize it
      if(!followers.len)
        followers = null
  //immediately moves all of our followers to where we're standing, IE for teleporting
  proc/grabfollowers()
    for(var/atom/movable/M in followers)
      M.loc = loc
  
  Move()
    //grab our old location
    var/atom/oldloc = loc
    //perform the default action and store the return value in the default return value
    .=..()
    //if the move was a success
    if(.)
      //move any followers to where we were just standing
      for(var/atom/movable/M in followers)
        M.Move(oldloc)
Mar 31 2008, 11:37 am
In response to Garthor
..() and .=..() just get deep into my nervs. I've tryed looking for a guide about those on byond 'Help On' with dreammaker, gave a look around the tutorials, and found nearly anything that explains that nicely and understandable. <.<
Mar 31 2008, 12:34 pm
In response to Takoma
..() is "do the previously defined action". . is the variable that will be returned by default (if you have no return statement, the proc will return . by default when it ends).
Mar 31 2008, 12:47 pm
In response to Garthor
I'm the same... I know the basics of '..()', but .=.. +.... or what ever, just confuse me.
mob
 verb
  Lol()
   src<<"Prepare for Lol"
   ..() // runs the Lol() // <.<, right?
 verb
  Lol() // <.<
   src<<"Lol =D"


Confusing.
Mar 31 2008, 1:07 pm
In response to Takoma
First of all, you can't define a proc twice. Only the first one needs the verb in front of it. Once it's been defined with "proc" or "verb" you can override it with just the proc name (like what you do with Move() or Enter()).

Additionally, the ..() is in the wrong one. To do what you're trying to do there:

mob
  verb/Lol()
    src << "Lol =D"
  Lol()
    src << "Prepare for Lol"
    ..()
Mar 31 2008, 1:14 pm
In response to Garthor
It is possible to create a game without ..() and such, isn't it?
Mar 31 2008, 1:24 pm
In response to Takoma
Yes. It's also possible to create one without using the letter "a".

Why would you want to?
Mar 31 2008, 1:25 pm
In response to Garthor
I never liked "a" anyways.
Apr 3 2008, 10:27 am
In response to Takoma
It might be hard to understand that setting (. = ..()) at first from Garthor, my, or the DM Reference's explanations. It is rather simple actually; I'll show you exactly how it works just without actually using the . variable so it's clear. But it will be a problem if you don't know about 'return' yet though. Look it up and learn about it if that's the case... 
mob/Move() //overriding a proc. the default Move() returns true or false according to the success of the movement
   var/returned_value = ..() //call the default proc, and store the value it returns into a variable
   if(returned_value) //check the returned value - if it's true, that Move() reported the movement succeeded
      src << "you just moved successfully"

   return returned_value //this returns the value again, so \
that any outside procs that call Move() will also receive the \
correct info to whether the movement succeded or not.

//the above override is equivalent to:

mob/Move()
   . = ..() //store the returned value into the variable called '.'
   if(.) //check it
      src << "you just moved successfully"

/*this is because '.' is a special variable - if a proc
reaches it's end, the '.' variable is automatically returned.
that means basically, that there is a "return ." line at the
end of every proc.
the default value of '.' is 'null', so the default value
for a proc's return value is also 'null', unless '.' is
changed or the 'return' statement is used explicitly*/
Apr 3 2008, 10:56 am
In response to Takoma
This might help you understand ..()

Whenever you are looking up a proc in the DM F1 help and you see a Default action section, think to yourself "so this is what ..() means"
Apr 4 2008, 9:22 am
In response to Kaioken
That was alot clearer thank you Kaioken.