lua questions


Ask fellow adventurers how to stay alive in the deep, dark, dangerous dungeon below, or share your own accumulated wisdom.

User avatar

Tomb Titivator

Posts: 857

Joined: Monday, 31st January 2011, 23:19

Post Saturday, 23rd January 2021, 08:03

lua questions

2 questions:

1. Is there a hook for general prompts, not just boolean prompts? Something like c_answer_prompt but can handle canceling a blink scroll when you identify one by reading it.
2. Is there a way to get a monster's weapon in lua (for example, to handle when a monster has a distortion weapon)? Right now I'm using monster.desc(monster, true):find("of distortion"), but that's flaky.

Thanks!
User avatar

Tomb Titivator

Posts: 857

Joined: Monday, 31st January 2011, 23:19

Post Saturday, 30th January 2021, 23:03

Re: lua questions

Just FYI, I solved both problems:

1. You can use c_message to capture prompts and respond with sendkeys
2. Regular expressions can make matching patterns in monster descriptions less flakey

New questions!

1. Is there a way to tell if there's "no reachable target in view" without pressing tab? (Is hit_closest written in Lua? Can I look at the source for that?)
2. Is there a way to tell if you have a clean shot at a monster without other monsters in the way?

Similarly, what's the difference between LOS_SOLID and LOS_SOLID_SEE? The documentation mentions "properly checking bushes and clouds" but I tested you.see_cell_solid vs you.see_cell_solid_see with a bush in the way and both returned true. I just want to know if there's something in the way when I cast my hexes. I'm literally about to try coding ray tracing in Lua and I'm dreading it >_<

Dungeon Master

Posts: 250

Joined: Thursday, 27th November 2014, 19:12

Post Sunday, 31st January 2021, 08:37

Re: lua questions

Re 1: autofight is written entirely in lua and can be found in the file autofight.lua in the crawl source tree

Re 2: Hmm, I'm not sure; SOLID vis SOLID_SEE: two bushes block los, one is transparent but blocks lof. Maybe look in automagic.lua or the new targeting hooks?

For this message the author ebering has received thanks:
snow

Slime Squisher

Posts: 368

Joined: Thursday, 11th April 2013, 21:07

Post Sunday, 31st January 2021, 17:14

Re: lua questions

You've probably done your own research by now, but here's some additional info:

Re: Unid blink scroll prompts: The prompt portion of this can be handled by c_answer_prompt -- prompt:find("cancel this blink") would handle it -- but that only handles the prompt, not the positional targeter input sink that happens prior to the prompt. As you've found, you can deal with the input sink through sendkeys.

Re: Monster weapon desc: Extracting a pattern with a regex from m:desc is also how I've been handling it. This approach is not ideal. Advil added some code in 0dde086 to access monster inventory -- but, although the context of that commit message might suggest an intent to expose it through clua, it looks like it's only exposed through dlua. (I think it would be helpful if that inventory information were exposed through clua in l-moninf, instead of through the dlua in l-mons. Maybe there were info leaks to consider that prevented an easy moninf bind for this?)

Re: "No reachable target in view!": As ebering mentioned, this is in /dat/clua/autofight.lua. You can use grep to find things like this in a git repo: git grep -n "reachable target in view" should find it.

I was looking at that autofight code a few days ago, and I'm not really a fan of how any of that autofight pathfinding is written. It has that AF_FAILS special case that doesn't exist in crawlcode, it dies when pathing is blocked by non-feature things, it refuses to consider paths outside of the you.los() radius, and (if I'm reading this correctly) it looks like it's using a greedy depth-first algorithm inside of that weird unrolled loop that often brings the player towards things regardless of whether that would be the best path? I tried looking at the commit history for autofight to get a sense of why it's written that way, but this is vintage 2009 crawlcode and it's hard to be sure how much of that is intentional, for either optimization or predictability to players.

More broadly, I think it would be nice if the conditions for autoexplore and autofight were binary: It feels bad from a UX perspective when autoexplore breaks on something, but autofight refuses to take action.

Re: LOS blocking: Personally, I was using you.see_cell_no_trans() for this, but I never reached the point in my script of adding ranged autofire targeting. view.cell_see_cell() can be used to test visibility from one tile to another, but as you've found, Crawl has a bunch of visibility checks that differ in subtle ways. (This was somewhat thorny for me when I wrote Rampaging, which has a similar visibility raytrace using see_cell_no_trans from the C side of the code, with some separate checks for the ray intersecting monsters.)

Re: How, exactly, the visibility checks differ: Uff. This is a bit of a rabbit hole, but ok.

you.cell_see_cell_solid and you.see_cell_solid_see are both defined in l-you.cc L547. Both of those functions wrap the C function cell_see_cell (losglobal.cc L116), passing a different los_type opacity parameter. Scrolling up a bit in losglobal, you can see the calls to opc_solid and opc_solid_see, grep from there and you'll find their definitions in losparam.cc L21, another grep and you'll find opacity_solid and opacity_solid_see at losparam.cc L81. It looks like opacity_solid_see has two extra checks: One for is_opaque_cloud(), another for mons_opacity(). mons_opacity() can be found over in los.cc L883, which seems to return OPC_HALF for monsters with the MONS_BUSH species flag, and OPC_CLEAR for everything else. The mons_species() function def can be found over in mon-util.cc L1311.

Here we run into what might be a bug in Crawl's code: mons_opacity() is *only* comparing the monster species flag to MONS_BUSH. Not the genus to MONS_PLANT, not the species to MONS_PLANT or MONS_DEMONIC_PLANT or MONS_WITHERED_PLANT or MONS_TOADSTOOL or MONS_FUNGUS or any other such cases. (These can be found in mon-data.h.) Possibly see_cell_solid_see wasn't intended to be used to check LOF-blocking, and may have originally been written as a connectivity or pathing check?

edit: ebering's post above puts this in context: see_cell_solid_see is literally just a LOS-blocking check for clumps of bushes and clouds like fog, I think?

So, your test was probably working fine, but the you.see_cell_solid_see() doc comment is misleading. (It will return OPC_CLEAR on monsters that aren't bushes.)

Anyway, hopefully this wall of text provides some context to wrangle one of the available binds into working with your code.

I think you're probably looking for a bind like opacity_no_actor(), but I don't see this exposed through clua anywhere. Good luck~ :/

For this message the author Implojin has received thanks:
snow

Return to Dungeon Crawling Advice

Who is online

Users browsing this forum: No registered users and 15 guests

cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.