Z-levels - organizing work

[12doze12]

Any help you need or discussion about what to do and how to do it feel free to create a topic for it ( unless this is it ), I will gladely help, I just want exactly 0% of the bounty.

[12doze12]

[quote=“Frostwood, post:20, topic:8935”]No interest in the bounty…

but doesn’t it pull in the adjacent maps just fine? Can’t you simply extend that up and down?

Having looked at the code for experimental-Z-levels mod, its not that simple. A lot of code assumes there is only one z-level, and trying to change one thing is going to break a lot of things, until you code everything that’s broken to work with multiple z-levels, that’s before you can even test it.

There is also the problem of how much cpu power extending z-levels is going to take-in some parts of the game there a noticeable slowdowns, from even simulating one z-level. Maybe how many z-levels the game simulates should be in the options.[/quote]

We could separate z levels so the reality bubble only includes 1 z-level at a time. One question tough, will these z levels be like df? in which you press a key and you can change the z-level of the display or is it going to be static always showing the z-level of the player? Using df like z-levels would really only be useful to see how high a building is …

[MormonPartyboat]

We could separate z levels so the reality bubble only includes 1 z-level at a time.

From what I understand, unless something is in the reality bubble, it doesn’t exist as far as the vast majority of game systems are concerned. Expanding the reality bubble to include more than 1 z-level is the first thing to tackle, because without it you can’t - say - look up or down because those levels simply aren’t there until your character changes their z-level and the new floor is loaded.

[12doze12]

[quote=“12doze12, post:22, topic:8935”]We could separate z levels so the reality bubble only includes 1 z-level at a time.

From what I understand, unless something is in the reality bubble, it doesn’t exist as far as the vast majority of game systems are concerned. Expanding the reality bubble to include more than 1 z-level is the first thing to tackle, because without it you can’t - say - look up or down because those levels simply aren’t there until your character changes their z-level and the new floor is loaded.[/quote]

But that is if we want z-levels like in Dwarf Fortress, I don’t know to what point looking up or down is that useful at least for now, sure someday we might have not only multi z-level buildings but also multi z-level terrain.

[jcd]

But that is if we want z-levels like in Dwarf Fortress, I don’t know to what point looking up or down is that useful at least for now, sure someday we might have not only multi z-level buildings but also multi z-level terrain.

But proper z-levels mean that zeds can spot you even if you are on a 2nd floor window if there is line-of-sight to them.
DF already implements this (eg. archers shooting arrows to enemies from above)

Anyway, the cpu needed will be more than what is now (more calculations since we will be having to not only calculate simultaneously what happens in every z-level inside the bubble, but also interactions between these)

Hopefully all of this won’t be too many cpu cycles, since most z-levels other than the ground will be mostly empty (unless we are talking modern urban area)

Also calculations for z-levels that cannot interact with the current (no line of sight or sound connection between the two) could be ommited. (besides 3d pathing)

No matter what happens though, optimization is secondary to initial implementation.

[Coolthulhu]

Anyway, the cpu needed will be more than what is now (more calculations since we will be having to not only calculate simultaneously what happens in every z-level inside the bubble, but also interactions between these)

Most of the time this one will probably not be a problem. Most of the stuff on the map doesn’t interact with anything except creatures and caches.

Most calculation penalty will happen on map load, because everything will need to get cached.

[kevin.granade]

