01:08:03 Stable branch on crawl.develz.org updated to: 0.23.3-3-gaaff5abdbf (34) 01:17:49 Stable branch on crawl.develz.org updated to: 0.22.3-3-g34f245f157 (34) 01:27:12 Stable branch on crawl.develz.org updated to: 0.21.3-3-g218456f21e (34) 01:38:17 Unstable branch on crawl.develz.org updated to: 0.25-a0-860-gf695395b5c (34) 01:58:03 -!- behalebabo_ is now known as behalebabo 03:23:48 Stable (0.23) branch on crawl.beRotato.org updated to: 0.23.3-3-gaaff5ab 03:36:59 Stable (0.22) branch on crawl.beRotato.org updated to: 0.22.3-3-g34f245f 03:38:35 Monster database of master branch on crawl.develz.org updated to: 0.25-a0-861-g2dbde65baa 03:54:22 Stable (0.18) branch on crawl.kelbi.org updated to: 0.18.2-3-g5ac21b8443 04:00:29 Stable (0.19) branch on crawl.beRotato.org updated to: 0.19.6-3-g7d5932f 04:12:29 Stable (0.18) branch on crawl.beRotato.org updated to: 0.18.2-3-g5ac21b8 04:15:31 Stable (0.21) branch on crawl.kelbi.org updated to: 0.21.3-3-g218456f21e 04:22:32 I just pushed the bugfix to Stoat Soup master. IDK if CKO/CPO are still in the throes of building all the things, but if someone could crank the handle when convenient, that would be appreciated. 04:26:22 Unstable branch on crawl.beRotato.org updated to: 0.25-a0-860-gf695395 (34) 04:38:33 Stable (0.22) branch on crawl.kelbi.org updated to: 0.22.3-3-g34f245f157 05:01:24 Stable (0.23) branch on crawl.kelbi.org updated to: 0.23.3-3-gaaff5abdbf 05:25:12 Stable (0.24) branch on crawl.kelbi.org updated to: 0.24.1-8-ga250c9d538 05:48:53 Fork (bcrawl) on crawl.kelbi.org updated to: 0.23-a0-3015-g7f46a08de7 06:13:25 Fork (bcadrencrawl) on crawl.kelbi.org updated to: 0.22.1-2608-g504c0113d8 06:36:47 Fork (stoatsoup) on crawl.kelbi.org updated to: 0.22-s0-48-g64bc6217c4 09:18:54 %git 28ba102798342 09:18:54 07advil02 * 0.23-a0-156-g28ba102: Don't use the full minor tag versioning for bones files 10(1 year, 8 months ago, 3 files, 48+ 8-) 13https://github.com/crawl/crawl/commit/28ba10279834 09:19:50 advil: why does upgrading a bones file prevent older saves from loading it? 09:19:59 or do you mean it prevents older binaries from loading it 09:44:47 older binaries 09:45:17 for servers that share a bones file set across binaries 09:45:29 mainly trunk 09:45:46 (since I think stable versions usually come with their own set on all setups) 09:49:32 ok, makes sense 09:49:35 thanks 10:38:24 03Aidan Holm02 07[wide-minor-tag] * 0.25-a0-857-g8e1eef3: Improve save version mismatch reporting 10(2 hours ago, 2 files, 31+ 23-) 13https://github.com/crawl/crawl/commit/8e1eef3714c4 10:38:24 03Aidan Holm02 07[wide-minor-tag] * 0.25-a0-858-g504c2e6: Allow phasing out support for old minor versions 10(34 minutes ago, 3 files, 39+ 3-) 13https://github.com/crawl/crawl/commit/504c2e6eb50a 10:38:28 Branch pull/1375 updated to be equal with wide-minor-tag: 13https://github.com/crawl/crawl/pull/1375 10:44:21 I wonder if the system could be made simpler (in the sense of easier to keep track of) by restructuring how tag major and minor relate a bit more; i.e. not assuming each major tag correlates with a clean set of minor tags (rather with a range of manior tags), and allowing major tags to have some compatibility across versions 10:44:38 *range of minor 10:45:41 so tag major 34 = minor tags 1-200, tag major 35 = minor tags 100-200 (or whatever), tag major 36 = minor tags 200-250, with support for tag major 35 minor tags 10:47:30 i fail to see how that is simpler :) 10:47:50 the idea would be that compat is still structured by major tags 10:48:35 or was 'major 34 = minor tags 1-200' a typo? 10:48:35 I do not think it will be very easy to keep track of compatibility with a full rolling model 10:48:53 that was just not changing the current meaning of major 34 10:49:33 to my mind, the definition of major tags is that they are mutually incompatible 10:49:33 right, I'm proposing changing that 10:49:36 i do realize i'm also playing fast and loose with the definiton of minor tags 10:49:52 since if I understand your proposal correctly the major tag would never change again, so becomes pointless 10:50:11 yes, that's one of the bits i quite like about my proposal 10:50:24 so just to make sure i understand correctly 10:51:06 you're proposing some form of overlapping majors? where maybe the first half the range of major N is also covered by major N-1 10:51:39 yes, that would be the idea 10:52:08 so if i were to draw it with brackets: [ ( ] ) 10:52:54 but then, how do you know if your major N game is in the middle section, where it's compatible with a binary with major N+1 ? 10:53:12 yes, where I think your proposal already has that structure but nothing except careful enum counting marks the bracketing 10:54:32 probably it would be explicitly defined somewhere in the N+1 game? 10:55:00 careful enum counting plus a test case, which is a whole lot better than all the other careful enum counting crawl is already riddled with 10:56:33 hm, so at some point you'd bump a version, and the compatible minor window would jump forwards by half the window width 10:57:06 yes, on this idea I think the workflow for adjusting the rolling compat window would involve increasing the major tag 10:57:44 i mean, this certainly seems doable, but it seems a bit more complicated than just having a rolling minor version 10:58:12 it also seems like you'd have less control over the window width, unless you resorted to careful enum counting, which i think is part of what you want to avoid? 10:58:20 basically I think it would be kind of useful for human understanding, and also quickly looking at a save file / crash log, to have a n.m format where n is meaningful, instead of just m 10:59:28 the window width would probably still be arbitrary 10:59:53 this isn't really a tech simplification, I agree 10:59:57 is that what you meant by not thinking it will be very easy to keep track of compatibility with a full rolling model? because I don't think i understand what you mean there 11:00:27 this is just some feedback from someone who has worked on an awful lot of save compat issues 11:00:27 'is that what you meant 11:00:27 ' == 'having a meaningful n.m format' 11:00:41 oh i definitely appreciate the discussion, especially with something of this nature 11:00:46 so five years from now, the save version will be let's say 352 11:02:09 which I guess would be paired with a game version 0.34 or something 11:02:43 so by 'n.m with meaningful n' you'd prefer to have n roughly correlated with time? 11:02:58 I could imagine bumping that consistently with every release version, yeah 11:03:18 having a sense of when a save is from is definitely useful, so why not just do that? i.e. serialize the save marshall date as well 11:03:39 that doesn't have the right semantics 11:04:30 what are the right semantics? 11:04:45 something where you don't need a calendar to figure out what it means :-) 11:04:52 I mean, possibly the game version would do what I want, if we're consistent about it 11:06:16 something more like this would also allow for easier analogues of the current server strategy of tracking version in a db 11:06:56 this is for debugging, right? so what would you do with this information? 11:07:30 i mean, the current n == 34 is not especially useful either, so in one sense things can't get any worse with a rolling model 11:07:40 right now when I get a save with some random minor tag it's ...not easy... to figure out where in the enum it is 11:08:27 yes, I agree that the current major tag is not very useful 11:08:36 that's why I'm suggesting rethinking how the major tag is used ;-) 11:10:24 this isn't the only possibility I could imagine 11:11:20 right, so with overlapping majors, you might get a major version several versions old, and you still have to go spelunk git because the enums have been deleted already 11:11:20 but going this way is going even further from having any sort of semantic versioning for save files than we already are, where it *did* start with the intent of semantic versioning 11:11:34 i don't know what you mean by semantic versioning, i'm afraid 11:11:40 https://semver.org/ 11:11:44 this isn't a computational linguistics thing, is it? :) 11:12:47 oh, sure, but semantic versioning implies hard breaks in compatibility 11:13:28 I guess using that terminology what I'm proposing is treating major as a minor, and minor as a patch # 11:14:30 I don't mean it as an exact analogue because standard semantic versioning is aimed at something different than file versioning 11:14:46 in that sense, i'm proposing treating a minor as a minor, and both proposals also include dropping compatibility for older patch/minor versions 11:15:32 in any case, to get back to the issue of easy (well, easier) debugging 11:15:43 what about serializing the minor tag name as a string? 11:15:47 what I'm looking for is something interpretable by a human that gives a quick way of answering the question that the major tag does answer in semver, i.e. where does compat break 11:15:56 that would probably be a good idea 11:16:13 well, whenever you like 11:16:47 i.e. we could remove support for old minors one by one, or we could do it in blocks of a hundred 11:17:15 but, human interpretable.. 11:18:51 so I guess i'm not convinced of the utility of making this human-interpretable, but one example approach is to say version 34.5xx will support everything >= 34.400 11:19:59 why wouldn't it be useful to be able to quickly look at a save version and interpret it?? 11:21:10 it may be useful to devs, but not to users, since save versions aren't exposed (apart from incompat errors) 11:22:14 for the dev perspective, given a save n.m, what are you trying to determine compatibility with? 11:22:49 presumably the range of trunk commits that support loading it, and any release branches with compatibility? 11:23:30 Stable (0.23) branch on underhound.eu updated to: 0.23.3-3-gaaff5abdbf 11:23:47 sure 11:24:04 and yes, I am talking about usefulness to devs 11:24:39 this sounds to me like a good candidate for a util script 11:25:43 ./versions-supporting-minor TAG_MINOR_STICKY_FLAME --> added in 12837, removed in 928374, compatible with 0.24 .. 0.27 11:29:29 it's true that this would take ~minutes rather than ~seconds 11:30:11 serializing the version of the game that wrote the save would probably be a good addition? 12:13:58 the version and version history is serialized already 12:14:39 %git aaf14ca39 12:14:39 07advil02 * 0.23-a0-760-gaaf14ca: Show version history in `?v` if a save has been upgraded 10(1 year, 3 months ago, 3 files, 19+ 5-) 13https://github.com/crawl/crawl/commit/aaf14ca3918b 12:20:09 oh, nice! 12:20:35 so it stores each version that was used, that's even better 12:36:09 ??test 12:36:10 test[1/44]: $(echo ??test) 13:15:52 Stable (0.23) branch on crawl.akrasiac.org updated to: 0.23.3-3-gaaff5ab 13:32:06 Stable (0.22) branch on crawl.akrasiac.org updated to: 0.22.3-3-g34f245f 13:45:01 -!- raskol_ is now known as raskol 13:57:07 -!- Tiobot is now known as Guest30562 19:30:45 I worry that the idea of rolling save compatibility will mean adding save-compat logic will become more complex. Right now, it's relatively straight forward to use #if directives 19:32:29 I'm not completely clear how it will work, but if there is greater maintenance burden on crawl contributors (when removing an item or changing the supported version window), that could be a problem 19:38:52 by rolling save compatibility, you mean breaking it every release? 19:40:29 -!- Tuxedo[Qyou] is now known as werecarpet 19:47:46 hi 19:47:51 i have a quick question 19:48:22 would you all be okay with exposing player::get_noise_perception() through clua? 19:48:50 !source player::get_noise_perception 19:48:50 1/1. https://github.com/crawl/crawl/blob/master/crawl-ref/source/player.cc#L5437 19:48:50 as far as i can tell, there's currently no way to get noise information through lua 19:48:58 except for some kind of ugly msgch_sound string comparisons that would end up being ugly as heck 19:49:18 i've already written the branch if it's, like, okay 19:49:19 yeah, seems reasonable, as this is the same info used in the noise bar display, from what I can tell 19:49:22 seems fine 19:50:33 okay i think i put the PR in but i am not good with git or github 19:50:44 probably even exposing the raw noise value is fine 19:53:45 also, um 19:53:46 wow, do noise levels have some scaling done? e.g. those breakpoint values are really high 19:54:05 New branch created: pull/1377 (1 commit) 13https://github.com/crawl/crawl/pull/1377 19:54:05 03Implojin02 07https://github.com/crawl/crawl/pull/1377 * 0.25-a0-861-gd76ab2a: Expose player::get_noise_perception() through clua. 10(17 minutes ago, 1 file, 14+ 0-) 13https://github.com/crawl/crawl/commit/d76ab2a5b7ea 19:54:17 noise values are using a 1000 scale iirc 19:54:17 i noticed a bunch of stuff missing from the clua api reference 19:54:17 ah, that explains it 19:54:17 is that part of the main crawl repo 19:54:18 because, yeah 19:54:22 yeah Implojin some basic things like player AC and EV are missing 19:54:28 i kind of want to fix that documentation 19:54:41 oh the api reference, sorry 19:55:05 yes, you can document those functions and ebering hosts the docs built from that documentation 19:55:12 you can see examples of how to do it in the source 19:55:13 ??lua 19:55:13 lua[1/2]: http://www.lua.org/manual/5.1/manual.html 19:55:15 also, i realize this one might be a little sketchier than noise perception 19:55:15 ??lua[2 19:55:16 lua[2/2]: Documentation of crawl's lua API: http://doc.dcss.io/ 19:55:32 but would there be any chance of exposing something similar to crawl.millis 19:55:45 i realize that might be some kind of timing attack issue or something so its probably dlua for a reason but 19:56:01 it would be nice to have for purpose of tracking realtime spent per player action 19:56:36 i'm writing a script with the goal of trying to minimize player realtime wasted on, uh 19:56:39 repeat nondecisions? 19:56:49 and tracking that is kind of handy 19:56:54 currently im just doing it in dlua 19:58:30 regarding the api reference 19:58:41 I'm not sure offhand why millis wouldn't be exposed 19:58:48 is documenting that as simple as adding comments in the l-whatever files 19:59:44 (sorry for the handholding, but i don't do this for a living) 20:00:06 yes, those docs that gammafunk linked are generated from the comments 20:00:11 ok 20:00:13 thanks 20:01:09 you can see some of the earlier documentation ebering did in this PR: https://github.com/crawl/crawl/pull/809 20:04:23 also i think you might need to run a rebuild or whatever on that dcss.io docs page because it doesn't even have gammafunk's acquirement hook listed 20:04:28 or it didn't the last time i looked 20:05:10 yeah, it's not actuall generated automatically 20:08:23 okay that's enough human interaction for one day 20:08:26 thanks for your time 20:12:04 not sure I documented that...actually yes I did 20:12:31 which reminds me, I need to fix vt's crash for using that clua spell listing function with > 52 spells 20:17:38 how is dcss.io's docs page generated? Can we move it into github actions? 20:17:50 I generate it and upload it 20:17:53 yes, maybe 21:03:09 -!- jfcaron_ is now known as jfcaron 21:11:25 if you can give me the commands, I'll happily take a shot at it 23:24:54 Monster database of stone_soup-0.23 branch on crawl.develz.org updated to: 0.23.3-3-gaaff5abdbf 23:51:24 Monster database of stone_soup-0.22 branch on crawl.develz.org updated to: 0.22.3-3-g34f245f157 23:54:03 about to test compilation of old versions on CDO going back to 0.19 23:54:03 so we can have proper monster lookup from Gretell for those versions