Object Respawn Help

ID:1232833
 
Apr 10 2013, 12:08 pm
Keywords: repop, respawn, spawn, torch
(See the best response by The Motto.)
Code:
obj/torch/verb/Get()
    set name = "Pick Up"
    set category = "ACTION"
    set src in oview(1)
    loc = usr
    usr.luminosity = 2
    sleep(500)
    var/obj/torch/T = new(loc)
    return


Problem description:

Objects.dm:13:warning: T: variable defined but not used

Even though it's a warning, it still doesn't work. I feel like I'm making a really silly error but since I'm new to coding in DM, I'm not so sure how to fix it or make it work.

I'm aiming for it to work like this:

User grabs torch. > Torch respawns.

Apr 10 2013, 12:18 pm
Best response
You are not defining the locations properly, Heres an example:
var/T = new/obj/tourch
T.loc=locate(x,y,z)//input location here

T is being defined as a new obj then you are relocating it aka respawning it.
Apr 10 2013, 2:59 pm
In response to The Motto
He actually isn't doing very much wrong - he just doesn't need to define it as a variable if he isn't going to use it again.

What it sounds like you want is to put a new torch back where the torch was after a certain period. For this, store the location it was at before usr picked it up in a variable, then use that location in new() :
new /obj/torch( location)
Apr 10 2013, 3:05 pm
In response to Albro1
I never said he was doing it wrong i just said he wasn't defining the locations properly, and Showed him how I'd do it. But i understand where your coming from and that way would work also
Apr 10 2013, 3:34 pm
That's a bad example, The Motto. You do not need to rely on coordinates, or modify the loc variable of the new torch. In fact, that's why the new statement has a way to provide arguments:

obj/torch/verb/Get()
    set name = "Pick Up"
    set category = "ACTION"
    set src in oview(1)

    var/oldLoc = loc
    loc = usr // Move the torch to the person who is picking it up
    usr.luminosity = 2 // The users glows, or something!

    sleep(500) //Wait 50 seconds...

    new /obj/torch (oldLoc) // Let's create a new one, in place of the old one!


Note that you do not need a return statement, it's completely redundant.
Apr 10 2013, 4:01 pm
In response to Super Saiyan X
Thanks SSX, I would've done an example like that but I'm on my phone and it makes that a bit hard.
Apr 10 2013, 8:43 pm (Edited on Apr 10 2013, 8:49 pm)
In response to Super Saiyan X
Super Saiyan X wrote:
That's a bad example, The Motto. You do not need to rely on coordinates, or modify the loc variable of the new torch. In fact, that's why the new statement has a way to provide arguments:

> obj/torch/verb/Get()
>     set name = "Pick Up"
>     set category = "ACTION"
>     set src in oview(1)
>
>     var/oldLoc = loc
>     loc = usr // Move the torch to the person who is picking it up
>     usr.luminosity = 2 // The users glows, or something!
>
>     sleep(500) //Wait 50 seconds...
>
>     new /obj/torch (oldLoc) // Let's create a new one, in place of the old one!
>

Note that you do not need a return statement, it's completely redundant.

What if we want to delete the item?
What if the tile itself is changed during that 50 seconds?
I think it's far better to defer this behavior to an external system.

spawnpoint
    parent_type = /atom/movable
    var
        spawn_type
        spawn_args
        spawn_delay
    proc
        picked_up()
            spawn(spawn_delay)
                var/list/L = params2list(spawn_args)
                L["loc"] = src.loc
                new spawn_type(arglist(L))


Of course, that's just me.
Apr 11 2013, 12:15 pm
Galactic Soldier wrote:
To conserve on memory, I think it'd be best to make the torch a turf that disappears after a person picks it up and creates a torch object in your inventory, then reappears after the spawn delay.

Turfs take up less memory than objects, and objects take up less memory than mobs. Everybody seems to use them wrong. For example, NPC's shouldn't be mobs except under the condition that a person may be able to "possess" them.

I can't think of more than one or two phrases that I agree with on that last comment.

Turfs' job is to define behavior pertaining to on-map containment. As such, you should not be setting them up to handle functions pertaining to object management, for the most part.

The turf isn't important, except as a container for objects that can act.

Mobs and objs differ only in the fact that they have group behaviors, and can be referenced as having a proper identity. they also have the inherent ability to interact through a client. There are many reasons to use mobs as opposed to objs, and not many to do the opposite. If memory is a bottleneck for you in BYOND, you are doing it wrong. The difference is negligible.

In the case of my system, the reason I chose to make it a movable as opposed to a turf was because I wanted the spawning behavior independent of the appearance of the turf, as well as the behavior of the turf.

Grouping the behaviors unnecessarily complicates things.
Apr 11 2013, 2:15 pm
Galactic Soldier wrote:
No performance difference is negligible in my eyes, even one that does not have any actual impact. If there isn't going to be a way to stop the torch from respawning, or the torch isn't going to move, then it should be a turf. Whether it complicates things or not is dependent on the programming.

So you'd rather create a unique type of spawner for every variation of item AND every variation of the turf's density, icon, etc, as well as any change in behavior of the location, such as harming the player on enter, as opposed to spending maybe a dozen bytes of memory?

The tile prototypes generated by this alone would more than wipe away any conceivable benefit.

While yes, mine will result in unique tiles on the map as well, it won't require manually changing any tile prototypes, nor will it require the duplication of code that your method would in order to achieve the same functionality.

It's not about performance in this case. Your suggestion is just undesirable from a fundamental design standpoint.
Apr 15 2013, 1:11 pm
Thank you, all of you. c: