00:33:35 Unstable branch on cbro.berotato.org updated to: 0.33-a0-798-g13cf12185f (34) 00:51:23 gimp (L22 DsHu) ASSERT(!invalid_monster(&mons)) in 'mon-death.cc' at line 2205 failed. (Elf:1) 00:55:28 Monster database of master branch on crawl.develz.org updated to: 0.33-a0-798-g13cf12185f 04:34:58 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5261-gd9800d219b 05:28:07 Unstable branch on crawl.akrasiac.org updated to: 0.33-a0-798-g13cf121 (34) 05:47:32 03advil02 07* 0.33-a0-799-gc9bed652d4: fix: maybe fix a crash in stale pid handling code 10(2 minutes ago, 1 file, 3+ 2-) 13https://github.com/crawl/crawl/commit/c9bed652d4dc 06:32:30 -!- Changesite1 is now known as Changesite 06:36:52 -!- Changesite1 is now known as Changesite 07:04:58 <06wensley> Are we certain that crawl's PRNG is expensive? PRNGs should be extremely fast, and AFAIK crawl's current one was written by bh, who is legitimately one of the world's foremost experts on this topic (was the RNG czar at Google) 07:06:23 <06wensley> Of course that was in like 2010, but I'd still want to see a benchmark before presuming the PRNG is the bottleneck 07:07:26 <06wensley> Aside, I have seen other fantasy games use "celerity" to specifically refer to swiftness of traversal 07:53:15 <06mumra> yeah i strongly suspect you're right there ... they are maybe conflating RNGs with cryptograpic RNGs or other related cryptography which can get rather more expensive 08:01:22 <06mumra> as far as i can see the main work involved in generating a random number is: uint32_t PcgRNG::get_uint32() { count_++; uint64_t oldstate = state_; // Advance internal state. Use the 'official' multiplier. Don't change // this without carefully consulting official sources, as not all // multipliers are ok: see // http://www.pcg-random.org/posts/critiquing-pcg-streams.html 08:01:22 state_ = oldstate * static_cast(6364136223846793005ULL) + (inc_|1); // Calculate output function (XSH RR), uses old state for max ILP uint32_t xorshifted = ((oldstate >> 18u) ^ oldstate) >> 27u; uint32_t rot = oldstate >> 59u; return (xorshifted >> rot) | (xorshifted << ((-rot) & 31)); } 08:01:50 <06mumra> mostly just bit operations, nothing expensive here 10:17:24 03Cgettys02 {gammafunk} 07* 0.33-a0-800-g511808601d: ci: Generate docs in CI and publish to GitHub Pages 10(4 days ago, 2 files, 68+ 0-) 13https://github.com/crawl/crawl/commit/511808601de0 10:26:22 <09gammafunk> woot 10:26:24 <09gammafunk> https://crawl.github.io/crawl/lua/index.html 10:26:31 <09gammafunk> just had to enable github pages 10:35:28 <09gammafunk> We'll have to work on that index page at https://crawl.github.io/crawl/ ; the FAQ is probably still not a doc we want to feature so prominently. Maybe just the README, which could be updated with e.g. lua doc links 13:41:59 glosham (L7 OpFw) Crash caused by signal #11: Segmentation fault (D:4) 13:42:27 !crashlog glosham OpFw xl=7 13:42:32 1. glosham, XL7 OpFw, T:2537 (milestone): https://underhound.eu/crawl/morgue/glosham/crash-glosham-20250127-204159.txt 13:43:54 something about a clockwork bee casting a spell,, possibly while it's being wound 16:41:15 Unstable branch on underhound.eu updated to: 0.33-a0-800-g511808601d (34) 16:48:55 <06mumra> not the bee casting a spell. it's just the method that's called when you wind it 16:51:20 <06mumra> // Couldn't find anything, so just deposit an inert bee near us if (!targ) { mgen_data mg = _pal_data(MONS_CLOCKWORK_BEE_INACTIVE, random_range(80, 120), SPELL_CLOCKWORK_BEE, false).set_range(1, 2); mg.hd = 5 + div_rand_round(calc_spell_power(SPELL_CLOCKWORK_BEE), 20); if (monster* bee = 16:51:21 create_monster(mg)) { mprf("Without a target, your clockwork bee falls to the ground."); // Still remember our original target, just in case it merely // ducked out of sight for a moment and the player wants to // reactivate us. if (targ) bee->props[CLOCKWORK_BEE_TARGET].get_int() = targ->mid; return; } } 16:51:21 Something is up here, the if (targ) should always be false since it's all inside a if (!targ) 16:53:45 <06mumra> i don't see any y glyph on the map so somehow the bee has disappeared 17:00:23 <04dracoomega> I can't speak to the crash, but I can see what I was trying to do there 17:00:35 <04dracoomega> (The reason for it is slightly outside the copied snippet) 17:01:31 <04dracoomega> But basically, the logic was meant to be: -Try to use saved target -If saved target isn't around, find the next-best one that is in sight -If nothing is in sight, flop on the ground, but if we had saved a target that still exists, preserve it on the bee, for its next activatioon 17:01:51 <04dracoomega> (Needs to store that in a different variable, since it already got wiped out, though) 17:03:04 <04dracoomega> The not-entirely-rare situation this was trying to address was: -You wind up against a monster -While moving towards you, that monster steps briefly out of sight at the very moment the bee deploys -By the time you go to wind your bee, there are multiple monsters in sight, and it would be nice if it remembers to prioritize your original target (this was requested by somebody) 17:03:09 <06mumra> i'm thinking the player was over deep water so it failed to create the bee; this still shouldn't cause a segfault since everything checks for bee to be truthy but clearly something happened 17:06:38 <06mumra> aha 17:07:07 <04dracoomega> Looks like monster* targ = monster_by_mid(you.props[CLOCKWORK_BEE_TARGET].get_int()); could segfault if the prop doesn't exist by that time (though that's not supposed to happen either) 17:07:15 <04dracoomega> Or maybe it can't 17:07:23 <04dracoomega> Actually, I guess that's safe 17:07:32 <04dracoomega> It just returns an empty value 17:07:43 <04dracoomega> (What are you 'aha'-ing about? ^^; ) 17:08:48 <06mumra> so, if targ is null somehow, AND then the "inactivate" bee fails to create, it will fall through to the final section, where it creates an "active" bee and assumes that targ exists at this point 17:09:19 <04dracoomega> Oh! 17:09:29 <06mumra> so segfault could be on this line doing targ->name 17:09:30 <06mumra> https://cdn.discordapp.com/attachments/747522859361894521/1333589736329052210/image.png?ex=679971ba&is=6798203a&hm=5c029d1e532c8b7776be74765e63259134fe1a7f8f10819a1f18e8cd70c445a9& 17:09:38 <04dracoomega> Yeah, makes sense 17:09:48 <06mumra> presumably an inactive bee is not flying therefore can't spawn on deep water 17:09:50 <04dracoomega> Just needs an else for the earlier block 17:09:51 <06mumra> but an ACTIVE been can 17:09:53 <04dracoomega> Yeah 17:10:34 <04dracoomega> (And honestly, a bee being able to fall into water because its power ran out is a feature, imo :P) 17:17:29 <06mumra> yep which seems totally reasonable 🙂 17:17:49 <06mumra> i'm not sure how targ got to be null in the first place as the gnoll appears to be in sight and there's no messaging to indicate anything else happened 17:20:37 <02Monkooky> ally targets remain stupid 17:20:50 <04dracoomega> Yes, but unrelated 17:20:53 <04dracoomega> Bee doesn't care 17:21:01 <02Monkooky> oh wait yeah this is the bee specific target 17:21:10 <04dracoomega> Bee very explicitly doesn't care, in fact ^^; 17:22:28 <04dracoomega> Anyway, after spending a fair bit of time yesterday investigating and discussing how to potentially give forms real mutations, I decided that it was even more tricky than anticipated (a bunch of it to do with mutation conflicts and stacking behavior with non-form mutations, which aren't just implementation issues, but semantic ones), I decided to opt for letting the player examine fakemuts for a longer description, instead. That's 17:22:28 the most meaningful thing that form fakemuts are currently lacking, I think. (rPois and cold-blooded have hotkeys since the fakemut names already match those of existing mutation descriptions, but it's easy to add descriptions to anything we choose) 17:22:29 <04dracoomega> https://cdn.discordapp.com/attachments/747522859361894521/1333592998881001574/image.png?ex=679974c3&is=67982343&hm=e9824a7466b50ee3f514ef7ed5becef912c41544a5b1bcae4d9681cf11ddec34& 17:22:37 <06mumra> _get_clockwork_bee_target is checking !mi->wont_attack() tho 17:22:59 <04dracoomega> (It doesn't really matter for those two here, but there are more complicated ones that could benefit from it for sure) 17:23:46 <04dracoomega> Flux melee (and probably melee properties on several forms), arguably things like being insubstantial... 17:24:15 <04dracoomega> (Vampire form definitely wants it, which was the impetus for doing it right now) 17:28:26 <04dracoomega> A quick glance at the map suggests the gnolls are probably on the other side of glass 17:28:26 <06mumra> actually looking at the messages again, there seem to be 2 different gnolls and a gnoll sergeant, but only two gs on the map; so definitely one of them has stepped out of view, which must have been the targetted one 17:28:26 <04dracoomega> Since there does seem to be a wall in the way 17:28:26 <04dracoomega> Despite being able to see them 17:32:13 <06mumra> yeah the lack of map colour threw me 17:37:08 <06mumra> looks very cool actually (will be really good to get some equivalent for monster statuses as well) 17:37:41 <04dracoomega> Index was working on the latter subject yesterday, in fact 17:45:56 <06mumra> yes as i saw .. was wanting to add some extra detail for some statuses i was implementing but there was nowhere to do it 19:29:21 Lobster4 (L24 TeAE) ASSERT(in_bounds(source)) in 'beam.cc' at line 744 failed. (source = (0,0)) (Depths:3) 21:16:24 <04dracoomega> So, as I go around cutting out various old-vampire related things, I arrived at the table of vampire attributes I remembered being hard-coded in game.html and went to trim it out. But I noticed while doing so that the footer labels for the mutation panel weren't accurate even outside of that (form properties weren't mentioned, for instance). So I began to wonder if any of this was even used at all. And apparently (after compiling in 21:16:25 webtiles to check) removing the entire mutations panel div there doesn't seem to affect the mutation panel negatively. Out of curiousity, I deleted a few others, and doing so for all of them (ie: describe-monster or describe-god) caused the UI element to print an error message. But the mutations menu doesn't seem to care. Which is leaving me confused as to what it is using, since it doesn't seem to be using this. 21:17:25 <04dracoomega> It doesn't look like the relevant UI-handling javascript is making substantively different calls, but my understand of this is extremely rudimentary. 21:18:13 <04dracoomega> (In general, I think things were aren't being used, but are easily confusable for things which are, are good to remove. But I would like to understand why this is working.) 21:19:00 <04dracoomega> If anyone who actually understands this stuff better than me has any thoughts, I'd be all ears ^^; 21:43:35 <04dracoomega> Well, I have found part of the answer, which is that the mutations() and mutations_update() functions appear to not be being called at all. Though the menu is working, so something else must be. 22:34:31 <06pleasingfungus> draco: oh, i was about to respond to your last comment by suggesting allowing examining fakemuts 22:34:44 <06pleasingfungus> great minds... 22:35:15 <06pleasingfungus> (by 'your last comment', I mean the one beginning "Also: I'd hoped to put this off...") 22:37:20 <04dracoomega> Hehe ^^; 23:35:08 Unstable branch on crawl.develz.org updated to: 0.33-a0-800-g511808601d (34) 23:57:10 Windows builds of master branch on crawl.develz.org updated to: 0.33-a0-800-g511808601d