No, the code was rewritten quite recently, between 0.3 and 0.4 build, with specific intention to allow for above ground z-levels. There is nothing “pseudo” about it. Below ground floor are mapped to z- layers and above ground floors are mapped to z+, where ground level is at z=0 layer, exactly how it should be.
This is one of the reasons why they don't want to include more of it; the system that Whales utilized is intrinsically faulty for the purposes that they would like to utilize it for, and thus must be written.
They are already including many new buildings relaying on the same system. It’s not faulty, it does what is supposed to do. There is no any difference whether new office tower will have a garage above or below ground. If one works, the other works just as well.
As for my logic, I would like to point that the claim that reasons not to increase utilization and those to continue current utilization are two completely different things. Your statement that "any reason to not have above ground z-levels is as good reason to throw underground levels from the game" would be exactly the same as saying "any reason to not use cars more is as good a reason to take away your current cars".
In a way, yes. You wan’t office tower to have underground garage, it makes the building more interesting, right? Then explain why do you not want church bell tower, would it not make church more interesting?
Just because a reason is valid to prevent further use of a system (in this case because said increase would not be worth the extra work later [1 bonus - 2 work = -1 total]) does not mean it is a valid reason for the removal of the system without a replacement (since the current implementation requires no extra work penalty regardless of if we remove it or leave it in, meaning the balance now favors leaving it in [0 negative - 0 work = 0 total vs 1 negative - 0 work = -1 total]).
Yeah, if it was not for huge contradiction, in that they are actually investing in the said system right now with all the new buildings being added. Those new buildings could have upper floors just the same as underground floors. It’s only a matter of drawing them on the map, or not.
To be fair, if I HAD been the one to write the current z-level code, I’d still think it was a well-intentioned but badly written buggy hack :P. Heck, I have that feeling about some of the code I did write before I’d really gotten a handle on the codebase, and it’s on my to-do list to clean it up (although at a lower priority than actual functional fixes/upgrades).
Can you point to when that change occurred, or what part of the code was changed? I don’t recall any large changes to z-level handling recently.
My bad, it wasn’t Whales’ code, but a quick check of git reveals that it came out approximately two months ago, which syncs it up either right before or right after the release of .2 (issue 191 and 204). Since then no issues that contain the text “z-level” have been present other then a small NPC fix and a small code cleanup, with the exception of someone’s submittal of a cleaned up version of LazyCat’s z-level code.
Assuming that the 0.2 tag is accurate, it looks like the partial z-level rewrite was about a week or two after 0.2 was released.
But, going back even further… a version from mid-June 2011 still has references to t_hole and z-levels, so it looks like the initial work was Whales (including, probably, the bug with monster corpses not falling).
Pull request 204 looks like an example of the sort of rewrite I was talking about earlier. It doesn’t seem to introduce any functional changes (by design, even), but it makes the existing system a little less awkward to work with, going forwards. Now we just need to see where benjamg is, and if he has time to keep working on it.
Interesting to know! Thanks for digging that up, i2amroy :).
The way you’re doing it for people doesn’t appease them.
Shut up about how “good it is” or “how good my mod is” it doesn’t matter. People have made up their mind.
They want to rewrite the whole z-level code. Implementing this hack is NOT worth the amount of time if we’re going to rip it out in a month. Maybe it adds a little to the game (IMO it doesn’t but it’s objectively more content) but it is going to be gone soon in favor of something better.
Which is funny, because there is nothing to re-write. Even if they make a whole new game from scratch this particular part of the code would stay the same. It’s just graphics, just a definition, like a collection of bitmap images, and there is no better way to store such data than two dimensional arrays.
Implementing this hack is NOT worth the amount of time if we're going to rip it out in a month. Maybe it adds a little to the game (IMO it doesn't but it's objectively more content) but it is going to be gone soon in favor of something better.
It’s only your blind fate in someone else’s hallucinations that makes you think it’s a hack. It’s not a hack, as I explained more than few times. It will be like I made it or it will not be at all. Mark my words.
You explicitly say that you would store three-dimensional data… in a series of two-dimensional arrays… with special-cased warp points between them. Rather than, say, a 3D array.
[quote=“Soron, post:53, topic:1229”]You explicitly say that you would store three-dimensional data… in a series of two-dimensional arrays… with special-cased warp points between them. Rather than, say, a 3D array.
O…kay. Moving along.[/quote]
No 3D arrays, your game can not make use of voxels. I was of course referring to individual levels. Are you going to draw/define them all at once in 3D? No, you will not, because you don’t have or need any vertical resolution in between z-levels. So naturally they will be defined in 2D arrays just like now. Whatever you do with your display code, graphic initialisation code for each horizontal z-level will be defined with 2D arrays.
What you do then is to layer them in another array, one-dimensional array (z-layer), and that’s how you get third dimension and multiple vertical levels, any or all of which you can then attempt to draw on the screen. If you look at the code you will notice that is exactly how it’s done, and how it should be.
Well, a set of 2D arrays contained within a 1D array is more-or-less the same as a 3D array, so that bit I don’t disagree with.
However, that’s not what we have at present. We’ve got a set of 2D arrays with some weird special-cased glue code, when what we really want is for the 3rd dimension to be treated similarly enough to the other two that we can eliminate the weird special-cased glue code.
[quote=“Soron, post:55, topic:1229”]Well, a set of 2D arrays contained within a 1D array is more-or-less the same as a 3D array, so that bit I don’t disagree with.
However, that’s not what we have at present. We’ve got a set of 2D arrays with some weird special-cased glue code, when what we really want is for the 3rd dimension to be treated similarly enough to the other two that we can eliminate the weird special-cased glue code.[/quote]
That does not change the fact you will still have each z-layer defined separately as 2D array, just like now. You don’t need to change any code relating to definition and storage of z-layers, if you want to DRAW multiple levels you simply need to extend your DRAWING code.
[quote=“LazyCat, post:56, topic:1229”][quote=“Soron, post:55, topic:1229”]Well, a set of 2D arrays contained within a 1D array is more-or-less the same as a 3D array, so that bit I don’t disagree with.
However, that’s not what we have at present. We’ve got a set of 2D arrays with some weird special-cased glue code, when what we really want is for the 3rd dimension to be treated similarly enough to the other two that we can eliminate the weird special-cased glue code.[/quote]
That does not change the fact you will still have each z-layer defined separately as 2D array, just like now. You don’t need to change any code relating to definition and storage of z-layers, if you want to DRAW multiple levels you simply need to extend your DRAWING code.[/quote]
Since the weird glue code for stairs is contained within the level DEFINITION and STORAGE codes, those codes by definition will need to be at least partially rewritten to replace that weird glue code with something that functions in the desired manner. (As well as the DRAWING codes, which will most likely need to be greatly rewritten).
What weird glue code, what exactly is the problem? What is “desired” manner, how is it different than existing one?[/quote]
The weird glue code is all the code currently related to stairs, z-levels, and how basements are defined. As for the “desired” manner versus the existing one, I refer you to this, which I think sums up the desired vs current debate rather well:
“Weird glue code” is your best description of the problem? You failed to point out anything even barely specific that is supposedly preventing you to achieve any of the functionality you desire. What file, what function are you referring to?
