new obj at click() loc!?

ID:2113534
 
Jul 9 2016, 11:56 am
(See the best response by Nadrew.)
Code:


Problem description:
No code yet, just figuring what's the best way to do this, because I have no idea what procs I could and should use for this. Can anyone refer me to a page in the guide or something?

Domo Arigatoooooo!

Jul 9 2016, 11:59 am
 
turf
    Click()
        var/obj/o = new/obj
        o.loc = usr.loc
Jul 9 2016, 3:09 pm (Edited on Jul 9 2016, 3:37 pm)
Best response
You don't really need to define a variable just for that.
turf
    Click()
        new/obj/my_obj(src)


You'd only need to create a variable reference if you're planning on interacting with the object right there using things you didn't allow for inside of New().
Jul 9 2016, 3:27 pm
...If you want to create the object at the location clicked, rather than at the player's location regardless of where the mouse is:
turf/Click()
    new /obj/my_obj (src)
Jul 9 2016, 3:34 pm
Assuming they don't have New() overridden yea.
Jul 9 2016, 3:37 pm
In response to Kozuma3
Kozuma3 wrote:
Assuming they don't have New() overridden yea.

The first argument of atom/New() is always expected to be the location. Someone overriding that to accept something else is engaging in bad practice and asking for trouble.
Jul 9 2016, 3:38 pm
In response to FKI
FKI wrote:
The first argument of atom/New() is always expected to be the location. Someone overriding that to accept something else is engaging in bad practice and asking for trouble.

I disagree.
Jul 9 2016, 3:41 pm
FKI is correct, you shouldn't alter the behavior of expected functions without a valid reason, normally an atom (or atom/movable) should always expect a location as the first argument in New(), if you intend to do special handling you might not want an atom for the job at all.

Of course there are special cases where you have to handle niche situations, but in general if you have something that's ever going to have a loc, New() should work as expected standardly.
Jul 9 2016, 3:45 pm (Edited on Jul 9 2016, 4:22 pm)
In response to Kozuma3
Of course. The first argument to the "new" keyword is where the object is initialized, but if they have /obj/my_obj/New() overridden to change its loc, it's not going to end up where it was initialized.

Also, if you have client/Click() overridden without calling ..(), then turf/Click() won't be called, so watch out for that.

Also, if you have client/New() overridden without calling ..(), or if you call del src in client/New() or client/Click() or mob/Login(), then your clients won't be able to join, so watch out for that.

But if you're not being absolutely ridiculous, the code I provided should work perfectly fine as-is.

edit: What I mean is, you'd have to intentionally include code that breaks this functionality, so it's not really worth a warning.

To be clear, this is what you'd have to do to break it:
obj/New(Loc)
    loc = ...

This, for example, wouldn't break it, but health wouldn't be initialized as you might expect (and it would undoubtedly be the fault of whoever overrode New() to do this):
obj
    var health
    New(Health)
        health = Health

// If T is a location, then new /obj (T) would still be created at T (and its health would be T)