It sounds like the biggest issue would be handling the showing/hiding of tiles that would obstruct your view of the player, but this is a separate issue.
This is a very specific feature request that, in the end, has a very small number of applications. You may need additional built-in features to implement this yourself, but this pile_map feature doesn't have to be built-in.
That's not an issue. That's for the developer to deal with. As I proposed in the last post, there could be an area (or possibly client) variable for displaying upper z levels.
And sure it does have to be built-in. The ability to do this on the developer end is very, very, very costly and ineffective in most scenarios. This could be a very "exciting" feature. It could effectively allow a three dimensional game WITH a proper z coordinate built in. Obviously it's built in already but it's currently rather useless for anything but map-jumping. | |
The ability to do this on the developer end is very, very, very costly and ineffective in most scenarios. The reason its costly is because, as I said, the developer "would be handling the showing/hiding of tiles that would obstruct your view of the player". Whether we need built in help to do that is a separate issue, but once that's done, this becomes easy. The problem with these types of feature requests is that there are a million different ways you could want it to work, so there's a good chance that the one way that the built-in solution would work wouldn't be what you're looking for. | |
Maybe you misunderstood. I was referring to showing multiple z layers at once. This can be "achieved" in one way or another already, but it's costly. It's also not very useful as anything other than a visual trick.
Displaying areas above particular players is a trick that's been used for ages, but it's not what's in question here. | |
This feature combined with your own collision checks would render PILE_MAP obsolete.
| |
No it wouldn't, because you're missing the best part of this feature. An actual z coordinate. As of right now, I'm working with someone on a project that's going to use pixel_z to display multiple coordinates. Now say I have a six tile high tower and I do a range() check on the bottom floor. Because I'm just stacking things on one level and we assume that all the levels are identical, range() is going to return everything on all six levels rather than just the bottom level. This makes pixel-based collision checks in such an environment extremely costly.
| |
Hiro the Dragon King wrote:
No it wouldn't, because you're missing the best part of this feature. An actual z coordinate. As of right now, I'm working with someone on a project that's going to use pixel_z to display multiple coordinates. Now say I have a six tile high tower and I do a range() check on the bottom floor. Because I'm just stacking things on one level and we assume that all the levels are identical, range() is going to return everything on all six levels rather than just the bottom level. This makes pixel-based collision checks in such an environment extremely costly. Give every atom an elevation var. Then override the Enter proc to make dense objects block movement only if they're on the same elevation as you. If you want to loop through objects on your level, do this: for(var/atom/a in view()) This is a minor issue. There is still the problem of how you'd define which map gets piled on top of another. And there's also the issue of how objects get shown/hidden to not obstruct your view. | |
Each of those issues have been addressed here several times. As I've said:
Areas and/or clients could be given variables that allow or disallow the viewing of higher (or lower; I can't think of a reason but someone will come up with one) z levels. For instance, when one walks into a building of multiple stories, one should be able to see inside only the current floor. The developer could set the area's variable to disallow the viewing of higher z levels and map the area to the building. Deciding how and which maps are stacked is easy. Only maps which are made to have multiple z levels in the map editor are displayed as having multiple z layers and the order is that of the editor, z=1 being the lowest. In the case of isometric maps, each map would be displayed as if it were layered in isometric mode. An object on z=2 will shown on z=1 as if it had pixel_z set to half of the world.icon_size's y dimension. As for current workarounds, there are workarounds to achieve this effect already, but they don't all play nice together and they don't really play well with other systems either, especially lighting systems. | |
Hiro the Dragon King wrote:
As for current workarounds, there are workarounds to achieve this effect already, but they don't all play nice together and they don't really play well with other systems either, especially lighting systems. Things don't magically work nicely together. A user-made lighting system would have to be designed specifically with this feature mind whether it's a built-in feature or a library that's doing the actual map stacking. | |
I just, you, no. Just no. There are ways to do everything. You can easily create your own directional system for objects, that doesn't mean that BYOND never should have put it in. Every single system can be done more elegantly, faster, and sometimes even better when they're built-in, but they can still be achieved otherwise. We get that, so stop arguing the same point on every feature request made. Feature requests are made to request features, not argue about why or why not they're needed. The feature isn't going to be forced down your throat and it isn't going to break compatibility. You can offer alternatives but stop arguing against features.
| |
I assume you're supporting this feature request because it's a feature you want to use. I imagine that you have a project that you can't make progress on until this feature is added, so I'm explaining how you can achieve this now, and why achieving this now is just as useful as a built-in feature would be.
There are billions of features that could be added to BYOND. Are you supporting ones you'd actually use? Or are you supporting this just for the sake of supporting it? | |
I have already progressed passed this but it would have been much easier and much more efficient with it. I support features I think are worth having. I don't however argue with people about features I'm not going to use.
| |
When you request a feature that would be useful to you, you're not necessarily requesting a generally useful feature. This feature would help with map stacking, but not the other way around. Also, such a specific feature as this one might satisfy your map-stacking needs, but not someone else's. In these examples the stacked layers are offset 32 pixels up from the lower layer, what if you want them offset 32 pixels up and right? A library can easily give you this flexibility, but I'm not sure that the built-in solution would.
I understand how this feature would be useful, it's just not practical as a built-in feature and I don't expect it'll ever be added. If this is truly something that people want to do we can work on a library (I'd be more than happy to help out) to handle this and make ancillary feature requests as needed. | |
In what examples? The isometric examples? It would be 16, not 32. And that was just an example. Besides, the purpose of the request is to bring true x,y,z coordinates to BYOND. You would handle offsets x offsets the same way you always do; with pixel_x. Offsetting the entire map would defeat the purpose of the coordinates.
Libraries are not the end all, be all that you think they are. If this were to become implemented, one would expect upgrades to o/view(), o/hearers(), et cetera. How exactly would you handle those with a library? P.S. If you're not supporting the feature and you don't think it'll ever be implemented, then why are you posting here? I'm posting ideas as to how it'll work. It's already been stated that there are workarounds and I've stated that I'm using some. So you're doing what? P.P.S. I understand what you mean now by up. Up AND to the right however is still a... no. Just no. However a variable to allow it to shift one tile in one of the four cardinal directions wouldn't be a bad idea for TOP_DOWN_MAP. | |
Personally, I'd request for DM to just be a much speedier language, which actually would enable us to make libraries for everything.
| |
What a coincidence, I was just about to make that request. (Not joking.)
| |
I understand what you mean now by up. Up AND to the right however is still a... no. Just no. I don't understand what you mean there. It's a more common perspective than you might think. P.S. If you're not supporting the feature and you don't think it'll ever be implemented, then why are you posting here? I'm posting ideas as to how it'll work. It's already been stated that there are workarounds and I've stated that I'm using some. So you're doing what? I'm trying to figure out why it's necessary to have this be a built-in feature. Personally, I'd request for DM to just be a much speedier language, which actually would enable us to make libraries for everything. I'm not sure how that relates to this. You'd have to change the Enter() proc to accommodate the stacked maps, but it wouldn't be much more complex than the default Enter proc (this additional complexity is also unavoidable). The process of stacking maps might be slow, but that's something that only happens once. People will tolerate one-time loading. | |
And I stand corrected. A variable that allows a shift in one of the eight directions would be warranted. That looks pretty neat, actually.
The reason is because it would open up a new door for gaming on BYOND. People said the same thing about isometrics that you're saying now. It's related because it would allow us to actually compensate for the overwhelming lack of features. Rather, most simple features are implemented. The more complex features are implemented in only the simplest way, leaving no room for using more advanced methods, which of course are very costly in soft-code. | |
I don't understand how this is costly in soft code. I would have no problem with this feature request if you said:
1. Here are some types of games this feature would open the door to. 2. Here's a demo of a good attempt to implement this in DM. 3. Because this is a useful feature (see #1) but is too slow to be practical (#2), we need this to be a built-in feature. (note: hypothesizing about potential slowness doesn't count) But I see very little of #1 and none of #2, so I'm not going to agree with #3. This is a summary of almost every issue I ever have with feature requests. Justify that it's useful and justify that it's not already possible (or that it needs some built-in help) and you have a good feature request. | |
Another way to do it is just to add the option to select whether this stacking behavior is used or not straight in the map editor. That way you could turn it on/off without leaving the editor or compiling and you'll also be able to set the pixel_z increment so that taller objects could be stacked properly.
...perhaps I should just make a feature request for something like that instead of hijacking this request, but the features are similar enough that I don't want to seem like I'm repeating a request.