The only problem I see with Z-levels not already posted, is that once you have z-level buildings, people are going to want z-level cars, so there death mobile can be a 4*4 tower into space. Also, if you can climb walls as a spider, people will want to be able to be spoderman (https://www.youtube.com/watch?v=9MQmHQh2Jlc), ans all sorts of shenanigans will come from there.

While features like that are desireable, they’re out of scope for the kickstarted bounties. Others can feel free to post bounties for them though.

[freezerbunny]

I may or may not return to claim this bounty.

Possibly…

[Coolthulhu]

I started working on the Z-levels.

I now fully understand why did it kill devs in the past.

The biggest problem is that it’s all a giant, intertwined structure of 2D code. There’s no easy way to do it part-by-part and split it into incremental updates.
When I added Z-levels in one place, it suddenly became required in 200. And substituting g->u.posz() in those places could result in incredibly evil bugs later on.

I still have hope that I can do it.

[Frostwood]

[quote=“Coolthulhu, post:29, topic:8935”]I started working on the Z-levels.

I now fully understand why did it kill devs in the past.

The biggest problem is that it’s all a giant, intertwined structure of 2D code. There’s no easy way to do it part-by-part and split it into incremental updates.
When I added Z-levels in one place, it suddenly became required in 200. And substituting g->u.posz() in those places could result in incredibly evil bugs later on.

I still have hope that I can do it.[/quote]
That is what I realized when I tried to look at implementing the code piece by piece. Then there is trying to figure out where the code ends and begins. There is map_load, then map_loadn, then finally load_submap(if I remember correctly), and everything calls everything. So therefore you have to change everything at once.

[Angle]

After I finish the mapgen rewrite, I could join you if you’re still having trouble.

[Coolthulhu]

After I finish the mapgen rewrite, I could join you if you’re still having trouble.

A manager went to the Master Programmer and showed him the requirements document for a new application. The manager asked the Master: "How long will it take to design this system if I assign five programmers to it?"

“It will take one year,” said the Master promptly.

“But we need this system immediately or even sooner! How long will it take if I assign ten programmers to it?”

The Master Programmer frowned. “In that case, it will take two years.”

“And what if I assign a hundred programmers to it?”

The Master Programmer shrugged. “Then the design will never be completed,” he said.

There will be enough work after the first phase is done - you’ll probably have the entire 3D mapgen issue to work on.

The part I’m working on right now requires designing more than writing. It would be kinda hard to divide this into pieces.
I need to untangle this thing without breaking it, because I can’t send a colossus that modifies 30% of game code as a PR.

It’s the kind of code that everyone loves the most - low level pointer operations, array indexing, 3D partial array copying. Took me about a day to understand how I want to do this and I just realized I’ll have to throw away the results of last 6-8 hours of work.

[Angle]

Mmm, fun. Well, if you want help debugging, I can try and help with that at least.

[jcd]

[quote=“Coolthulhu, post:29, topic:8935”]The biggest problem is that it’s all a giant, intertwined structure of 2D code. There’s no easy way to do it part-by-part and split it into incremental updates.
When I added Z-levels in one place, it suddenly became required in 200. And substituting g->u.posz() in those places could result in incredibly evil bugs later on.[/quote]

is cleaning and sanitizing the 2d code, before starting to mess with anything 3d worth considering?

[Coolthulhu]

is cleaning and sanitizing the 2d code, before starting to mess with anything 3d worth considering?

It’s not really not-clean, it’s just that it’s all related. Most functions form “families” where changing one requires changing the rest. For example, if you add a ‘z’ parameter to ‘move_cost’, you need to update all functions using it (so that they can pass some ‘z’ argument) and all functions used by it (so that it doesn’t just drop the z and do something stupid).

I think I have managed to isolate some code that will form a nice first phase of z-level migration, so maybe it’s not as bad as I first thought.

[jcd]

ah, i see…

Would it be possible to overload the functions then, so that for example both move_cost(x,y,z) and move_cost(x,y) are valid?
Then you’d be able to debug it in limited situations before going for large scale.

PS. I don’t know c++ in a very great depth, so i might be terribly wrong or missing something obvious.
Either way, you seem to know what you are doing
gl!

[Coolthulhu]

[quote=“jcd, post:36, topic:8935”]Would it be possible to overload the functions then, so that for example both move_cost(x,y,z) and move_cost(x,y) are valid?
Then you’d be able to debug it in limited situations before going for large scale.[/quote]

That’s what I will have to do, though it WILL lead to some stupid bugs. I already wasted 2 hours trying to find out why isn’t my map saving: it was trying to save only the segment on 0 z-level, because I made such an overload.

Additionally, the part of map code related to submaps is arcane.

[Angle]

Funny, I wasted like two hours the other day on my own saving related bug.

[Trihook]

I was just making some z-leveled ascii maps for cata and I thought I might link them, maybe you could make some use of them. They’re not .json map files, just ascii drawings, so you’d have to convert them to something use-able. Not sure how much it will help, but who knows eh ^^

http://rghost.net/6b6GW9kwG

[Coolthulhu]

I have to share, because I’m both 200% mad and 200% glad.

I am at the creature tracker part of the update (nearing the end of https://github.com/CleverRaven/Cataclysm-DDA/issues/6818 ) and I just fixed an extremely evil bug I created.
I forgot an overload for monster::setpos(x,y,z), but everything compiled just fine. Later on I encountered very strange monster position behavior and even rebuilding the monster location cache wouldn’t fix it - it would constantly re-break. Turns out monster::setpos has a 3 argument overload, except the third argument isn’t ‘z’, but “don’t update the monster in the tracker, because it is not spawned yet” boolean.

Took me 6 hours or so to find it and now I fully understand why in Java, C# and similar languages casting ‘int’ to ‘bool’ needs to be explicit. I don’t understand why didn’t the compiler warn me of it despite -Wall and -Wextra.

On a side note: hard stuff from the first phase of z-level update is mostly done by now. Once 0.C is out, I’ll be PRing parts of the update that don’t depend on other stuff.
What is left is mostly tedious replacement stuff that won’t require much mental effort.