A way to attach some data to *.dmm

ID:2274022
 
Jul 26 2017, 2:23 am
Redundant
Applies to:DM Language
Status: Redundant
This feature has already been implemented, or is already achievable with existing methods.
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.
Jul 26 2017, 2:13 pm
What?
Jul 26 2017, 2:44 pm
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
Jul 26 2017, 3:01 pm
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.
Jul 26 2017, 3:15 pm
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
    var/tmp/metadata

Then in the map editor, just find one turf you want to change and setup its metadata:

metadata = list("name"="security1" ,"group"="security", ...)
Jul 26 2017, 3:15 pm
Lummox JR resolved issue (Redundant)
Jul 26 2017, 6:06 pm
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.
Jul 26 2017, 6:34 pm
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.
Aug 5 2017, 2:43 am (Edited on Aug 5 2017, 1:45 pm)
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
/map/Del()// on destroy


May be: 
/map
  default_turf = /turf/space


For random z-transfer:
/map
  var/access_probability = 15

var/list/accessible_z_levels = list()
var/list/maps_by_name = list()

/map/New()
  ..()
  check_name() // to keep it unic. Code is omitted
  maps_by_name[name] = src // for quick'n'easy access
  if(access_probability)
    accessible_z_levels[name] = access_probability

/atom/movable/proc/touch_map_edge(var/dir)
  /*
  use pickweight(accessible_z_levels) and get new map
  use new_map.max_x, new_map.max_y for locate entrance point.
  */

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)
    admin_levels = list(3)
    contact_levels = list(1,2,4,6)
    player_levels = list(1,2,4,5,6,7)
    sealed_levels = list(6)
    empty_levels = list(6)
    accessible_z_levels = list("1" = 5, "2" = 5, "4" = 10, "5" = 15, "7" = 60)
    base_turf_by_z = list("6" = /turf/simulated/floor/asteroid) // Moonbase

Both are not flexible enough.
Aug 11 2017, 2:48 am
You could just have a separate code/JSON file storing the data.
Aug 11 2017, 3:31 am
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.
Aug 11 2017, 3:45 am
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.
Aug 11 2017, 6:03 am
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.