| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
| |
Perhaps someday I will manage to rebase something without SOMETHING
mysteriously vanishing in the process. But that day is not today.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changes the metric for how sirens select their movement destination
in a couple ways. They no longer try to surround themselves completely
with deep water, but instead prefer at least one neighbouring tile
be shallow water or land. The presence of a single tile of deep water is
valued more highly, but multiples more lowly. Moreover, they will no
longer always reposition if a more optimal spot is visible to them, so
long as their current location is 'okay enough', which should reduce the
distances they move while still trying to give them sufficient terrain
advantage.
In general, this should cause them to make themselves inaccessible far
less often, as well as move away less often, period.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For some reason, the check performed to see if a monster can fire at
its target when the path to reach melee range with it was obstructed
was only performed for I_NORMAL or higher creatures... meaning that
eels, hell hounds, and many other things were literally too dumb to
realize they could shoot across water or lava if they could not ALSO
walk straight up to their target. One of the most noticable effects
of this was eels sometimes appearing to retreat or generally move
oddly as they attempted to path to the player's position via some more
circuitous route when you touched against water non-adjacent to them.
I see no reason for an intelligence check here at all (the monster is
clearly smart enough to shoot at you most of the time), and so have
simply removed it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make sirens even more likely to prefer deep water than before (to
the point of being willing to move past the player to reach some, when
previously they never would if shallow was available closer to them).
Given how key it is to their offense, it seems important to prioritize
it further.
Also adjust siren pathfinding slightly so that they will attempt to
move around the player instead of stopping in front of them, if you
happen to bar their path.
Finally, remove siren's melee attack altogether. It almost never
works anyway and was harmless even when it did. It is better not to
give the illusion that she will actually hit something when she so
rarely does, I think.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
I left them only where the contents is not indented, like in a namespace
or a template.
|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
Being able to awaken trees and pull you next to them is a strong
combination on its own, it's not necessary for them to also hide in the
trees while doing so.
Removes a lot of code for handling wall movement since rock worms are gone
too, but leaves HT_ROCK - it appears that spatial maelstroms sort-of-use
it (not sure if they actually need it, though).
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
It was really weird: working on a square, but in almost all cases
restricting it to your view (a circle). Note this is _your_ view rather
than from the iterator's center -- which hasn't been used once in the
obvious interesting way.
As usual, this commit fixes a load of "act through glass" bugs, ando/or
using los modes that don't make sense in the context.
|
| |
|
|
|
| |
This also fixes a bunch of "act through glass" or "doesn't obey nightstalker/
lantern of shadows" bugs.
|
| | |
|
| |
|
|
|
| |
Seriously, even preparing this commit gave me a pain in the triangle between
the thumb and index finger's bases and the wrist.
|
| |
|
|
|
| |
It degenerated to a simple loop over menv, hardly worth any syntactic sugar.
I kept it for now, though.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Does the "in view" part of functionality of monster_iterator, is simpler,
allows using los models other than LOS_DEFAULT, and gets rid of a lot of
uses of get_los().
The code is nearly identical as actor_near_iterator, but the old delegation
used more code than either of those. Still, perhaps templating could work?
This commit also fixes a buttload of ignoring invis / see invis / sense invis
(ie, visible_to()) and act-through-glass bugs.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unintelligent hostile monsters would reset their patrol point
whenever the time came to return to it from out of sight, which
meant that setting them as patrolling did nearly nothing at all.
Friendly unintelligent monsters (most likely zombies) behaved
somewhat differently, but still tended to wander greatly instead
of staying put. Unintelligent does not necessarily mean bad at
following orders, though (one would expect a golem set to guard
a specific spot wouldn't forget about it immediately once
distracted), and several vaults function with the assumption
that telling a monster to patrol will actually do this.
Now there is no longer an intelligence distinction to this
behavior and patrolling monsters will all patrol as they should.
On the player side, this means that zombies told to wait will do
a better job of actually staying put and not wandering the level
- probably this is an okay and perhaps even more desireable
behavior than the old, though it could easily be restored without
affecting hostile monster behavior, should someone wish to.
|
| |
|
|
|
| |
These print the out-of-bounds coordinate as part of the assertion
message.
|
| |
|
|
|
|
|
|
| |
The word "familiar" suggests a summon rather than a magical construct; this
spell is much more like Conjure Ball Lightning than Call Canine Familiar.
Since the suggestion "battlesphere" has met with great approval (or at
least nobody has come up with better), let's use that.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a level 4 conjurations/charms spell which conjures an arcane familiar that
follows the caster around and fires blasts of energy at its creator's target whenever
they cast any projectile-based conjuration.
Like orbs of destruction, they cannot be directly commanded, but should generally
do their job with minimal fuss on the player's part. Unlike orbs of destruction,
they can be targetted and destroyed by enemies.
The familiar is created with a small number of charges. Each time it fires, a charge
is consumed, and the familiar will expire when all these charges are expended
(or after a moderate length of time, if they are not). Only one familiar can be
active at a time, but recasting the spell while one exists will give the familiar
additional charges (up to a limit) and also recall it if out of sight.
If it does not have a clear shot at the chosen target, it will attempt to reposition
itself so that it does; if it can reach a valid spot before the next player turn, it
will fire its own volley, otherwise no shot will be made (though it will hopefully
be better positioned so that it can mirror your spell on the following turn).
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
For most header files, this only saves on having to recompile a
small number of source files, but there are also a few headers
where small changes would now take significantly less time.
This is most obvious for the Tiles build for which the dependencies
have been greatly reduced, so that the only additional includes
when compared to console are strictly library or tile related.
|
| |
|
|
|
|
|
|
|
| |
For a summon to be able to attack a target (by whatever mean), both it and
its target needs to be in LOS of the player. It doesn't have to be actually
visible, but it cannot be behind glass (the check is cell_see_cell_no_trans).
Aditionally, wandering friendly summons will try to stay in sight of the
player.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
I had to rename distance() (in coord.h) to distance2() because it conflicts
with the STL function to compare 2 iterators. Not a bad change given how it
returns the square of the distance anyway.
I also had to rename the message global variable (in message.cc) to buffer.
I tried to fix and improve the coding style has much as I could, but I
probably missed a few given how huge and tedious it is.
I also didn't touch crawl-gdb.py, and the stuff in prebuilt, rltiles/tool
and util/levcomp.*, because I have no clue about those.
|
| |
|
|
|
|
| |
Non-wizmode crashes already have that.
Also, reveal the monster's identity, it's almost always out of LOS.
|
| |
|
|
| |
For way too paranoid and underinclusive values of "simple".
|
| | |
|
| |
|
|
|
|
|
| |
Having both it and LOS_RADIUS is misleading, especially as they're
arbitrarily used. This distinction doesn't make sense anyway, as any
LOS changes need to be done at runtime, only the max matters during
compilation.
|
| |
|
|
|
|
|
|
|
|
|
| |
Allow games to use different root branches. Currently this is Zot for
zotdef, and Dungeon for everything else.
If there are reachable branches that precede the root branch in
branches[], the ^O screen will incorrectly print them first. This is
not currently the case for any game type, and isn't likely to be the
case in the future, because branches[] is for the most part
topologically sorted.
|
| |\ |
|
| | | |
|
| | | |
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Its name suggests it's about line of effect, while in fact it's both effect
and sight. Thus, I've split its uses into LOS_SOLID and LOS_SOLID_SEE -- the
former is what LOS_SOLID was usually understood to mean, the latter is what it
actually was (being targettable with an arrow/beam).
The difference is: LOS_SOLID_SEE obeys clouds.
The name of the latter is abysmal -- if you have a better idea, please sed.
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
| |
This should never happen for hostiles, but you can teleport into and summon
stuff. You can even aggro your summons so an allegiance check wouldn't be
right.
Keeping the assert, though -- in any case where it fails, the monster would
stare blankly into the space, not responding to attacks. Better to crash
than to give a free victory.
|
| |
|
|
|
|
| |
We shouldn't expect the player to always be reachable by monsters except
if the player is on the ZotDef map itself, so we mustn't crash about this
unless the player is actually in a dungeon-type level...
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Pathfinding uses chebyshev metric.
|
| |
|
|
|
|
| |
When a monster with an intelligence >= I_ANIMAL is attacked but cannot retaliate it
will retreat. This is similar to fleeing but the conditions for it to stop are
different (and a bit randomized).
|
