Conversation
use command enableZPrePass and then pressCapsLock
….5.0 second encounter
….5.0 third encounter
….5.0 fourth encounter
….5.0 fIfth encounter
….5.0 sixth encounter
….5.0 seventh encounter
….5.0 eight encounter
….5.0 nineth encounter
….5.0 tenth encounter
….5.0 twelveth encounter
…NotificationType::animatedObjectSetWalkPath
…rgin ( five percent) not exactly last point
…frag Channel0.png
…ght closed doors) fixed
… around the prison
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
colourizeMaterial() names its colourized copy by appending the colour
suffix to the material it was given, and colourizeEntity() recovers the
original material by cutting the name at a "##" separator. The separator
went away when the Z pre-pass work commented it out of the append (the
outliner and brighter suffixes use "##" too, and a generic find("##")
strip would eat theirs), so every recolour has been cloning the already
colourized material and growing the name by one more suffix:
WoodBridge, WoodBridgeColor_1_, WoodBridgeColor_1_Color_2_, and so on,
one fresh Ogre material per refresh.
A tile that rarely changes colour hides this well enough. Claiming
enemy squares walks right into it: every handover refreshes the tile
and its neighbours, the chain of clones grows by one link each time,
and a few claims in, the cloned material no longer renders - the
square's bridge planks disappear from the map while the server keeps
saying, correctly, that the bridge is there. The claim-a-bridge level
from the review of the square-by-square claiming change shows exactly
that: bridge tiles wink out one by one as the enemy workers dance.
Bring the separator back as "@@", which nothing else uses, so the
recolour replaces the suffix instead of stacking it and never touches
the "##_Outliner"/"##_Brighter" names: colourizeEntity() only ever
serves tile and bridge meshes, and the set of materials stays bounded
at one per (material, seat colour, dig mark, vision) combination.
Verified on ForgottenTreasures2 with enemy workers claiming a bridge:
unfixed, five claimed squares lost their planks within a minute;
fixed, all 27 squares stay drawn through 14 handovers, recoloured to
the claimer's colour, and the material name stays WoodBridge@@Color_2_
instead of growing without bound.
Claude-Session: https://claude.ai/code/session_014hrk8PiEUMgjYJnTxLF2PU
…er-tile Claim bridges square by square instead of all at once
…material-leak Stop tile recolouring from stacking material clones until tiles vanish
"Quit Game" in the in-game options never quit the game: it dropped the player back at the main menu, which is misleading enough that it came up in the interface review (issue tomluchowski#6). There was no way to leave to the desktop from inside a game at all short of the window manager. The button is now labelled "Quit to Menu" and keeps its behaviour, and an "Exit OpenDungeons" button below it leaves to the desktop, both through the existing confirmation popup. Which of the two the popup confirms is remembered when it opens, and the Escape shortcut arms the menu path, so a confirmation abandoned with "No" cannot make a later Escape-quit fall out of the program. Claude-Session: https://claude.ai/code/session_014hrk8PiEUMgjYJnTxLF2PU
Losing the dungeon temple already makes the creatures stop obeying, but the rest of the game carried on as if nothing had happened: the keeper kept announcing "we are under attack" (with battle music) for fights that were no longer the player's business, kept nagging about missing beds, food, workers, treasury space and an empty skill queue, and the server kept accepting build and cast orders - a defeated player could go on summoning workers, which reads as "maybe I can still come back" when there is no way back (issue tomluchowski#5). The advisory notifications and the team-fighting alarm now return early for a player who has lost, and the server refuses room builds, trap builds and spell casts from one, answering with a clear "You have been defeated and can no longer give orders" message instead of silently obeying. Claude-Session: https://claude.ai/code/session_014hrk8PiEUMgjYJnTxLF2PU
Two camera complaints from the interface review (issue tomluchowski#11), both of which had been offered as options in the discussion there: The arrow keys and autoscroll panned at one fixed speed, too fast for some tastes and unadjustable. The speed cap the camera derives from its height now goes through a user multiplier, set from a slider on the settings window's Input tab (10% to 300%, default 100% keeps the historic speed), applied live while the window is open and saved with the rest of the input settings. Zooming moved the camera straight down, and since the camera looks ahead at an angle, whatever sat in the middle of the screen slid away while zooming - "zooming in zooms to the bottom instead of the middle". The zoom now keeps the ground point at the screen centre fixed: the camera base shifts by the difference of its ground offsets at the old and new heights, so what you zoom at is what you get. The height clamps are applied to the target height first so hitting the floor or ceiling of the zoom range cannot shear the view sideways. Verified in a running game: the portal at the screen centre stays centred through a full zoom-in where it previously slid off towards the bottom, and the new slider shows and applies on the Input tab. Claude-Session: https://claude.ai/code/session_014hrk8PiEUMgjYJnTxLF2PU
Make the camera pan speed adjustable and zoom towards the screen centre
Every caller of the advisory notifications already tested getHasLost() before calling, so the guards added inside Player::notify*() were a second check of the same thing (and the trap handler tested it a third time after refuseIfDefeated()). Keep the check in the callee, where it cannot be forgotten, and drop it from the callers. Claude-Session: https://claude.ai/code/session_014hrk8PiEUMgjYJnTxLF2PU
…feat Stop nagging and taking orders from a defeated player
Issue tomluchowski#42 asks for explicit types instead of auto. The fourteen auto declarations added by the last month's merged changes (room split, per-tile bridge claiming, the seat tile-state lookup and the console test) now name their iterator, std::function or Command::Result type. No behaviour changes. A CLAUDE.md at the repository root records the rule, along with the C++11 baseline and the surrounding style conventions, so the assistant keeps to it in future sessions.
Issue tomluchowski#42 asks for explicit types instead of auto.
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
…editor-improvements
…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
| ground->setQueryFlags(0); | ||
| ground->setVisibilityFlags(CullingType::SHOW_ALL); | ||
| Ogre::SceneNode* groundNode = mSceneManager->getRootSceneNode()->createChildSceneNode("DungeonGroundUnderlayNode", | ||
| Ogre::Vector3((gameMap->getMapSizeX() - 1) * 0.5f, (gameMap->getMapSizeY() - 1) * 0.5f, 0.0f)); |
Author
There was a problem hiding this comment.
The -1 offset places the underlay one tile below the floor so exposed seams reveal earth; it is a chosen clearance, not a measured minimum.
|
|
||
| // Cover tile and room seams with continuous earth below the dungeon. | ||
| const Ogre::Real groundMargin = mViewport->getCamera()->getFarClipDistance(); | ||
| const Ogre::Real groundWidth = gameMap->getMapSizeX() + 2.0f * groundMargin; |
Owner
There was a problem hiding this comment.
Why margin at all ?
If we have the end of the plane , let it endup somewhere ... in space of something :)
For sure current solution fools the player ... for example that there is a ground , and the creature can pass through ( while they don't )
Author
There was a problem hiding this comment.
The margin intentionally prevents the space background from appearing around the dungeon in oblique edge views; it does not extend the playable area, so we will keep it.
Rokk001
force-pushed
the
pr/dungeon-ground-underlay-complete
branch
from
September 27, 2026 17:16
269d69c to
8720793
Compare
This was referenced Sep 27, 2026
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
6 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.
Close camera views can expose the sky through gaps between dungeon geometry. Add a continuous earth plane below the dungeon, sized from the current map and removed during renderer teardown, so those gaps reveal ground.
This independent renderer correction has no dependency on the other interface contributions. No matching narrow open issue was identified.
Validation: 987 isolated ground-underlay checks passed, together with a Windows x64 Release integration build and runtime preparation. The original close-zoom visual acceptance is not recorded as complete; no new manual game run or other-platform verification is claimed.