Explanations of areas

Apr 15 2008, 3:37 pm (Edited on Apr 15 2008, 3:48 pm) In response to Xooxer
Obs	No new areas at run time? Really? That's short sighted. What exactly are you supposed to do if you are creating new levels at runtime, levels which need new areas? You should be able to create a new anything at runtime. This thread has also exploded into a cesspool of contradicting information from various sources. Might as well wait for a godbie.

Apr 15 2008, 4:10 pm In response to Obs
Garthor	There's no contradiction. Xooxer is just being wrong.

Apr 15 2008, 4:12 pm In response to Xooxer
Garthor	Xooxer wrote: Before I posted there was nothing but confusion, even from Garthor, who is usually 100% on the money. At no point was I confused. Everything was clear until you started insisting that certain uses of areas were verboten for no particular reason.

Apr 15 2008, 4:26 pm In response to Garthor
Xooxer	No, I'm not being wrong. As for your example, Orbs, that would not create new areas. new turfs are added to the already existing area. It's not about Z levels or location. Areas aren't restricted to turfs, turfs are restricted to areas. When you create a new level on the fly, all the turfs in that new level are added to already existing areas. There's no need for new instances of the same area.

Apr 15 2008, 4:28 pm In response to Garthor
Xooxer	Sure did look like you were confused to me. That whole "The DM reference is wrong" bit, especially. The reference is accurate, your understanding is flawed.

Apr 15 2008, 5:31 pm In response to Xooxer
Garthor	I was specifically referring to, "For each area type defined, one area object is created at runtime." This statement is demonstratably false. Once again: area Bob mob/verb/lookforBob() for(var/area/A) if(istype(A, /area/Bob)) usr << "Bob has been found" return usr << "Bob has not been found" Bob will not be found, as there is not an instance of Bob, despite it being defined.

Apr 15 2008, 5:34 pm

In response to Xooxer

Garthor

If you use areas as a collection of turfs, then yes, copies of the same instance of an area would be useful. As an example: representing the roofs of buildings with an area, which uses client images to make the roof appear and disappear when a player enters or exits the building. They can't all be the same instance or you'd see into a the building next door, but they CAN all be the same type. A roof's a roof, but THIS roof isn't THAT roof.

Apr 15 2008, 5:56 pm In response to Garthor
Xooxer	Fairly poor example, really. No need for different instances of the same area type when you should be tracking which roof goes where through a datum, which is much cleaner and more modular than creating tons of area instances.

Apr 15 2008, 6:10 pm In response to Garthor
Xooxer	Ah, yeah. That is wrong.

Apr 15 2008, 6:43 pm

In response to Xooxer

Garthor

area/roof
  layer = MOB_LAYER+1
  var/image/roofimage
  New()
    ..()
    roofimage = image('roof.dmi',src)
  Entered(var/mob/M)
    if(ismob(M) && M.client)
      M.client.images -= roofimage
  Exited(var/mob/M)
    if(ismob(M) && M.client)
      M.client.images += roofimage

client/New()
  for(var/area/roof/F)
    src << F.roofimage
  ..()

Apr 15 2008, 11:38 pm

In response to Xooxer

Kaioken

Ah, quit it. Seriously, it's clear you've no idea what you're talking about in these later posts. I expect you won't even listen if Lummox comes here and sets you upright. Unfortunately he probably doesn't have time to read all these mountains of crap you've popped out.

But, anyway -

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.

I'm afraid you fail at arguing properly at all, and likely in at reading too, so simply quit it. Obviously I was talking about the facts not depending on what any newbie may think or understand, then you introduce new unrelated topics about learning DM and newbies, which had nothing to do with this entire topic.

Apr 15 2008, 11:46 pm

In response to Obs

Kaioken

Obs wrote:

No new areas at run time?

Really? That's short sighted.

Indeed, I agree

This thread has also exploded into a cesspool of contradicting information from various sources. Might as well wait for a godbie.

Lol, godbie? Did you make it up? lummoxbie..
Anyway, just don't read Xooxer's post about not needing to use objects in BYOND and not all atoms being objects, and all that stuff.

