Kaioken wrote:

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.

Um, no it doesn't. They are the same map. One is a file, and one is an instance, but they contain the same things.

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 is no use. There is no need for two instances of an area of the same type. It doesn't allow you to do anything you can't do with one instance. Areas are not objects. They are nothing more than "ideas" which contain turfs. If your "idea" is the same, there is no reason to need two. If your "idea" is not the same, a new type is required. Anything else is a pointless waste of areas.

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

If I feel that saying it differently will provide better understanding, I'll say it. If not, then it doesn't need to be said. The level of confusion in the rest of this topic prompted me to make a more straight-forward post, to gather the good information into a single post while leaving the confusion out.

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.

Rarer than posts about objs or mobs or 'how i code NPCs?', but BYOND is rather old these days. Areas have been covered numerous times in great depth. No, not all 9800 posts for "area help" have useful info, but a forum search (which everyone should do before making a new post), almost always provides the info you need. Just because you haven't seen a thread specifically explaining what an area is, doesn't mean it doesn't exist. This forum conatains some 630,000+ posts. I'd be shocked if anyone could say they've seen them all, or even a minute portion of them.

No, you can't.

That doesn't create anything. All it does is set's the turf's loc to that area type. One instance is created at compile time for each type used.

Xooxer wrote:

No, they are not objects. Lists are certainly not objects. I don't know where you got that idea from. Mobs and objs are objects.

http://en.wikipedia.org/wiki/ Object_%28computer_science%29#Objects_in_object-oriented_pro gramming
I replied on the "list topic", so you could look there for that.

Turfs are objects, though stationary ones. Atoms are not objects.

You're evidently very mistaken. Being an object has NOTHING to do with being stationary or moving or with being on the map at all.
Atoms are objects, the only objects that have anything to do with the map. The rest of DM objects - lists, clients, savefiles, /icons, /sounds, what have you - have nothing to do with it.

Areas and datums are simply concepts. They aren't physical objects in the world.

Again, being an object has nothing to do with "existing physically". That has to do with being an atom.

Your opinion doesn't alter how areas behave.

Neither does yours, anyway. <,<

I'm not talking hypothetically. I'm talking about areas and how they work. You guys are all confused about them. They are not real things like you seem to want to think of them. They don't really exist like turfs or objs or mobs do. Two of nothing is still nothing.

I don't know, aren't you going slightly overboard?
They are not real things, they don't really exist. Are /areas in DM a fairy tale or something then?

If they have different variable values, they should be different types.

1)Hell no x1000, that is so very wrong.
2)What if they're uh, dynamically assigned, non-constant variables?

Xooxer wrote:

We're talking about DM, not general programming jargon.

Unless you're saying DM isn't an OOP language, the above applies.

You don't know what you're talking about here. Forget it.

Ah, how blunt, but since we're both sure the other is mistaken and apparently won't listen to eachother, I suppose we will have to wait for others to speak on the subject.

I don't know, aren't you going slightly overboard?
They are not real things, they don't really exist. Are /areas in DM a fairy tale or something then?

The only fairy tale exists in your mind in regards to how you think areas work. Your concept of them is the fairy tale.

But you said areas aren't real, that they don't exist. I'd consider that concept of implementation more fairy-talish than mine any day.

You're not getting it. An area shouldn't even be used like this.

Like "this"? I didn't give any specific example.

There's no reason to.

There're the same reasons for using areas at all in the first place. Only being able to create new ones in runtime is more flexible and dynamic.

Xooxer wrote:

An object is a solid, real thing, and area is a more of an idea or concept. A rock is a thing, the space around that rock is not. An area is the space, not the thing the space holds. If you have two spaces that are the same, it doesn't matter what they hold, they can be thought of as the same space.

DM is a programming language (an object-oriented programming language, at that) so there's no reason to exclude the usual programming concept of an "object" for a more restrictive one based on the physical meaning. The very fact that DM does allow you to create multiple instances of an area is a good reason to call areas objects.

