| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
| |
The only place it was used.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
...by moving bloodspatter functions into their own file.
Death to misc.cc! Long live the new file hierarchy!
|
| | |
|
| | |
|
| |
|
|
| |
Or of any other monster with M_NO_SKELETON.
|
| |
|
|
| |
"One of Your potions of coagulated blood[...]"
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Item inventory weights (based on item mass) generally don't lead to
meaningful decisions that justify the inventory juggling and interface
problems that come from having burden states. The 52-slot limit is a
better system for limiting inventory and providing inventory-related
decisions because it's not so fine-grained and doesn't require the
player to examine weights for each slot. Work is ongoing to improve
the slot system by consolidating food types and handling strategic
consumables in a different way.
|
| |
|
|
| |
There's probably a bunch more obsolete code for this still lying around.
|
| |
|
|
|
|
| |
Trying to pick up a consumable while under Gozag penance occasionally
turns the consumable to a small amount of gold - more likely with higher
value items.
|
| |
|
|
|
|
|
|
|
| |
Pay half the value of items in one of three randomly generated shops to
generate that shop on a level that can generate shops that you haven't
visited yet. This shop appears on the Overview screen with a darkened
level name so you know exactly where it appeared, and is announced (and
its location marked) when you arrive on the level so long as you are
still following Gozag at the time.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In the case of rings/amulets that identified themselves when they
had an effect, the player would want to try to put themselves in
a position where the item would identify, which was techincally
optimal but quite annoying. There were a few items that never
would identify, but on the whole it's not worth keeping around
the behavior just for them.
The ID code is pretty confusing and it's quite possible the
implementation is not ideal or there are actual bugs.
|
| |
|
|
|
|
|
| |
It was something that was almost never relevant but that cluttered
up the code regardless. If it were to be more relevant that would
not really be a good thing since a chance for instadeath is rather
bad design.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The prompt to hit an enslaved creature differs very little regardless of
your god, even if it would cause penance with that god. This patch makes
such attacks require yes_or_no like walking into a Zot trap instead of
yesno, and explicitly states that it will cause penance with your god.
For reference, only betrayal attacks under Okawaru and the good gods,
attacking neutral creatures under Elyvilon or TSO, unchivalric attacks
under TSO, and plant betrayal under Fedhas is affected; attacks with
brands offensive to your god are not, and neither are attacks which
only cause piety loss.
|
| |
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Instead of trying to differentiate sanctuary vs. other conduct issues, just
count them equally as a conduct violation, which seems the intention of
bad_attack() anyways. Elec attacks for targets in water and devastator also
give conduct prompts now with no double-prompting.
|
| |
|
|
|
|
| |
The player can target an in-range empty square for jump attack. If it turns out
that the square is empty, the jump-attack fails and the player rebounds to their
original position, losing the turn.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Player chooses a monster target within range where there's at least one valid
landing site adjacent to the target.
* There must be a monster to target to use the ability, but the monster can be
friendly or neutral.
* A random valid landing site is chosen, the player is moved to that square, and
weapon melee occurs against the target at the landing site.
* Jump attacks are melee with the wielded weapon and get a 20% damage bonus
* Valid landing sites are always habitable squares with no monster and no
thing that's dangerous to the player.
* Flying monsters or giant monsters not standing in deep water or lava can
'block' the path of a landing site by being in the ray path from the player to
the landing site.
* If a visible monster blocks the path to a landing site, it won't be considered
as a valid landing site.
* If something invisible blocks a landing site, the site will be shown as valid
and can be randomly chosen, in which case the player 'rebounds off something
unseen' and never leaves the starting square, but wastes a turn (delay 10aut).
* If the player is adjacent to the monster, sites adjacent to the player are not
valid; you have to 'jump over' the monster in this case.
* Player can't jump if exhausted or standing in water/lava/liquefied ground
* Exhaustion duration is set after jump (regardless of success) to prevent a
second jump, with a duration formula that's the same as the breath duration.
* The usual melee checks wielded weapon/friendly etc. checks are performed for
the jump melee.
* If any of the valid landing sites would cause problems with self-electrocution
or sanctuary violation, the player is warned first.
* Range is determined by evocations training; starting attack range is 3
(movement 2), and it increases by one at evocations 5 and 10.
* The cost of the jump is 2MP and a hunger cost using the same calculation as
for flame breath.
* The delay of a successful jump is the same as melee delay.
* Fail rate for the ability calculation based on evoke taken from breath fail
rate code
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 should have no effect on their functionality, but further
unifies related code.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Each terrain change specifies a desired feature, a duration (which may
be INFINITE_DURATION), a terrain change type (used for reference and
stacking at the moment), and optionally a source monster (if one is
specified, the terrain change is undone upon the monster's death)
A temporary terrain change will automatically revert to the original
underlying feature when it times out, or the source monster is killed.
There can only be one terrain change of a given type at a single
location. A new change of the same type will overwrite the old one
if it either changes the terrain to a different feature type than the
old one, or has a greater duration than remains of the old one (this
will change the associated source monster, if appropriate).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
bolt::handle_stop_attack_prompt only checked the first enemy; if
there was no need to prompt about that enemy, it was treated the
same as an explicit "no" response to the prompt, so subsequent
enemies were not checked. But maybe you're worshipping TSO, the
first enemy is alert, and the second is asleep :(
Now we check whether the user was actually prompted, and only mark
the tracer_info as dont_stop if they were.
Also, don't prompt twice for the same beam, even if one target is an
ally and another is a bad_attack enemy. Previously stop_attack_prompt
was called once for the first enemy and once for the first ally.
|
| |
|
|
|
|
| |
This might be portability for portability sake (Solaris is so dead), but
come on, we can't disappoint Igor Pashev by porting our stuff later than
several hours after the first installable build of Dyson is released :)
|
| |
|
|
|
| |
Making it require investment in evocations to use as well as a turn to
activate adds a little more thought to the process of using it.
|
| | |
|
| |
|
|
|
| |
It works a little too well: misc.cc:_maybe_id_jewel() reveals all
properties of an affected artefact, not just the relevant one...
|
| |
|
|
|
|
|
| |
While this already appeared to happen if you killed the warden yourself
(since the seals are updated after each player action), if the warden
was killed by another creature, the seals wouldn't actually disappear
until the following turn. Now they vanish immediately.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
These are the watch captains of the vault, similar in stats to a
greater vault guard, with more HD and slightly better equipment.
They can evoke a rune of sealing which slams shut doors near the
player and seals them closed. Sealed doors cannot be opened by the
player by any means (though they can still be destroyed in the usual
ways), although monsters can open them freely.
The seals will expire after a number of turns, or instantly upon
the death of the warden which sealed them.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move most of the player_* functions related to amulets, and all of the
player_effect_* functions, into class actor, with some overridden in
class player. Likewise, move player_equip(), player_equip_ego_type(),
and scan_artefacts() into class player, with pure virtuals in class
actor and corresponding implementations in class monster. Also remove a
few now-redundant functions.
This commit doesn't actually make any kinds of equipment have an effect
on monsters that didn't already, but it should be much easier to do so
now, since the relevant methods are there now. Monster gourmand,
conservation, faith don't necessarily make sense, but those methods are
in actor anyway for consistency with the rest.
Fixes #6172. We now check for innate gourmand (etc.) without reference
to suppression.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
Spending more time doesn't help.
The formula doesn't make sense, needs to be not merely adjusted but made
from the ground up.
|
| | |
|
| |\
| |
| |
| | |
Yay for conflicts galore (wax removal, std:: purge, tileidx changes).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| |/ |
|
| |
|
|
| |
For way too paranoid and underinclusive values of "simple".
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
You could tediously id anything by bashing a plant or throwing it at a wall,
with as little as 0.1 skill. This is no more: every weapon has a secret
skill level needed to auto-id it. You must know enough about the weapon to
possibly id it under the old system -- having wielded it once is enough, so
are certain other ways. I intentionally didn't go into the complexity of
checking current curse status or blocking distortion/vamp.
Save compat: on training a weapon skill and certain other events for the
first time, you'll get unsightly ids of a bunch of items. Probably not
worth any effort, you are very unlikely to get multiple ids at once during
normal play.
This commit does not handle missiles: they are mergeable and thus don't have
an unique random number, it would be enough to id one with the smallest
number and then merge stacks, you are currently encouraged to keep one of
every missile with different enchantments, etc.
|
| | |
|
| |
|
|
|
|
|
|
| |
Even if we thoroughly randomized food gains and usage, there's no way to
hide 233% food loss for more than a couple or so cycles.
Not revealing the ring immediately leaves at least a bit of cost for
identifying it, and preserves status quo for spoiled players.
|
| |
|
|
|
|
|
|
|
| |
Improved colouring and transparency.
Consistency with corpse blood colour.
More variety of shapes.
Some wall bloods have inscriptions. Those ones will only be used on level
generation and only on south facing walls, because rotated inscriptions are
not so hot. And they are rare.
|
