Issues as of 0.4.9

[vi]

10a8fbb208da790db92000f9dd12bae2f2a2cf2d

1. Diving out still resulted in being near water, not above it. I remember this bug being fixed at least twice. Can't it just generate dive-in-dive-out location pairs once per depth and not rely on any calculation results to be matching for diving out to work correctly? I.e. only calculate locations where you can dive in (and where it leads to underwater), processing diving out just using table lookups, not coordinate calculations.
2. Some sprites are missing (e.g. scroll of divination).

[Smujb]

2 is known. As for 1, that's not actually possible on the current engine

[vi]

https://vi-server.org/pub/yapdbug30.mp4

Seed: 3945743078123 Depth: 7

[vi]

that's not actually possible on the current engine

Then maybe a fuzzing test can be written?

Level generator is run in a loop. For each generated level:

1. Assert that number of deep water tiles matches the number of light-from-above tiles. If applicable, also assert there are no more than one entry/exit occupying the same tile and that they don't match main depth staircases.
2. Iterate each deep water tile. Dive in there, then immediately dive out. Assert that we are back on the same deep water tile.

[Smujb]

This requires rapidly loading and unloading levels (yes, only one can ever be loaded at a given time) which will freeze up.

[vi]

Subissue 3.

The text for describing skill levels say "One point of strength per 3 points invested", but it seems that scheme is now simplified and it is now one to one. The same for Focus.

[vi]

which will freeze up

What do you mean? That level loader is buggy and if you keep on generating levels more and more it will eventually freeze up?

Or that loading and unloading levels would dominate CPU time, compared to checking diving bijection?

Or that this process would not stop and run endlessly, locking up the game?

[Smujb]

Loading a level takes 400ms on my device. Repeatedly loading and unloading will take forever and probably freeze up the render thread.

[vi]

Just turn off rendering at all for this mode. It is not intended to be a part of normal playing mode, just a development tool.

As soon as discrepancy found, it should output seed&depth, then exit. If everything is OK, just run forever. For 400ms I expect about 50k dives to happen if the app is running overnight. Not that much for a fuzz test, but better than nothing.

[vi]

Also freezing things because of just too much things happening it also a [latent] bug.

Such things can also affect old, weak and overloaded devices where everything is very slow and lag is everywhere.

[vi]

Subissue 4.

Difficulty selection is misaligned. May be caused by Power Saver mode

Subissue 5.

After falling down in Distant Well room, no bone remains.

Fortunately, deep water is present.

After a while I found out that I have the key for that door (I don't remember where exactly I picked it).

[vi]

Subissue 6.

Unless it's deliberate gameplay change, I don't see any "locked on target" mark for Sniper. Or is this part of Shattered is not yet or not intended to be ported?

[Smujb]

Nope, it's not intended. I'll have to fix.

[vi]

Also are Scrolls of Upgrade supposed to be fireproof like in Shattered?

[Smujb]

No, idk why they are

[vi]

No, idk why they are

Items that have constant quantity per run (SoU and PoS) are protected from accidental destruction in Shattered.

[vi]

Subissue 7

Hero steps into a recently discovered trap.

In Shattered hero routes around it automatically.

[Smujb]

So many subissues at this point you should probably create a new one. This is known and it's a bug with the map flags cache; disable it in development settings and you'll see this doesn't happen, but performance may be reduced.

[Smujb]

Reproduced your bones bug.

[Smujb]

So yep, I've added a way to enter seeds on debug mode so I can play other people's games.

[Smujb]

And the diving issue is not really fixable without some really ugly code. The game halves your x and y when diving, and places you in that location, and doubles for diving.

[Smujb]

If your x or y is an odd number on the surface you will not be placed on the right tile when undiving. (sorry issue closing was accidental)

[Smujb]

Eg: x is 13. Halved that's 6 (Java rounds down in integer division but the result is the same), so your x underwater is 6. When undiving on this same location, your x is 12

[Smujb]

There is no way to avoid this whatsoever without refactoring the level system to allow multiple levels to be loaded at once

[Smujb]

Why not have a list of x,y coords that each tile sends to? Because I'm simplifying here, and PD uses a 1d array to represent a 2d map, so to convert xy coords to a single int, the index of the tile in the list (how mob positions are handled as well), you need the level loaded.

[vi]

Maybe make each deep water location to be minimum 2x2 size? This way you'll at least appear within the same 2x2 square.

Or make deepwater a subarea of each depth, without stretching. Outside of that subarea there's just no deepwater possible and speed of moving underwater does not convert to double speed moving overwater.

---

Ugly hack idea: if after diving explicitly check if hero is inside a wall then jump to nearest water body.

---

But anyway internal ugliness of diving mechanic may present a problem when more features gets deviced, e.g. enemies/familiars that dive, underwater bombs, etc.

[Smujb]

Outside of that subarea there's just no deepwater possible

Again, this is two-way interactions between two levels. Not really possible.

Maybe make each deep water location to be minimum 2x2 size?

A nightmare to code into the current levelgen.

[vi]

Again, this is two-way interactions between two levels. Not really possible.

I don't understand. If underwater level is guranteed to be smaller than overwater level, diving out is trivial - just copy the coordinate. For diving in - if reusing coordinate for underwater level results in out of range thing then just don't dive in (and don't paint deep water there).

/ Note: I haven't researched into Pixel Dungeon code much, so maybe I don't know some issues /

[Smujb]

It's quite simple: The values have to be calculated on the fly as coordinates don't hold up between multiple visits to a level.

[vi]

What about this hack?

Ugly hack idea: if after diving explicitly check if hero is inside a wall then jump to nearest water body.

[Smujb]

I already made it check for walls and then place you on the nearest non-solid tile (older diving issues were more serious than this and had a different issue entirely). It shouldn't be possible to land in a wall anymore but it's still possible to land on regular water rather than deep water.

[vi]

Is it possible to land on a trap? Would it activate if so?

[Smujb]

No, as traps can't be in water. Deep water is always surrounded on all sides by shallow water and the calculation is only ever off by 1 space.

[vi]

Can it intersect with an enemy?

[Smujb]

Nope as a tile with an enemy is considered "solid"

[Smujb]

The remaining issue here, "hero doesn't route around traps" is now fixed indev. For now, disabling the map flags cache should prevent this ever happening.