notes.txt

NB: The concept of randomized monster spellbooks has been removed:

https://github.com/crawl/crawl/commit/bc7614a589d44ba8a134ede3e547d9d85f470a25
this commit removed multi-books as-a-thing from most mons, except deep elf mages and liches

https://github.com/crawl/crawl/commit/97bf95f3a4eb27709f8eba932d03cda88303a32d
https://github.com/crawl/crawl/commit/4c84cb832125a208706bc18fce23bec912d4fb57
deep elf mages and liches multibooks, removed

https://github.com/crawl/crawl/commit/3d1ca0d2d81d10d4c5f25e9f2ea6d83abcc60257
this commit removed the underlying multi-book code

At time of writing, dcss.io was never regenerated after those commits:
https://doc.dcss.io/modules/monster.html#monster.info:spells
still references the obsolete behavior.

https://github.com/crawl/crawl/commit/3d1ca0d2d81d10d4c5f25e9f2ea6d83abcc60257
Part of this commit updated the moninf_get_spells function, as monster
multi-books were removed. This function comment in l-moninf.cc may read as
though monster multi-books remain a concept somewhere, but they aren't.
Currently, this lua bind appears to return an un-named table representing {book},
containing a table of {spell names}.

note: this bind does *not* return draconian breath attacks as known spells.
I have no idea if any other monster natural abilities are missed by this bind.
I briefly tested some non-draconians, and their natural abilities were all
listed as spells, but it's probably safer to assume this bind is unreliable.

-----

note: if i do a tostring() on a raw mons table entry like this:

table.insert(threat_table, {mons, threat[2]})
crawl.mpr(tostring(threat_table[1]))

crawl emits some memory hexadecimal (probably the hex of the userdata mons subtable pointer?)

-----

monster entries ordinarily lack any kind of gid, making it difficult to later identify if we've already issued a warning
for a particular monster when there are multiple of its kind in view.


-----
----> can I store / compare against each given tostring(mons), for purposes of using the memory hex as a semi-unique identifier
--for each mons instance?

--This seems like it ?might? work? Depending if the memory address in question is the pointer to the initial mons,
--or just the pointer to the later table offset?

--If I write this right I could, maybe, get this to work???
^^^ none of these memory address comparisons work.
get_monster_at() returns a new, unique object every time it's called, which has a new memory address.

this approach could maybe work if i tried to access memory locations in a different way, somehow, but not like this.

for now, i'm moving on to trying to compare against mons:pos(), which seems promising?

--------

question: what happens when you try to pull monster.info:pos() from a stored mons table entry that now references a deceased mons?

i'm thinking here about using mons:pos() as an effective-gid, since testing shows that stored mons_table entries contain
actively-updated position information, and position information is mostly-unique
(actors in dcss mostly cannot stack, fedhas plants aside)

but the question then becomes: what happens to stored mons_table entries from previous turns, that reference now-dead mons?
will they return the last known information for the mons?
or will they return nil?
or something else entirely?

i'm really hoping they don't return last known position because that would lead to a bunch of dead mons:pos() entries like
{1,0}, pointing at the spot where the character has been melee attacking.

TODO: test this?

---------

alternate design, since the above won't work:

each turn, build a stack of current_threat s as usual.

for every (previously) known_threat on the stack, you simultaneously pop a matching threat from the known_threat stack,
and pop its match from the current_threat stack, and insert the match into the new_threat stack.

if you run out of current_threat s, discard the remainder of the known_threat stack.

if you run out of known_threats,

any remaining threats in the current_threat stack at this point get added to the new_threat stack,
and here is where you issue warnings for every threat being added.

after this is completed, the new_threat stack becomes the known_threat stack.

-----

this should work, right?

do i need 3 stacks? can i do it with two?

( just do your sorting and warning while building the current_threat stack ? )


So the way I'm doing this is building a stack of current threats each turn, and comparing that stack
to a stack of known threats. Each current threat that didn't have a matching known threat pops a warning:
this allows us to, for example, pop repeated warnings for things like floating eye paralysis gaze channelling,
or to pop simultaneous warnings for multiple monsters with the same name / threat profile.

