For example: "Name", "Description", "Group", "Default turf", "Probability of access", "Is that admin only level", etc.
It could be very helpful.
And that's obviously much more clear way than hardcode z-level number (based on file order!) or place special objects on map.
All in all, i think it can be some kind of idem "special objects" build-in Byond and bounded to each .dmm file.
PS:
Sorry for any spelling mistakes. English is not my native.
ID:2274022
Jul 26 2017, 2:23 am
|
|||||||
Redundant
| |||||||
Jul 26 2017, 2:13 pm
|
|
What?
|
They want to be able to work with maps and zlevels as meta objects with metadata.
So you can create, and programmatically access, data about maps and zlevels, for controlling access or init time generation |
In response to MrStonedOne
|
|
MrStonedOne wrote:
So you can create, and programmatically access, data about maps and zlevels, for controlling access or init time generation This would go hand-in-hand with dmm loading/saving at run-time, if it ever was to be added to the language itself. |
You already have the ability to do this.
If you set a custom tag for any turf on the map, you can lookup that turf by its tag with locate(). Thus if you've got a tag like "map=security1", then locate("map=security1") will find the turf that has it. So you don't need to hard-code Z levels at all. If you want to set other metadata, why not create your own metadata var? turf Then in the map editor, just find one turf you want to change and setup its metadata: metadata = list("name"="security1" ,"group"="security", ...) |
Metadata about the turf isn't the same as metadata about the map or zlevel
and yes, you can abuse turfs to provide this, it isn't proper OOP code to put world/map/zlevel data on a turf. =P but ya, you COULD just tie this into (1,1). I think how ever they are wanting to use this for dealing with dmm files at runtime, where they aren't loaded yet. Byond built in ways of dealing with dmm files at runtime would actually be super nice (and might include such metadata features), but thats just me. |
What about attaching meta data to areas and assigning an area to each z-level? That would avoid redundancy by trying to assign it to each subset of turfs.
|
In response to MrStonedOne
|
|
use this for dealing with dmm files at runtime, where they aren't loaded yet. No. After load only. Something like: /map/New()// on map load May be: /map For random z-transfer: /map That will allowed using maps with different default turf and different map sizes (map.max_x, map.max_y instead world.max_x, world.max_y). You already have the ability to do this.Yes that also could be impliment with areas or turf at 1,1 and we already done that with meta_object at 1,1. Someone use hardcode way like that (bounded to map files order, creepy): station_levels = list(1, 2) Both are not flexible enough. |
In response to PJB3005
|
|
Correct me if I'm wrong.
This way is we slill use hardcode, miss compile time error checking (JSON) and can't get info about map sizes. And how would we link map file and data-file? Metaobject at (1,1) is preferred I think. |
In response to Lethal Ghost
|
|
This way is we slill use hardcode Still, so I don't see the difference. You have to hardcode basically all config file reading. miss compile time error checking (JSON) I mean if you're really insane you can set up a build tool or JSON schema checker. can't get info about map sizes. This isn't different with my proposal. |
That thing is more usasbe:
https://i.imgur.com/6xUNbzW.png https://i.imgur.com/cZmY5Ch.png Main advantage - it is bound to Z level. |