Add a MAP_EDITOR define when BYOND is compiling for the purposes of the map editor

ID:2831057
 
Nov 2 2022, 8:32 pm
Applies to:
Status: Open
Issue hasn't been assigned a status value.
In SS13, mapper quality of life is a very high priority for us.

Sometimes atoms have an icon that is more complicated and generated at runtime. For these, we try to intentionally set icons of these atoms to ones that look good from the map viewer, then set the icon later on. This works out fine most of the time.

However, there is a specific case I am currently hitting where a turf that we generate a lot of, ore turfs, has a different runtime icon to its map editor icon. This is because the icon that we set it to at runtime is much easier to manipulate, but looks terrible on its own in the map editor. We have a huge amount of ore turfs, and so the process of setting `icon = new_icon` is non-negligible. This means we have to make a tradeoff: do we accept the worse performance for the sake of mappers, or do we fix the issue and make the mapping experience worse?

It would be nice to not have to make this decision at all and instead simply:

#ifdef MAP_EDITOR
icon = 'map_editor_icon.dmi'
#else
icon = 'easily_manipulable_but_on_its_own_ugly.dmi'
#endif
Nov 2 2022, 8:35 pm
+1
Nov 2 2022, 8:51 pm
Would be nice if the define was set to a value such as BYOND or DREAMMAKER in order to have all the different mapping tools be able to specify a unique value allowing us to distinguish them apart.
Nov 2 2022, 9:19 pm
I'm reaffirming myself the define is the best route for this rather than something like map_icon since I recently added pixel_x/pixel_y to the atoms in a way that is only important at runtime, and is making the mapping experience worse.
Nov 4 2022, 5:52 pm
Lummox and I discussed this some time ago in discord:

https://discord.com/channels/725444629172060262/ 807452890331086858/964728532066525206



While my suggestion was deemed wildly infeasible, I'd like to see something a little more baked in than a preprocessor. It being set to a preprocessor doesn't really make a ton of sense because you aren't compiling the code differently, the editor should be storing some kind of database of alternate atom appearances, while still having the on-map values be editable for instances.

I think the best solution is a library that can be passed around independently of source code that contains everything you need to map, with none of the code required to compile the game. Preferably, there would be an editor.rsc and a runtime.rsc package, and maybe separating the map from the DMB would be a saner workflow as a whole.