--------

-- problem set:
-- when explore_greedy is used with travel_open_doors = avoid ,
-- autoexplore stops adjacent to feature "closed_door", *without* printing any message to the log.
-- only when the player tries pressing 'o' again, *after* this stop-with-no-context, will the game print an "unopened door" message.

-- I want my script to automatically handle re-issuing explore_greedy,
-- after the initial (no context) stop.

-- questions:
-- Can I re-issue a command from within ch_stop_running?
-- Technically, I think this hook is called while the rundelay is still active -- 
-- you can see in travel.cc runrest::stop that this hook is called before stop_delay() ?
-- I suppose the quickest way to figure this out is to test re-issuing a command from within the ch_stop_running hook.

-------

-- Note: I don't think that I should be issuing actions from within ch_stop_running(),
-- because this is the wrong place to issue generic actions,
-- and I really only want to have one unified "action handler",
-- not a bunch of piecemeal scattered checks that make it impossible to analyze the codeflow / decision tree
-- conceptually, it's okay-ish to set a flag here, *if this is the only place the flag can be set*,
-- but any action that needs to be taken based on the flag should happen from the action handler.

--------

-- Note: we can't do anything re: unopened door explore within c_message(), because travel_open_doors = avoid
-- *stops without doing anything*; only the next turn's attempt to explore generates a message.
-- I think we can't issue commands here either, because this hook can be called when it's not the player's turn?

