[Neus]

Additions:
- Location Saving; The mapping environment will save the location you were last at to make testing maps between adjustments easier.
- Turf click: Clicking a turf will show its icon_state, y_end (for cliffs and buildings), autojoin_elevate, and x,y,z coordinates. This is useful if you have any issues with autojoining.
- Autojoining; Support for 47 state autojoining. Essentially this means that you can avoid the busywork of setting up icon states exactly as you want them by letting the game join with adjacent tiles for you.

You can see an example of this in the autojoin testing map and the mountain path map. (To get to them, compile the environment and note the order of the 'loading [map].dmm', then use set-z to go to the z level that matches its order. IE, if autojoin testing.dmm is third in the list, use set-z 3.)

You can also check the respective .dmm files to see how they're setup.

General Autojoin Guide:

- You do not really have to do anything special to make autojoining work. The default behavior is likely fine for most cases. However, in the event that you want to change the way a certain turf joins with other tiles, you can make a new definition (DO THIS IN #New Stuff AND NOT IN THE DEFAULT AUTOJOIN FILES.) and change them accordingly:

• t_type - When set to a path type (IE, /turf/autojoin/my_thing), this turf will autojoin towards adjacent turfs of that type. By default, this is used with cliff type autojoin tiles if there are any walls they should join with - this allows them to 'smooth' into vertical sections of the wall.
  
• aj_paths, aj_walls, aj_terrain, aj_cliffs, aj_building, aj_roof - When set to 1, this turf will autojoin with any other adjacent turfs of that specific type. For example, terrain type autojoin turfs have aj_walls, aj_paths, aj_building, and aj_roof set to 1 by default - this allows the terrain to continue uninterrupted when it encounters these tiles. (Otherwise, they would not join, and you would have 'edges' around these turfs, which looks quite bad.)
  

Autojoin Turf Types:

• paths - These are generally intended to be paths. Usually it's a good idea to utilize an icon state with transparency so that when you place it on the map, the tile below it will show through.
  
• walls - These are walls that border the tiles they occupy, which are dense and opaque. Their autojoin_elevate is 1 by default so that front-facing cliff walls will work with them.
  
• terrain - This is the generic terrain that covers the ground. By default, it will join with walls, paths, building, and roof type autojoin turfs (so that it looks like actual ground and you don't get odd edgiing around those turfs). By default, these are non-dense, however special directional density and global density can be setup using various procedures (though, you generally don't have to worry about this.)
  
• cliffs - These are essentially 'front-facing' walls like the edges of a cliff. They are dense, but not opaque. They generally have a t_type set to the wall autojoin turf that they're meant to 'fall off' from, or for special instances such as cliff walls from terrain elevation differences, those terrain turfs instead. They also will not join with other cliffs of the same type unless they both end on the same y position (to show things like jagged cliff edges or multiple layers of depth, etc.)
  
• building - These are buildings. They function similar to cliffs in that they do not join with other turfs of the same type unless both 'rows' end on the same y position. Their autojoin_elevate is set to null, meaning that any terrain that will join with it, will still join with it regardless of its elevation. (For example, if you wanted to put a building on a hill made of high elevation autojoin terrain.)
  
• roof - These tiles are the rooves for various buildings. Just like buildings they have autojoin_elevate of null, for the same reasons. Note that you can set the color of certain roof types by modifying its color variable to a hex value or a color matrix.
  

autojoin_elevate:

- Autojoining supports a variable called autojoin_elevate (default of 0). This determines the joining rules of other autojoin turfs, even those of the same type, that have different elevation. cliffs, by default, are treated as having 1 elevation higher than their actual autojoin_elevate var for their specified t_type (this is so things such as terrain will join with them properly).

There are only a few times you may need to worry about this variable. Its primary purpose is to support same terrain turf stacking (such as in the mountain_path.dmm map). If you are using elevated turfs along with cliff walls, just make sure you use the same autojoin_elevate on each level. IE, if you have a default terrain turf, and want to add cliff walls, simply leave the cliff walls at the default value as well. Essentially, simply use the same autojoin_elevate value for the cliffs as the terrain tile they will end on. (You do not need to take into account the additional +1 given to the cliffs for t_type.)

Tilesetter:

- Generally, if requested, I will try and convert existing tiles used in the game to the autojoin format for the mapping environment. If you want to do this yourself, for some reason, you can use a program called Tilesetter (available for free here: https://www.tilesetter.org/ ) to do so. (Note: Please only use resources which are freely available for use or that you created yourself. Please do not use things such as RPG Maker tilesets, unless the author specifies they are free to use.)

You can find more information on how to use Tilesetter on the website. Once you have a working blob set, select all of it (starting from the top left of the very first tile, to the bottom right empty tile directly below the bottom right most tile. If you select more than this, it will not work.) and export it into .png format.

Then, create a new .dmi file. Uncheck 'use size from file', make sure the DMI Size is 32x32, and click Graphic -> Import. Select the .png file you just exported. Once this is done, save the .dmi file and close it.

In the mapping environment, use the verb 'covner-from-tilesetter47'. Select the .dmi file you just made. You will then be prompted to save the converted .dmi file (you can simply overwrite the .dmi file you selected, or save it to a new icon, whatever you prefer.) This new .dmi will have all of its states automatically and named for use in the autojoining system.

From there you can simply set your autojoin turf's icon to this .dmi and all should work as intended.

Final Notes:
- If your autojoin turf icon features transparency in one of its states, there is some behavior regarding the map editor that you should be aware of. If the icon_state of the turf you are placing completely fills the 32x32 icon space, it will replace every other turf in the tile you place it on. This is normal and perfectly fine behavior if every icon_state will be the same.

If you have, for example, a situation like dark_forest's icons, where there are things such as corners that show the tile underneath of them, then you will want to make sure the icon_state that you are placing them down with has some transparency as well. If you look in icons/autojoin/autojoin_terrain_darkforest.dmi for example; I have added an icon_state called 'e1' that features a hole in the middle.

When you place an icon that is not fully covering 32x32, such as this state, the map editor will add the turf below it to the newly placed one as an underlay. However, the turf underneath of it is only an underlay; it will not, for example, autojoin with other turfs, etc. Its appearance will not be changed. This may cause some some problems when you are layering these turfs.

If you need an underlay to have a specific icon_state, you will have to right-click that turf and set it manually. This should generally not be a huge issue, but is something to note if the map layers get complex.

- You can add icon_states to the autojoin icons freely, such as for the above example, and you can set the icon_state of autojoin turfs you lay down to anything (such as the above) and it will still autojoin properly. Do not, however, modify the existing states in the icon file.