Autojoining turfs

ID:260847
 
Dec 14 2009, 7:55 am
Proposed idea: get Lummox JR to implement his autojoining library in BYOND itself.

Specifying an icon and telling BYOND the icon is for autotiling (perhaps in the icon itself?) would cause the map editor to automatically set the states to whatever state type it is (whether it be 15-state auto-joining all the way up to 255-state auto-joining).

Reason: The map editor is pretty covered now, and such a feature should in theory be peanuts as all it involves is automatically placing and adjusting map instances as they are placed.
Dec 14 2009, 9:12 am
Android Data wrote:
Proposed idea: get Lummox JR to implement his autojoining library in BYOND itself.


I'd like to see this happen for just about all of Lummox JR's libraries. DMIFonts, SwapMaps, Regex, Autojoining, etc.
Dec 14 2009, 9:57 am
Android Data wrote:
and such a feature should in theory be peanuts as all it involves is automatically placing and adjusting map instances as they are placed.

How does the map editor know which state to use? The autojoining method you've selected will tell it which case is occurring at a tile, but how does it know which icon state gets drawn for that case?

The feature you're requesting would almost certainly require support for autojoining tiles in the icon editor (similar to how the icon editor has support for 4/8 directional icons). This feature by itself would be very handy. I always found the hard part to be keeping the images straight, not writing the code to figure out which image gets used when.

A couple of questions:

Would the feature be used often enough to justify it?

There are tons of ways you can handle autojoining tiles (2 state, 16 state, 64 state, 256 state). You name it, there's probably a use for it. Which methods get implemented?
Dec 14 2009, 10:45 am
In response to Forum_account
Forum_account wrote:
How does the map editor know which state to use? The autojoining method you've selected will tell it which case is occurring at a tile, but how does it know which icon state gets drawn for that case?

The system automatically checks for turfs/objs with the same icon next to it, and changes their icon_state depending on which level of autojoining was selected. It does not specifically care if the icon_state is present in the icon.

The feature you're requesting would almost certainly require support for autojoining tiles in the icon editor (similar to how the icon editor has support for 4/8 directional icons). This feature by itself would be very handy. I always found the hard part to be keeping the images straight, not writing the code to figure out which image gets used when.

Support in the icon editor is not necessarily needed once you know which states are used in which circumstances. Some support would be helpful, but I'm not getting my hopes up.

Would the feature be used often enough to justify it?

I'm actually requesting the feature on behalf of someone else, who isn't that good with programming but is good with icons and mapping. He'd love to have a way so he can reduce the hassle needed for him to implement such a feature himself and he also wants to see his work in action within the map editor itself without even running the game.

There are tons of ways you can handle autojoining tiles (2 state, 16 state, 64 state, 256 state). You name it, there's probably a use for it. Which methods get implemented?

How about "all of the above"? It shouldn't be that difficult to do: the pseudo-code (in the form of Lummox JR's original library) is already present, and he is more than qualified to write such a system.
Dec 14 2009, 1:00 pm
As a more general case, being able to specify code that would run specifically for the map editor would be nice. Obviously not a small request, though.
Dec 14 2009, 1:27 pm
In response to Garthor
Garthor wrote:
As a more general case, being able to specify code that would run specifically for the map editor would be nice. Obviously not a small request, though.

This is a fantastic idea, and I'm for it.
Dec 15 2009, 3:27 am (Edited on Dec 15 2009, 3:41 am)
In response to Android Data
Android Data wrote:
The system automatically checks for turfs/objs with the same icon next to it, and changes their icon_state depending on which level of autojoining was selected. It does not specifically care if the icon_state is present in the icon.
Support in the icon editor is not necessarily needed once you know which states are used in which circumstances. Some support would be helpful, but I'm not getting my hopes up.
I'm actually requesting the feature on behalf of someone else, who isn't that good with programming but is good with icons and mapping. He'd love to have a way so he can reduce the hassle needed for him to implement such a feature himself and he also wants to see his work in action within the map editor itself without even running the game.

Without icon editor support this feature would only help the people who already have a good understanding of how it works. Your non-programmer friend isn't going to understand what state 237 should represent without some support for this feature in the icon editor.

