1005 Commits

Author	SHA1	Message	Date
Luciano Ciccariello	e883d78be3	libgpu sys functions (#1932) ... `D_8002C26C` is the GPU type. zero is the retail GPU from the first PSX model. Non-zero values is used for arcade boards that have 2MB of VRAM instead of 1MB. It is a bit hard to rename the symbols. Normally I would mark them as `static` and give them the original names. But on `main` the `.data` section is shuffled due to some linker silliness . I removed the various `extern const char []` as those strings are now migrated to the functions that owns them.	2024-11-22 19:56:17 +00:00
Josh Schreuder	ff4e1baf0f	Decompile no0 EntityDiplocephalusFoot (#1928) ... PSX: https://decomp.me/scratch/4UL86 PSP: https://decomp.me/scratch/FAeQw	2024-11-21 20:09:56 +00:00
AlChar	2244619e83	Decompile no0 func_us_801D2A64 (#1925) ... PSX : https://decomp.me/scratch/P02IW PSP: https://decomp.me/scratch/LURHt (not a full match) This was the largest function that hadn't been decompiled, A few things I've noticed: - I had to update `func_us_801D2424` to take `Point32*`s instead of `Entity*`s, making me think that Entity position is probably a Point32 - Point32 probably uses `f32`s instead of `s32`s - `self + 3` is referenced a lot and seems to use a separate extension struct. I named it `ET_UnkPlatelordPlus3` - I made `ET_PlateLord` `unk88` and `unk9C` a separate inlined struct because they are often passed as an argument to other functions.	2024-11-21 19:37:36 +00:00
H.M. Burger	33e3776558	deompiling tt_003 func_us_80172DC4 (#1924) ... Small function. Getting the starts to the demon extension	2024-11-21 15:19:28 +01:00
Luciano Ciccariello	fc91e63a90	Rename LoadClut2 to LoadClut (#1923) ... The function name is mislabeled. `LoadClut2` really exists and it was introduced in PSY-Q 3.5, but it only loads a row of 16 colors into the VRAM. The implementation we have at [src/main/psxsdk/libgpu/ext.c](https://github.com/Xeeynamo/sotn-decomp/blob/master/src/main/psxsdk/libgpu/ext.c#L31) loads 256 colors though, which matches the implementation of `LoadClut`. From `PSX/CHANGE_E.TXT` in the PlayStation Programmer Tool - Runtime Library Version 3.5: ``` LoadClut2 Loads Clut for 16 colors. Syntax u_short LoadClut2(u_long *clut, int x, int y) Arguments clut Starting address of the texture color x, y Destination frame buffer address Explanation This function loads the texture color data(CLUT) starting at the address specified by "clut" to the frame buffer(x, y) and then calculates CLUT ID for the texture CLUT just loaded. Return Value CLUT ID for loaded CLUT Remarks This function transfers the CLUT data of only 16 colors. ```	2024-11-21 13:51:50 +01:00
bismurphy	b1c617a1dd	Finish a .c file for DRA PSP (#1914) ... More functions, lots of them are direct copies of the existing ones, or just tiny tweaks away. No de-duping at this stage since things are still pretty different.	2024-11-19 19:24:27 +00:00
H.M. Burger	ceb671f716	Adding Faerie to CMakeLists (#1913) ... Adding Faerie to CMakeLists Seems like SFX not working, but Faerie at least loads. ~~Possibly also an issue with with the g_Entities array as the wings should occupy g_Entities[5] (set up in line 550 of Faerie.c), but they don't seem to either load or update (unsure which).~~ Seems this was either a graphical bug or something transient as the wings seem to work now... I'm not particularly interested in debugging this issue at this time, so if you'd rather I abandon the PR, I can do that too. There wasn't a lot of change.	2024-11-19 15:23:05 +01:00
H.M. Burger	a3678181dc	Changing PLAYER_STATUS_UNK40000 to PLAYER_STATUS_ZERO_HP (#1911) ... Simple change. Figured out that UNK40000 is either "Player has Zero HP" or "Player is dead", which is largely the same I think. The Faerie "Life Apple" ability triggers off of this status. Touches a lot of files so I didn't want to put it in my Faerie refactor. Also a small renaming in Faerie that I realized I forgot in my refactor	2024-11-19 05:58:31 +01:00
Josh Schreuder	9927a518b9	Decompile no0 Ctulhu shockwave attack (#1912) ... Planning on doing a cleanup pass over this whole enemy file next and importing data / documenting PSX: https://decomp.me/scratch/0jcyg PSP: https://decomp.me/scratch/n4vUq Thanks to Xeeynamo for help with the UV pointer array	2024-11-18 21:08:39 +00:00
H.M. Burger	d9bd6a6e4d	Finishing refactor of Faerie (#1909) ... For the most part, I think I've got this code all figured out as to what does what and how it functions. The only thing I need to do some more research on is how the animations for using items and how the animation for the Life Apple work. I straight up don't remember how items look when they are being used look and I don't think I've ever actually seen the Life Apple animation. This is probably where I'll leave the refactor for now, but I may come back again and try to figure out some of the animation frames.	2024-11-16 06:18:09 +01:00
Josh Schreuder	d646cd1a17	Decompile no0 EntityCtulhuDeath (#1907) ... Little'un PSX: https://decomp.me/scratch/qOMdH PSP: https://decomp.me/scratch/wgU6e	2024-11-16 00:05:06 +00:00
H.M. Burger	2503ab71fb	Refactor and cleanup for TT_002 (#1904) ... This is mostly just the low hanging fruit that I kind of already had a good handle on. The rest of the refactoring is going to take a little more digging in and probably some running the game in a debugger to figure out what's going on. I think the update for D8 and D9 are for the "hidden path" mode where the Faerie tells you to try to destroy a wall. DA,DB, and DC i think are actually yousi code for performing the "song". But I'm not sure on any of that. DD and DF are for the sub entities created when using an Item. I think they should use a different extension, but still need to dig into that more.	2024-11-15 19:37:13 +00:00
Josh Schreuder	dfea3429ae	Decompile no0 Skelerang entities (#1900) ... ~~Planning on giving this a tidy up when I import data and do some analysis in debugger so I'll fix up some of the naming then unless there's something glaring that sticks out here.~~ `func_us_801D191C` / `EntitySkelerangUnknown` was previous decompiled but slightly updated here for PSP match: https://decomp.me/scratch/8lEH0 `func_us_801D20A4` / `EntitySkelerangBoomerang` matching both PSX: https://decomp.me/scratch/SMgwb PSP: https://decomp.me/scratch/WFD0w `func_us_801D191C` / `EntitySkelerang` matching both PSX: https://decomp.me/scratch/BUkq2 PSP: https://decomp.me/scratch/OYg4D Thanks to Discord gang for helping with some PSP stuff here ^	2024-11-15 02:57:00 +01:00
AlChar	fe8c58f3a1	Decompile no0 func_us_801CCAAC (#1903) ... PSX : https://decomp.me/scratch/ATsZa I started off with @JoshSchreuder first attempt : https://decomp.me/scratch/Cji94 While I was at it I also updated the conditions in `UpdateBirdcages` to make them clearer	2024-11-14 20:22:20 +00:00
bismurphy	0729f18d0b	Next funcs on psp DRA (#1902) ... I noticed that my previous function, `DebugShowWaitInfo`, is actually the first function in the C for ps1. To me, this suggests that all the prior code in PSP (there is a pretty large amount of it, about 0x18000 bytes) is PSP-exclusive. Therefore, I adjusted the file splits to start a file on that function. Then I did the next function, `DebugInputWait`. After that is a bunch of debug screen capturing functions. These appear to be unused (presumably used in development but not in the final game code) and therefore I assume they are missing due to deadstripping. Since we know that's an issue on PSP, I decided to make a dedicated macro to flag that code is being removed due to deadstripping - this way, if we get deadstripping to work as intended, we don't have to look through every VERSION_PSP usage to identify what is dead code, versus altered code. We can just find all the uses of `PSP_DEADSTRIP` and eliminate them. Leaving it there for now, will continue working through DRA in future PRs.	2024-11-14 20:14:40 +00:00
AlChar	755b0f7e21	Decompile no0 func_us_801D7DAC (#1901) ... PSX : https://decomp.me/scratch/WCc3T PSP: https://decomp.me/scratch/9Um4e I had to convert `Entity.attackElement` to u16 to get a match and it didnt break anything. Let me know if I should revert that and find another solution	2024-11-14 20:10:54 +00:00
AlChar	a01de6c4a9	Decompile no0 StoneRose seed functions (#1897) ... Decompile smaller StoneRose seed functions func_us_801D7D00: https://decomp.me/scratch/YtL8I func_us_801D8DF0: https://decomp.me/scratch/APfvh func_us_801D8FFC: https://decomp.me/scratch/21YNJ	2024-11-14 00:29:02 +00:00
bismurphy	45bfe61037	Decompile PSP DebugShowWaitInfo (#1899) ... Mostly an inconsequential function, but we can learn a whole lot from this one. 1. Lots more symbols added to PSP. This function touches a lot of previously-unseen things in PSP. 2. This is the first PSP function to print a string. Importantly, PSP puts strings in `data`, not `rodata`! Luckily, the process of pulling them in is simple and easy, as demonstrated here. 3. I modified the Makefile for the -O4 stuff. At this point I think DRA is `O4` and all the overlays are `O0`. We can always make the logic more complicated later if we need to. 4. We discovered a discrepancy in the size of DR_ENV on PSP. I suspect we will have more SDK differences, but we will find them function by function. I decided to set the size in a variable so that we can put all the version differences at the top of the file, instead of them being more scattered. I think that's it!	2024-11-13 18:06:22 +00:00
H.M. Burger	a91c2acd3c	Data Import tt_002 (#1896) ... Importing the remaining data for tt_002 Importing sbss data Adjusting the data files The data except for the servant_events data is all unique to the faerie. I suppose all the data could be put in 1 file, but I had it split up because ghost and bat shared a significant amount of data. ~~D_us_801724CC[] should actually be an array of Unkstruct_801724CC; however, that doesn't match because it's on a 2 byte barrier and the compiler wants to align it to 4 bytes. I tried #pragma pack and __attributed__((packed)) and a few other things with no avail. So that and the cast to Unkstruct_801724CC in func_us_80177F84 are just going to have to be wonky.~~ This issue was figured out by @Xeeynamo I didn't really do any refactoring beyond what I needed to in order to get the data in. I'll work on that next.	2024-11-13 15:41:34 +01:00
AlChar	e95e97c1b0	Decompile no0 func_us_801D8150 (#1888) ... PSX : https://decomp.me/scratch/RAzGU	2024-11-10 10:50:08 +01:00
Jonathan Hohle	b48d12ac5a	Decompile TT_002 func_us_80177380 (#1885) ... While this is a pretty straight forward function, `unkA4` appears to be either a pointer to a `s16[3]` or a struct. It's more self-documenting for it to be a struct, but there is one case where it behaves like an array. A cast resolves the match.	2024-11-10 10:40:41 +01:00
Josh Schreuder	6c8454590a	Decompile no0 Ghost functions (#1889) ... `EntityGhostEnemySpawner` / `func_us_801D606C` matching both PSX: https://decomp.me/scratch/CrIPN PSP: https://decomp.me/scratch/RyIgW `EntityGhostEnemy` / `func_us_801D5E4C` matching both PSX: https://decomp.me/scratch/YEAXd PSP: https://decomp.me/scratch/HpJ4I Also extracted the data and split files. That's for these cute little fellas: 	2024-11-09 14:48:40 +00:00
AlChar	85c7f9d961	Decompile no0 func_us_801D9264 (#1881) ... PSX : https://decomp.me/scratch/rJEtD	2024-11-06 14:11:43 -08:00
Luciano Ciccariello	89f1933811	NZ0 cohabitation (#1871) ... I had this on a local branch. I do not remember why I did not submit it. Main changes: * `EntityRedDoor` ➡️ `OVL_EXPORT(EntityRedDoor)`: while the entity is the same across all stages, their `OVL_EXPORT(RedDoorTiles)` is different * `g_EInitBreakable` ➡️ `OVL_EXPORT(EInitBreakable)`: each stage has variations of the breakable NZ0 is now good to go 👌	2024-11-06 19:51:31 +00:00
H.M. Burger	b978d7e432	Decompile tt_002 func_us_80176504 (#1880) ... The data structure for the ranked lookup table is messy because the PSP version requires it to be a flat array. I'm pretty sure I have a union solution for that so the data tables will at least make sense, but until I can get data import done, we'll keep it like this as it will need to be used like this anyway. PSX: https://decomp.me/scratch/SN6vr PSP: https://decomp.me/scratch/DM13D PSP has a register swap that I couldn't figure out, but is largely a match	2024-11-06 09:13:44 -08:00
Jonathan Hohle	6c0544e1c7	Decompile & Map tt_002 Functions (#1879) ... Decompiles `func_us_80177958` and `func_us_80177F64`. Maps shared `ProcessSfxState`.	2024-11-05 21:49:57 -08:00
AlChar	2765a6eb80	Decompile func_us_80177F84 (#1878) ... PSX : https://decomp.me/scratch/9GOEx I haven't tested if it matches on PSP	2024-11-05 22:22:26 +00:00
AlChar	1b9e5dded8	Decompile func_us_80176C98 (#1876) ... PSX: https://decomp.me/scratch/oJCYW PSP: https://decomp.me/scratch/Uu6xa Thanks to @Onenutmcgee and @bismurphy who helped me out to get a match on both PSP and PSX. `if ((*((FgLayer32*)&D_8003C708)).flags & (LAYOUT_RECT_PARAMS_UNKNOWN_20 | LAYOUT_RECT_PARAMS_UNKNOWN_40)` For PSX is the only way to load D_8003C708.flags as a word while keeping the order of operations. Co-authored-by: gamezter <gamezter93@gmail.com>	2024-11-05 19:06:34 +00:00
Josh Schreuder	d8f94dfb96	Decompile no0 EntityFleaMan functions (#1870) ... `CheckFieldCollisionY` / `func_us_801DC64C` with thanks to @mrmidi who had done most of the work here. Matching both PSX: https://decomp.me/scratch/Ga3ax PSP: https://decomp.me/scratch/ki27x `EntityFleaMan` / `func_us_801DC788` Matching both PSX: https://decomp.me/scratch/Vu3Zx PSP: https://decomp.me/scratch/Y8HsL Also extracted the data while I was here. I think this enemy also appears in Olrox so should be able to extract into a shared header later on. --------- Co-authored-by: Aleksandr Shabelnikov <mistermidi@gmail.com>	2024-11-03 11:46:24 +00:00
Josh Schreuder	95d91584b4	Decompile no0 Ouija Table components sub-entity (#1867) ... Also split into a separate entity file for Ouija Table Matching both PSX: https://decomp.me/scratch/oph7c PSP: https://decomp.me/scratch/MTVot I'll probably extract the data on this one shortly just to round it out	2024-11-02 17:40:36 -07:00
H.M. Burger	5c0a64991a	Decompile tt_002 func_us_80174F0C (#1865) ... This looks like the Faerie's revive you if you die mode (ie, use Life Apple). Apparently there is a sound clip that gets played if you die while the faerie is active and you don't have a Life Apple. I don't believe I've ever heard this clip before.	2024-11-02 00:42:57 +00:00
Josh Schreuder	8dbb75fb78	Decompile no0 main Ouija Table function (#1859) ... Match on both PSX: https://decomp.me/scratch/A79x5 PSP: https://decomp.me/scratch/HJrWp The functions directly after this are related to the sub-entities such as vase and beaker I believe, so I'll decompile those next. Possible this might lead to changes in the extensions I've added here. Think this was my first time adding new extension(s) so let me know if something's wrong there Once all that's done I'll split into a separate Ouija Table file with all the related code.	2024-11-01 19:38:44 +00:00
H.M. Burger	55a696cba9	Decompile tt_002 func_us_80176178 and func_us_80175DBC (#1863) ... A lot of these update functions are code revolving around the faerie using items (which makes sense, that's what the familiar does). This means that these update functions share a lot of code. In fact, entity update steps 0, 1, 4,5,6 are mostly shared between the update functions. Steps 2 and 3 vary in what they do exactly, but tend to pull from common ideas. Combined, they look like they do the same concepts for each function. Data structures are slightly different, but all are used in similar methods. I will add an enum for these steps as I get farther along. But there is still some steps that I am not sure of and I'd rather keep it like it is for now, and do it when I'm either done with decomp or at least done with the base update functions. There is a lot of refactoring that I'll do when I'm closer as well. Worth noting that I believe all of these functions are mostly a PSP perfect match meaning we may be able to add this to PSP build fairly easily once the decomp is finished. This PR has 2 functions. Step 2 and 3 are really the only differences. func_us_80176178/func_psp_092EAC80 PSX: https://decomp.me/scratch/axD5C PSP: https://decomp.me/scratch/3KWit func_us_80175DBC/func_psp_092EA6F0 PSX: https://decomp.me/scratch/Rx6yJ PSP: https://decomp.me/scratch/youUM	2024-11-01 18:17:51 +00:00
bismurphy	2467f973d6	Various cleanup on a few things (#1858) ... 1. Give a name to the variable `g_PauseAllowed` - this is a bool which gets tested when we're also testing for pressing START or SELECT to open the menu or map, so to me it seems like it's flagging whether or not you are allowed to pause. It is normally 1, but gets set to 0 at the start of cutscenes, and then restored to 1 at the end of them. 2. Name LAYOUT_RECT_PARAMS_HIDEONMAP, which is relevant for item 3 on this list. I already used the HideOnMap name when setting up this flag in the assets handler in my previous PR. 3. Name `g_canRevealMap` - this is a variable that is normally set to true, but for some particular rooms in the game, it's set to 0. Those rooms will not appear on your map. Good examples include the forest area left of the castle gate (the first moment we see Alucard), and the DRE stage. This variable gets set to 0 if the LayerDef has the LAYOUT_RECT_PARAMS_HIDEONMAP flag set. 4. Deduplicate a common structure in the code where entities have a debug routine that lets the Player 2 controller control the behavior of the entity. By pulling this out, the code can be more concise. Most importantly, when searching the codebase for g_Pads[1] (which is an interesting thing to do, since we're looking at uses of the Player 2 controller in a single-player game), you can focus on the interesting, unique examples, rather than having a ton of copies of the same exact code. 5. Change all instances of `g_Pads->` to `g_Pads[0].` A minor change, but good to use a formatting which makes it clear that g_Pads is the array of both pads, and not a pointer to one. 6. A couple functions I noticed with obvious fake stuff (including a do{}while(0)) have been adjusted so that they will match on PSP. Naturally, this also meant removing those fake things, which is always nice. Overall, this is several small changes combined into one PR; honestly I just scrolled through the codebase for a while, finding things that made me think "I know a way this could be better". Others may disagree with some of these though, happy to take input, especially on the new names!	2024-10-31 23:44:05 +00:00
bismurphy	86bcbb69d6	Eliminate MyLayer and MyRoomDef to use the normal structs (#1857) ... These were temporary structs that were needed for the assets tool. I adjusted the assets tool so that we will now properly produce normal RoomDef and LayerDef structs, so now we don't need these. Should help with understanding how the rooms work.	2024-10-31 22:12:30 +00:00
H.M. Burger	c82d3726cb	decompiling func_us_801753E4 (#1856) ... D_us_80172BE4 seems like it should be an array of a struct, but the psp version uses math to move around the single dim array of s32. I messed with it, but couldn't figure out a way to do it where we kept all the left shifts in the psp version. No condition for loop is weird, but it's what is needed. (or a while(1), but I really don't like that either). PSX: https://decomp.me/scratch/r7VMm PSP: https://decomp.me/scratch/zX0Ly	2024-10-31 20:34:48 +00:00
Jonathan Hohle	74960176e9	Add Include Guards for All Headers (#1855) ... This is part of the `game.h` refactor from a few months ago. I'm parting those changes out into discrete PRs.	2024-10-31 20:27:49 +00:00
H.M. Burger	b481dc211f	tt_002 func_us_80175730 and func_us_80175A78 (#1854) ... These are essentially dupes of each other, but uses a slightly different offset for a u8 counter and params for the create factory and event functions. PSX: https://decomp.me/scratch/ghT05 PSP: https://decomp.me/scratch/lts6D	2024-10-31 19:27:20 +00:00
H.M. Burger	24d70e9823	decompiling func_us_80177AC4 (#1847) ... Full match both PSP and PSX PSX: https://decomp.me/scratch/iF9Ax PSP: https://decomp.me/scratch/bA5Ta I made a comment in the code that it looks like the extension used by this entity is wrong, but I don't have enough context to build a "correct" one yet. We'll have a better idea as we get more functions decompiled (especially the functions that spawn these sub entities).	2024-10-29 21:41:21 -07:00
H.M. Burger	7d285b6d5e	Decompile tt_002 func_us_80174998 (#1846) ... Weird issue with this one. The explicit casts for CalculateAngleToEntity and GetTargetPositionWithDistanceBuffer are required. Decomp.me will compile to the correct code without the casts, but the bit shifts to clear the high side get compiled out with the actual build. PSX: https://decomp.me/scratch/K1ruf PSP: https://decomp.me/scratch/x5w17	2024-10-29 22:14:30 +00:00
H.M. Burger	35ffeb8314	Decompiling function func_us_80173BD0 (#1843) ... The 2nd argument to func_us_80173994 is probably either some flags or needs to be an enum. But I am not sure what they are yet. I'll come back to clean them up once I get that function decompiled.	2024-10-29 09:28:17 -07:00
Jonathan Hohle	07081331b8	Decompile rbo3 func_us_801923DC and func_us_80192D64 (#1839)	2024-10-28 11:37:35 -07:00
bismurphy	1554483f24	Decompile ST0 EntityBackgroundVortex (#1838) ... Another one down! In terms of the sequence of functions, this is the last function in the ROM for ST0. The split between C and BSS was off by one (the NOP after the RA for this function was being pulled in as part of the 00 bytes in BSS), so I had to make some small BSS fixes to get a match. All good now! I believe this leaves only a single ST0 function remaining.	2024-10-27 14:32:20 -07:00
bismurphy	27b9e1fc80	Decompile ST0 EntityClockTower3D (#1837) ... This uses a few separated elements of its Ext; I suspect this corresponds to this Ext being shared across the entities in this file, but that kind of consolidation can be something we do in the future when they're all done. Anyway, another GTE-heavy function completed!	2024-10-27 13:33:57 -07:00
Josh Schreuder	4e9a6c22d1	Decompile a couple of no0 funcs + minor cleanup (#1835) ... Fixed a rodata split in one of the `no0` files Decompiled a couple of small functions While working on this I was having trouble getting a match, looked like `abs` but as usual I was having trouble getting it to work. Turns out I was using `--no-builtin` on decomp.me which breaks `abs` and is why I also had issues on my earlier scratches. So I've cleaned up the `ABS()` macro I added for those as it is not necessary on PSX	2024-10-27 20:02:54 +00:00
bismurphy	d97142f0f7	Decompile ST0 EntityCutscenePhotograph (#1833) ... Well. Oh my god. This function is finally done. It was brutal. I feel like the status bar face of the Doom Guy when he's at 1 HP. Anyway, it's decompiled! What a wild function. ST0 is coming to an end just as the other stages did before it. GTE continues to be a monster, but it's done.	2024-10-27 20:02:05 +00:00
bismurphy	59d4a40dd9	Decompile ST0 func_801BC5C0 (#1832) ... A very ugly one with a ton of GTE instructions that required fixing M2C errors to get it to work. Glad to have it done! Had to do a file split due to EntityCutscenePhotograph in the same file having rodata that isn't pulled in yet. This uses a few GTE macros which weren't being used before. While I'm at it, I reorganized the GTE macros file to match the order of the functions as used in the SDK's INLINE_C.H file. Doesn't really matter, but the file has some light organization so I figured we might as well match up with it.	2024-10-26 16:18:34 +01:00
Josh Schreuder	017f90e3cf	Decompile no0 Slinger functions (#1830) ... That's these guys in Marble Gallery  They share quite a bit in common with e_skeleton and e_bone_scimitar, but I decided not to deduplicate these ones at this stage	2024-10-26 11:45:01 +01:00
H.M. Burger	d774a146f4	Decompiling tt_002 func_us_801739D0 (#1829) ... PSX: https://decomp.me/scratch/e2PlK PSP: https://decomp.me/scratch/ien4a PSP is close, but has a register swap going on starting at ASM 134-148. v0 and v1 get flipped. I couldn't get that to fix I had to add a 2nd Ext for this overlay as in another function 0x7C is an Entity* and in this function 0x7E is an s16 set to an entity_id. This leads me to believe that this is an update function used for a sub entity.	2024-10-26 11:41:55 +01:00
bismurphy	5d68662c27	Name FLAG_BLINK for entities (#1828) ... This came up a little while ago, I discovered the purpose of this entity flag and we agreed in Discord that FLAG_BLINK would be the best name. This entire PR was a single find-and-replace operation; doesn't seem to have caught any false matches :)	2024-10-26 11:40:16 +01:00