00:59:37 -!- indigaz20 is now known as indigaz2 03:33:11 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5261-gd9800d219b 05:10:23 Unstable branch on crawl.akrasiac.org updated to: 0.34-a0-622-g6778cbb (34) 06:55:51 New branch created: pull/4731 (1 commit) 13https://github.com/crawl/crawl/pull/4731 06:55:51 03Matt Smith02 07https://github.com/crawl/crawl/pull/4731 * 0.34-a0-623-g2ce8c1f4c3: Orb of attunement also applies to Elemental Staff and Staff of Olgreb 10(3 minutes ago, 1 file, 5+ 5-) 13https://github.com/crawl/crawl/commit/2ce8c1f4c39e 07:55:28 <08nicolae> at first i thought the embedded thumbnail was the submitted image and i was like... what the hell do a blue star and a tree have to do with crawl. but also that art rules imo 10:12:46 <07acrobat> it is invisible PoSu casting summon forest with orb of stardust 10:54:24 <08nicolae> genius 12:02:44 03dolorous02 07* 0.34-a0-623-g1302c14e92: Reorder a monster check wrt umbral torchlight. 10(3 minutes ago, 1 file, 2+ 2-) 13https://github.com/crawl/crawl/commit/1302c14e920f 12:54:44 03dolorous02 07* 0.34-a0-624-g73f07e0534: Fix indentation. 10(4 minutes ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/73f07e0534c2 15:41:14 Unstable branch on underhound.eu updated to: 0.34-a0-624-g73f07e0534 (34) 20:22:43 New branch created: pull/4732 (2 commits) 13https://github.com/crawl/crawl/pull/4732 20:22:44 03coraxioU902 {GitHub} 07https://github.com/crawl/crawl/pull/4732 * 0.34-a0-625-g9a44f513ae: docs: Recommend Tab instead of ! for spell library navigation 10(45 minutes ago, 1 file, 1+ 1-) 13https://github.com/crawl/crawl/commit/9a44f513ae33 20:22:44 03coraxioU902 {GitHub} 07https://github.com/crawl/crawl/pull/4732 * 0.34-a0-626-gae17f1d469: docs: Update spell library help screen to recommend Tab 10(19 minutes ago, 1 file, 5+ 4-) 13https://github.com/crawl/crawl/commit/ae17f1d4695e 22:02:20 <04dracoomega> @gammafunk I'm wondering if the _artp_can_go_on_item check for fixed properties specified for a randart is actually necessary. Like, one of the main uses for that function is to control what artprops will randomly appear on an item, not necessarily 'which would actually function'. And if we've requested a specific artprop, isn't the responsibility on the caller to pick something that is reasonable? (I ask since I'm trying to get 22:02:20 the Bane artprop to generate on an item type it normally doesn't appear on randomly, but would otherwise function on just fine, and it's rejecting it. And apparently it would also reject a lot of other fairly pedestrian things like school enhancers on the wrong aux armour type. Ironically, you can use it to force artprops that never generate on anything, since they don't actually have restrictions in this function.) 22:21:59 <03implojin> imo pull out the props that literally do not work to prevent future devs from footgunning and it should be fine to pass responsibility to the caller 22:22:06 <03implojin> doesn't look like there are that many 22:23:24 <04dracoomega> I did notice that comment you made about talisman ARTP_REGEN there just now (which I ought to look into fixing....), but really almost none of these have any functional problems 22:23:27 <03implojin> (alternatively, fix the broken ones to work across basetypes) 22:23:44 <03implojin> case ARTP_DRAIN: case ARTP_CONTAM: return item_class != OBJ_TALISMANS; // TODO: support..? 22:23:54 <09gammafunk> yes, it's important. The reason being due to random item types/subtypes 22:24:33 <09gammafunk> the caller doesn't know what the actual subtype will be if they say any jewellery 22:24:38 <09gammafunk> for example 22:26:17 <09gammafunk> I don't quite understand the connection with Bane and not appearing on a type it would normally appear on 22:26:42 <09gammafunk> we have been doing things like that for some time (e.g. the one-of-a-kind rings) 22:31:51 <04dracoomega> For example what? And as I said, One-of-a-Kind rings works because none of the artprops it's using generate normally at all, so they have no code forbidding them from certain types of base types via _artp_can_go_on_item. But artprops that can generate normally (but only on certain base types) do this by forbidding being added to those base types via _artp_can_go_on_item which means that trying to do this via artprops spec will 22:31:52 fail. 22:33:30 -!- khadgar2 is now known as khadgar 22:35:37 Unstable branch on crawl.develz.org updated to: 0.34-a0-624-g73f07e0534 (34) 22:36:41 <09gammafunk> "for example" was in relation to the statement above it. Item specs allow something like any jewellery artprops:... where the subtype is not known. So the random subtype chooser needs to check the validity of a randomly chosen subtype relative to the specific artprops. If a randomly chosen subtype conflicts with the specified artprops, the result is discarded and a new type is rolled and checked, until something compatible is found 22:37:46 <04dracoomega> Er, when I try it, it just prints an error message that it's ignoring an incompatible artprop and simply generates the item without it 22:38:26 <04dracoomega> I guess because there's nothing it can reroll to that's compatible? 22:38:45 <09gammafunk> the relevant function is bool are_fixed_props_ok(item_def& item) 22:39:22 <09gammafunk> you seem to be concerned only about _get_randart_properties() I'm guessing? 22:40:20 <04dracoomega> Yeah, I guess I didn't even realize this higher layer using it to reroll base types existed 22:40:57 <09gammafunk> right, I expanded it subsequently specifically so r-i could do things like that, but it actually already existed for many item types before that 22:41:07 <09gammafunk> before even fixed properties existed actually 22:42:05 <09gammafunk> my intuition is that you can make Bane work with this system, let me take a look at this code a bit 22:42:11 <09gammafunk> it's been a while since I've digested it 22:57:25 Windows builds of master branch on crawl.develz.org updated to: 0.34-a0-624-g73f07e0534 23:13:36 Unstable branch on cbro.berotato.org updated to: 0.34-a0-624-g73f07e0534 (34) 23:18:25 <09gammafunk> @dracoomega I think we should restrict the use of _artp_can_go_on_item() to where there's just a fundamental problem between the specified property an another intrinsic or extant property. A relatively straightforward solution might be to expand artefact_prop_data to have a default nullptr function pointer for a boolean lambda that returns true if a property is wanted as a random one. 23:19:14 <09gammafunk> Right now we're using _artp_can_go_on_item() both as a filter for randomness and as a more fundamental check for Actual Conflicts and that's causing issues 23:19:31 <04dracoomega> Yeah, I had been pondering something similar. Just disentangling "Shouldn't randomly generate" from "Shouldn't be allowed at all." 23:19:58 <09gammafunk> the check for property weights is very straightforward and only occurs in two places (really one, the second is a quirk of preventing a double-choice of a property) so it would be easy to refactor I think 23:32:00 <04dracoomega> Yeah, possibly I should look into doing that. (Though that sure makes the scope of this 'tweak an item drop' vastly larger ^^; ) 23:55:33 Monster database of master branch on crawl.develz.org updated to: 0.34-a0-624-g73f07e0534