Map datum in BYOND Discussion

ID:132866
 
Sep 3 2009, 10:39 pm
This may sound like a bit much and I know swap maps does something similar but I feel it would be better if it was built in.

Here's an example on how you would use it

world/map=/map/Main

map/Main/File='Main.dmm'
map/House/File='House.dmm'
mob/verb/Make_Your_Dream_House()
var/map/A = new /map/House(world.maps)
usr.loc=locate(1,1,1,A)//x,y,z,map
usr<<"You are filled with joy."


I think it would lift a few restraints on byond...

Tell me if you would like it or dislike it.
#1 Sep 4 2009, 12:41 am
As much as I like this idea, it has already been suggested a number of times in the past, and each time it was met by general disagreement. So no, I don't think it's going to happen any time soon.
#2 Sep 4 2009, 12:54 am
In response to Metamorphman (#1)
Metamorphman wrote:
As much as I like this idea, it has already been suggested a number of times in the past, and each time it was met by general disagreement. So no, I don't think it's going to happen any time soon.

I have to ask to what point and purpose?

I don't see any functionality this would offer that you cannot achieve in the same manner without it.
#3 Sep 4 2009, 1:00 am
In response to AJX (#2)
- You could save map datums in files and load them again later
Is the first thing that comes to mind. It would make map saving a whole deal easier, not to mention faster.
#4 Sep 4 2009, 1:03 am
In response to Metamorphman (#3)
Metamorphman wrote:
- You could save map datums in files and load them again later
Is the first thing that comes to mind. It would make map saving a whole deal easier, not to mention faster.

Duly noted. Not a bad concept.
#5 Sep 4 2009, 7:53 am
It wouldn't lift any restraints. It wouldn't even lift your lazy butt off of using your brain to make something that does that yourself! :P

Built-in stuff is always nice, but it's never really necessary.
#6 Sep 4 2009, 8:18 am
Tom and I have actually talked before about building map saving/loading into the language itself. The problem is it is a fairly big project. The .dmm format doesn't appear to have anything needed to support runtime maps, which might include not only complex nesting but also objects with references to each other, or references to turfs and other objects that aren't even on the map. We would have to extend the map format to somewhat hybridize it with the savefile format, build a new format with the best pieces of both, or modify savefiles to allow for saving map sections. We're agreed that map loading/unloading is something the language could handle a lot faster on its own than a soft-coded library.

The good news is, right now I'm tackling big projects, so this isn't to imply that map saving will be on the back burner indefinitely. It's actually something I wouldn't be surprised to be working on soon.

As far as extending locate() to take four parameters, I don't think that would happen in any case. In an environment where maps were dynamically loaded, we could make it easy to keep track of their location without needing to modify the locate() proc.

Lummox JR
#7 Sep 4 2009, 3:23 pm
In response to Kaiochao (#5)
The restraint I was referring to was speed related. Not as much of a matter as can or can't.
#8 Sep 5 2009, 3:52 am
In response to Lummox JR (#6)
Yes! This just made my day. :)