Mappable Datums

ID:132965
 
Jul 15 2009, 11:14 am
I would like to see mappable datums sometime in the future. The reason for my suggestion, is because, there are times when I want to use multiple turfs on a location, But, when I stack one turf on another any turf below it gets fused into the new one making the old one's procedures not read.

I suggest using mappable datum's because upon creation it won't have tons of variables and procedures already set to it, and, it will solve the multiple turf problem where people like to use turfs stacked on top of each other, lowering the excessive amount of object's and mob's used to mimic a turf.
#1 Jul 15 2009, 11:17 am
Or they could just make stacked turfs actually function <.<
#2 Jul 15 2009, 11:29 am
One turf per location is rather fundamental. You aren't going to be able to change that.

Mappable datums already exist, they're called "atoms". Areas, turfs, objs, or mobs.
#3 Jul 15 2009, 11:39 am
In response to Garthor (#2)
Garthor wrote:
Mappable datums already exist, they're called "atoms". Areas, turfs, objs, or mobs.

atom solely cannot be mapped, unless it is a specific area turf obj or mob.

Area - You can only have 1 per tile.
Turfs - You can stack, but only the top 1 will have it's proc's count.
Objs & Mobs - I would like to cut down on the amount of them I use per game, Saving it for the important objects and not things that should be considered turf's, not people or items.
#4 Jul 15 2009, 12:00 pm
In response to Inuyashaisbest (#3)
Inuyashaisbest wrote:
Garthor wrote:
Mappable datums already exist, they're called "atoms". Areas, turfs, objs, or mobs.

atom solely cannot be mapped, unless it is a specific area turf obj or mob.

Area - You can only have 1 per tile.
Turfs - You can stack, but only the top 1 will have it's proc's count.
Objs & Mobs - I would like to cut down on the amount of them I use per game, Saving it for the important objects and not things that should be considered turf's, not people or items.

No. areas are collections of turfs (though they could have no turfs as well), so describing them as "only one per tile" is a bit odd. turfs are the definition of a tile... each tile has one turf, and each turf is on one tile. "Stacking" turfs in the map editor destroys the old turf because otherwise things would just break: what's your loc if you're standing on a tile which has two turfs? The only "problem" here is that people have gotten the impression that you SHOULD be able to have two turfs on the same location, which is just silly.

As for "saving objs and mobs", they're not endangered, and they are EXACTLY what you want: an object type that can be freely placed on the map. You are literally asking for what you already have.
#5 Jul 15 2009, 12:22 pm
Inuyashaisbest wrote:
I would like to see mappable datums sometime in the future.

This suggestion makes no sense. Garthor already covered the rest. Use objs*. I assume not, but in case what you want to add is visual-only, then you could also use visual-only stuff such as overlays or perhaps images.

*: You've no reason to worry directly about 'saving objs'. If you're not doing insane things with them, you won't ever come close to the limit, which was big in the past, but now is 16 million.

I suggest using mappable datum's because upon creation it won't have tons of variables and procedures already set to it,

http://www.byond.com/docs/ref/info.html#/atom/var
A lot of those vars are important for something on the map, you can't just automagically stick an object on the map without its appearance-and-map related properties. That would be like ignoring the physics of the world.
The whole point of being able to use datums is being able to use objects WITHOUT the above mentioned extra baggage of properties. Again, this makes no sense.
#6 Jul 15 2009, 12:26 pm
In response to Garthor (#4)
He's essentially correct that areas can only be one per tile, though it's important to note that it's a 1:many relationship; an area can have many turfs, but a turf has only one area.

But anyway, the obj type is versatile enough that it should function just fine for antyhing that turfs would ordinarily do if you want something special for stacking purposes. With the object limit raised it's unlikely there would be any kind of issue with that either.

Lummox JR
#7 Jul 15 2009, 12:38 pm
In response to Lummox JR (#6)
Would using /atom/movable instead of /obj be any better?
#8 Jul 15 2009, 12:48 pm
In response to Kaiochao (#7)
Kaiochao wrote:
Would using /atom/movable instead of /obj be any better?

No, since it's an abstract and can't be instantiated. Really there's no logical way to define a new atom concept since the ones that matter are already used; the situation in this case clearly calls for the use of objs.

Lummox JR
#9 Jul 15 2009, 12:58 pm
In response to Lummox JR (#8)
Lummox JR wrote:
No, since it's an abstract and can't be instantiated.

About this part; you can actually instantiate /atom, which acts as a turf, and /atom/movable (which of course acts like an obj), and they can be on the map at and all. Irregardless of any difference or merit this may have, it does appear to work on the surface (and according to the type, the objects aren't being replaced with the 'normal' ones).
#10 Jul 15 2009, 4:39 pm (Edited on Jul 15 2009, 5:05 pm)
I think they should should add full support for multiple turfs per x,y,z (your location being that x,y,z; and not some literally defined "location") though it would probably cause a lot of legacy problems.
They could also just completely remove support of it from the map builder. This would probably be easiest and most sensible way to go. Allowing for old maps to function as they do, but if you try to stack turfs in future mapping, it will simply replace the current one like area mapping does.
They may also be able to go somewhere in between, allowing all the turfs to function properly, but simply marking your "location" as the very top one.
As it is now turf mapping gives a false sense of design, and tends to lead to problems, especially for new developers.
#11 Jul 15 2009, 9:06 pm
In response to Lummox JR (#8)
When mapping with obj's mimicing turfs, on the map builder, if one obj completely covers another, the one below doesn't vanish (which is reasonable for games that stack potions on the floor) but when mapping it becomes hard to tell if you double-stacked or not.
#12 Jul 16 2009, 12:47 am
Okay, this idea doesn't add up since you can't have multiple turfs in a single spot, but allowing multiple areas (or defining a new type /group that can do this) would be a neat idea.

You are not necessarily dependant on having one area per turf. Perhaps internally somewhere in the depths of the BYOND source-code, but externally nothing big would be changed.

If the existing area system is used, the only change that would be made is that, in the event of multiple areas being present in a single location, a turfs' loc variable would turn into a list of those areas.

Because older projects still rely on a single area per tile, it wouldn't break older projects (which can still store the single reference to the area), but it would allow newer projects to make use of the feature to cut back on the area types that need to be defined.

Still, just a thought. Probably doesn't make all that much sense either, but I thought I'd try to make some sense out of all of this.
#13 Jul 16 2009, 1:21 am
In response to Kaioken (#9)
Kaioken wrote:
Lummox JR wrote:
No, since it's an abstract and can't be instantiated.

About this part; you can actually instantiate /atom, which acts as a turf, and /atom/movable (which of course acts like an obj), and they can be on the map at and all. Irregardless of any difference or merit this may have, it does appear to work on the surface (and according to the type, the objects aren't being replaced with the 'normal' ones).

Yea... I've set atom/movable's on the map when wanting to conserve resources.

I would like to be able to create atom/movables on the map at compile time instead of runtime however.

As far as the whole multiple turfs idea: doesn't it seem like this would break the 'fabric' of BYOND's structure? I mean... when you check a variable's loc, it returns a turf... a single turf... If you allowed more than one turf per tile you'd have to have it return a list or something and it'd require a LOT of changes to the way we work with BYOND, and if I was to make an assumption I'd say an infinitely larger amount of changes to the 'behind the scenes' part of BYOND.
#14 Jul 16 2009, 5:56 am
In response to AJX (#13)
AJX wrote:
Yea... I've set atom/movable's on the map when wanting to conserve resources.

I don't see how it conserves any resources, though. In a fresh environment, the resulting object is virtually identical to /obj, only it has a different type. Everything else is the same.
Only the /mob type carries extra baggage since it has person and player-related properties (Login(), see_invisible, sight, group...). /obj however doesn't.

<font color=green>Actually, using /atom/movable wastes more resources because the different type is longer and therefore takes more bytes of memory! Haha!</font>
Of course, the above is a joke. And type paths aren't stored as text strings anyway, rather probably as simple indexes to the table of type paths, so making it longer won't increase memory usage.

I would like to be able to create atom/movables on the map at compile time instead of runtime however.

Well, there's just not much point to it though, as Lummox basically said. The only advantage would be if you went and declared various vars on the base /obj type and want a type without them, but that's just a mistake, since for precisely this reason you shouldn't ever define vars on the base types unless they're really meant to be global. Yes, everybody and his mother tends to define mob/var/HP, but that's not as right as mob/fighter/var/HP or something similar.

As far as the whole multiple turfs idea: doesn't it seem like this would break the 'fabric' of BYOND's structure?

Yes, you are correct. BYOND's map and location handling is pretty much built upon only one turf per tile. In fact, that's not even accurate - the turfs themselves are the tiles. So, naturally, you cannot have multiple tiles as a tile... :P

And, I thought while I'm posting I'll point out (not that explicitly pointing it out is necessary) that Falacy said some pretty nonsensical things, including suggesting to remove functionality from the map editor.
#15 Jul 16 2009, 7:46 am
--From one of my not-a-bug reports, stating that if you Entered an obj's location or whatever it doesn't teleport you.--
------------------
#2 Lummox JR:
There are multiple problems in your code. Enter() is not a usr-safe proc, Entered() should be used instead for teleporting, and you need turf/Entered() instead of obj/Enter() since the mob is not walking into the obj but merely onto the same turf.
--------------------------------

If you stack a turf, only the last-added on turf's proc's will be called.
so if the bottom turf, was supposed to merge(thanks Shadowdarke ;o) and the top turf was supposed to Teleport the person walking into it somewhere else, The turf on the bottom will not merge, but you will be teleported. Now as Garthor said: As for "saving objs and mobs", they're not endangered, and they are EXACTLY what you want: an object type that can be freely placed on the map. You are literally asking for what you already have.

But, Entered() Cannot be used for obj's as they can for turf's so what good is objects to mimic it anyways? How is this Exactly what I want if it cannot take the player to a new location on the map.

#16 Jul 16 2009, 12:57 pm
In response to Inuyashaisbest (#15)
Inuyashaisbest wrote:
But, Entered() Cannot be used for obj's as they can for turf's so what good is objects to mimic it anyways? How is this Exactly what I want if it cannot take the player to a new location on the map.


You can, very easily, with just a couple lines of code.

From the sd_procs library:
turf
    Entered(O)
        for(var/atom/movable/A in contents - O)
            A.Trigger(O)    // tell A that O stepped on it
        ..()


Then use the obj's Trigger proc exactly as you would a turf's Entered proc.
#17 Jul 16 2009, 2:26 pm
In response to Nickr5 (#16)
Nickr5 wrote:
You can, very easily, with just a couple lines of code.

A very good point brought up here is that there are many things that can be easily coded if you open your mind a little. This approach would work just fine for what you're talking about.