| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
.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!
|
| | |
|
| |
|
|
|
|
|
|
| |
Based on a note about wanting corrupted_temple to support a variable
number of altars; it can now do 6-9. (I left the lower limit at 6
because that's currently the smallest any temple is.)
Inspired by a couple of temple designs I'll probably add shortly.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
Mainly so that blood is always red; it looks weird otherwise.
They're still ID'd automatically, so this is entirely cosmetic.
This partially reverts commit 1111ebd27a4060aa07678e1af2f67a414fff2594.
Conflicts:
crawl-ref/source/ng-setup.cc
|
| |
|
|
|
| |
In neither of proposed destinies for the Forest (removal and replacement of
Vaults), it is a Vaults subbranch.
|
| |
|
|
|
|
| |
There hasn't been any changes to Crypt recently, and we know it works. On
the other hand, Forest needs quite a lot of balancing if it's to feature in
0.14.
|
| |
|
|
| |
Them having obvious descriptions was a spoily thing.
|
| |
|
|
|
| |
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 in a better shape than LO or Dj, but the consensus seems to be that
it still needs a lot of polishing and balancing.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This should hopefully make games from the same seed proceed the same on all
architectures[1], as I can't think of anything else that behaves differently
based on pointer size, endianness or exact pointer values.
I used a NIH implementation instead of passing a third argument to
random_shuffle, as the interface is so much nicer.
[1]. This will be affected by terminal size (elemental colours are not
resolved outside the screen), tile windows size (random animations),
tiles/non-tiles and possibly others.
Also, I don't think we use STL hashes anywhere, but if we'd do, the STL
implementation will matter. Please don't make this stop you: this commit
is only to make test cases from my stress tests portable which is a small
benefit, perhaps even smaller than the nicer call interface.
|
| | |
|
| |
|
|
|
|
|
|
| |
This only computes the weight of generic overflow temples once
(previously it calculated this for every multi-god temple the game
wanted to place), and re-weights specialised overflow temples to be
placed on a (weight of applicable specialised temples) / (combined
weight of above and generics of the appropriate size).
|
| |
|
|
|
|
|
|
|
| |
This also adds a primitive version of selection by weight for the
generic multi-overflow size.
Along with some tweaks made previously, it's possible to have more than
one generic multi-overflow per game; the weighting of this might need to
be adjusted if they turn out to be too common.
|
| |
|
|
|
|
|
| |
The previous cap was an error.
I'm not convinced the cap is necessary at all, but it's there for the
moment.
|
| |
|
|
|
| |
We usually use "place" to mean putting something into the grid, which
isn't what's happening here.
|
| |
|
|
|
|
|
|
| |
Right now, if there's a combination of overflow gods that has such a
vault available, the associated vault (or one of the associated vaults
if there are multiple vaults that satisfy the condition) is guaranteed
to be placed; this might need to be changed up later if we end up with a
large number of multi-god overflow vaults.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changes up the temple overflow tag syntax thus:
- Generic overflow temples now use the tag "temple_overflow_generic_N".
- Specialised overflow temples use "temple_overflow_N" and tags for
the deities they place; this includes single-altar overflow temples
(so the existing overflow vaults have been re-tagged).
The overflow vaults are now collected in dat/des/altar/overflow.des
(generic ones have been moved from dat/des/branches/temple.des).
The "good god temple" vaults (the ones that place altars to the three
good gods) have been assigned tags using the new format as an
illustration of this.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are currently only three possible maps (one each of sizes 3, 5,
and 6), so the 10% chance might be too high. On the other hand, given
how many times we see general_overflow_altar, maybe 10% is fine.
Only one multi-god overflow temple will be used per game. Changing that
is possible but avoiding duplicates is notrivial, particularly when
there is only a single map for a given size.
The selection of overflow temple size should eventually be improved to
take map weights into account; currently it chooses uniformly from among
the possible overflow temple sizes.
|
| |
|
|
|
|
|
| |
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).
|
| |
|
|
| |
(Also had to fix a prototype in ctest.h)
|
| | |
|
| |
|
|
| |
As opposed to checking the game mode every time.
|
| |
|
|
|
| |
It was not sprinty enough before; as a multi level branch it fits even less.
This saves us the need to fix related crashes :p
|
| |
|
|
|
|
| |
It'd break when save compat is bumped.
Also, clean up a warning for clear potions.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Without Evaporate, they lost their last use.
|
| |
|
|
|
|
|
|
| |
The biggest problems have been dealt with, and it would be nice to
get some feedback on the balance of the roulette pairs before 0.11
is released.
This reverts commit 2f186193e81e2b0bfa6ab956a2cfa1bfc88590c6.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
brdepth[] is loaded before any actual levels, and this way, multi-level
sprints are possible.
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| |\| |
|
| | |
| |
| |
| | |
The other three branches compete for a single slot.
|
| | |
| |
| |
| |
| | |
This disables itself automatically at 0.11 branching, but will probably be
removed earlier.
|
| |\|
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| | |
Also, fix uninitialized starting depth.
This makes an actual difference as absdepth will be one more in proper hells,
but it's not used for anything but item properties on Hell:7.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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 old Hive vaults remain in dat/des/branches/hive.des for now.
This means that the Hive portal vault only has one map at the moment,
but we can test the functionality and see how it goes, then if it's
good request more maps (or rework the old ones, if that's feasible).
|
| |
|
|
|
| |
Turn the hive into a guaranteed portal, allow queens to berserk worker
Allow bee larvae to turn into bees by eating honey/jelly
|