--------

    -- so, apparently the c_message() hook is pre-empted if I print a message with crawl.mpr() from within ch_stop_running....
    -- (we can't issue messages from ch_stop_running without breaking our other message search hooks?)
    -- need to limit ch_stop_running() functionality to setting script-internal flags only, I guess?

--------

-- my understanding is that the c_message hook is called when a message is sent:
-- at minimum, i think you can't expect the player will be able to issue commands here?
-- this hook is likely to be called in the middle of a monster turn / other delay?
-- TODO: look into when this hook is called

--------

# XXX: Here we bind a no-op for use by send_no_cmd() .
# The script sometimes needs to issue a null command to move to the next ready() cycle.
# We repurpose the [O]pen doors key for this, as it's mostly unused in normal play.
bindkey = [O] CMD_NO_CMD_DEFAULT
:function send_no_cmd()
:    crawl.sendkeys("O")
:end

-------

-- state tracker for the previously-sent command, for script control purposes
local previous_command = nil
function issue_key(key)
    previous_command = key
    crawl.sendkeys(key)
end

-------

    -- Note: Monsters do not target Alive player Vp with DU Range, even though the player *would* take damage from this.
    -- Its targeter in mon-cast.cc, case SPELL_DISPEL_UNDEAD_RANGE:, checks (foe->holiness() & MH_UNDEAD), which exempts Alive Vp.
    -- We return false for Alive Vp here because they are not in danger from DU in practice, at present.
    -- Undeadhunter uses the same holiness check exempting living Vp, so writing it like this seems to be okay in practice?

-------

        -- TODO: Is there any way I can auto-generate resist value needed vs. ability damage? (d10, d20, r+, d30 r++, d40 r+++)
        -- TODO: look at tengu reaver mons:desc(true) for the above: they have six types of bolt spells,
        -- could possibly auto-compare using <color> tag of spells in mons:desc()
        -- ynoxinul iron shot is the same colour as most elec spells,
        -- fenstrider witch hurl sludge is the same colour as poison spells but not resistable,
        -- LCS is white, petrifying cloud is white, most ice spells are also white,
        -- I don't think that distinguishing resistable spell element by text colour is going to work,
        -- the codebase is too inconsistent about how colour is applied
        --
        -- I could maybe reconstruct the spell to beam, beam to zap, zap to resist tables in Lua,
        -- and add an assert for (new,unknown) spells that don't exist in my tables

-------

        -- bolt of magma is BEAM_LAVA which returns 55 from get_resistible_fraction, it looks like this is 45% irresistible?
        -- looking at the code in resist_adjust_damage, resists only apply to the resistible portion
        -- bolt of fire with rF1 reduces damage by half: 3d26 becomes ~3d13
        -- bolt of magma with rF1 reduces resistible portion by half: 3d25 becomes 11.25 irres, 13.75 res, /2 == 6.875, == 18.125
        -- bolt of magma @ base 3d25 w rF1 would == ~3d18, rF2 == 15.83 == ~3d16, rF3 == 3d14
        -- by this analysis, most bolt of magma mons are fine with rF1, but scorchers and roxanne should have rF3?
        -- drac scorcher magma rF2 @ ~3d16 is ~ to margery bolt of fire 3d32 with rF1 @ ~3d16, which isn't quite enough
        -- roxanne magma rF2 @ ~14.56 is slightly better, but still ~ 3d30 bolt of fire with rF1 only
        -- I guess my gamesense that you don't need rF3 for roxanne is wrong because I never fight roxanne?

-------

        -- half done: split up warnings into 3 tiers, based on damage and resist type:
        -- t1 -> low threat (d10,d20 / rX1 ele warnings), yellow warning text, no force more
        -- t2 -> mid threat (d30 / rX2 ele warnings, ~banish?), red? warning text, force more
        -- t3 -> max threat (d40+ rX3, paralyse), purple? warning text, force more, flash screen? (maybe y/n prompt to continue?)

        -- I've broken the warnings up by tier, but I still need to implement resistance checks for the generic damage warnings

-------

        -- TODO: Dream Sheep never actually cast Dream Dust if the player has clarity,
        -- *even though* clarity does not strictly make an actor immune to Dream Dust.
        -- grep _foe_sleep_viable( for details.
        -- I need to fix this, but player::clarity() is unexposed through clua.
        -- Reconstructing it independently on the clua side is possible, but it has several conditions,
        -- and it would be better if a simple clua bind to bool player::clarity() were added.
        -- Looking into this opened another can of worms re: /other/ l-you.cc clua binds that should be exposed,
        -- and, just, ugh.
        -- I don't know if I want to open a crawl PR with the dozens of issues this revealed,
        -- or if I just want to hack this one instance into my script and move on.
        -- (To be fair, player_res_torment is another such issue that I've already had to hack into my script, so, yeah.)
        -- (There was also player_movement_speed that I had cause to hack into ff.rc ...)
        -- There's also player::undead_or_demonic and player::res_holy_energy, which I've already had to hack into this script...

-------

These bindings need to be added to l-you.cc :

all of the below bindings are in player.cc, as player::thing(),
but without any corresponding clua bind in l-you.cc.

the bindings listed here are informational binds that are not-trivially-reconstructable through lua;
player:: binds that reduce to things like a single you.transform() aren't included here as they're not needed.
[I'm treating this as "does it have >= 2 conditions, and are its conditions non-obvious"]

(I should also double-check to make sure that every effect that displays pips on % is accessible through clua)
TODO: this

clarity, faith, cloud immunity, repel missiles,

undead_or_demonic, evil, holy,
nonliving, unbreathing,

res_miasma, res_torment, res_petrify, res_constrict,

no_tele (not sure if this needs to be exposed), 

you.invisible() has an incorrect binding in the clua,
it only checks you.duration[DUR_INVIS],
while player::invisible() also checks shadowform and backlit,
this bind should directly call player::invisible()

is_lifeless_undead,

can_polymorph, can_bleed, can_drink, can_feel_fear

is_nervous (fungusform nearby threatening mons check)

can_potion_heal, 

allies_forbidden

-------

TODOs:

continue to cleanup spammy/excessive T3 warnings

downgrade warnings that now match unusual item highlights to T2 warnings?

either pull in the auto-identify code from ff.rc, or re-write it?
saving time of manually identifying stuff would be nice.

add some code to autopick aux slots,
it's a pain to constantly ctrl+f aux things

add some code to autopick the usual throwables and evokables at game start

set default_manual_training = true ?

add some code to autodrop stones + disable autopick for stones past a certain point

autodrop + disable autopick for the usual consumables I don't use:
noise
immolation
torment
degeneration
attraction
++ others I'm forgetting?