Basically, you want to create a new area instance, right? Use new() simply as always, but use no argument. There you have a new area instance, put any turfs you want it to include into it's contents.
If you use an argument to area/New(), it will add the argument to an existing area instance (or create a single one if there isn't one existing of the relevant type) instead, so make sure you have a null argument.
Example (posted in a previous post...)

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()
        
        new /area/bass(src)
    create_area()
        set src in view()
        set desc = "Add this turf to a new area instance"
        
        var/area/yas/A = new()
        A.contents += src

Apr 16 2008, 12:26 am

In response to Kaioken

Xooxer

Kaioken wrote:

Ah, quit it. Seriously, it's clear you've no idea what you're talking about in these later posts.

You keep on thinking that if it makes you feel better about yourself.

I expect you won't even listen if Lummox comes here and sets you upright. Unfortunately he probably doesn't have time to read all these mountains of crap you've popped out.

You're right, I won't. Mainly because I don't need setting. Your remarks, however, are bordering on flamage. Might want to tone it down. It's just a forum thread.

Obviously I was talking about the facts not depending on what any newbie may think or understand, then you introduce new unrelated topics about learning DM and newbies, which had nothing to do with this entire topic.

Whatever. Have fun with your ego.

Apr 16 2008, 12:28 am In response to Garthor
Xooxer	Which should be managed by a datum, not creating a bunch of instances of areas to track rooftops.

Apr 16 2008, 2:56 am

In response to Xooxer

Alathon

There are cases where the term 'should be' can be applied.

goto should be avoided unless you have a very specific reason to be using it

The : operator should be avoided unless you have a very specific reason to be using it.

Those are rather standard cases, which have clear consequences (spaghetti code and being far more prone to runtime errors, respectively).

This really isn't a clear-cut case. I don't see any problem in using areas in the fashion demonstrated by Garthor. Yes, you could use a datum as well. Neither of those two methods holds any significant, built-in reason to be horrible. Neither of those two methods present unreadable code, break with standard conventions, et cetera. Which means 'should be' is simply wrong here, because that implies an argument based on fact, not opinion.

Apr 16 2008, 6:09 am In response to Xooxer
Obs	So everything you said was wrong?

Apr 16 2008, 6:14 am In response to Alathon
Obs	Don't even get me started on the : operator. I can't believe the amount of misinformation people threw out on that one. People were saying it was slow and terrible and no one should ever use it, which wasn't really true. You just have to know what you are doing to use it correctly. Makes me skeptical when I hear people speaking in absolutes.

Apr 16 2008, 6:36 am

In response to Xooxer

Kaioken

Xooxer wrote:
631202

You keep on thinking that if it makes you feel better about yourself.

It doesn't have anything to do with me, anyway. You can also keep on thinking your mistaken, made up beliefs are correct all you want, I care not. Just don't post it on a public forum claiming them to be fact.

You're right, I won't. Mainly because I don't need setting.

Your remarks, however, are bordering on flamage.

If you're already trying to use "huge ego" insults, might as well not act like someone with one. Saying someone is wrong isn't flaming. It's usually called correcting, or otherwise, saying the truth.
Of course, you might want to take note that I'm not saying you're wrong in a different way than you've already done to me, before calling it flaming.

Might want to tone it down. It's just a forum thread.

Which is exactly why you shouldn't post your own hypothetical personal beliefs about how the language works here and claim they're fact. You even went as far as to say the BYOND staff implemented features that were never intended to be used, though I guess that does make sense considering they don't have anything particularly important to do in their free time anyway.

Whatever. Have fun with your ego.

The same subject-changing techniques again. :) But I suppose it is better this way since you're probably not going to say anything much more meaningful than just "whatever" either case.

Apr 16 2008, 7:00 am In response to Kaioken
Xooxer	Nothing I've said was nonsensical, and I have plenty more to say, I just know that this is no longer the place to have this conversation. You're more than welcome to blog, but I won't participate in a flame war here, sorry to disappoint.

Apr 16 2008, 9:26 am In response to Obs
Xooxer	No. Kaioken is just being a jerk and trying to make it seem like I don't know what I'm talking about. If you read what I wrote, you'll see that I am correct. The only point of debate between us is whether it's proper to use runtime created areas like this or not, and for some reason he wants to make it a personal issue.