Explanations of areas

Page: 1 2 3 4
ID:161657
 
Apr 13 2008, 4:58 am
The DM guide says one area object is defined per area type on the map.

So lets say I want to dynamically create a new area at runtime in a 5x5 box in location, and then I want to create another area in another seperate location in a 5x5 box. These two are actually the same area? So if a player enters one of these areas they've basically entered both areas?

How to get around this? Keeping in mind that whatever solution is given must also be sufficiently automated to create many many areas at run time.
Apr 13 2008, 10:02 am
They are not the same area. That line from the DM guide is just wrong. It doesn't imply what you think it implies, either.
Apr 13 2008, 6:44 pm
In response to Garthor
Garthor wrote:
They are not the same area. That line from the DM guide is just wrong. It doesn't imply what you think it implies, either.



God.

Who can we trust, if not the DM guide?
Apr 14 2008, 2:35 am
In response to Obs
The DM Reference, but of course. It has much more information than just on every proc and variable, y'know.

The DM Guide is known to be quite outdated. But the Reference is still being updated, so you should always check it as well. Well actually I do always say "look things up in the reference before you use them", it isn't a thing for newbies only, I do it too, and so should you.

Anyway, you can use new() to make new instances of /area at runtime; you just need to do it the right way. The DM Reference says to use a null loc argument in new() to create a new instance. Otherwise it will add the loc argument to an existing area if there is one.


But I don't know if that guide line should be considered wrong anyway. It is mostly correct, unless you dynamically create new instances specifically. You could just call that line inaccurate, but it explains areas okay.
Apr 14 2008, 5:59 am
In response to Kaioken
I don't think that line is inaccurate; calling new() without a loc variable won't place the area on the map.

This is really interesting though, I always thought there could be only one area per type anywhere in a game.
Apr 14 2008, 8:16 am (Edited on Apr 14 2008, 8:38 am)
In response to DivineO'peanut
DivineO'peanut wrote:
I don't think that line is inaccurate; calling new() without a loc variable won't place the area on the map.

Areas are never technically "on the map". Their loc is always null anyway. The rest of the map is inside areas.
<s>Probably</s> (EDIT: I've just confirmed this), area/New(loc) just takes the loc and puts it inside the area, not the other way around.
But what I said is what the reference says, are you challenging it? :P

This is really interesting though, I always thought there could be only one area per type anywhere in a game.

Thankfully that aspect of DM is flexible too. =)
Apr 14 2008, 8:49 am
In response to Garthor
Quoted from the DM guide:

"For each area type defined, one area object is created at runtime. So for areas on the map, all squares with the same area type belong to the same instance of the area.

Additional instances of rooms may be created from the same type by explicitly creating them with null as the initial location. That is, the first argument to new() should either be null or left unspecified."

This is completely correct information.

Obs's confusion stems from overlooking the "at runtime" bit. You see, to expand upon an area, you actually add the turf to the area's contents, thus putting another turf into the original area.

var/area/a = locate(/area/specific) in world
a.contents += locate(1,2,3)
a.contents.Add(block(locate(1,2,3),locate(4,5,6)))


This example expands your current area, while the next creates a whole new instance.

var/area/a = new/area/specific()
a.contents.Add(block(locate(1,2,3),locate(4,5,6)))