There is no reason to have two instances of the same space. If once space differs from another, then it is not the same spce, it is a different type, ergo, it should be defined as a unique area type. Doing otherwise is an improper use of areas.

Have you ever looked at Shadowdarke's sd_DynamicAreaLighting library? That uses area instances (of the same type) to good effect. I would not call that improper.

You could of course do the same thing without areas, but why use a slower and less apt method when creating area instances works perfectly well?

If I'm glancing through these posts correctly I sense that areas basically share contents if they are of the same type, no matter where they are on a map or how seperated they are or how many seperate instances are created at run time.


If that is the case then areas are useless to me and I will have to come up with my own datatype.

No, you can create completely separate area instances of the same type. Don't glance, read.
You can experiment with the code I've posted in [link] to see how it is done and works.

1) Select an area from the left
2) Look slightly to the right. Big white box, outlined with the header "Object", should have the area you just selected in it.
3) Right-click on that area. Select "New instance"
4) Change something - two instances can't have the same variables.
5) Click OK

There. Two instances of the same area type.

Kaioken wrote:

Yes, what is it? A 75% OOP language? Maybe half?
Maybe 0%? I mean, it doesn't even have objects. Like, except atoms, since they're like, on the map and stuff?!!?

Why don't you tell me, since you're the expert on the topic.

for one, and most newbies, who would look to this topic for info, know nothing about OOP and would only be confused by it's inference here. [...] bla bla bla bla bla excuses newbies bla

Yeah yeah yeah. What newbies are going to learn from this topic now because of your posts is as good as what they'd learn from studying rips code. areas don't exist and only turfs mobs and objs are objects, and whatever else things you've made up.

Before I posted there was nothing but confusion, even from Garthor, who is usually 100% on the money. It wasn't clear at all what areas were. Your argument has dragged this away on a tangent, and your insistence on using areas like they were any other type of atom has lead to this quandary of confusion once again. I'm not making up anything. You're using jargon that's confusing and out of context for most BYOND developers. If you were describing datums, that's another matter.

But I thought you said we were talking facts. Newbies and whether they understand things or not have nothing to do with this. Are you backing out of all the nonsense you've said?

If you believe that newbies have nothing to do with learning DM, please uninstall and leave. Now. You fail at BYOND.

Ah, but your opinion does not change what is proper and what isn't, what is fact and what isn't. The fact remains this "improper use" of areas was intentionally and officially added and supported by BYOND, whatever you might say about areas "not being intended to be used in such a way".

Oh, now you claim to know the intentions of Dan? Areas were added primarily for text muds, to be used as rooms. Having them for visible turfs on the map was so developers could have non-localized control over spatial effects, like lighting.

The only reason I can gather that Shadowdarke is creating new area instances is so he can track them as his and not part of the existing world, since his code is executed from an external library and could be combined with many sorts of games. Even then, he could have tracked his area's turfs instead, and not had to create any new instances of existing types.

Like with everything, it means it's okay in certain situations.

And since you don't understand the situation, you aren't someone who should be listened to when it comes to knowing when it's okay and when it's not. I trust someone like Shadowdarke to know how to handle area management elegantly. I don't trust newbies to do the same.

Obviously enough, because situations it is okay are very rare and most people would not encounter them.
But of course, this again came out of nowhere and has nothing to do with the discussion.

It has everything to do with the discussion. Knowing when to use something and when not to is a vital piece of information to have, which you're downplaying to save face.

Repeating nonsense about supported features not being intended to use again and new nonsense about that you shouldn't use something that doesn't fit and you need to modify it. Then why should we use any of the default object types in DM? Hell, switch everything to /datums, /mobs don't have all the variables I want.

The nonsense is in your head, sir. Those a friggen programming basics. If you don't get it, maybe you should stop giving people code advice until the newb runs off.

Ah, you could say extremely pointless and vague things, but should you? No.

Unless they're not vague or pointless.

ok hi titan topic???