Features & Bug Fixes with no workarounds > Feature requests with workarounds

Bravo1 wrote:

This technically doesn't have any soft code workarounds. The best you can do as a workaround is to edit the pixel_z of every single turf you want to stack after placing it in the map editor. If you have anything more than a few small rooms it makes mapping incredibly tedious and time consuming.

To stack one z level on top of another, create objs on the first z level that represent the turfs on the second z level (make their icon, icon_state, layer, density, etc. all match) and set their pixel_z to 32. Then override the Enter proc to consider collisions with these objects only when the mob's elevation matches the obj's elevation.

This isn't difficult, CPU intensive, or much of a stretch of how BYOND works. Things like this are the reason why you can override Enter().

True, but the mapping of buildings, especially in isometric will become incredibly difficult as you'd be looking at a mass of ground level objects that will auto-adjust to their heights with New(). Either that or you'd have to create subtypes for each building block that matches the initial pixel_z requirement.

I don't think it's difficult at all to work around this, it's just that the only possible workarounds are either incredibly long-winded, requiring you to use up a ton of time which could be spent elsewhere, or would cause the map to look incredibly odd while you're building it.

It's not that a work around isn't possible, it's just that the viable workarounds aren't much better than the initial issue.

Status: Resolved

A minute ago BYOND was way too slow to handle this and it absolutely had to be a built-in feature. Now we have two solutions. We're on a roll, what feature do you want to tackle next? :-)

I already told you that we had a system for it. The "solution" still doesn't account for mapping. Our solution is tedious but manageable. Your solution is easier but not so manageable.

I also did not say that BYOND was too slow to handle it. I said that BYOND was too slow to handle the other functions that go along with it. range_3D() is simple enough, but view_3D() is another story entirely. We are working to get around that limitation but we're finding that every different situation needs a different workaround instead of just using view_3D().

Yes, but it's made more tedious by either having to either manually edit pixel_z or create new objects for each layer. Doing what you do which was proxies, or just having world/New() move everything from every other mapz and move it to the correct place on the the first map, either one is made difficult by not being able to see all of the layers at once. Either way, it's an issue.

Forum_account wrote:

http://files.byondhome.com/Forumaccount/map-stacker.zip

Using pixel_z (more like pixel_y) seems like a bad choice for a flat game world, it may help simplify hit detection, but can cause some serious visual fails; like moving your character completely out of view (which could be accounted for with client.pixel_z, but that causes other problems). It will also cause o/view() related problems, and it would cause somewhat flunky movement behavior if you actually implemented it into gameplay elements like stairs or ladders. It also makes it difficult to get an accurate in-game view of the map from DM's map builder; Though, that's probably going to be the case with any non-built-in implementation.

Elevation based opacity doesn't work. Though, that's partially due to a BYOND bug with opacity on invisible objects.

Presumably, as seen in the original post here, you would want to be able to see the entire exterior of the building while outside.

Running your if(!turf) checks in stack_map() seems rather pointless. Those situations should always return a turf. Assuming you were attempting to prevent the game from pointlessly duplicating "empty" tiles, you would want to check the turf's type against the default. Though, that would skip any "floating" objects, without another minor change.

Also, you would probably want to do some kind of cleanup (location nulling for non-turfs) after duplicating the layers. Since having multiple copies of the same objects could pointlessly bog down multiple aspects of the game.

Kaiochao wrote:

Forum_account wrote:

I'm not sure why mapping is such a problem. In the example I posted you make maps how you normally would and they're stacked at runtime. If you want to define a 30x30x3 block of turfs, you have to place 2700 turfs in the map editor. Placing 2700 turfs on the map is tedious but there's no way around it.

Hiro, I'm curious how your solution makes mapping easier. Care to explain?

This is the mapping method that I used for the examples I posted. However, this leaves all those Z levels completely empty in the end, which may eventually be a problem.

You can make the maps on separate z levels, compress them into one z level at runtime, then save the result.

I guess it depends on the kind of environment you're making. If you have a generally 2D map with a few elevated platforms, I'd just deal with creating the map as one z level initially. If you have a lot of multi-floor buildings, it'd be easier to map them as separate z levels.

Bump.