| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
.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!
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This function was misleadingly named (it only provided the skill
used for melee weapons, not ranged weapons), and incomplete;
code along the lines of "is_ranged_weapon(*it) ? range_skill(*it)
: weapon_skill(*it)" was scattered in about half a dozen different
functions. I've corrected both of those problems (renaming weapon_
skill() to melee_skill() and adding item_weapon_skill()), and also
possibly fixed two bugs in the process - an l_you.cc function that
claimed to provide the skill used for the starting weapon (but
actually only gave the melee skill), and unrand creation code that
checked if a potential unrand swap used the same (melee) skill as
the weapon type being generated.
|
| |
|
|
|
| |
This makes them properly pick any nearby monster, as originally
intended.
|
| |
|
|
|
|
| |
Also when they are berserk or insane (the other situation MAINTAIN_RANGE
enemies lose their special AI). This commit also encapsulates choosing a
monsters' firing target in a function.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
They will no longer become hostile if hit by one of your spells.
Hitting a servitor with a melee or ranged attack will still anger it.
|
| |
|
|
|
| |
Monsters are now distracted for 1-5 turns on a 3% chance per pile of
gold in LOS.
|
| |
|
|
|
|
|
| |
It's unused now that curse skulls are stationary again.
This reverts commit e381e79d48aaf3bf1e770f58b6abfcf0817f2b81.
This reverts commit 5a745abeb842ba05116320a397ba05de73a94303.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
As the original commit describes, this was experimental. The moving
version wasn't well liked, at least the staionary version can be
ignored.
This reverts commit 2034c5180c8ce08fb2fb3c7955e200c7909a41d0.
Conflicts:
crawl-ref/source/mon-act.cc
crawl-ref/source/mon-behv.cc
crawl-ref/source/mon-data.h
|
| |
|
|
| |
Also silences some compiler warnings.
|
| |
|
|
|
|
| |
They already went hostile when attacked in melee, and making it possible
to attack enslaved zombies with darts without them turning hostile
isn't a behaviour that should be preserved.
|
| |
|
|
|
|
| |
They become un-bribed, and other bribed creatures that can see them also
become un-bribed; a permabribe increment for the creature is deducted
against the branch bribe score for this action.
|
| |
|
|
|
| |
The monster. It didn't really exist anywhere, nor did the idea seem
to add too much to the good-sized danger that spriggans already posed.
|
| | |
|
| |
|
|
|
|
|
| |
Touches a lot of files since their #includes have to be edited.
(Pushing now since it shouldn't break anything and keeping it updated
is nasty.)
|
| |
|
|
|
| |
This was previously comparing a grid distance to a spell range for
purposes of setting the firing position.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are two main changes here:
Firstly, given that this summon is more likely to be used by conjurers
than a typical summon, the tendency for them to walk into your line of
fire is more problematic than usual. I have added some fairly 'dumb'
code to try and reduce their chances of doing this. All it does is
refuse to let the servitor step anywhere in the direct line between the
player and the servitor's current enemy target, unless it's already
there (either you stepped behind it, or it acquired this target while
already interposed). This target is not guaranteed to be what the player
wants to fire at themselves, of course, but there's probably a
reasonable chance that it often is.
Secondly, make the servitor likely to hold position once its target is
within range for all of its spells, rather than close further into
melee. It has no melee attack in the first place, and I think that
keeping its distance will help it avoid blocking the player's line of
fire in other cases (as well as help the servitor's own survival).
It will not actually retreat, however - simply not advance.
My hope is that neither of these behaviors will obtrusively apparent
(produce visibly strange behavior) and simply result in it causing
fewer visible problems in actual games.
|
| |
|
|
|
|
|
|
|
|
|
| |
This block of code didn't actually seem to do what it claims it does
(since it doesn't set new foe properly and ends up getting reset before
the monster can even take a single action with the new values), and
it seems likely it would be bad if it actually did (allied monsters
randomly wandering off from the player for no reason?).
Behavioral code is convoluted enough as it is, without more bits of
it being maintained when they don't even do anything. (I hope.)
|
| |
|
|
|
|
|
| |
This should fix them sometimes inexplicably attempting to walk
into walls, and hopefully improve their movement in a number of
other situations where you have a clear view of their target, but
they don't.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most pathfinding checks assumed that the only thing a monster
would be trying to path towards was the player, even though this
was frequently untrue (either hostile monsters targeting player allies
or friendly monsters trying to reach other monsters). A few bugs
existed as a result of this:
When monsters without ranged attacks would check the reachability of
their foe, they would check the reachability of the player instead,
regardless of what was shooting at them or whether the player was
even involved in the battle. This meant that melee-only monsters
would flee from ranged attacks in the arena (where the player is
understandably never reachable) and also could show up occasionally in
normal play - such as retreating from an oklob fort if the player
is behind water.
I expect there are a few other bugs related to similar assumptions,
but moreover, allowing monsters to use proper pathfinding to non-player
foes likely improves ally intelligence somewhat.
As always with fiddly monster behavioral code, there is a non-trivial
chance that some important side-effect has been overlooked, but initial
testing looks good.
|
| | |
|
| |
|
|
|
| |
If it received a behaviour event after the death of its owner but
before being removed.
|
| |
|
|
|
|
|
|
|
|
|
| |
The flag no longer makes the monster automatically notice the player as soon
as the player enters sight. Instead, it divides the chance of the monster
forgetting about an out-of-sight player by 3. (The flag also still has the
effect of making the monster's foe_memory not decrease with time.)
This affects only one monster currently: curse skull. The purpose of the flag
is to make the monster handle being out of the player's sight better, so
possibly wandering mushroom should gain it too.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is another issue with allied monsters being out of los of their
foe, while the player is not, and it being non-obvious that the allied
monster actually cannot see their target's position. Since summon creation
position is randomized, it was not uncommon for them to spawn out of sight
of a target you had assigned as the pet target, and thus sometimes they
would appear to simply ignore the pet target and stand around doing nothing
(this applies to both ta and also autofoe as assigned by the previous commit).
Now they will use the player's ability to see their foe to allow them
to preserve their own target lock, allowing more intuitive ally behavior
when commanded to attack things.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Having to repeatedly pause to tw after summoning new allies in a
battle-in-progress (lest they simply stand around doing nothing)
makes the pure summoner playstyle a bit more tedious than necessary.
Also, it is not always intuitive to new players why allied monsters
will sometimes appear to engage on their own and other times ignore
obvious threats (say, if those threats simply missed you with their
attacks on the previous turn).
This adds the capacity for newly created summons to automatically
choose valid nearby foes similar to if tw had been used just after
making them. If there are no valid nearby foes, they will simply
follow alongside the player as normal (no change to their general
AI behavior has been made).
(I did this by repurposing the apparently unused M_PLAYER_MADE flag.
Hopefully there wasn't some reason for its existence that was not
clear to me.)
There is one caveat that is slightly different from tw: they will
choose only foes that the player is also in los of (so as to not
run off after monsters the player is not yet even aware of) and will
even choose a foe that they are not in los of, but the player is, if
no other one is available). This last property is particularly because
often summons will be created slightly more distant from a monster
you are fighting than the player is, and it is often very unclear
that the monster cannot actually see the target from that spot. So
when they do not engage and simply stand around the player, it
appears moreso that the AI has failed to work properly, rather than
the monster cannot see any target. We will assume that the player
passes along some indication of its foes' positions that allies can
use - in practice, the fact that this is even happening is not obvious;
things simply just appear to move towards obvious enemies.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the beam was KILL_MISC, the source for the behaviour event will be
null (maybe that should be fixed? See beam_source_as_target). Looking
up the name of the source of the attack, as happens when stripping
ENCH_FEAR, would then cause a crash.
See for example:
http://crawl.lantea.net/crawl/morgue/dck/crash-dck-20140212-132407.txt
where the spell causing the crash was the self-affecting portion of
Chaotic Mirror.
Make this case of behaviour_event handle a null src, like everything
else in that function. Say "The attack" rather than "Its attack".
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The monster versions of these spells were misbehaving differently
depending on whether they are friendly or hostile due to assumptions in
handle_behaviour(). Some changes that let these "avatars" behave
properly when both friendly and hostile, regardless of caster:
0. I added a mons_is_avatar() function that returns true if the given
monster type is a battlesphere, spectral weapon, or grand avatar.
The behaviour changes only affect spectral weapons and
battlespheres, and the function is currently only used for code
relative to those two, but they're all in the class of "magical
constructs attached to the caster".
1. Spectral weapons and battlespheres seek their owner upon creation.
2. Avatars now always know the location of their owner and will attempt
to seek to their owner if they fail to seek their current target.
3. Avatars not created by the player see their owner as the "foe" to
fall back to instead of the player. Using the owner for mon->foe
when the avatar cannot attack (in the case of spectral weapons) is
perhaps not the best system, but it's how non-avatar player-friendly
monsters are currently able to track the player, so we use the
analogous approach now.
4. Spectral weapons are all properly "leashed" to their owner and fall
back to seeking owner if they are out of their two-distance leash.
Battlespheres also seek back to their owner if said owner is
teleported away.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
With the forest dispersal work done, and with everything working up to
the original designer's standards, this is ready for trunk.
Conflicts:
crawl-ref/source/beam.cc
crawl-ref/source/dat/des/branches/pan.des
crawl-ref/source/enum.h
crawl-ref/source/hiscores.cc
crawl-ref/source/melee_attack.cc
crawl-ref/source/mgen_enum.h
crawl-ref/source/mon-cast.cc
crawl-ref/source/mon-data.h
crawl-ref/source/mon-ench.cc
crawl-ref/source/mon-info.cc
crawl-ref/source/mon-info.h
crawl-ref/source/mon-place.cc
crawl-ref/source/mon-spll.h
crawl-ref/source/mon-stuff.cc
crawl-ref/source/mon-util.cc
crawl-ref/source/mutation.cc
crawl-ref/source/output.cc
crawl-ref/source/player.cc
crawl-ref/source/spl-data.h
crawl-ref/source/status.cc
crawl-ref/source/wiz-you.cc
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Listed in the proposal as Icon of Greatness.
A grand avatar behaves similarly to both a spectral weapon and a
battlesphere in that it attacks targets the caster and its nearby allies
either attack in melee or by battlesphere-triggered conjurations; it
is only guaranteed to attack if the triggerer does at least 15 damage,
though it may trigger randomly below that threshold.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A long-acknowledged problem with sirens is that while their
mesmerisation can be powerful and relevant when supported by dangerous
allies, they are completely harmless on their own yet can still camp
out where you can't reach them and prevent you from leaving as well.
The solution I propose to these staring matches is to make lone sirens
actually dangerous and so I am giving them a powerful and thematic form
of offense: calling up the spirits of the drowned to inflict the same
fate on their captive audience.
When a siren starts to sing, it starts a counter that will (after a
short time) start to continuously call up drowned souls from nearby
deep water. These drowned souls have very short duration and die upon
hitting something, but their touch inflicts considerable AC-ignoring
drowning damage.
Since mesmerisation can already be powerful in the presence of allies,
said counter will not be incremented in the presence of more than a few
HD worth of them (and thus sirens with existing support will not call
up drowned souls). This ability is intended foremost to give threat to
the many sirens one encounters WITHOUT any backup to speak of without
making all others much more dangerous.
I think requiring deep water to perform this ability could work well with
their already-existing behavior to pull the player towards this terrain
and gives a powerful incentive to try and not let that happen.
Most of the numbers involved here are provisional, including rate of
soul calling, damage of individual souls, number of allies required to
inhibit using it, etc. The idea is that it should be quite dangerous on
its own without making situations where a siren's presence is already
dangerous far moreso, but nor should one or two harmless monsters prevent
it outright.
Let's see how it plays.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sirens should now be less likely to voluntarily break LoS with a
mesmerised player, either by stepping away or ducking around a
corner. Hitting a siren will no longer sometimes cause it to start
dancing or run off to the top-left of the map. Also sirens should
more properly maintain a target lock on the player, even while
moving away (this would affect ranged attacks if they had any).
Unfortunately, it seems there's no clear good way to go about fixing
the fact that under almost no circumstances will a mesmerising siren
actually use its melee attack. The best solution I could find causes
the siren to oscillate back and forth around the spot it wants to
stand, which I don't consider an improvement. But given that siren
melee is pathetic and irrelevant anyway, I consider this relatively
unimportant (and plan to give them something better to replace it
anyway)
|
| |
|
|
| |
fear)
|
| |
|
|
|
|
|
| |
command))
Apparently I preserved the wrong one of the two synonyms in one of the 'useless'
bits of code I just removed. Gee, I wonder how that happened....?
|
| |
|
|
|
|
|
|
|
| |
These are checks for conditions that either don't seem to matter or
outright can never happen (despite comments speaking explicitly as
though they can!)
Hopefully I have not missed something that performs an actual purpose
here.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
message)
Performing a melee attack against a fleeing monster has always made it
stop fleeing, but didn't remove the fear enchant at the same time, which
made it fear-immune for a while (it also didn't give any message at all).
Now a suitable message is explicitly given and fear properly removed.
It's arguable that a mere attack attempt shouldn't automatically break
it - at the very least, perhaps it shouldn't happen if you miss?
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
It was only ever checked at the same time as mons_is_fleeing(), which
itself already checked for this flag.
Moreover, the flag doesn't seem to ever be used by anything, so maybe
it should just be removed itself?
|
| |
|
|
|
|
|
|
|
|
|
| |
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)
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
They behave like giant spores now - they can't be controlled directly,
instead seeking out the nearest target and exploding when sufficiently
near. (Yes, this means they aren't permanently confused any longer.)
I've also made the distribution of how many ball lightnings are summoned
a little bit smoother, and put a cap on how many monsters can summon at
once.
In my testing, CBL is a little less suicidal to use now, but I think
further tweaks that I've previously toyed with such as reducing the
explosion radius might still be warranted.
Also, try fighting Lom Lobon now; CBL is much more effective in his
hands, too!
|
| |
|
|
| |
The old name was quite puzzling...
|
| |
|
|
|
| |
Sometimes, they're there to emphasize a break between two sections of code,
which is good. In a majority of cases, though, they're just inconsistent.
|
| | |
|
| | |
|
| |
|
|
| |
See Mantis for discussion.
|
| | |
|