How about "all of the above"? It shouldn't be that difficult to do: the pseudo-code (in the form of Lummox JR's original library) is already present, and he is more than qualified to write such a system.

The problem is that the complexity can grow depending on the developer's needs. For example, 256-state autojoining typically means that you have a distinct image based on which of a tile's 8 neighbors are of the same type. Each neighbor is either of the same type or not, so these two possibilities for the 8 adjacent tiles gives you 28 = 256 states.

What happens when you want to have transitions between many tile types? You not only need to know if an adjacent tile matches types or not, but you need to know what type it is if it doesn't match. If you have three types of tiles (ex: water, sand, and grass) you now have three possibilities per neighbor. 38 = 6561 states.

Considering how the problem can grow, a developer-implemented solution is probably best. This lets the developer place the icon states in whatever files they want and name them however they want.

It would be handy to see how things look in the map editor, but [link] suggests a better way to handle it. Since the map editor is part of the complete development environment, if you can edit the map you can run the game to see how things look. There will always be some features that cannot be run inside the map editor (line of sight, screen objects, weather or lighting effects, etc.) so it's probably best to find an easy way to preview sections of the map by running the game.

Edit: A handy feature related to the icon editor support for this would be support for "sub-icon states". Similar to how a directional icon state can have 4 or 8 states to it, it would be nice to be able to define an arbitrary number of sub-states.

For example, if you have 5 different grass icons to make things look less tiled, instead of 5 separate icon states you could have a single icon state with 5 sub-states. This could also be used for autojoining turfs, numbers, or anything else that clutters up your icon files.
Dec 15 2009, 4:35 am
In response to Forum_account
Forum_account wrote:
Considering how the problem can grow, a developer-implemented solution is probably best. This lets the developer place the icon states in whatever files they want and name them however they want.

I concur. While autojoining is useful, the method favored by myself and Pmikell before me is just one way of doing it and it doesn't cover all cases. Also, if you expand it to deal with other autojoining types (like 161-state, for instance), it then becomes necessary to explain those to the end user, who might simply find the whole thing confusing.

I like Garthor's suggestion in [link], though I don't think it's feasible at this time since to interpret a proc you'd basically need to spawn a limited server and then you'd need to know how to translate its results back into map instance variables. It does bring to mind one workaround though: You could build a tool to read a .dmm file and run your proc, and then spit a .dmm file back out after its turfs have been modified (provided the result is still .dmm-compatible).

Lummox JR
Dec 15 2009, 6:24 am
In response to Lummox JR
Lummox JR wrote:
It does bring to mind one workaround though: You could build a tool to read a .dmm file and run your proc, and then spit a .dmm file back out after its turfs have been modified (provided the result is still .dmm-compatible).

Lummox JR

I made a tool like this for the development of Survival. I believe the tool itself doesn't support overlays though. When I get home from work I can take a look and see.

Edit: I have the files here. I took a look and all I used was a general purpose AutoJoin routine and Iain's fabulous dmp_writer.

An example might look something like (requires the above library):
turf
    proc
        AutoJoin()
            // let's do our autojoining logic here!

world
    New()
        ..()
        sleep(10)

        world << "Autojoining..."
        for(var/turf/T in world)
            T.AutoJoin()

        world << "Writing to DMP..."
        var/name = "newmap-[world.realtime].dmp"
        var/dmp_writer/D = new()
        D.save_map(locate(1,1,1), locate(world.maxx, world.maxy, world.maxz), name, DMP_IGNORE_PLAYERS)

        world << "Process complete! Joined map written to '[name]'!"

        Shutdown()


Basically I would have this as a separate file in my environment that is normally unchecked (not included). I would do a bunch of mapping work, then I would include this file, and run the world. It would automatically load up, generate my new map file, then shut back down. I then uncheck this file again, and I can include the new map and run the game - bam, autojoined turfs.

This is also useful for doing things like randomizing your grass/dirt/etc. to add little variations to the map.

I've suggested the same thing with being able to run DM code within the map editor, and I'd still love to see that functionality at some point in the future - however for now this does provide a hackish workaround for the problem.


~Polatrite~