Test it out, I assure you that these areas are seperate. Therefore, the guide is completely correct.
Apr 14 2008, 8:56 am
In response to Ter13
Exactly, I agree (well, this is what I've said, but in code form too :P).
Apr 14 2008, 11:49 am
In response to Kaioken
DM Guide and DM reference are synonymous to obs.
Apr 14 2008, 11:58 am
In response to Ter13
"For each area type defined, one area object is created at runtime."

This is not correct, and it's easy to show:

area
    Bob

mob/verb/test()
    for(var/area/A)
        world << A


Note the lack of Bob.

As for instances of areas... "duh". However, for bonus fun: you don't need to use locate() to add to an already existing area. new(turf) works as well:

mob/verb/test2()
    var/area/Bob/B = new(loc)


This appends to an existing (well, if one exists, otherwise it creates a new one) Bob area. Don't ask me what happens with more than one. Oh, and for an entertaining error, try new() with a list (like, say, new(oview()))
Apr 14 2008, 12:21 pm
In response to Kaioken
Fine, nitpicker. That's what I meant anyway. :P

Edit: I thought what was written in the reference is what Obs said. That's why I said it wasn't inaccurate.
Apr 14 2008, 4:52 pm
In response to Garthor
Why would you use new(turf) unless you were going to have a 1x1 area?
Apr 14 2008, 7:22 pm
In response to Obs
new(turf) adds to an (not sure which, if there are multiple instances of the same type) existing area. Strangely enough.
Apr 15 2008, 12:35 am
In response to Garthor
Man, you guys confused me by confusing the DM Guide and Reference. :P

Garthor wrote:
"For each area type defined, one area object is created at runtime."

This is not correct, and it's easy to show:

Eh. You're taking it too literally. Of course if you never place or create an area in your code, it isn't gonna get created. Besides, that paragraph is kind of specific to areas placed on the map anyway.
<big><code> For each area type defined, one area object is created at runtime. So for areas on the map, all squares with the same area type belong to the same instance of the area.</code></big>

The first sentence doesn't mean "every area type can only have one area object". It just means that by default BYOND creates only one for each at runtime. Your custom code may do otherwise (this is exactly what it says the next paragraph so it makes even less sense for that line to be a mistake), but at runtime (meaning, when you start the world) it creates one area object for each type [that is on the map].

new(turf) works as well:

<small>I already mentioned this</small>

new(turf) adds to an existing area. Strangely enough.

It does make some sense, though. new(_loc) is sometimes used to add a new atom to a tile, _loc. So with areas, it "creates a new area piece on that tile, _loc", so to speak, by adding _loc to the area.
Oh, it also adds all the movables on that turf to the area of course, but I think that's because it's hardcoded.

Don't ask me what happens with more than one.

I expect it'll add to the first one of the appropriate type it finds, like if you use locate()?
Apr 15 2008, 4:16 am
An area is a conceptual container that contains all turfs in the world. They are most often used for non-localized effects and gameplay features that are turf-independent but occur over a large area of the map. Hence the name, area.

If you create a new() instance of an area, and that area is already being used in the world, the loc passed to the area/New() proc will be added to the existing area instead of creating a new area instance. If no area of the new type exists, a new instance is created and the loc is added to it. If no loc is passed to area/New(), a new instance of the area is created even if one already exists in the world, but no turfs are added to it.

If two turfs on opposite sides of the world are both using the same area type, they are in fact using the same area instance as well. Areas have no location. They do not exist like objects or mobs. They are not added to the map, the map is added to them.

If you require two different types of areas on your map, you need to define two different types in your code. You might be able to set the parent type at runtime, creating dynamic areas on the fly, but I'm not certain how that would work in practice.

~X
Apr 15 2008, 4:23 am
In response to Xooxer
Xooxer wrote:
You might be able to set the parent type at runtime, creating dynamic areas on the fly, but I'm not certain how that would work in practice.

Heh, of course you can't set the parent_type on runtime. Anyway, like said quite many times before in this topic (and you've repeated stuff again, meh), you can utilize multiple instances of an area type at runtime, so you don't need to try to... define new object types on runtime or something, which is impossible.
Apr 15 2008, 4:32 am
In response to Kaioken
You can not create a new area instance on the map. You can create a new instance in the world, but it will hold no turfs.

And yes, I'm fairly certain that you can create a new type at runtime.

And while I may have repeated some of the information contained in this thread, I presented it coherently without a lot of confusion and misinformation.
Apr 15 2008, 5:36 am (Edited on Apr 15 2008, 5:46 am)
In response to Xooxer
Xooxer wrote:
You can not create a new area instance on the map.

Like I and actually you too already said, areas aren't on the map, the map is inside areas.

You can create a new instance in the world, but it will hold no turfs.

Well this was covered in the topic, but I'll say it again (meh). I don't see the problem here, it didn't even need to be covered anywhere (you must've accidentally overlooked this, I don't mean to attack you - I can see you're clearly a good coder). After you create the new instance by using a null argument in new(), you just add any needed turfs to it manually. The objs and mobs in them are hardcoded-ly added automatically, too.

And yes, I'm fairly certain that you can create a new type at runtime.

I'm fairly certain that you can't. It would be very nice if you could tell me otherwise, though? Somebody already whopped out an undocumented DM feature in another topic when I was certain you couldn't do something.
Anyway, fact remains the parent_type var is a compile-time-only var.

And while I may have repeated some of the information contained in this thread, I presented it coherently without a lot of confusion and misinformation.

Yes, that was a good thing, I didn't say it wasn't, good job actually. Just that it's a little annoying that this thread is spammed with the same information everywhere and it's a little messy, since this discussion of areas is probably rare or might even be one of the only topics like it.


