I wonder if isn’t a bad idea releasing an 1.6.2 release…
Best regards from Italy,
dott. Piergiorgio.
is an actual feature, but in specific cases the disamb priority can be problematic:
let’s have a location named, say, “East gate”, whose obviously includes a gate; the disamb always choose the room instead of the (fixed in this case) thing, e.g. from my WIP (also with tiny differences, in Creative Cooking 1.5, so there’s no actual spoiler…)
e
East Gate
The ancient, millennia-old, East gate, the only surviving defensive gate of Luroz, flanked by short remains of the wall, now repurposed into the west walls of the two houses beside the gate leading out to the road to Sarneste
west is the market, and east you can exit Luroz on the Sarneste road.
x gate
East Gate
The ancient, millennia-old, East gate, the only surviving defensive gate of Luroz, flanked by short remains of the wall, now repurposed into the west walls of the two houses beside the gate leading out to the road to Sarneste
west is the market, and east you can exit Luroz on the Sarneste road.
x peace gate
The defensive gate reminds of Railei’s violent past of many millennia ago; On the top of the gate is carved the Draconic glyph “lomleem”, a star intertwined with a crescent, a symbol the Dragons gives to places whose embraces Peace, albeit keeping mementos of the dark times when violence sadly was the answer.
The issue is plainly clear, I hope…
My suggestion is that in the case a room and a thing with same vocab name, the disamb chooses the thing in the case of EXAMINE, and the room in the case of LOOK, whose I think is what the player actually expects…
Best regards from Italy,
dott. Piergiorgio.
1 Like
I’m planning to. Probably next month.
4 Likes
I’m unable to reproduce this behaviour. The nearest to it I can get results in a disambiguation question, “Which do you mean, the gate or the east gate?”, which is admittedly ungainly but does not show the parser preferring the room to the gate object. So maybe there’s something else in your implementation that’s causing the result you’re seeing?
In any case, this is easy enough to fix in game code where it occurs; just add the following to the definition of your gate object:
vocabLikelihood = 10
2 Likes
hmmmm… I’ll cut& paste the relevant code,'cuz basically is reused in Creative Cooking 1.5, minus a pair of spoiler (a todo comment and code NOT ported to CC):
egate: Room 'East Gate'
// [SPOILER]
"The ancient, millennia-old, East gate, the only surviving defensive gate of
Luroz, flanked by short remains of the wall, now repurposed into the west
walls of the two houses beside the gate leading out to the road to Sarneste\n
west is the market, and east you can exit Luroz on the Sarneste road."
east = eroad
west = market
[SPOILER]
;
// sadly reckoning the current (as of 2024) mess
earch: Decoration 'east gate; defensive carving peace; glyph lomleem star
crescent memento' @egate
"The defensive gate reminds of Railei's violent past of many millennia ago;
On the top of the gate is carved the Draconic glyph \"lomleem\", a star
intertwined with a crescent, a symbol the Dragons gives to places whose
embraces Peace, albeit keeping mementos of the dark times when violence sadly
<b>was</b> the answer."
;
walls: Decoration 'stone walls; ancient reclaimed repurposed stones; wall
stonewall stonewalls stumps stump; it them' @egate
"During the last 10,000 years or so, the walls's stones was reclaimed for
building and civic engineering, but the walls along the road was repurposed
as the eastern walls of the pair of houses alongside the gate, and two short
stumps alongside the gate, between these two houses and the throughfare, is
all what remains visible of the wall."
;
BTW, I suspect that the best solution seems
autoname = nil
but has the side effect of reducing the player’s QoL, removing the convenient
GO TO EAST GATE
(oh, side note: albeit considered harmful 
I think isn’t a bad idea having GOTO as synonym of GO TO…)
Best regards from Italy,
dott. Piergiorgio.
2 Likes
Ah, now I see what the problem is. You’ve declared the gate object to be a Decoration, which the parser treats as a less important object and thus a less likely target of an EXAMINE command, so what you’re seeing isn’t a preference for Rooms over other objects but a preference for other objects over Decorations.
One fix would be to add the following to the definition of your gate object:
dobjFor(Examine) { verify() { logicalRank(110); } }
This would then boost the parser’s choice of the gate object over the gate room as a target of an EXAMINE command,
4 Likes
true. changed to Fixture (after all, is a massive gate…) and here’s the inspiration:
Best regards from Italy,
dott. Piergiorgio
1 Like