ID:2266746
 
Independence Day has come and gone, and sadly I did not see any fireworks or thwart an alien invasion.

But I have been at work on BYOND. Mostly sticking to 512 stuff, I shored up some of the items already mostly done so that they could be buttoned up properly, but also I've started to look into some things related to the map editor. Overhauling the map editor is high on a lot of people's lists, but it's actually a really big project. However, I've come to the opinion that it might be approachable in stages, and some of the stages I need to approach first are pretty simple ones. The ultimate end goal for me would be for the map editor and Dream Seeker to use pretty much the exact same display code, which would simplify a lot of things and also make it easier to retire software rendering mode, but that's some ways off.

However I have been at work doing something that's been on my list a while: reworking the map saving code so that it preserves existing symbols whenever possible. This is a big deal to a lot of projects that rely on content revision systems, so I'm finally getting to it as promised. Part of this also is to dip a toe back into the map code to begin with (although the backend and frontend are different animals here), so I know what I'm getting into.

I don't intend to bog down too much on map stuff and honestly I think a complete rework for 512 is not going to happen, but getting part of the way there would not be a bad idea at all.

So that's just a quick overview. I'm keeping the post short this week to start off the month breezy. But don't forget, summer's a great time to work on those games or spend a late night playing them. Enjoy it!
Any update on graphical filters and that sort of thing?
I still need a good syntax/format for filters. I've been stumped.
Sure looking forward to some mapping updates! :D
In response to Lummox JR
Lummox JR wrote:
I still need a good syntax/format for filters. I've been stumped.

Okay. Is there an ongoing forum discussion or anything about this? Where can I participate?
reworking the map saving code so that it preserves existing symbols whenever possible.

does this mean map saving and loading will be viable?
The peoples republic of china wrote:
reworking the map saving code so that it preserves existing symbols whenever possible.

does this mean map saving and loading will be viable?

What Lummox is talking about is DMM symbol table generation.

The current format for DMMs generates a unique symbol to represent a tile pop. A tile pop is a unique combination of /area, /turf, and movables within a single tile.

"aaa" = {/mob;/obj;/turf;/area}

Currently, the DMM saving behavior simply discards the old symbol table, then builds a new one. Since symbols are generated from bottom-left to top right, a single change early on in the map will cause cascading changes through the whole symbol table.

This causes problems down the line for users who want to use CVS systems to sync changes in map files, because those systems use diff tracking to keep changeset downloads small. A large number of symbol changes cascading through a map from a minor change is pretty catastrophic for that use case.


What Lummox is talking about with map saving is a change to the algorithm that attempts to preserve symbols as much as possible to prevent these symbol changes from cascading through the tile data for DMMs.
The peoples republic of china wrote:
does this mean map saving and loading will be viable?

Maps can't be saved in the .dmm format, because the format is incapable of capturing some of the nuances.
is there any way to make it possible? I know some libraries exist on BYOND that offer the functionality but they aren't really practical for any actual projects.
It is possible to save and load maps, they just can't be done saved in .DMM format.
Native saving is something Tom and I talked about before. It's something I'd like to do, but it's tricky to figure out exactly what info should be saved with the turfs.

Ideally it'd use a variation of our existing savefile format, so we have the savefile functionality already available, and the main benefit of having an internal save is that there wouldn't be soft code looping over every turf. But there would still be a need, I think, to save them the way that regular saving would work, which means looking for a Write() proc and calling it. (However with turfs it might be feasible to simplify when they have no Write().)
Looking forward to it! Keep up the good work.