00:47:47 Monster database of master branch on crawl.develz.org updated to: 0.33-a0-595-g69c26771d4 02:02:48 -!- rozlav87 is now known as rozlav8 02:25:09 -!- rozlav80 is now known as rozlav8 04:34:39 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5249-g4a8afe7061 07:49:13 <05icoson> they have a buggy runrest_ignore, probably. (Until somewhat recently, those didn't error, so there are a bunch of very common ones floating around in copy-pasted rc files) 07:49:39 <05icoson> e.g. a quick search shows some popular rcs with the line ignore += Jiyva says: Divide and consume 07:49:44 <05icoson> the : needs to be escaped there 07:52:01 <12ge0ff> this line is unnecessary, since there's the ignore += god:Divide and consume default setting in runrest_messages.txt already 07:54:01 <05icoson> yes, it's probably pretty old 09:09:54 <04dracoomega> So: probably completely unrelated to the actual crash, then? 11:40:38 <09gammafunk> hrm, sort of difficult to figure out absolutely every thing to test with these fixes to fixed artprops. The refactoring looks good and was reasonably straightforward (although not without some annoying dead ends), but there's potential breakage even for normal item gen 11:42:24 <09gammafunk> how do you even request a random magical stave in an item spec 11:42:51 <09gammafunk> ah, any magical staff 18:47:13 <04dracoomega> @gammafunk So, as my equipment slot refactoring gets further along and I am starting to remove now-unused code, I've noticed the client lua api that interacts with these functions. I've unified wield/wear/puton to all go through a single function now, and lua still has these as multiple different functions. And as someone who uses clua a lot (unlike me), I wanted your opinion on what you think makes the most sense to do with 18:47:13 this. a) Replace all 3 with just a single 'equip' function that does the work of all 3. (Logical, but this breaks older .rcs using the old functions) b) Keep the old functions around for backwards-compatibility, but make them all effectively an alias to the same code. (ie: you can try to 'wear' a sword and it will just wield it instead, since that's the only way you can equip a sword) c) Keep the old functions around, but make them individually 18:47:13 print an error if you call them on an object that doesn't match the type (ie: calling 'wear' on a long sword just prints a message and does nothing.) (I've removed most of these sort of error messages from the primary equipping functions, since it generally no longer makes sense for them.) (To be clear, I'm not changing UI behavior here, insofar as w/W/P still bring up lists of different sorts of items, just as now. It's just the code to actually try 18:47:13 equipping them internally is unified.) 19:03:11 <09gammafunk> It's funny, but qw actually uses the keys to wield/equip items and doesn't use the clua api functions. I didn't really know about these and haven't tried them. Probably using them would simplify things a bit. I've had to struggle through countless equipment management issues and don't exactly want to rewrite it to use that part of the API, since I'd have to also carefully refactor/extract the parts of equipment slot logic I would need 19:03:12 to retain even if I did use the API instead of keys! But to answer your question, my suspicion is that there are vanishingly few users of these functions. There are probably a very small number of weirder scripts out there for turncount-related equipment swapping things, but I've not even heard of anything specific about equipment swapping. I'm incline then to "break" RCs using the old API since there's less code to maintain. 19:04:29 <09gammafunk> We really don't have any standards when it comes to breaking the API and I've always felt free to make necessary changes even if there is breakage. 19:04:45 <09gammafunk> In this case my guess is just that there really wouldn't be a meaningful number of users affected 19:05:04 <04dracoomega> Oh, ha. I assumed qw used them for sure. 19:05:43 <09gammafunk> I looked back at the current equip code for qw and I have had to unify it. It's sort of funny that it likewise has been rewritten to have a single equip function internally 19:06:09 <09gammafunk> precisely because having all these duplicate implementations was a massive pain, each being somewhat older than the other 19:06:28 <09gammafunk> but yeah, it just send the correct action key and then any necessary destination item key 19:06:55 <09gammafunk> and has logic to know when it needs a destination item key (i.e. the slot needed for the item is full and the old item will be unequiped) 19:08:01 <09gammafunk> lua function equip_item(item, slot, keep_items) local dest_letter = equip_letter_for_item(item, slot, keep_items, true) if not dest_letter then return false end local verb = "WEARING" local key = "W" if slot == "ring" or slot == "amulet" then key = "P" elseif slot == "weapon" then verb = "WIELDING" key = "w" end say(verb .. " " .. item.name()) magic(key .. 19:08:01 item_letter(item) .. dest_letter) return true end 19:08:19 <09gammafunk> and equip_letter_for_item() has a bunch of logic for checking slot fullness etc 19:08:41 <04dracoomega> Feels like it would have been easier to use this other API in the first place, but at least nothing I do seems likely to break any of this ^^; 19:08:57 <04dracoomega> (But really, the clua api is very mysteriously documented in general, imo) 19:09:02 <09gammafunk> well, I'm not sure how the api deals with items in the existing slot 19:09:26 <09gammafunk> which is what equip_letter_for_item() has to inspect etc 19:09:39 <04dracoomega> I think it currently brings up the same sort of prompts the player would get if pressing 'P' manually or whatnot 19:09:45 <04dracoomega> Er, on the item 19:10:13 <09gammafunk> well, I need to not have a prompt; hence qw has to just "send the keys" 19:10:23 <09gammafunk> so it's sending 2-3 keys 19:10:31 <09gammafunk> always at least two (one for action, one for item to equip) 19:10:35 <04dracoomega> I meant the 'press button for ring to remove' thing 19:10:38 <09gammafunk> and possibly a third for destination 19:10:59 <09gammafunk> right, but I'm saying that this prompt must not occur for qw 19:11:01 <09gammafunk> it can't use it 19:11:11 <09gammafunk> hence if that's the case, it can't use the api 19:11:42 <09gammafunk> but again I haven't actually tried; I should mess with them at some point 19:11:54 <04dracoomega> Oh, I thought what it was currently doing via sending keys was just handling the prompt via keypress 19:12:07 <04dracoomega> By knowing the correct sequence in advance 19:12:25 <09gammafunk> yes, exactly 19:12:52 <04dracoomega> Oh, but I guess if you call a remove function in the api and then it needs a keypress, you have to do the sending keypress thing anyway 19:13:01 <04dracoomega> So it's maybe not saving as much 19:13:06 <09gammafunk> yep 19:13:24 <04dracoomega> (Funnily enough, the api currently has a unified remove item function. Just not a unified equip one. 19:13:50 <04dracoomega> And the unified remove function is still like 15 years old, so it's hardly new 19:14:12 <09gammafunk> yeah, I'm not quite sure how this api evolved 19:14:20 <09gammafunk> again, I'd be interested to see any rcs that actually use it 19:14:26 <09gammafunk> but I don't think I've seen one 19:15:28 <04dracoomega> Either way, I guess I won't try to keep any legacy functions around 19:15:54 <09gammafunk> sounds good; if somehow there's some big resulting complaints, we can always do the extra work and add your (b) or (c) options 19:18:41 <04dracoomega> Suddenly wondering if anything will have changed on the keypress sequence angle that would affect qw. Probably not? You can swap on a two-hander without having to manually remove your shield first, but it's not like manually removing your shield first works any differently. 19:35:28 <09gammafunk> yeah, doesn't sound like it would. qw does have logic for unequipping items: lua function unequip_item(item, slot) if not item or not item.equipped or not can_swap_item(item, true) then return false end local verb = "REMOVING" local key = "T" if slot == "ring" or slot == "amulet" then key = "R" end say(verb .. " " .. item.name()) magic(key .. item_letter(item)) return true end and 19:35:29 for switching from e.g. shield + 1h to 2h or vice versa, it simply has unified logic to know when it should do this as part of its plan cascade 19:35:51 <09gammafunk> if something does break, it's always fixable since we can modify our key sending logic appropriately 19:37:04 <09gammafunk> by "do this" I mean "take off our shield before wielding the two-hander" 19:37:52 New branch created: pull/4186 (1 commit) 13https://github.com/crawl/crawl/pull/4186 19:37:53 03pyy15694102 07https://github.com/crawl/crawl/pull/4186 * 0.33-a0-596-g5b3bcc8925: Fix: no prompt when invoking Summon Divine Warrior while having Fulsome Fusillade active (#4182) 10(24 minutes ago, 1 file, 2+ 0-) 13https://github.com/crawl/crawl/commit/5b3bcc89250d 20:39:21 -!- The topic of #crawl-dev is: Crawl Development | https://github.com/crawl/crawl | Logs: http://s-z.org/crawl-dev/, temporarily http://crawl.akrasiac.org/logs/cheibriados/ | People with +v have commit access, devs on bridged discord as well | General Crawl-related chat to #crawl | Long stuff to a pastebin service, please 20:39:21 -!- The topic of #crawl is: Play Dungeon Crawl Stone Soup online now! Type ??online for instructions, ??lg / !lg for play stats | PM Sequell for long queries | http://crawl.develz.org | FooTV game replays: ??footv for instructions | #crawl-dev for dev discussion, #crawl-offtopic for offtopic 20:52:44 <06pleasingfungus> @dracoomega minor - what do you think about making sheza's dance & resonance strike into metalcraft? 20:54:22 <04dracoomega> Seems fine, but affects basically nothing. (Well, I guess a spell being Forgecraft is one of the rare situations of it actually marginally mattering for a monster spell, since creatures created by a Forgecraft spell are valid targets for Percussive Tempering. Which I guess would make those dancing weapons temperable when other dancing weapons are not, hmmm) 20:54:47 <04dracoomega> (Relevant basically only if you bind Zenata or something, I guess) 20:54:56 <04dracoomega> Resonance Strike feels like an easy fit, at the very least 20:55:28 <06pleasingfungus> i'm going to go do chores but just wanted to float that, since i randomly thought of it earlier 20:55:39 <09hellmonk> does it still affect spellbinder or did we change how that works 20:55:47 <06pleasingfungus> probably it does but like 20:55:50 <06pleasingfungus> unrands aren't real 20:57:29 <06pleasingfungus> btw, tyvm for the ongoing devwork! makes me happy whenever i pop back in here 🙂 21:00:20 <04dracoomega> Spellbinder is very sad these days, anyway 21:00:34 <04dracoomega> I've regularly felt something else ought to be done with it 21:01:13 <04dracoomega> Also, glad to hear you think so! ^^; (I am deep in the mines of refactoring equipment slot code for the last... weeks?? Making decent incremental progress, at least) 21:02:04 <04dracoomega> But you may be happy to know that it involves fewer coglin special-cases than currently exists ^^; 21:05:47 <04dracoomega> Also fewer Lear's special cases 😛 21:06:20 <04dracoomega> As I have seen many commits of you sighing deeply at that thing over the years