Dir not working!

ID:264238
 
Nov 7 2008, 5:07 pm
Code:
            Water
                icon_state = "watermovement"
                density = 1
                Entered(obj/a)
                    var/L = new/obj/Trail
                    if(istype(a,/obj/projectile))
                        src.overlays += L
                        L.dir=a.dir
                        spawn(10)
                        src.overlays -= L
                        return 1
                    else
                        if(usr.icon_state == "fly")
                            return 1
                        else
                            return 0


Problem description:
Were it says "L.dir=usr.dir" it is not working.
It tells me:
Turf.dm:234:error:L.dir:undefined var
Nov 7 2008, 5:19 pm
This was an original reply to your first thread before you deleted it:

Heh, that's because you aren't thinking logically. You adding an instance of an object to the overlays, and then using a silly, illogical method of removal. This method of removal is however, flawed by the fact that you are removing a prototype instead of the actual instance.

Now, if I may show you another method of doing the same that is 1) quite logical, and 2) quite elegant.

(May I also point out that use of usr in this proc will cause you some headaches. Allow me to show you a much more correct way of managing this.)

Water
  icon_state = "watermovement"
  density = 1

  Enter(var/atom/movable/entered) //in this case entered is correct, as a /mob could also enter here.
    if(istype(entered,/mob)) //if a mob enters
      var/mob/m = entered //type cast entered as a /mob
      if(m.icon_state=="fly") //if the player is flying
        return 1 //allow passing
      else
        return 0 //block
    else if(istype(entered,/obj/projectile)) //if is a projectile
      new/obj/trail(src) //create a new trail.
    else
      return ..(entered) //otherwise, call the parent procedure and return the default value.

obj
  trail
    icon = 'trail.dmi'

    New(var/turf/t) //called when the object is created
      if(t) //if this was created with a turf in mind
        t.overlays += src
        spawn(10) //wait ten server ticks (not necessarily milliseconds) without tying up resources
          src.fade(t) //call a proc that removes me.
      return ..() //default operation

    proc
      fade(var/turf/t)
        t.overlays -= src //remove me from the overlays
        del src //delete me


I will make a second post showing another method of doing this with an even more logical approach.

To answer your new question:

var/L = new/obj/Trail


This line is the problem.

It's an issue of type-casting, type casting is a way of telling the game what kind of variable "L" is. In this case it's an /obj/Trail. You need to define it as such.

var/obj/Trail/L = new/obj/Trail


Honestly, you need to do some serious work on your basic programming skill. These threads you have posted the last few days could have been answered with the first chapter of any beginning programming book.

Often these kinds of issues show a lack of actual study (or thought).
Nov 7 2008, 5:26 pm (Edited on Nov 7 2008, 5:38 pm)
In response to Ter13
I know I ain't the most Logical thinker but yeah, I've been coding for 4 years learning, so I know a lot about it...
I just get stuck on certain things in coding that I've forgotten..
Nov 7 2008, 5:46 pm
I stated that I would give a more complete post on how to do this kind of operation logically. I'm going to explain it after the code block.

atom
  proc
    Entered(var/atom/movable/entered,var/atom/oldloc)
      return
    Exited(var/atom/movable/exited,var/atom/newloc)
      return
atom/movable
  Move(var/atom/newloc,var/dir) //default Move override
    var/atom/oldloc = src.loc   //store the current location
    . = ..(newloc,dir) //call the default procedure but don't return.
    if(.) //check the value returned by the default procedure
      if(oldloc) //if the player didn't move from null
        oldloc.Exited(src,src.loc) //call our spiffy new exited proc on the player's old location
      if(src.loc) //if the player didn't move to null
        src.loc.Entered(src,oldloc) //call the entered proc on the new location
      src.Moved(oldloc,src.loc) //call the moved proc for this atom
    return . //return the default value
  proc
    Moved(var/atom/oldloc,var/atom/newloc)
      return


You may ask yourself what is the need of the above. It's quite elegant, though, you have to admit. It seperates a successful move into a location from a failure. Your old method assumes that the object is going to enter the location, ans enter() really is a function that tests to see if the object can move into the space.

It also allows you to define post-movement behaviour from the mob or obj.

Now to get to your function, and how it should logically flow:

turf
  water
    icon_state = "watermovement"
    density = 1
    Enter(var/atom/movable/entering)
      if(istype(entering,/obj/projectile))
        return 1
      if(istype(entering,/mob))
        var/mob/m = entering
        if(m.icon_state=="fly")
          return 1
        else
          return 0
      else
        return ..(entering)
    Entered(var/atom/movable/entered,var/atom/oldloc)
      if(istype(entered,var/obj/projectile))
        new/obj/trail(src)
        return 1
      return ..(entered,oldloc)

obj
  trail
    New(var/turf/t)
      t.overlays += src
      spawn(10)
        src.fade(t)
    proc
      fade(var/turf/t)
        del src


In this case, the old approach is still valid, but if you need similar behaviour on other surfaces, it would probably be more logical to create the behaviour inside of the projectile's Moved() function. However, since the behaviour only occurs for that one turf, it doesn't make a difference in a design sense.

Really, this is all preference, and has mostly to do with modular programming techniques. You don't want your game to get all screwy if you take out one piece of code. For instance, if you took out projectiles in this sense, you'd be screwing up turfs.

The logical modular architecture should be:

turfs as a base
objects on top of turfs
mobs on top of objects
etc.

Logically, it makes sense that a mob's code would depend completely upon the existence of objects and turfs, where it wouldn't make much sense that the existence of an object should be based on a mob.

Now in some cases, this can and should be defied, but in most cases it's best to keep with the modular approach.
Nov 7 2008, 6:06 pm
In response to Ter13
Can you tell me why the 'dir' of the watermovement ain't changing??

            Water
                icon_state = "watermovement"
                density = 1
                Enter(obj/a)
                    var/obj/Trail/L = /obj/Trail
                    if(istype(a,/obj/projectile))
                        L.dir=a.dir
                        src.overlays += L
                        spawn(10)
                        src.overlays -= L
                        return 1
                    else
                        if(usr.icon_state == "fly")
                            return 1
                        else
                            return 0
Nov 7 2008, 6:43 pm
In response to Gizhy Games
Overlays are dependent upon the direction of the base object.

In order to make the object have a different direction from the turf, you need to do one of two things: change the direction of the turf, or locate the object on the turf instead of in the overlays.
Nov 7 2008, 6:53 pm
In response to Ter13
Okay I get it.
Nov 7 2008, 6:54 pm
"No put usr in proc. Ungh."