Anyway, I wrote this earlier to validate and experiment with all of this, so I'm going to save you guys the trouble. It's pretty interesting. The rgb() stuff is just to mark the turf so it's easier to follow and you don't forget which one you ran the verb on. 
area
    yas
    bass

turf/verb
    put_in_area()
        set name = "put in existing area"
        set desc = "Add this turf to a single-instance area"
        set src in view()
        src.icon += rgb(100,0,0)
        new /area/bass(src)
    create_area()
        set src in view()
        set desc = "Add this turf to a new area instance"
        src.icon += rgb(0,200,0)
        var/area/yas/A = new()
        A.contents += src

atom/verb
    check_area()
        set src in view()
        var/atom/A = src
        while(A && !isarea(A)) A = A.loc
        if(A)
            usr << "Area found:{[A]}([A.type])x-coord([A.x])"
        else usr << "No area found!"

mob/verb/see_areas()
    for(var/area/A)
        src << "Area:{[A]}([A.type])"

proc/find_player(key)
    key = ckey(key)
    for(var/client/C)
        if(!key) return C
        if(C.ckey==key) return C
area/New()
    var/client/C = find_player()
    if(alert(C,"Run default area/New()?","title","Yas","Nop")=="Yas")
        . = ..()
        C << "default area/New() called."

area/verb/see_contents()
    set src in oview()
    usr << "[src]([src.type]) contains:"
    for(var/atom/x in src)
        usr << "    {[x]}([x.type])"


The reason for the area/New() override: It was interesting to use check_area() on the turf just before New() runs and then afterwards, etc, so look into that too.
Apr 15 2008, 5:54 am
In response to Kaioken
Kaioken wrote:
Xooxer wrote:
You can not create a new area instance on the map.

Like I and actually you too already said, areas aren't on the map, the map is inside areas.

Well, if you want to get downright friggen technical, areas do exist on the map. They are defined in the dmm file, and can be accessed in the map interface. Turfs (not the map itself) exist inside areas, objects inside turfs, etc. Areas are the main container for the map, and usually a map only has one area type with a single instance in the world. Areas created with no loc passed are not created on the map. No turfs on the map belong to the area. It exists in the world, but not within the map.

Well this was covered in the topic, but I'll say it again (meh). I don't see the problem here, it didn't even need to be covered anywhere (you must've accidentally overlooked this, I don't mean to attack you - I can see you're clearly a good coder). After you create the new instance by using a null argument in new(), you just add any needed turfs to it manually. The objs and mobs in them are hardcoded-ly added automatically, too.

That may be true, but it's not really how areas were meant to be used. What's even the point of having multiple instances of the same area type? They aren't a localized atom that can occupy space, they are conceptual. If the area you have doesn't meet the required concept, a new type should be used. There's not much point in even using multiple instances of the same area type.

Yes, that was a good thing, I didn't say it wasn't, good job actually. Just that it's a little annoying that this thread is spammed with the same information everywhere and it's a little messy, since this discussion of areas is probably rare or might even be one of the only topics like it.

There's no spam in this thread. More information, even if it's only the same info presented in a different way, is a good thing. And I'm pretty sure this topic has been covered plenty of times, with far more information than any of us could provide. A few quick forum searches bring up thousands of hits.
Apr 15 2008, 6:08 am
In response to Xooxer
Xooxer wrote:

Well, if you want to get downright friggen technical, areas do exist on the map. They are defined in the dmm file,

Yeah well okay okay. It depends whether you're talking about the map file or the map itself (ie what you see in-game) and stuff, but there's no need to argue over this.

That may be true, but it's not really how areas were meant to be used.

Well, it's a documented feature. And since adding to area.contents also has a special effect, I wouldn't say the BYOND Staff didn't mean you to have the option to do this.

What's even the point of having multiple instances of the same area type? [...] There's not much point in even using multiple instances of the same area type.

Oh, it's definitely possibly useful and there is point to it. I used to have a few possible ideas once before I looked into this because of this very topic, but that was a long time ago so I forgot. But, you could ask Obs here what his current idea for it is. Care to share Obs?

There's no spam in this thread. More information, even if it's only the same info presented in a different way, is a good thing.

You're ultimately right, but it can still possibly confuse readers that posts keep saying things differently.

A few quick forum searches bring up thousands of hits.

Well, I doubt you've checked them all to be relevant though. Either way, I've browsed lots of question topics and don't think I've seen one about this before, so they must be quite rare.
Page: 1 2 3 4