Skip to content

Align dungeon target selection with the visible cursor - #97

Closed
Rokk001 wants to merge 3918 commits into
tomluchowski:shaders-improvementfrom
Rokk001:pr/world-target-selection-complete
Closed

Rokk001 wants to merge 3918 commits into
tomluchowski:shaders-improvementfrom
Rokk001:pr/world-target-selection-complete

Conversation

@Rokk001

@Rokk001 Rokk001 commented Sep 8, 2026

Copy link
Copy Markdown

Align the selected dungeon tile with the visible pointing-hand cursor: ray-test the rendered wall height and floor instead of treating every target as the ground plane, and use the current GUI cursor and viewport coordinates consistently for hover, clicks and stationary feedback.

Depends on #94 for contextual selection feedback. GitHub's comparison includes its prerequisites until they merge: review the focused target-selection fix and recheck the remaining diff after their individual merges. This addresses pointer-selection behavior related to #6 without claiming that the broader issue is fully resolved.

Validation: Windows x64 Release integration compilation and runtime preparation passed. The extracted production tile-picking implementation passed 12,280 checks, including randomized rays and visible wall/floor targets. The user accepted the pointing-hand selection correction. No new manual game launch or other-platform runtime verification is claimed.

New TileVisual types for all the rooms, and tileset.cfg modifed to allow proper config of neighbouring tiles, for example for TileVisual::hatcheryRoom the code shall compute the neighbouring index e.g. 1010 and give an appropriate tile
Minor bug not allowing the destruction of rooms also fixed
Missing room meshes added, treasury tiles should now display ok
TileVisuals can now impose setting the position ofa creature diffrent than z=0
Now all ground tiles meshes should use Room.mesh
…k around celler or fight there when they are being dropped there
CMakeList.txt modfied due to paroj fixtures, all tests are now passed
tile info for debugging information -- seat, position, visualTileType, tileType, floodFillValue, floodfill bug introduced at 5409832
tomluchowski and others added 27 commits August 27, 2026 13:11
Spell out the types that the recent changes had left to auto
With rooms both claimable and destructible, fighters at the spearhead
still reach enemy rooms first and destroy them, so in practice little
changed. RoomsClaimableByEnemies now takes three values: 0 keeps the
historical behaviour (destroy only), 1 allows both, and 2 lets only
workers take a room, tile by tile — rooms in that mode are not
attackable, so fighters skip them when choosing targets, and damage that
bypasses target selection is dropped in Room::takeDamage. The dungeon
temple, which cannot be claimed, stays destructible in every mode since
destroying it is how a player is defeated.
The loadLevel message rebuilt the map with createNewMap, which only
recreates the tiles and trusts whoever started the connection to have
cleared everything else. Any path that broke that promise - pressing
Launch a second time from the same menu screen, or reconnecting after a
failed start - piled a second copy of every creature class, seat and
weapon onto the old ones. The editor then aborted while filling its
Creatures menu, because CEGUI refuses two menu items with the same name:

  CEGUI::AlreadyExistsException : Failed to add Element named:
  Adventurer to element at: EDITORGUI/Menubar/Creatures/PopupMenu4

Clear the map in the handler itself, the same way the newMap message
already does. Also make the editor load menu stop when the server could
not be started instead of connecting to whatever server was already
running; every other menu already returned there.
Let enemy workers claim room tiles (DK2-style), behind a config switch
"Exit OpenDungeons" did not fit the button well, and reads even longer once the
game is called OpenDungeonsPlus. "Exit to System" pairs with "Quit to Menu"
above it and says where the player ends up without assuming they know what an
OS is. The tooltip still spells out that it leaves to the desktop.

Claude-Session: https://claude.ai/code/session_01JiKh7f4nenYBTjhJfAGa3y
The editor's P shortcut refused to ask about any tile the client did not
believe looked like a wave portal, and that belief proved wrong: the check
compared against the tile visual, and the window then never opened at all,
with the "Point at a wave portal" hint shown even over a portal.

The client is only ever told what its tiles look like, never which room
covers them, so it has no reliable way to tell. The server does, and it is
also the only side that knows the waves. So the editor now always asks, and
the server answers with the waves, or with an empty room name when the tile
holds no wave portal, in which case the editor shows the hint.

Claude-Session: https://claude.ai/code/session_01JiKh7f4nenYBTjhJfAGa3y
…ttons


Say what the quit buttons do, and add one that actually exits
The editor offers two rooms of its own, a dungeon temple and a portal, so a
wave portal could only ever be edited in a level that already had one. Add a
third button for it, next to the portal, drawn with the portal's glyph in red
so the two cannot be confused.

Claude-Session: https://claude.ai/code/session_01JiKh7f4nenYBTjhJfAGa3y
…ments


Editor improvements: creature levels, help window, wave portal editing and more
Clear the client game map before loading a level into it
Embed per-monitor DPI awareness and maintain the verified OGRE 13.6.5 renderer patch required for context-safe window replacement, runtime GL options and correct fullscreen client geometry.

Validation: clean Release build, DPI and 3440x1440 fullscreen probes, three GL3Plus variants and the patch reverse check passed; version 0.7.1 remains unchanged because this is unreleased work and the project has no changelog.
Apply display, input, audio, gameplay, minimap, shadow and negotiated nickname changes to the running session while preserving rollback for failed window or input transitions and keeping the 3440x1440 navigation visible.

Validation: clean Release and Debug builds, packet tests, DPI, layout and GL3Plus probes passed; the user confirmed the reported resolution, fullscreen, cursor, flicker and navigation failures are fixed. Version 0.7.1 remains unchanged because this is unreleased work and the project has no changelog.
The spells tab put its ten buttons in a single row of 60 pixel squares running
out to x=700. The pane they live in is the window width minus the 200 pixels of
minimap, so at the 800 wide minimum window it is 600 pixels across, and the last
two spells, Weakness and the Eye of Evil, hung past its right edge where they
could be neither seen nor clicked. Only a window at least 900 wide showed the
whole row, and nothing said so.

The rooms tab solved the same problem long ago: two rows of 40 pixel buttons.
The spells tab now uses the same shape, five spells to a row, ending at x=300
with room to spare at any size the game accepts. The cooldown bar inside each
button now covers exactly its button too, instead of overhanging 20 pixels on
both sides, which with narrower buttons would have bled half way across the
neighbours.

The rooms tab had the tail of the same bug: the temple and portal buttons the
editor uses sat at x=570 to 690, past the same edge. They join the end of the
second row instead.

(cherry picked from commit 10db1cb)
Replace the auto declarations introduced by this branch with explicit types,
as requested in issue tomluchowski#42 and required by CLAUDE.md. No behavioural change.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants