00:08:57 <06mumra> Ooh I forgot about gingham. (I'm sure there's a bunch more ... my research was far from exhaustive) 03:32:25 Experimental (bcrawl) branch on underhound.eu updated to: 0.23-a0-5208-geafff8c3b6 03:49:07 <02sentei> @asciiphiliaI pulled in the repo locally, built the dockerfile using docker build --tag dgl-forks -f utils/testing-container/Dockerfile . from the root of the git repo, created the 4 volumes, updated the entrypoint to build-trunk and did docker-compose -f docker-compose.yaml up to get a working server that I could log in and play the trunk version at localhost:8080 03:49:26 <02sentei> have you gotten it working? 03:49:47 <02sentei> I will look into building the forks as well now 03:53:55 <12asciiphilia> https://github.com/refracta/dcss-webtiles-server/commit/7310d4dfb908ae7a4c328237e249a3c593f9c732#diff-ae989d0ba9d900a2325acca4a289ddd3f9b85b2f534da42c9e05b82aefb9f017R1 I also verified that the latest testing-container of dgamelaunch-config works and then manually merged it after updating the OS version of your dgamelaunch-dcss-forks-server to 22.04. I haven't checked if it works for other builds, but I confirmed that it works when 03:53:55 using the build-trunk script. 03:54:28 <12asciiphilia> It seems that a higher version of Python is installed in version 22.04, which has resolved the issue we encountered yesterday. 03:56:14 <12asciiphilia> Ah, additionally, I haven't committed a few modifications yet, but to get it working, I also had to remove the part where gcc-6 is installed via apt. 03:57:54 <02sentei> Yes, I did expect that to be the case on updating the ubuntu version. Regarding building the fork versions, I had a thought that perhaps clang might work better to build the forks, instead of trying to get an old gcc into the new container. since I did try out changing the -std=x but it made no difference 03:59:20 <12asciiphilia> What argument did you use for the -std flag? 04:00:20 <12asciiphilia> I haven't tested it yet, but when I asked an LLM what default argument GCC-6 uses for -std, it said gnu++14. 04:03:35 <12asciiphilia> If the build fails even after trying with the appropriate value, we might need to consider using something like Clang, as you suggested. 04:03:39 <02sentei> I tried using pretty much all of them with the GCC-7 compiler, -std=c++03, -std=c++11, -std=c++14, -std=c++1z (17) the very old ones just had more errors, the newer ones had the expected error I've seen before 04:04:28 <02sentei> gnu++14 as well 04:07:30 <02sentei> @tzer0 perhaps you can weigh in on what's the best way to handle compiling old version of crawl, since you have upto 0.10 on your server? 04:11:21 <12asciiphilia> When encountering these issues, I sometimes think it would be helpful to have a document that outlines the compilation environment for each version or a container that sets up the build environment, or an official repository that preserves the built binaries. 04:12:58 <12asciiphilia> The legacy builds seem to be available here: https://crawl.develz.org/trunk/archive.html, but I'm not sure if they can be used in the WebTiles format. 04:14:58 <12asciiphilia> Additionally, most forks don't seem to have such archives. 04:17:09 <06mumra> There is actually a build environment container in this PR https://github.com/crawl/crawl/pull/3757 04:52:51 <02tzer0> Uh, I don't think I've compiled 0.10 for a long time. Let me check. 05:07:40 Unstable branch on crawl.akrasiac.org updated to: 0.32-a0-1247-g5f74a55 (34) 05:28:06 <05icoson> 0.10 won’t compile even on cao and lacks some known security fixes 05:29:42 <05icoson> Gotta say I don’t really think that old versions / forks can be assumed to be entirely safe to run on a public server 05:32:25 <05icoson> I have backported certain really crucial fixes as far as 0.11 05:33:27 <05icoson> But that’s a bare minimum, not any sort of guarantee 05:38:53 <02sentei> yeah, the forks I chose are all more recent than 0.10, I just mentioned that, since it's an old version and TZero has it compiled on the server, so could have some pointers regarding it 05:41:54 <12asciiphilia> From which version do you think it is safe to offer services on a public server? And have there been any actual hacking incidents? I wanted to offer all versions from 0.10 onward, but if it's not safe, I might need to reconsider. 05:51:36 <12asciiphilia> Hmm, now that I see the CAO server also offers versions starting from 0.11, it seems there might not be a significant issue. 06:25:28 <06dolorous_84348> No problem. 07:25:11 <09gammafunk> We haven't had any incidents, and the chroot at least in theory makes it difficult to perform any significant exploit (and in your case you'll also be running a container), but we don't really maintain older versions due to the effort involved and the fact that they can be difficult to compile with modern compilers. 08:05:41 03dolorous02 07* 0.32-a0-1248-g5ce18b405a: Add another pattern name. 10(73 seconds ago, 1 file, 2+ 0-) 13https://github.com/crawl/crawl/commit/5ce18b405af4 09:15:41 <05icoson> well, there was a complete working vulnurability that was shared with us by a security researcher that was patched 09:16:00 <05icoson> https://nvd.nist.gov/vuln/detail/CVE-2020-11722 iirc 09:16:09 <09gammafunk> true, and you patched that all the way back to 0.11 or so as I recall? 09:16:18 <05icoson> yes 09:17:43 <05icoson> but forks may or may not have the patch 09:17:51 <05icoson> looks like aidanh backported something relevant to 0.10 09:18:24 <05icoson> I think the issue with cao was that I was unable to rebuild, so I disabled 0.10 09:19:03 <09gammafunk> I wonder if CUE has that fix 09:19:21 <09gammafunk> since it does still have 0.10 (not sure if it rebuilt other old versions either) 09:19:43 <05icoson> hm that may be a different fix that he backported 09:20:34 <05icoson> %git 92545cb749b47 09:20:35 <04Cerebot> advil * 0.11.4-1-g92545cb749: Guard against repeated calls to lua_object_gc (ruderubik) (4 years, 1 month ago, 1 file, 4+ 1-) https://github.com/crawl/crawl/commit/92545cb749b4 09:20:42 <05icoson> that's the earliest backport I see 09:35:24 <02sentei> The forks in the docker server have that fix, since I applied it to those that were missing it. I think it was actually you who advised me to do it. 12:28:48 <12asciiphilia> Are the security patches applied to each version tag or branches in the Crawl repository? Do I need to manually apply the security patches to the older versions? 12:29:37 <12asciiphilia> The commit named "Guard against repeated calls to lua_object_gc (ruderubik)" seems to have been cherry-picked to all the stone_soup* (version >= 0.11) branches. 12:57:12 <05icoson> stuff like that we have applied to the official repo to the extent possible, but tbc, versions more than about current - 2 (maybe really just current - 1) are not supported 15:33:02 03dolorous02 07* 0.32-a0-1249-g87cd461dd1: Add Xom message for metal statues. 10(5 minutes ago, 1 file, 2+ 2-) 13https://github.com/crawl/crawl/commit/87cd461dd1b3 15:36:58 <04dracoomega> For a brief moment, I read that as 'for mental states' and honestly that felt apropos too 😛 15:38:04 Unstable branch on underhound.eu updated to: 0.32-a0-1248-g5ce18b405a (34) 16:12:49 <02sentei> I looked into the forks not building, one was due to a bad configuration, that I updated in the repo, 2 were due to an interesting git checkout interaction which happens when building all of the forks in a row, that I also fixed and made a pr to the crawl/dgamelaunch-config repo to also handle that edge in case it ever comes up, and the final one is due to the main branch simply being not buildable right now, I left bcadren a message. My 16:12:49 repo is now updated and really does build all forks when simply launched. 16:29:33 <12asciiphilia> @sentei Write permissions need to be added for the testing-container/*.sh scripts. Currently, only docker-entrypoint.sh has write permissions. The permissions applied in the Git file system are used as-is when the files are copied to build the container image. As a result, changing the docker-compose.yml entrypoint to docker-entrypoint-build-trunk.sh or similar and running it results in a permission error. 16:37:45 <12asciiphilia> https://github.com/Rytisgit/dgamelaunch-dcss-forks-server/pull/12 16:39:18 <12asciiphilia> * Write permissions → Execute permissions 16:41:29 <12asciiphilia> I wrote it wrong by mistake 16:44:02 <02sentei> Thanks, looks like windows messes with the permissions when making the docker images, I tested on it and didn't run into these issues. I will also add the --chmod to the docker file copy to make sure it has the permissions always. 16:53:23 <12asciiphilia> https://github.com/crawl/dgamelaunch-config/blob/master/utils/testing-container/Dockerfile#L16 Does anyone know why the language setting is necessary here? It seems to work without it, so I'm curious why it's explicitly set. 16:54:09 <12asciiphilia> Is it for environmental stability, just in case? 17:03:22 <09gammafunk> I seem to recall that crawl won't run without LANG set to utf-8? 17:09:13 webtiles won't, looks like 17:09:48 for console there's an ASCII mode 17:49:41 <05icoson> in the past it definitely did not work without the various complicated locale tweaking there 17:54:09 I poked at the code, webtiles mode refuses to start up unless the locale is explicitly UTF8 17:58:44 <05icoson> can you clarify what is causing the need for the change in the pr? 17:59:15 <05icoson> I can't really see how there could be untracked changes after a checkout in a clean repo? 18:00:58 I can't either, but I note that another project I work on has explicit checks in its CI for that case 18:09:48 <02sentei> When building all of the forks I encountered both of the edge cases with simple calls to the update-gcc which calls the git checkout to switch branch. I saw both checkout not wanting to switch to a another branch due to conflicts and files being left with changes after switching to another branch which made compilation fail. So since this solved the issues for me I think it would be a nice safeguard to include in the main repo as well. 18:11:49 <06mumra> I believe you will get a Y/N prompt during some installation step if this is not set, so your process will hang 18:13:01 <06mumra> or maybe that's not related to this 18:31:06 <06mumra> I'm wondering if anyone has an opinion on fixing another oddity I noticed in monster movement... Basically I noticed that monsters have a strong tendency to approach the user from cardinal directions. (And also to drift onto the ordinal paths if they are closer to the diagonal, but it is less prominent - Either way they do not like approaching on shallow paths) It comes down to some code in _find_best_step in mon-act.cc: cpp if 18:31:07 (delta.rdist() > 3) { // Reproduced here is some semi-legacy code that makes monsters // move somewhat randomly along oblique paths. It is an // exceedingly good idea, given crawl's unique line of sight // properties. // // Added a check so that oblique movement paths aren't used when // close to the target square. -- bwr // Sometimes we'll just move parallel the x axis. if 18:31:07 (abs(delta.x) > abs(delta.y) && coinflip()) dir.y = 0; // Sometimes we'll just move parallel the y axis. if (abs(delta.y) > abs(delta.x) && coinflip()) dir.x = 0; } So the impact of this is that if a monster is approaching from, say, the far left but 1 tile down from the player (so delta is {x:7, y:1}) there is a 50% chance each step to move onto the cardinal and approach in a straight line. If the monster 18:31:08 is at 3 distance or closer (e.g. delta is {x:3, y:1)) this logic is skipped so they will always take the diagonal move and arrive on the cardinal (dir begins as delta.sgn() so will be {x:1,y:1} in both examples. 18:31:08 <06mumra> If a monster is approaching on a diagonal they will stay on that diagonal (there is some extra fiddling as they might move off the diagonal to give an ally behind them a clear line, but otherwise this seems always true). If they are on a cardinal they will stay on the cardinal (with the same fiddling). But approaching from any other cell in the 7x7 grid around the player they are going to drift to the cardinal; and outside of that grid 18:31:09 they drift towards cardinal or orthogonal with a 50% chance each step, so from most positions they are strongly inclined towards one or the other. So this makes monster approaches rather predictable and it's easy to know that they're going to step onto the cardinal, it makes it easier to get monsters in a line if you understand how this works. It helps Starburst quite a bit. So the question is, is it a reasonable thing to fix? It can be done fairly 18:31:13 simply by replacing the coinflip() with an x_chance_in_y based on the ratio of x delta to y delta so e.g. on the {x:7,y:1} very shallow approach they have a 1/7 chance to step onto the ordinal instead. But I wanted to double check if anyone sees the current behaviour as desirable for visual reasons, to help with lining up monsters, to not nerf Starburst, any other reason? 18:46:26 <04dracoomega> You say 'fix' as if this is broken behavior, immediately after 'this helps starburst quite a bit'. (Note: it also helps rampage, boulder, arguably Wu Jian lunge...) I can't say that I really know how much it would change gamefeel to change this. It's not at all intuitive to me how impactful or obvious the difference would be (and there's other sources of effective randomness in how monsters approach anyway). But in general, 18:46:26 monster movement being somewhat predictable is largely a good thing in this game, I think (and a lot of player tools benefit from it), so I'm not convinced on its own that a change that is aimed at making this be less the case is positive. (But again, I don't really know how much this ends up changing anything that one can feel without paying close attention to the detals) 18:50:00 I feel like this has come up before (I recognize "exceedingly good idea") and vaguely recall that the point back then (bwr?) was circlelos 18:57:16 <06mumra> Well i should have put "fix" in quotes really 🙂 18:58:18 <06mumra> I was looking at this for the purposes of wall monsters - noticing that they would hardly ever stay in the walls on approach 18:58:57 <04dracoomega> Huh 18:59:00 <06mumra> Which I can of course get them to do another way 18:59:11 <04dracoomega> Well, back in the day, there was code to specifically make wall monsters favor being in walls 18:59:51 <04dracoomega> Yeah, the comment itself is clearly talking about the properties of circlelos, but I think there are other potential benefits of it regardless 19:00:04 <04dracoomega> Comment possibly could be removed, though 😛 19:01:26 <02Monkooky> Predictability of monster movement is I think generally a good thing 19:02:04 <06mumra> Some of the behaviour it creates seems odd in a squarelos world - favouring the cardinal over the diagonal doesn't make any difference if your next move will put you next to the player regardless 19:02:20 <02Monkooky> well, that's not really true 19:03:27 <06mumra> If predictability is the aim then why randomise things at all ? There is some code further on where on a coinflip the monster might sidestep to allow an ally to attack 19:08:07 <06mumra> (The resultant behaviour of all this, from some testing, seems rather less intuitive to me than would "monster approaches on roughly a beam path" and it feels even exploity to know exactly how they will move in the 3 tile radius) 19:09:51 <06mumra> But yeah there are certainly some benefits for rampage and other stuff (but these seem to be marginal in practise and you can still manipulate things to where you want them regardlesa( 19:13:22 <04dracoomega> Yeah, like I said, I don't really have a good sense of how different it feels without this property 19:14:29 <04dracoomega> Though Crawl movement code is full of all kinds of rather specific and sometimes marginal things, I think - some of which may or may not matter a whole lot, but it's often hard to say. 19:20:43 .oO { s/movement// } 19:24:44 <06mumra> Yeah and I think a lot of stuff just gets left in place because well someone put it this way so there must be a reason 19:25:44 actually it's because some years back someone tried to clean things up and promptly discovered there was a reason for it 19:25:52 not necessarily in this part of the code 19:28:09 but it's happened often enough thatthere's a certain amount of fear that they'll break something that turned out to quietly rely on it 19:29:21 <06mumra> Well exactly 19:29:56 <04dracoomega> I mean... I think it's good policy to question "Does this serve a real purpose anymore?" fairly often, but also: sometimes it does. Is this one of those times? It seems very plausible, but I'd really need to play with it changed to have a more informed opinion than what I've already said, I think. 19:30:15 <06mumra> (Case in point this doors pathfinding PR, it seems simple enough but I'm still extremely hesitant about possible side effects https://github.com/crawl/crawl/pull/3823 ) 19:37:09 I'm having a vague recollection that the first time it was fixed it uncovered a bug in sound propagation (no, not that bug) 19:39:50 -!- 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 19:39:50 -!- 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 19:45:11 <04dracoomega> That is the sort of case where there's an obvious important benefit to doing a change/fix that I'd just do it and see if anything else ends up needing fixing afterward, tbh. 19:45:35 <04dracoomega> Like, yes, maybe something somewhere else is unknowingly leaning on this, but also: monsters should be able to pathfind through doors 19:45:44 right, but it's also one you only discover that about when you make the fix 19:45:45 <04dracoomega> Yes 19:46:05 I personally think that fix should go (back) in 19:46:10 <04dracoomega> Agreed 19:47:52 <06mumra> (The original fix is still there, it just got broken in a different place later) 19:48:55 03mumra02 {Peter Hurst} 07* 0.32-a0-1250-g5cf9a61fe5: Remind monsters how to open doors 10(5 days ago, 1 file, 0+ 5-) 13https://github.com/crawl/crawl/commit/5cf9a61fe565 22:35:29 Unstable branch on crawl.develz.org updated to: 0.32-a0-1250-g5cf9a61fe5 (34) 22:59:38 Windows builds of master branch on crawl.develz.org updated to: 0.32-a0-1250-g5cf9a61fe5 23:13:34 Unstable branch on cbro.berotato.org updated to: 0.32-a0-1250-g5cf9a61fe5 (34) 23:55:46 Monster database of master branch on crawl.develz.org updated to: 0.32-a0-1250-g5cf9a61fe5