| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
Scripted, then manually reviewed.
|
|
|
|
|
|
|
|
|
| |
2% of a qw profile was spent there.
Might be better to optimize it for levels with actual slime on them as well:
we call set_terrain_changed() which can update slime neighbour counts,
removing the need to compute them repeatedly. Not doing this right now only
because I'm not sure about all cases vault placement can alter the terrain.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
At one time, before runed doors were added, connected_doors was almost
nice shorthand for find_connected_identical(position, DNGN_CLOSED_DOOR,
all_door). Now its just a pointless and inconsistently applied layer of
indirection.
Also refactor find_connected_identical a bit.
[Also updated the remaining f_c_i calls to the new parameter list,
and made the _f_c_i helper static. -neil]
|
| |
|
|
|
|
|
| |
I can't quite fathom the reason to not moving it to /dev/null instead, but
here you go.
|
|
|
|
|
|
|
|
| |
This might be a bit debatable, but to me having a portal both ways suggests
you're magically transported somewhere. A mundane stair protected by a gate
would have a gate on one side and a regular stairway on the other -- a pair
of gates is possible but would be unnecessary expense on part of the
dungeon's builders.
|
|
|
|
|
| |
map or set.count() can test the presence of a given key and return 0 or 1
outright.
|
|
|
|
|
|
|
|
|
|
|
|
| |
D is now 16 levels (the unsealed part was 14 levels previously), and the
Depths are six levels. Vaults is enterable from Depths:2-5; Abyss, Hell,
and Pan portals are available for the entire length of the branch.
Right now the monster set is identical to Vaults except for the absence
of Vaults-specific humans. D's monster set has also been truncated,
mainly on the out-of-depth front. It's my intent that this serve as a
starting point for figuring out what monsters we want to split between
the two branches.
|
|
|
|
| |
It hardly deals with remembered map.
|
|
|
|
|
| |
Seriously, even preparing this commit gave me a pain in the triangle between
the thumb and index finger's bases and the wrist.
|
|
|
|
|
| |
These can be really confusing, especially if there are operators of different
priorities, or multiple levels of parentheses, nearby.
|
| |
|
| |
|
|
|
|
|
|
|
| |
This turns out to be the cause of elusive "multiple exits" faults.
The check could be amended to ignore mimics, but as the player already
knows which exit is the real one (he entered through it!), such mimics
have no chance to fool anyone.
|
|
|
|
| |
No more restarting, let's have the name reflect it.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
There might be a monster underneath.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Minus gargoyle clinging, of course.
With monster clinging back, it would be inconsistency for inconsistency sake.
Player clinging:
* is what people expect spiders to be able to do (if monsters can). Count on
bug reports about this.
* allows people to learn monster mechanics on their own
* is useful in the early game, or later if you don't have that particular
spell. People don't tend to lug heavy potions of Flight either.
* is actually fun
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clinging might be a minor feature, but it's a distinguishing one, it's thematic
and it's working quite well.
Player/monster symmetry has never been a goal, so it seems dubious to invoke it
as the reason to throw away all the work that has been put into clinging. We
can always say that the player turns into a different kind of spider which is
unable to cling for some reason.
This reverts commit bdc56382eacf7af1b2330dc6444916d368741fec.
This reverts commit d689486464fcaaac025a6f469ab69674a2f4d173.
This reverts commit 1addaaf8ee92de5060fdb436f93251843abd2035.
|
|
|
|
|
| |
Pull 'you.religion [!=]= FOO' checks into a function: you_worship(FOO).
This change is part of a large plan to clean up religion.
|
| |
|
|
|
|
|
|
|
|
| |
Among other things, this allows their ability to have some effect
when encountered in Vaults:$.
It currently works on all non-portal stairs and hatches (including
branch entrances and exits)
|
|
|
|
| |
It's easy to re-add it if we'd have a better idea for it after all.
|
|
|
|
|
|
|
|
|
|
|
| |
With player clinging removed, monster doesn't make much sense.
Note that I personally somehow like clinging -- even if it's rarely useful
except early on, it was quite harmless. However, I'm strongly against
having players and monsters inconsistent when there's no very good reason.
Thus, reverting this and MarvinPA's change is an option. Just please keep
or revert them together.
|
|
|
|
|
|
|
|
|
| |
As a player mechanic, it's almost never relevant and in the few cases
where it can be relevant it's quickly obsoleted by fairly common
sources of flight, as well as being unnecessarily complicated (no
diagonal clinging for some reason?). As a race-specific mechanic it
also results in a lot of annoying message spam ("You open the door. You
fall off the door.").
|
|
|
|
| |
The next commit will be making use of them.
|
|
|
|
|
| |
These print the out-of-bounds coordinate as part of the assertion
message.
|
|
|
|
|
|
|
|
| |
Since the new temporary terrain change framework, nuking a transformed
wall automatically reverts to its previous feature, but in this case
we don't actually want that behavior (a shattered sealed door turning
into a normal door). Now effects that nuke sealed doors should properly
revert them to floor.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Each terrain change specifies a desired feature, a duration (which may
be INFINITE_DURATION), a terrain change type (used for reference and
stacking at the moment), and optionally a source monster (if one is
specified, the terrain change is undone upon the monster's death)
A temporary terrain change will automatically revert to the original
underlying feature when it times out, or the source monster is killed.
There can only be one terrain change of a given type at a single
location. A new change of the same type will overwrite the old one
if it either changes the terrain to a different feature type than the
old one, or has a greater duration than remains of the old one (this
will change the associated source monster, if appropriate).
|
|
|
|
|
|
|
|
|
|
|
| |
This works very well for the most part with
two small problems:
- Webtiles will not support this yet (in probability,
this will stop any clouds showing in webtiles)
- Floor items interact strangely and will draw over
the top of clouds instead of behind them
|
|
|
|
| |
Otherwise, the tile could come back when loading a save.
|
|
|
|
|
|
| |
This fixes a number of issues where a layout/vault applies a tile
to a feature and then subsequent vault/terrain placements incorrectly
inherit that tile.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The routine which finds free space to place these monsters now uses
monster_habitable_grid directly instead of its own logic (which ignored
flying entirely).
Spells which can summon both fliers and non-fliers (ie: call imp,
summon greater demon, etc.) will make no attempt to respect the surrounding
terrain when choosing a monster type (and so will sometimes attempt to
summon a monster that cannot be placed at that terrain, and fail as
previously), though it is arguably better if players cannot influence what
things they summon by where they are standing. In either case, this is
certainly much better than Haunt and Battlesphere failing when over deep
water for no clear reason.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
This may cause problems, but then, with #if TAG_MAJOR_VERSION, we'd have
them without warning when the bump happens. There's quite a few functions
that use enum ordering for passability/etc.
At least this way fewer saves will be affected.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These are the watch captains of the vault, similar in stats to a
greater vault guard, with more HD and slightly better equipment.
They can evoke a rune of sealing which slams shut doors near the
player and seals them closed. Sealed doors cannot be opened by the
player by any means (though they can still be destroyed in the usual
ways), although monsters can open them freely.
The seals will expire after a number of turns, or instantly upon
the death of the warden which sealed them.
|
| |
|
|
|
|
|
|
| |
Rather than relying on feat >= DNGN_FLOOR having the same semantics
as 'open space', wrap this in boolean functions (which already largely
exist). This is also more robust if the backend ever changes.
|
|
|
|
| |
The previous inconsistency was mentioned in Mantis 6667.
|
| |
|