ID:155596
 
Hey there, yet another question from me. I've asked around the saloon, but wasn't able to get a good answer for this question.

world.maxx and world.maxy will set the boundaries of the entire world. That works for games that I only need one screen on, but when I have to update every map in the game with empty spaces whenever I want to make a new map from scratch, it becomes a problem. Is there a way to set a map's x and y size at run time (without changing the entire world's), or will I have to make an empty .dmm before the game starts, and just fill that?
While running, a world only has one global map. It's made up of any map files that were compiled with the game (which get stacked on different z layers), and its size can be modified by changing world.maxx/y/z. If you make the global map larger, new turfs will be created for you using the default type you set in world.turf. If you make it smaller, turfs are destroyed.

If you want to make a small map area that isn't as big in the x/y sizes as the global map, your only option is to fake it. You can do this by surrounding the area you want to treat as a regular map with dense, opaque turfs, and setting client.edge_limit for anyone who enters this region (if you use EDGE_PERSPECTIVE, that is). In this way you can have a whole map file that consists of nothing but house interiors for instance.

Lummox JR
In response to Lummox JR
I have no idea how the inner workings of DM work, so excuse this question, but;

Do large maps lag BYOND, usually? Even ones that are entirely empty, or filled with default terrain? Or would it just cause some minor stress on startup, then not bother with them something moves in there?
In response to SqueakyReaper
SqueakyReaper wrote:
I have no idea how the inner workings of DM work, so excuse this question, but;

Do large maps lag BYOND, usually? Even ones that are entirely empty, or filled with default terrain? Or would it just cause some minor stress on startup, then not bother with them something moves in there?

Worlds will take longer to startup with large maps because they have to load everything into the global map. Once started however there should be no impact on lag. The server only sends partial map updates to the client at any given time, which consist of anything you can see and a certain number of turfs beyond that. The map only needs to be updated when the player moves out of range or to a new z level. Objs and mobs update separately.

Lummox JR
In response to Lummox JR
Thank you for the help. I hear a lot of exaggeration about maps being huge and killing everything, though I suppose second-hand references are never completely reliable.
In response to SqueakyReaper
SqueakyReaper wrote:
Thank you for the help. I hear a lot of exaggeration about maps being huge and killing everything, though I suppose second-hand references are never completely reliable.

One thing that will definitely impact lag, and more so with more users, is using a very large view size. Some games like to do this because it's more immersive, but it should be balanced with the expected number of users per server. Version 482 introduced some network enhancements that could help on the actual bandwidth side of things, but CPU usage on the server will still be slightly higher. (How much higher is an open question. Internally, having the server look up turf info during a map update really isn't a huge drain I think.)

A large global map on the other hand shouldn't really impact much except that it'll eat slightly more memory, and if it's large at startup time it'll eat into the world's startup cost. For this reason it's best to keep your global map as compacted as possible--if you do use smaller regions meant to represent tiny maps like building interiors, you'll want to cram those onto the same map file as much as possible.

Lummox JR