Editing obj loc?

ID:2452199
 
Apr 11 2019, 3:58 pm
(See the best response by Kaiochao.)
Code:
mob/verb/Duel()
    for(var/obj/Disk in usr.client.screen)
        del (Disk)
    new/obj/Disk(src)
    var/obj/Disk
    Disk.loc = "8.3,6"


Problem description:
I'm at a complete loss here, I'm trying to edit the location of the Disk obj as it's spawned (to later use it as a part of the code that spawns it at a different location depending on where the player is facing) and I'm not really sure how to do that. The above code returns this in the actual game:

runtime error: Cannot modify null.loc.
proc name: Spawn (/mob/verb/Spawn)
  usr: (src)
  src: PhantomThiefofHearts (/mob/Player)
  src.loc: Wall (5,5,1) (/turf/Wall)
  call stack:
PhantomThiefofHearts (/mob/Player): Spawn()


Apr 11 2019, 4:04 pm
Best response
 
// This declares a variable of type /obj/Disk called "disk"
// and initializes it to a new instance of that type
// with an initial loc of src.
var/obj/Disk/disk = new(src)

// This sets the screen_loc of the disk.
// screen_loc is the HUD position, which you probably want. 
// loc is the physical position in the world. 
disk.screen_loc = "8.3,6"
Apr 11 2019, 4:31 pm
Ah there we go, the problem was the new(src) part. Thank you very much.
Apr 12 2019, 11:17 pm
In response to Kaiochao
Kaiochao wrote:
> // This declares a variable of type /obj/Disk called "disk"
> // and initializes it to a new instance of that type
> // with an initial loc of src.
> var/obj/Disk/disk = new(src)
>
> // This sets the screen_loc of the disk.
> // screen_loc is the HUD position, which you probably want.
> // loc is the physical position in the world.
> disk.screen_loc = "8.3,6"
>



This reminds me of how i was pestering myself with sun rays effect last night.

I tough went with

var/I = new/obj/Sunset_Lightning
            usr.client.screen += I


It still adds it to client screen..is this good way to go about it?
Apr 13 2019, 12:41 am
In response to X-ShinraTensei-X
It doesn't matter what the variable's declared type is if you're not actually accessing the object it refers to. The declared type of a variable just tells the compiler what type to treat the variable when checking what variables and procs that variable can be used to access.
var o = new/obj
o.density = TRUE // error: o.density: undefined var 
// o has no type, so even though it contains an obj, it can't access any vars

var atom/obstacle = new/obj(loc)
obstacle.density = TRUE // this works because /atom has density
// and it's safe because /obj inherits from /atom

// if the declared type is the same as the type you're creating with "new",
// you can leave it off of new, so you don't have to repeat yourself:
var obj/obstacle = new(loc)
obstacle.density = TRUE

If you're only using a variable once, you often don't need a variable at all:
usr.client.screen += new/obj/Sunset_Lightning

new/obj(loc).density = TRUE

An exception to that is if the variable improves readability. (But I is not a great variable name because it's not very descriptive and it can potentially be confused for 1 or l depending on the font.)


Any usage of usr just smells of usr abuse, even out of context. If src is valid, just use it. It's declared as the type you're working in (whereas usr is always declared as a /mob) and it can usually be implicitly accessed without writing "src." every time.

src should be considered "the object this code belongs to".
usr should be considered "the mob that caused this code to run" and requires that the code it's used in is caused by a player executing a verb.
When src and usr are guaranteed to be the same, you should always use src.

mob/player
  var 
    stuff

  verb
    test()
      usr.stuff = 123// error: usr.stuff: undefined var
      // stuff is defined under /mob/player
      // usr is declared as /mob
      // usr can't access stuff, even though 
      // usr refers to a /mob/player object that has a stuff variable

      stuff = 123 // this works and is concise

      usr:stuff = 123 // only villains do this