| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
They were only used in one place, and the relevant code was moved to
that one place in the previous commit.
|
|
|
|
|
|
|
| |
.cc, moving its contents into the new stepdown.cc and strings.cc.
(The latter also got many donations from libutil.h.)
Down with stuff! Up the new flesh!
|
| |
|
| |
|
|
|
|
| |
As part of a wider scheme to make draining temporary.
|
|
|
|
|
| |
We were calling mlist.get_monster(0), but get_monster returned a random
monster because the index 0 was out of bounds.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
A good deal of functions move to the two new files, mon-poly and
mon-message. Of the others, some go to where they are used, some to
mon-util, and a few are made member methods of monster.
This probably breaks Xcode compilation, and I'm not able to test
the changes I made to MSVC that will (hopefully) keep it working.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
It was something that was almost never relevant but that cluttered
up the code regardless. If it were to be more relevant that would
not really be a good thing since a chance for instadeath is rather
bad design.
|
|
|
|
|
|
|
|
| |
[It had much the same problems as racial weapons, with only very slightly more
significant effects. Some of the old effects of racial armour could potentially
be rethought and made into a new armour ego. Beogh still gives a (slightly
smaller than before) bonus for armour use, without the orcish requirement.
-MarvinPA]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The effects of racial weapons were very minimal and unlikely to be
noticed. Even if they were made significant, they would only apply to a
very small subset of races. The only somewhat notable effect was Beogh's
slight slaying bonus (and even that was very minor), this could be
compensated for in some other way if necessary.
Racial armour has slightly more noticeable effects and currently still
remains, but could probably be removed too (potentially replacing the
racial effects with armour egos instead).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After detailed scrutiny, it was unclear that BEH_CORNERED was actually
serving any real purpose. When a monster was told to stop fleeing (maybe it
hit a wall), it would briefly enter BEH_CORNERED, but then immediately exit
it again unless at low health. But even in BEH_CORNERED, there seemed to
be few meaningful logic differences from a stripped down BEH_SEEK against
a visible foe. (There were also some other checks that seemed to serve no
function.)
Now BEH_CORNERED has a distinct purpose from other behaviors. When a monster
is fleeing and its path is obstructed by a monster or terrain obstacle, instead
of immediately stopping fleeing (and incidentally becoming invisibly immune to
fear for some time!), it will pause one turn in place in the hope that a path
will open up next turn. This actually happens frequently when multiple monsters
are fleeing in a confined space (say you read a scroll of fear in a corridor);
instead of many of them breaking fear immediately, they will wait just a moment
to give outer monsters a chance to move and thus give space to move themselves.
In practice, this means that fear tends to operate in a more intuitive manner
when playing, instead of sometimes appearing to have no practical effect.
It should be noted that breaking fear due to being stuck did not actually remove
ENCH_FEAR from a monster, even if it acted in all ways as though this enchantment
was not present. However, since cause fear would not apply ENCH_FEAR to a monster
that already had it, if any monster broke fear prematurely, it would remain
invisibly immune to further fear until the effect on them wore off. (It would even
give a message later on about the monster 'recovering its courage', which seems a
little odd if it's just been chasing you for several turns already). Now fear is
properly removed if the monster actually stops fleeing.
This commit also adds a few comments to try and explicate the difference
between 'fleeing' and 'retreating', where the former implies a disorderly
run away from a target (such as when afflicted by fear) while the latter
subsumes any case where the monster wants to move AWAY from its target pos
instead of towards it (which includes backing away from a player with a
reaching weapon that it cannot retaliate against)
Note that BEH_CORNERED is subsumed beneath mons_is_fleeing() since the monster
still WANTS to flee, even if it currently cannot move, and this is often relevant
when fleeing status is checked.
|
|
|
|
|
|
|
|
|
|
|
| |
While several parts of code checked if a monster WAS 'panicking' (described
in a comment as 'fleeing without running away'), it was never actually
possible for a monster to enter this state, nor did there seem to be any
behavioral code associated with being in it. The flee-based behavioral
code is convoluted enough already without mysterious unused things cluttering
it up, so I have pruned it.
(Hopefully I am not overlooking anything)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This has been suggested a few times. Gameplay-wise, they're not very
challenging to avoid (except for the Snake ending that places them)
thanks to the constraint of being stuck in a pool of lava; flavour-wise,
the mythological creature it's based on is amphibious in many
representations.
Snake could use a slightly more diverse enemy set anyway (see
snake-enemies branch).
This introduces an HT_AMPHIBIOUS_LAVA, which is exactly what it sounds
like; perhaps a better name could be found for it.
|
| |
|
|
|
|
|
|
| |
This reverts commit b0c9531a8997436f0bddfa218105d2e67c16f2ce.
This reverts commit 054e7ae2f5fb42c12dc169898259e58f2dc5a77b, reversing
changes made to 1ddc8957bd848179aac795187f07496f02932644.
|
|
|
|
| |
Wields a hooked quarterstaff, throws snowballs.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Also simplify quite a few cases.
It turns out in >90% cases of non-literals the argument had .c_str(),
which meant it was pointlessly malloc()ed and converted from and to
std::string. I believe a sprintf is faster, so even the argument of
miniscule speed-up doesn't apply.
|
|
|
|
|
|
|
|
| |
It trades readability and consistency for an utterly negligible bit of
speed. With the amount of further processing mpr() does, a single sprintf
is nothing.
This reverts commit d9dfa8fc9755fb0a4e8954c7eb94f32fe97b82e0.
|
|
|
|
| |
Scripted, then manually reviewed.
|
| |
|
| |
|
|
|
|
|
| |
Can't test Android, MSVC or Mac, but a very brief glance at the diff suggests
it's unlikely they're affected.
|
|
|
|
|
| |
It degenerated to a simple loop over menv, hardly worth any syntactic sugar.
I kept it for now, though.
|
|
|
|
|
|
| |
Looks like, unlike "target[t]ing" where a single t is used by many brits and
even some aussies, "cancel[l]ing" has double l even for a good deal of
americans.
|
| |
|
|
|
|
| |
Easy to revert if anyone feels like actually implementing them.
|
| |
|
|
|
|
|
|
| |
The default, substring match, was totally unintuitive and broken.
Only one place is actually changed, something about shapeshifters.
|
| |
|
| |
|
|
|
|
|
| |
It doesn't name the slots but does give the slot numbers, like the
spells: dump. Arguably slot names would be more useful here, though.
|
|
|
|
|
| |
Again, a magic value of -1. It was also wrongly checked in a few error
handling routines, rendering them inoperative even with gcc.
|
|
|
|
|
| |
The only cost is having assignments be a function, as you can't overload
operator[] to have separate bits be lvalues.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The behaviour should be preserved exactly or almost exactly, only the code
changes from totally, utterly unreadable to merely hard to read.
Actual differences:
* strong OODs in shallow branches would degenerate into picking a monster
randomly from the whole branch, now they pick from the bottom level (or
so-called OOD cap of Elf:7, Tomb:5, D:31 and Vaults:15).
* Zot no longer replaces requests for Zot:5 by Zot:4, and proper hells,
$(HELL):4-7 by $(HELL):3.
* this means hell monster sets need fixing!
* zombie size doesn't affect their spawning
* zombie selection obeys the depth passed
* which makes zombie sets pretty limited -- needs review/redesign?
The new format is:
{ 9, 19, 826, SEMI, MONS_YAK },
which means: yaks can spawn on D:9-19, with _linear_ rarity 826 in the
middle of the range. A "SEMI" distribution means that at the edges,
D:9 and D:19, the effective rarity is half that, 413.
Distributions:
FLAT 100% 100% 100%
SEMI 50% 100% 50%
PEAK 0% 100% 0%
UP 0% 50% 100%
DOWN 100% 50% 0%
That "0%" doesn't mean the monster won't spawn on the top/bottom level
(D:9 and D:19 for yaks), the range is fudged so D:8 receives 0% chance,
D:9 16.6%, linearly up to 100% on D:14.
Yes, this sounds and is complex, but at least the complexity is not strewn
around obscure code anymore, and a number of limitations have been lifted.
ZotDef still uses the old code via an emulation layer.
|
| |\ |
|
| |\ \
| | | |
| | | |
| | | |
| | | | |
Merge commits instead of rerere suck, but not being able to comfortably use
the test rig sucks even more.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Also, get rid of one of three copies of '8'/'9' logic.
Also, fix the depth of place: not being heeded for some purposes.
Technically, there is one actual change: shallow items in Ziggurats had
a fixed level of 27, they now use 27 + depth in Zig. Not noticeable as
most nearby items use level 351 anyway.
|
| | | | |
|