| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
| |
Ideally, we wouldn't be using special for unrands totally different from
how items of the same type do, but that's less trivial than this commit.
A centralised place to check for being an unrand should at least make such
a change easier.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This function was misleadingly named (it only provided the skill
used for melee weapons, not ranged weapons), and incomplete;
code along the lines of "is_ranged_weapon(*it) ? range_skill(*it)
: weapon_skill(*it)" was scattered in about half a dozen different
functions. I've corrected both of those problems (renaming weapon_
skill() to melee_skill() and adding item_weapon_skill()), and also
possibly fixed two bugs in the process - an l_you.cc function that
claimed to provide the skill used for the starting weapon (but
actually only gave the melee skill), and unrand creation code that
checked if a potential unrand swap used the same (melee) skill as
the weapon type being generated.
|
| |
|
|
|
|
|
|
| |
Generally it doesn't create interesting decisions because dragons are
such a small group and are mostly a subset of monsters slowed by the
freezing brand. In addition, it has rather arbitrary effects against
players, hitting some for an degenerate amount of damage while ignoring
others.
|
| | |
|
| |
|
|
|
|
|
| |
Chris Oelmueller made an excellent patch for this, but unfortunately it
was rather rotted by the time somebody decided to look at it. It was
easier to recreate than update. I've also added some tiles stuff which
was missed in the original patch.
|
| | |
|
| |
|
|
|
|
|
| |
Toting around an unbranded weapon just to be able to swap to it
is no fun, and not even that much more of a difficulty; maybe it
just means getting pain out takes 0.7 more turns or so. You still
can't overwrite artefacts, of course.
|
| | |
|
| |
|
|
|
|
|
| |
Elec and venom launchers already use the same brands, and with ranged
code more similar to melee code this change actually simplifies most
code. There should be no gameplay change though some weird brand picking
code for launchers was refactored, which might have some effect.
|
| |
|
|
|
| |
This also removes some dead code from when Gozag abilities where
cancellable
|
| |
|
|
| |
This fixes all the instances caught by unbrace.
|
| |
|
|
| |
There's probably a bunch more obsolete code for this still lying around.
|
| |
|
|
| |
Oops.
|
| |
|
|
|
| |
This allows the correct ring slot to be registered for art-func hooks
if we choose to make any such unrands.
|
| |
|
|
|
|
| |
This allows us to more easily add or remove those hooks on existing unrands.
The data type has also been changed to FixedBitVector from unsigned short,
allowing the expanded ring slots to be referenced.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit has the following effects, which are sufficiently interconnected
that separating this into multiple commits seemed hard:
* Don't allow players to invoke potion petition unless they have enough gold
for the guaranteed porridge/blood potion.
* Don't allow players to invoke call merchant unless they have enough gold
to pay for any shop that might be offered.
* Tweak the formula for shop prices; now it really doesn't depend on the
shop type at all, and the maximum price will always be a nice round number.
* Display gold requirements in the ability screen. These numbers are slightly
misleading because the actual gold cost for potion petition or call merchant
will be a bit different from the displayed cost, but these numbers give the
player a way to tell whether an ability can be used without committing to
using it.
|
| |
|
|
|
| |
Prices are 2/3 what they would be otherwise, and removing the amulet
counts as two uses of the relevant ability for price purposes.
|
| |\
| |
| |
| |
| |
| |
| | |
The implementation is done; from here on out it's all balance work, and
that's better done in trunk.
Release the ogre hordes!
|
| | |
| |
| |
| |
| |
| |
| | |
This renders it unnecessary to try and preserve the impact of shields on
launcher delay.
A fair bit of now-dead code goes away as a result as well.
|
| | |
| |
| |
| |
| | |
Those give one level of -50/+50 stealth each. Stealth is priced at old
sustenance level (but often comes cursed), loudness around 50-60 after curses.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
#8465).
I removed the message since randarts with +/-/AC/EV ARTPs aren't
possible, and accidentally removed the check that tells the screen
to re-generate the AC/EV values.
|
| |/
|
|
|
|
|
|
| |
The ones that tell the player that they can evoke a new ability
don't seem all that useful, given the fairly clear inscription
system on artefacts. The remaining jewellery items that give a
message on equip are mostly ones that are potentially dangerous,
such as ring of fire/ice and amulet of stasis.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
| |
The comments made it clear the only reason for this was statdeath,
and 0 stats, while bad, are not bad enough to justify telling the
player when he or she has no reason to care.
|
| |
|
|
| |
For some properties, these were cryptic enough to confuse players.
|
| |
|
|
|
| |
Now for everyone with MUT_MANA_SHIELD, not just vine stalkers.
Also, refactor out the duplicated code.
|
| |
|
|
|
|
|
| |
Nothing that changes functionality or that makes the interface looks
too weird. In several of the instances the code would be weird
after moving to TAG_MAJOR_VERSION 35, so it seems worth it to remove
now rather than leaving it around.
|
| |
|
|
|
|
| |
For Shields in particular, carrying a shield is sufficient for training
purposes. Remove a number of now-unnecessary checks, including some checks
that were already obsolete for curses on wielded weapons.
|
| | |
|
| |
|
|
|
|
|
| |
Move calc_hp() to player.cc, and fix all but a couple instances where
you.hp is changed directly to use set_hp() instead. We'll eventually
just move these functions to inline methods for the player class, but
this reorganization will do for now.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently if a monster enters LOS and goes invisible on the same turn,
it can disappear from the screen before the player has a proper
indication of where it was. This commit makes the following changes:
1. Fixes invisible monster indicators so that they can reliably be set
in the monster map knowledge update code at locations that of the
current monster being processed in this loop. The previous code tried
to set this indicator, but due to how the old loop cleared all flags
other than MAP_SEEN_FLAG and did tiles cell draws in the same pass as
map knowledge updates, these wouldn't work. This commit adds a
MAP_INVISIBLE_UPDATE flag to help retain MAP_INVISIBLE_MONSTER when
necessary, as well as a second loop in show_init that loops over a
vector of the updated cells found in the radius_iterator loop. This
second loop should be fast enough that it doesn't significantly affect
performance.
2. Add 'bool went_unseen_this_turn' and 'coord_def unseen_pos' to the
monster class (with the necessary save compat code) to allow monsters
that go invisible in LOS to always get an invisible indicator. The
code prefers to use indicators arising from the monster failing
stealth checks if those occur; they are based on the monster's true
position and hence are usually more accurate.
3. Somewhat simplify the stealth check code for invis indicators, and
only ever allow one invis indicator per monster. The stealth check
logic perhaps could be simplified further (there are multiple checks),
but I've preserved the existing checks for now. Also turned a
coinflip() in one of the secondary checks into a seeded/hashed
coinflip so it won't change over screen updates.
This commit lets players with antennae always see the location of an
invisible monster through an invis indicator, and sets the invis
indicator on the monster's last position whenever a monster becomes
unseen (e.g. going invis or already being invis but the player removes
sinv). If the monster fails a stealth check, that potentially more
accurate information is favored over the unseen position.
|
| |
|
|
|
|
|
| |
Djinn games can't be started (hopefully including using the rcfile),
and djinn code should be removed on save-compat bump.
Also, schedule a few SE things to be removed.
|
| |
|
|
|
| |
At least three devs are probably waiting for this to be pushed if
they're not about to push it themselves. So now it's done.
|
| | |
|
| |
|
|
|
| |
This should be a little more clear for players, besides which there's
been some hesitation expressed about the latter.
|
| |
|
|
|
|
|
|
|
|
| |
Dithmengos hates items, spells, and monsters that cause illumination,
and particularly appreciates kills of the latter. This hatred extends to
most forms of fire (enemy of the darkness since ancient times).
There's a few questionable things in here which could stand to be looked
at (I'm including items that only glow through their description, most
notably freezing-brand melee weapons).
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In my observations of relatively recent wins by Lucy followers, very few
actually bother to take advantage of the 6* gift; this might partially
be on account of the limitations of the brand itself, but even for
weapons which pair well with it (fast-hitting weapons, axes, and the
like) players prefer other brands. I theorise this is partially on
account of being effectively restricted to use of the one weapon if the
player doesn't want to be subject to extreme negatives.
I've run this idea by quite a few people and there doesn't seem to be
any negative feedback on it as yet, so I think it's worth giving a try.
|
| |
|
|
|
| |
They now don't give messages or make noise at all when just travelling or
exploring, only when hitting things. Also reduce their noise level slightly.
|
| |
|
|
|
| |
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.
|
| |
|
|
|
| |
You can still disable them later when that titan waltz by, saving you that
precious 10 aut over just removing the boots.
|
| | |
|
| | |
|
| |
|
|
|
| |
No particular reason, other than consistency. And all but two used wasteful
double-conversion, so this is not a speed regression.
|
| |
|
|
|
|
|
|
|
| |
Also simplify quite a few cases.
It turns out in >90% cases of non-literals the argument had .c_str(),
which meant it was pointlessly malloc()ed and converted from and to
std::string. I believe a sprintf is faster, so even the argument of
miniscule speed-up doesn't apply.
|
| | |
|
