| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Also cleans up some old Forest code, which might make ^O look a bit
weird on imported saves; probably not a big problem.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows us to have a consistent and logical ordering of branches
without requiring the branch enum itself to be reordered (which could
have save compatibility implications). The new ordering of branches just
moves Depths to the place in the ordering that it already is planned to
go on the next major save compat bump, but other changes are possible,
if desired. All places in the code that iterate over branches have been
updated to use the new iterator except for code dealing with save files,
which still uses enum order, so that we can change the display ordering
without affecting saves.
|
|
|
|
|
|
| |
The complaints against the branch are well documented, mostly stating
Dancing Weapons are awful enemies and the Hall of Blades is filled with
them.
|
|
|
|
| |
This fixes all the instances caught by unbrace.
|
|
|
|
|
|
|
|
|
|
| |
Spend 3000 gold for a chance of temporarily turning some of the
inhabitants of a branch good neutral, or possibly even friendly. Bribes
are only effective against newly generated monsters (i.e. on level
creation or monsters that spawn afterwards); the fund times out over
time and more quickly with the number of enemies affected, upon which
neutral enemies turn hostile again; friendly followers will continue to
follow the player subject to occasional follow-up payments.
|
|
|
|
| |
In particular, ctrl-O should no longer mention the branch.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we don't per-game brentry data, make parent_branch return what would
be the parent, rather than NUM_BRANCHES. Among other things, this
avoids leaking random branch choices in the ctrl-o screen (branches not
in the current game were never listed).
Also revert two piecemeal fixes that are now handled by the more general
code:
This reverts commit 259fcac8a0cba227ee4dc49cf5a7d5d2718cdc9c.
This reverts commit 81f5e101725dc1c0d5e96fc068a7b2b8d72b12ba.
|
|
|
|
|
|
|
|
|
|
|
|
| |
D is now 16 levels (the unsealed part was 14 levels previously), and the
Depths are six levels. Vaults is enterable from Depths:2-5; Abyss, Hell,
and Pan portals are available for the entire length of the branch.
Right now the monster set is identical to Vaults except for the absence
of Vaults-specific humans. D's monster set has also been truncated,
mainly on the out-of-depth front. It's my intent that this serve as a
starting point for figuring out what monsters we want to split between
the two branches.
|
|
|
|
|
| |
We needed to check whether its *default* parent was Lair, not whether
its parent was Lair in this game.
|
|
|
|
|
| |
Can't test Android, MSVC or Mac, but a very brief glance at the diff suggests
it's unlikely they're affected.
|
|
|
|
|
| |
Seriously, even preparing this commit gave me a pain in the triangle between
the thumb and index finger's bases and the wrist.
|
|
|
|
|
|
|
|
| |
This allows moving branches around without breaking save compat or at least
serious hacks.
The portal stack can be probably dropped now: two copies of the same level
can't exist anyway.
|
|
|
|
| |
It's easy to re-add it if we'd have a better idea for it after all.
|
|
|
|
|
| |
Among other things, this prevents G ctrl-p in zotdef from showing
"Dungeon".
|
|
|
|
|
| |
The perl regexp to do so is:
s&ASSERT\(([^\n]+) >= ([^\n]+)\);\s*ASSERT\(\1 < ([^\n]+)\);&ASSERT_RANGE($1, $2, $3);&sg;
|
|
|
|
|
|
|
| |
Forest's entrance depth and absolute depth are now the same as Crypt's.
This also adds functionality to move Tomb's entrance to Forest if Crypt
isn't placed in the game, so Tomb always exists (at present).
|
|
|
|
|
|
|
| |
Convert conjunctive assertions into separate assertions. This ought to be correctness preserving. I ran the stress tests and didn't notice anything unusual. While I have confidence in it, if you are the slightest bit suspicious of this, please roll it back.
Found instances with `ASSERT(\([^(|]*\) && \([^)|]*\))`
Manually inspected each instance.
|
|\
| |
| |
| | |
Sorry for merge commits, but rerere is pretty limited.
|
| |
| |
| |
| |
| |
| |
| | |
This does not include trunk versions older than some time after 0.11
branching, although you can upgrade such saves in two steps, by loading in
0.11 and then in current trunk. I doubt this will lead to any troubles
as 0.10 saves are not compatible anyway.
|
|\|
| |
| |
| |
| | |
Merge commits instead of rerere suck, but not being able to comfortably use
the test rig sucks even more.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|/ |
|
|
|
|
|
|
|
|
|
| |
The problematic spells happen to be the same that add a massive number of
enchantments and alter save structure, adding save compat for those would
require a lot of work and be risky.
Thus, it's easier to rewind, and then re-apply parts that we do want to
keep.
|
|
|
|
|
| |
This is incomplete, partially because of me getting bored, partially because
of doubts about the point of leaving simple addition/etc in parentheses.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
These accumulate but never get removed; no wonder compilation times keep
rising.
The includes.sh script has lots of false negatives (and positives...), and
can't check .h files which cause the biggest slowdown, it'd be nice to run
multidelta on those somehow.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
The only call to it was special-cased to return the Vestibule immediately.
|
| |
|
|
|
|
|
| |
This assumes no walkways when there's anything on the stack -- ie, no
non-portal subbranches from a portal vault.
|
|\
| |
| |
| |
| | |
This includes fixes for 64834896234968 places in master that add new uses of
LEVEL_FOO and so on.
|
| |
| |
| |
| |
| |
| |
| | |
The lair rotation is now one of spider/snake and one of shoals/swamp.
Spider still isn't finished, but it's playable. I don't know about the
branch difficulty, but we should find out soon enough.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
As a side effect, branches can now be shortened without breaking major save
compat.
This commit itself doesn't preserve compat though, even though it'd be easy
-- other parts are too nasty already.
|
| |
| |
| |
| | |
The tutorial uses it, but for encompass vaults that's not needed.
|
|/ |
|
|
|
|
|
|
|
|
| |
Old unmappable levels are gone for good, and good riddance.
Thus, player_in_mappable_area() is obsolete; I removed it and stolen the
name for "Lab or Abyss" check, done inconsistently in several places.
Also, exclusions there were problematic -- I removed them for now, please
change this back if you can fix them.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Starting from D:10, any door, stairs, escape hatch, shop fountain and
portal has one chance in 100 of being a mimic.
Branch entry vaults can be placed with a branch entry mimic.
No mimics in the temple and the vestibule. For now, those are the only
excluded places.
|
| |
|
| |
|
|
|
|
|
|
|
| |
Anything relying on it -not- checking level_type is probably obscure and should
be done in a different way. Not sure whether such cases exist.
Should fix #415[23].
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Especially constructs like: long foo = x.props[].get_int()
can get you by surprise on 32 bit arches -- even worse now that most
devs are on amd64.
Item flags I typedeffed as iflags_t, as it's likely we'll have to extend
it soon, yet defining it as uint64_t now would be misleading since there
are so many places it's used in a 32 bit manner.
|