| 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!
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
mons.speak prompts a monster to speak using the specified key.
view.update_monsters calls update_monsters_in_view().
These are both used in a vault that I'll commit in a moment.
|
|
|
|
|
| |
They didn't have anything specified to return then, leading to undefined
and odd behaviour.
|
|
|
|
|
| |
This stops autofight/automagic from opening runed doors to get to enemies who
are visible through glass.
|
|
|
|
|
|
|
| |
Because getting trampled into your own clouds is terrible.
Also disables this when under penance, which was an oversight for the
former.
|
|
|
|
| |
Fixes tab behaviour with Qazlal.
|
| |
|
|
|
|
|
| |
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.
|
|
|
|
| |
It returned garbage, now it returns "unseen".
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The dungeon should not arrange itself to suit the player's abilities.
Besides this general philosophical objection, there are a few actual
bugs caused by this behaviour:
* Entering a vaults level in bat form (which cannot open doors)
causes a level generation failure.
* travel_avoid_terrain = shallow_water can cause vaults to be vetoed.
* Permanent flight or levitation could allow item shifting to push
an item (even a critical item) into lava or deep water while trying
to save it.
Fixes #4722.
|
|
|
|
|
|
| |
It might be preferable to call something like _is_travelsafe_square(), but
that function does some things that we might not want here. For now, the
function just combines simple checks for cloud/trap/feature safety.
|
| |
|
|
|
|
|
|
|
| |
"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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(BREAKS SAVES) (v3)
Changes in v3 (rob):
- update to current master
- fix colouring of out-of-LOS clouds
- fix reload crash due to env.cgrid
Changes in v2:
- Features and monsters should now be properly grayed
Currently map_cell only stores the topmost "thing" in a cell.
This is good enough for the console view, but not for more
sophisticated clients (e.g. tiles).
This commit refactors the code so that all player knowledge about a
cell (including detailed monster and item information) is represented
in map_cell, and so that map_cell is used to build the console view.
Save compatibility is broken since the new map_cell is serialized
instead of the old one.
This will allow, for instance, to load console savegames in the tiles
version, and still get proper tiles for the explored area.
Furthermore, this new map_cell will be the basis of the Crawl protocol
for the client/server split.
Signed-off-by: Robert Vollmert <rvollmert@gmx.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently env.show stores information about the LOS rectangle, while
env.map_knowledge stores the rest of the map.
This unnecessarily complicates the code, makes serialization harder,
and makes it hard to change the LOS model.
This code uses map_knowledge for both kinds of data.
Regressions are quite possible.
Signed-off-by: Robert Vollmert <rvollmert@gmx.net>
|
|
|
|
|
|
|
| |
Also extract unwind_var template to unwind.h. The latter is now
included from AppHdr.h, though it needn't really be.
This means it's now possible to use coord_def in libutil.h.
|
|
|
|
| |
Now returns the feature name of the appearance of a feature in view.
|
|
|
|
| |
Also add a few previously indirect includes.
|
| |
|
|
|