01:38:09 grothendieck (L19 DgHu) ASSERT(in_bounds(source)) in 'beam.cc' at line 737 failed. (source = (22,69)) (Spider:1) 03:33:01 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5199-gb287095a7e 05:23:30 Oerpetix (L19 OnWr) ASSERT(in_bounds(source)) in 'beam.cc' at line 737 failed. (source = (0,31)) (Elf:1) 05:35:42 Oerpetix (L19 OnWr) ASSERT(in_bounds(source)) in 'beam.cc' at line 737 failed. (source = (0,31)) (Elf:1) 05:49:04 Zigma (L17 VpEn) ASSERT(false) in 'god-companions.cc' at line 855 failed. (Shoals:2) 05:54:49 Zigma (L17 VpEn) ASSERT(false) in 'god-companions.cc' at line 855 failed. (Shoals:2) 07:15:41 03DracoOmega02 07* 0.32-a0-1152-gbc14699165: Don't crash when monsters aim hellfire mortar near level boundaries 10(22 minutes ago, 1 file, 3+ 0-) 13https://github.com/crawl/crawl/commit/bc1469916508 07:15:41 03DracoOmega02 07* 0.32-a0-1153-g6203b1e6a4: Mention glowing orange brains' brilliance aura in description (namsan) 10(23 minutes ago, 1 file, 3+ 2-) 13https://github.com/crawl/crawl/commit/6203b1e6a422 07:46:49 Rudyous (L27 DsCj) Crash caused by signal #6: Aborted (Pan) 07:54:46 <06mumra> I did some more tweaking with sigil placement and I think I have something that works well (while largely avoiding writing two entirely separate versions of the spell for monster vs player!) One thing that became apparent is that the player (/the caster) is treated quite differently in terms of duration of the binding if they do step on one. The player has a flat random range not scaling with spellpower, whereas the monster enchantment 07:54:46 scales with the player's spellpower. If i apply the same formula with monster spellpower then targets are bound for an excessively long amount of time, and the player a relatively short time, which gives the player rather too easy an escape time. For simplicity it's probably better if the player still has a flat random range but maybe longer than with the player version. Either way there's another detail that becomes necessary: if the player is also 07:54:47 casting sigils, then they need to know which ones are theirs and which ones are the monster's, since the binding durations are going to be different. At this point the sigils need to be visually distinguishable, so probably a different colour -- unless the whole thing is simplified a bit and we don't use spellpower at all for the player's ones either, but then what effect should spellpower have? 08:03:26 <04dracoomega> I mean, it's pretty common that monster placement of things and player placement use some different code. The goals of the player spell versus the monster spell are fairly different, after all, even if they're using common elements. Distinguishing player and monster sigils is a point, though I'm not sure how likely it is that the player is casting the spell at that point in the game - and even if they were, that's a pretty terrible 08:03:27 enemy to cast it against, and even then it may be obvious from placement which is which. That being said, a slightly different color is probably okay. 08:05:01 <04dracoomega> (You should be able to check ownership of the terrain change effect that created the sigil without needing a new feature type or anything, probably) 08:16:16 <06pleasingfungus> also not totally sure it’s critical to distinguish mon and player bsigs 08:16:28 <06pleasingfungus> even if they’re slightly different effect strengths 08:16:44 <06pleasingfungus> like it’s be nice but it doesn’t seem mandatory? 08:19:08 <04dracoomega> Yeah, like... maybe a minor color difference would be fine, but I don't know how important it really is, realistically 08:19:28 <04dracoomega> (But I also don't think this would be hard to do, so... might as well, probably?) 08:24:34 <06mumra> Yeah I'm already having to check ownership as it's necessary for a few things, at very least calculating spell power, and also setting the enchantment source 08:29:43 <06mumra> It certainly seems like it shouldn't be an important distinction, but at the same time it's information the player could know but they'd have to tediously track it, if there was a situation where one duration is likely to be a lot longer than another 08:48:56 <06pleasingfungus> in theory, yes 09:19:33 Gandelf (L1 OnHW) ASSERT(valid_cursor_pos(pos.x, pos.y, region)) in 'libutil.cc' at line 404 failed. (invalid cursor position -34,9 in region 2, should be 3,9 in region 3) (D:1) 09:31:21 Zigma (L17 VpEn) ASSERT(false) in 'god-companions.cc' at line 855 failed. (Shoals:2) 09:33:51 Zigma (L17 VpEn) ASSERT(false) in 'god-companions.cc' at line 855 failed. (Shoals:2) 09:38:44 <04dracoomega> Zigma seems to be another case of that problem that occurred once a couple weeks ago where some apostle had invalid data (because somehow someone recruited 4 of them at once at one point??). I did get a save file from a game that suffered from that issue, but I never did end up figuring out the cause. 09:39:23 <04dracoomega> I ought to try again at some point 09:47:47 Zigma (L17 VpEn) ASSERT(false) in 'god-companions.cc' at line 855 failed. (Shoals:2) 10:08:22 Zigma (L17 VpEn) ASSERT(false) in 'god-companions.cc' at line 855 failed. (Shoals:2) 10:26:46 <04dracoomega> Probably I ought to also figure out how to put an assert in for when the data first breaks 10:29:41 03dolorous02 07* 0.32-a0-1154-g5d753f05ca: Give Coglins invisibility in Fedhas' Mad Dash. 10(65 minutes ago, 6 files, 25+ 4-) 13https://github.com/crawl/crawl/commit/5d753f05ca40 10:45:51 -!- Panjera2 is now known as Panjera 10:47:50 03dolorous02 07* 0.32-a0-1155-g93184b181e: Actually display equipped scarf of invis (oops). 10(3 minutes ago, 1 file, 1+ 0-) 13https://github.com/crawl/crawl/commit/93184b181efa 12:32:22 03DracoOmega02 07* 0.32-a0-1156-ga0239f6ce8: Allow placing traps via temporary terrain changes 10(24 minutes ago, 3 files, 31+ 7-) 13https://github.com/crawl/crawl/commit/a0239f6ce88c 12:32:22 03DracoOmega02 07* 0.32-a0-1157-gea327e7d78: Buff Arachne 10(17 minutes ago, 9 files, 58+ 7-) 13https://github.com/crawl/crawl/commit/ea327e7d78d3 12:32:22 03DracoOmega02 07* 0.32-a0-1158-g28453e2830: Prevent enemies from summoning in Okawaru's Arena 10(13 minutes ago, 1 file, 8+ 0-) 13https://github.com/crawl/crawl/commit/28453e28303c 12:32:22 03DracoOmega02 07* 0.32-a0-1159-g2d6ab54fa9: Make living spells count as 'conjured' 10(3 minutes ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/2d6ab54fa9ad 12:32:22 03DracoOmega02 07* 0.32-a0-1160-g066ad49fd8: Give Beogh recruit/dismiss abilities at 0* instead of 3* 10(68 seconds ago, 1 file, 4+ 4-) 13https://github.com/crawl/crawl/commit/066ad49fd8ac 12:38:13 <06pleasingfungus> huh, didn’t spot that we’d exiled arachne 12:38:19 <06pleasingfungus> makes sense re jorogumos 12:38:22 <06pleasingfungus> but so cruel… 12:39:53 <04dracoomega> Said unfortunateness is even in her description/speech now ^^; 13:27:03 <09gammafunk> we're one step away from demon nets, I can feel it... 15:37:11 Unstable branch on underhound.eu updated to: 0.32-a0-1160-g066ad49fd8 (34) 17:12:11 <04dracoomega> Huh, digging into that save file properly this time actually gave me a decent clue as to what the problem was and it's very silly 17:12:25 <04dracoomega> (And probably easier to fix than I expected, honestly) 17:13:28 <04dracoomega> It looks like the apostle data was being properly deleted when they were dismissed, but somehow they were still on the companion list (ie: the old style list of 'things you can interlevel recall'). So you'd 'dismiss' them while they were off-level, but then be able to recall them anyway, and you'd have this 4th 'orphaned' apostle, with no data, still following you around. 17:13:40 <04dracoomega> I don't think there's a theoretical limit on how many you could get, so long as you were careful about it 17:14:13 <04dracoomega> Of course, they can't be revived by Beogh, since they aren't really a proper apostle anymore. But good news! The game just crashes whenever they die, so you never have to worry about losing them 😛 17:22:40 <06pleasingfungus> hurray! 17:24:54 <04dracoomega> Basically, you have to dismiss an apostle who is in a disconnected branch, while you are not in the branch with them 17:25:37 <04dracoomega> Normally, if the apostle is off-level, it uses an excursion to got there and remove them, but it (correctly) assumes that you can't go back to a disconnected branch anyway. But then it doesn't actually remove them from the companion list either, so you can just recall them back out of the aether 17:26:08 <04dracoomega> Surprisingly straightforward to fix, and I'm fairly sure this is the underlying issue 18:13:36 make that "100% certain" (I wanted to try it) 19:19:28 <04dracoomega> I mean, I tested and I know that this works. I meant more "I think this is what happened to these people who are crashing" even if that is a tiny bit more speculative 19:19:46 <04dracoomega> And it's always possible there's some other method to end up with a similar result 21:15:50 03DracoOmega02 07* 0.32-a0-1161-gbcb4e34c79: Fix a crash-prone way of getting more than 3 apostles at once 10(2 hours ago, 1 file, 6+ 0-) 13https://github.com/crawl/crawl/commit/bcb4e34c79d6 21:15:50 03DracoOmega02 07* 0.32-a0-1162-g92b31c1b4c: Remove some seemingly unneeded companion code 10(2 hours ago, 1 file, 0+ 4-) 13https://github.com/crawl/crawl/commit/92b31c1b4c94 21:15:50 03DracoOmega02 07* 0.32-a0-1163-ga4d4a8453a: Experiment with making bands a little harder to separate 10(84 minutes ago, 5 files, 51+ 2-) 13https://github.com/crawl/crawl/commit/a4d4a8453ae5 21:15:50 03DracoOmega02 07* 0.32-a0-1164-gdbf92fe7da: Replace RevMP gizmo property with RevMPSaver 10(2 minutes ago, 4 files, 13+ 12-) 13https://github.com/crawl/crawl/commit/dbf92fe7daf7 22:17:38 03dolorous02 07* 0.32-a0-1165-gbb83fb5040: Remove unneeded space. 10(2 minutes ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/bb83fb504089 22:35:23 Unstable branch on crawl.develz.org updated to: 0.32-a0-1165-gbb83fb5040 (34) 22:58:23 Windows builds of master branch on crawl.develz.org updated to: 0.32-a0-1165-gbb83fb5040 23:35:45 Unstable branch on cbro.berotato.org updated to: 0.32-a0-1165-gbb83fb5040 (34) 23:55:13 Monster database of master branch on crawl.develz.org updated to: 0.32-a0-1165-gbb83fb5040