Repository navigation
Conversation
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)
Keep the accepted grip angle and strike animation while using the visible left blade tip as the tile-selection hotspot. No version, README or changelog change is required because this completes the existing unreleased hand contribution without changing controls or data formats.
# Conflicts: # source/render/RenderManager.cpp
Use the actual striking-face axis, retain the accepted left-end cursor hotspot and reuse the digging wrist animation frame for frame. The README now describes the shared movement; no version or changelog change is required because this completes an unreleased visual feature without changing controls or data formats.
# Conflicts: # source/render/RenderManager.cpp
Retain the normal empty-hand wrist angle for both effects and synchronize the index-finger flex with all three yo-yo return cycles. The README now records the completed behavior; no version or changelog change is required because this refines an unreleased visual feature without changing controls or data formats.
This packages the accepted implementation without private development notes. No release version or changelog change is required for this unreleased contribution.
This packages the accepted implementation without private development notes. No release version or changelog change is required for this unreleased contribution.
This packages the accepted implementation without private development notes. No release version or changelog change is required for this unreleased contribution.
This packages the accepted implementation without private development notes. No release version or changelog change is required for this unreleased contribution.
…62408a1c296287d00f9e647306654deb35ca' into HEAD
This packages the accepted implementation without private development notes. No release version or changelog change is required for this unreleased contribution.
Author
|
The user has now confirmed successful in-game retests of the latest changes, including rejected construction clicks; the separately documented Windows-blocked automated probes are not claimed as passed. |
Replace the auto declarations introduced by this branch with explicit types, as requested in issue tomluchowski#42 and required by the project coding guidelines. No behavioural change.
This was referenced Sep 25, 2026
Rokk001
force-pushed
the
pr/dungeon-heart-combat-2026-09-22
branch
2 times, most recently
from
September 30, 2026 05:00
571eb80 to
84fd163
Compare
The generated probes of the heart combat, targeting, construction and demolition checks used auto for the check helper, iterators, viewers and results. They now use std::function and explicit types.
…in the build protection Describes what each heart override does, who may attack the heart and how health is saved, names the role of the heart object class and comments the half unit tile reach used for the footprint test.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Make the central dungeon heart the enemy-only combat target, with one saved health pool; protect its room floor from demolition/damage and its visible footprint from room/trap construction. Heart destruction uses the existing defeat and cleanup path; editor placement remains unchanged.
Prerequisites: #191 (room-area demolition, including its existing dependencies), #181 (rejected construction feedback) and #142 (standalone duplication fix). These are separate contributions, not additional features of this PR.
Review this contribution alone: 11 files. GitHub's default comparison includes 88 commits until the prerequisites merge; merge those separately and recheck the remaining diff rather than merging the cumulative stack as one feature.
Validation: this exact candidate passes 46 heart-combat, 361 duplication and 51 demolition checks. Its construction-footprint and input-dispatch probes compile, but Windows application control blocks execution (4551); no fresh pass is claimed for those runs. The complete fork previously passed 250 footprint and 745 dispatch checks, a Windows Release build and 32 resource checks. The enemy-discovery runtime probe remains Windows-blocked. No new game, multiplayer or Linux run was performed during publication.
The user confirmed demolition protection and subsequently reported successful in-game retests of the latest changes, including the construction-click follow-up; this is user verification, not an agent-run game test. Old saves retain their total remaining durability; new saves add an optional heart-health record and require this implementation to reload. No numerical rebalance or regeneration change.
Related to the construction-feedback portion of #4 only; this does not close that broader issue or claim to complete the failure-sequence requests in #5. No private documents, release-version or changelog change are included.