| 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.
|
| |
|
|
|
|
|
| |
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.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
level via new stairs.
Previously, even if you exited a level and reentered it using a different staircase, monsters could still retain knowledge of exactly where you were on the level for a considerable number of turns (100+), which sometimes led to the odd situation of a whole pack making a bee line for your new location on the other side of the map.
Monsters will now also lose tracking on other monsters they're targeting, if those monsters get teleported across the level.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
This also reveals how bad the beam blaming code is, need to rewrite that soon
-- mostly because of problems with reflection.
|
| |
|
|
| |
Not just physical attacks.
|
| |
|
|
| |
It is referenced many times for every monster per turn in ZotDef.
|
| |
|
|
|
|
|
| |
"File:" is shown in your editor's status bar.
"Written by:" was used only for the first person who changed a file. We got
git for that now, and pre-DCSS history is so woefully inaccurate it doesn't
really matter.
|
| | |
|
| |\
| |
| |
| |
| |
| | |
Much manual merging, and a few fixes for changes in the code (particularly
monsters->monster and the like). Now compiles and seems to work. Zot Def
added to start menu.
|
| | |
| |
| |
| | |
release branch. Quite a few edits required...
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Submerging now generally avoids damage from clouds, not just if the
monster doesn't care.
Cloud avoiding submergers don't cut short the monster action loop, so
they don't build up a big energy pool. (#2199)
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
|
|
A lot of monstuff.cc was moved into mon-abil.cc (monster abilities),
mon-act.cc (the main monster loop), mon-behv.cc (monster behaviour) and
mon-cast.cc (monster spells). mstuff2.cc was completely merged into
other files.
|
