In response to FIREking
FIREking wrote:
I would be more interested in a built-in map saving and loading feature for developers; I would generate all of my auto-joins at run time and then save them directly to the map file that gets compiled (and write logic to stop generating them if icon_state differs from the default). My saves would work because each turf's icon state is the only information that describes the state of the autotile anyway!

So in the big picture, we need map saving and loading a little more importantly than map-editor auto-tiling... because that feature would be so much more powerful.

I generally agree with you, though I think mappers would be hugely thrilled if they had access to both. Tom and I have talked about built-in map loading and saving before. It's one of the wish-list features for BYOND 500, though I'm not sure if it'll be a 500 thing because we might want to get my current project out in beta first. If native map saving was in place, though, it would easily clear the way for me to put in map connections, a feature that I've been kind of drooling to add for a while that would hugely benefit MMOs.
I came up with a chunk saving / loading thing that allows for like 30 million tile worlds. It takes a little bit of time to set world.max_ to those values, but after that, its smooth sailing. When something changes position, the chunk system is notified and it will determine if a chunk needs to be loaded or not. We also tell the check system when items are taken, added, deleted, or moved so that it can react accordingly. Chunks are only saved when they are made dirty, and chunks are only loaded from disk once (if they are about to be seen).

There's several problems with being able to save turf data quickly though, and currently the fastest way is just with text while keeping the amount of data you want as minimal as possible (bare minimum location and type), generate or process the rest.

Would you agree this is the best approach for single server worlds with what we have right now?
In response to FIREking
FIREking wrote:
I came up with a chunk saving / loading thing that allows for like 30 million tile worlds. It takes a little bit of time to set world.max_ to those values, but after that, its smooth sailing. When something changes position, the chunk system is notified and it will determine if a chunk needs to be loaded or not. We also tell the check system when items are taken, added, deleted, or moved so that it can react accordingly. Chunks are only saved when they are made dirty, and chunks are only loaded from disk once (if they are about to be seen).

Interesting, though the 30 million size is probably unwise. The \ref macro is going to crap out on you before 16.8 million, because it assumes the data part of the reference is never more than 3 bytes. Internally I think BYOND can handle up to four billion, but obviously in a 32-bit program it'll run into trouble well before that.

There's several problems with being able to save turf data quickly though, and currently the fastest way is just with text while keeping the amount of data you want as minimal as possible (bare minimum location and type), generate or process the rest.

Would you agree this is the best approach for single server worlds with what we have right now?

If you mean saving in a format that looks very similar to the .dmm format, I would tend to agree that's probably ideal. If you mean using savefiles and ExportText(), that's gonna get ugly pretty fast.

My past discussions with Tom about native map saving have frequently come back to the inadequacy of the .dmm format to handle a "living" map. A lot of things that can be expressed at runtime can't at compile-time, such as objs inside of mobs, so we'd need to use some kind of extended format. However I like the savefile engine enough (because why reinvent the wheel) that I think it'd be folly to abandon it; I think most of SwapMaps' difficulties come from the fact that it has to do its work in soft code. Internally, the server is capable of detecting turfs that haven't been modified from their base type.
In response to Lummox JR
Good to know about the 16.8 million. I'm currently only interested in real-use case of about 1500x1500x5 which is 11,250,000 tiles and works for what I'm trying to do...

The way I'm saving turfs is basically this per turf per chunk:

f << "x=[];y=[];z=[];t=[]"
//x,y,z = loc
//t = type


I read them back out sequentially and sleep a bit every 500 loaded turfs...

I guess it is somewhat similar to the dmm format except it wastes more space and doesn't rely on file position for actual position. It could be made better in that regard, but the bottleneck I believe is actually in the turf.New() and not the reading of the strings. I could be wrong, though.
I would like to revisit this topic. Specifically this:

Map editor should have some form of auto-tiling functionality just like experienced in RPG Maker Map editor.

Almost every 2d tile based game, isometric included, uses some form of auto-tiling map editing. The current map editor is a PITA because we don't have this.

Another thing that would be great is a feature that lets you select any tile-based size (square or rectangle) from a sheet of graphics to paint with. This helps you assemble complicated roofs, trees, and other things you find in most 2d tile based games.

I'd love to see some updates to the built-in map tool we have in V510! (Which is why I'm reviving this)

Tiles autojoin?
Built-in Map loading/saving?
New UI to the map editor? (Just like we had one recently for the icon editor)
More mapping features?
Page: 1 2