2026-03-31T05:32:12  <OpenMW-bridge> <S3c:tor> Why the heck does getHeightAt want a reference to a cell anyway?
2026-03-31T05:34:12  <OpenMW-bridge> <S3c:tor> The position should always explain to you the target cell. Even if we need to account for some kind of ESM4 thing I don't see any reason to take a reference to a cell, we'd want a worldspace id, yes?
2026-03-31T05:37:28  <OpenMW-bridge> <S3c:tor> The case for which these functions were developed was Fall's footsteps mod, so, the usage he had at the time makes flawless sense: core.land.getHeightAt(self.position, self.cell)   But when you need a landscape height for a cell to whom you do not already have a reference, it's bad. But also I don't see why this needed the cellOrId to begin with.
2026-03-31T05:38:35  <OpenMW-bridge> <S3c:tor> I'd think we could... Uhmmm... Maybe not.
2026-03-31T05:38:39  <OpenMW-bridge> <S3c:tor> Well.
2026-03-31T05:39:17  <OpenMW-bridge> <S3c:tor> I think we should actually have differentGetHeightAt(position, worldspace?)
2026-03-31T05:40:02  <OpenMW-bridge> <S3c:tor> getLandHeightAt, whatever. This ain't right, Dutch, I'm tellin' ya
2026-03-31T17:09:14  <OpenMW-bridge> <wareya> requesting a screenshot api
2026-03-31T17:09:39  <OpenMW-bridge> <wareya> doesn't need to be particularly advance, the bare minimum of "take the current or next frame or whatever as a screenshot to a file over here" would be fine
2026-03-31T17:10:24  <OpenMW-bridge> <wareya> context: i have a cubemap/panorama maker but it needs me to manually edit the screenshot filenames to tell it which faces are which. i also need to manually take the screenshots
2026-03-31T17:11:55  <OpenMW-bridge> <S3c:tor> Consider resurrecting the cubemap screenshot feature we killed in .49 because it was broken and nobody used it?
2026-03-31T17:12:40  <OpenMW-bridge> <.hemaris> 🙋 i would have used it if it had worked! i tried and everything
2026-03-31T17:13:05  <OpenMW-bridge> <S3c:tor> I do not remove features
2026-03-31T17:13:28  <OpenMW-bridge> <wareya> didn't we not just kill it but remove the code?
2026-03-31T17:13:53  <OpenMW-bridge> <wareya> also i think this is one of those things that makes more sense as "expose the individual necessary functions so an addon can do it" than an engine feature
2026-03-31T17:14:08  <OpenMW-bridge> <wareya> well, we need cubemap rendering in general
2026-03-31T17:14:13  <OpenMW-bridge> <wareya> but that's slightly different from cubemap screenshots
2026-03-31T17:14:15  <OpenMW-bridge> <wareya> e.g. no postprocessing
2026-03-31T17:14:22  <OpenMW-bridge> <Good Eye> I added it to the RTT MR so you can use it for viewing your screenshots in game:todd:
2026-03-31T17:14:35  <OpenMW-bridge> <S3c:tor> It will be a long time before Lua scripts are making cubemaps screenshots unless someone fixes the underlying cubemap screenshot feature
2026-03-31T17:15:13  <OpenMW-bridge> <wareya> is "a long time" "right now"
2026-03-31T17:15:14  <OpenMW-bridge> <wareya> https://cdn.discordapp.com/attachments/1230951723443552256/1488587485532524686/image.png?ex=69cd52a1&is=69cc0121&hm=02c1b186d019154265508788cbb342d7fffccd893e372237b28eb6d9bca15b1e&
2026-03-31T17:15:17  <OpenMW-bridge> <S3c:tor> You would need IO access you don't have and it stitch them together yourself
2026-03-31T17:15:29  <OpenMW-bridge> <S3c:tor> So no it is not right now or soon
2026-03-31T17:15:29  <OpenMW-bridge> <wareya> oh yes i'm doing the stitching with a vibecoded panorama converter
2026-03-31T17:15:32  <OpenMW-bridge> <S3c:tor> Yes
2026-03-31T17:15:33  <OpenMW-bridge> <wareya> but that's fine
2026-03-31T17:15:39  <OpenMW-bridge> <wareya> no issues
2026-03-31T17:15:43  <OpenMW-bridge> <S3c:tor> Okay good luck
2026-03-31T17:15:48  <OpenMW-bridge> <wareya> just want the screenshots to be named so i don't have to rename them myself
2026-03-31T17:16:07  <OpenMW-bridge> <wareya> https://cdn.discordapp.com/attachments/1230951723443552256/1488587708551921889/mwpano.png?ex=69cd52d6&is=69cc0156&hm=993468f0eba0df7e7528cab648c7f9048115b5928d48a77ffa1a75b32f8ff632&
2026-03-31T17:18:18  <OpenMW-bridge> <.hemaris> that still has a seam where the solar glare cuts out
2026-03-31T17:18:33  <OpenMW-bridge> <wareya> you should see the one i just made where the seam is even worse
2026-03-31T17:19:14  <OpenMW-bridge> <wareya> https://cdn.discordapp.com/attachments/1230951723443552256/1488588495155892254/image.png?ex=69cd5391&is=69cc0211&hm=20d122a8148b88bd9f467c16e2c0afe9f583d0fe0acd0818c3ae529a7852a3fc&
2026-03-31T17:19:52  <OpenMW-bridge> <.hemaris> this happens in panoramic photography too 😔
2026-03-31T17:38:26  <OpenMW-bridge> <S3c:tor> Hey @DaisyHasaCat you totally 100% resolved my issues with the MR but friendly reminder thread author does resolution 💜
2026-03-31T18:15:56  <OpenMW-bridge> <Good Eye> RTT for 0.52? :ur: 💭 ⌨️
2026-03-31T18:38:33  <OpenMW-bridge> <S3c:tor> Please, boss? :sadcat:
2026-03-31T18:38:52  <OpenMW-bridge> <S3c:tor> Everyone except OpenMW has dehardcoded inventories now :sadcat:
2026-03-31T19:59:41  <OpenMW-bridge> <Capo> no more Lua features for .51 :sadcat:
2026-03-31T20:00:32  <OpenMW-bridge> <Capo> especially not rushed Lua features
2026-03-31T20:02:12  <OpenMW-bridge> <DaisyHasaCat> let's wait 6 more months before doing a feature freeze
2026-03-31T20:03:39  <OpenMW-bridge> <assumeru> And then we can wait another 6 months after that :todd:
2026-03-31T20:04:53  <OpenMW-bridge> <Good Eye> that's why I said 0.52 :ur:
2026-03-31T20:05:14  <OpenMW-bridge> <Capo> yes that's good that's holy
2026-03-31T20:05:33  <OpenMW-bridge> <assumeru> That's why he's the good one
2026-03-31T20:05:39  <OpenMW-bridge> <sophie42069101> Yolo the physics mr as well so when we're waiting we can spend 12 months not stuck in Balmoras rock while testing. 🫠
2026-03-31T20:06:06  <OpenMW-bridge> <assumeru> The trick is to not use whatever mod adds that rock
2026-03-31T20:06:16  <OpenMW-bridge> <DaisyHasaCat> if capo got his way we'd remove lua
2026-03-31T20:06:57  <OpenMW-bridge> <Capo> that would fix all lua crashes, EE would love it
2026-03-31T20:07:05  <OpenMW-bridge> <assumeru> I see advantages
2026-03-31T20:07:57  <OpenMW-bridge> <assumeru> We'll replace it with a DSL expressed in JSON, but we'll use yaml-cpp to parse it so people don't think it's fast to compile
2026-03-31T20:08:18  <OpenMW-bridge> <DaisyHasaCat> Just use papyrus
2026-03-31T20:08:52  <OpenMW-bridge> <assumeru> Too sensible
2026-03-31T20:09:08  <OpenMW-bridge> <S3c:tor> None of the features on the table right now are being rushed
2026-03-31T20:09:18  <OpenMW-bridge> <S3c:tor> They are just being pushed back
2026-03-31T20:10:39  <OpenMW-bridge> <S3c:tor> Collision state could use a review from someone who's familiar with physics but I took several pains to ensure it made sense and was reasonable in the context of magic dehardcoding. It's very useful and large projects have requested it for quite some time
2026-03-31T20:11:00  <OpenMW-bridge> <S3c:tor> But anyway I know better than to ask for any of that to be .51 material to begin with
2026-03-31T20:11:21  <OpenMW-bridge> <S3c:tor> But collision state needs looked at and the land bindings are sus
2026-03-31T20:11:36  <OpenMW-bridge> <DaisyHasaCat> land bindings work fine
2026-03-31T20:11:55  <OpenMW-bridge> <Capo> i have foreseen this
2026-03-31T20:11:56  <OpenMW-bridge> <Capo> https://cdn.discordapp.com/attachments/1230951723443552256/1488631953425956864/0d09f524f8a81b50.png?ex=69cd7c0b&is=69cc2a8b&hm=e52031879a559a4b7ec6f438a4f57c1e9ff608da3efd87bee8d8ee303f0c1cbd&
2026-03-31T20:12:31  <OpenMW-bridge> <S3c:tor> No, they do not
2026-03-31T20:12:36  <OpenMW-bridge> <DaisyHasaCat> They do
2026-03-31T20:12:52  <OpenMW-bridge> <S3c:tor> Please explain to me why a position and cell are necessary.
2026-03-31T20:13:04  <OpenMW-bridge> <DaisyHasaCat> You need either the worldspace or a cell
2026-03-31T20:13:21  <OpenMW-bridge> <S3c:tor> Right, so pass a position or a worldspace id optionally like I said.
2026-03-31T20:13:25  <OpenMW-bridge> <DaisyHasaCat> and some form of position is needed, would work for it to accept V3 or V2 though
2026-03-31T20:13:32  <OpenMW-bridge> <DaisyHasaCat> But it still works fine in the current form
2026-03-31T20:13:35  <OpenMW-bridge> <S3c:tor> They go together and a reference to a cell is pointless.
2026-03-31T20:13:39  <OpenMW-bridge> <S3c:tor> I did not say it was broken
2026-03-31T20:13:43  <OpenMW-bridge> <S3c:tor> I said it was wrong.
2026-03-31T20:14:02  <OpenMW-bridge> <Capo> eh, they're serviceable, not a blocker
2026-03-31T20:14:09  <OpenMW-bridge> <S3c:tor> Didn't say that either
2026-03-31T20:14:15  <OpenMW-bridge> <S3c:tor> But needs corrected
2026-03-31T20:14:17  <OpenMW-bridge> <Capo> I'd understand if they had a bug or something
2026-03-31T20:14:22  <OpenMW-bridge> <assumeru> I disagree with workspace id being optional
2026-03-31T20:14:31  <OpenMW-bridge> <DaisyHasaCat> openmw.content needs to be finished
2026-03-31T20:14:44  <OpenMW-bridge> <assumeru> I mean, that's definitely not happening this release 😛
2026-03-31T20:15:06  <OpenMW-bridge> <S3c:tor> I mean why not assume sys::default if the second param is nil?
2026-03-31T20:15:23  <OpenMW-bridge> <S3c:tor> Can we even get the current world space id?
2026-03-31T20:15:26  <OpenMW-bridge> <assumeru> Too TES3 centric
2026-03-31T20:15:37  <OpenMW-bridge> <DaisyHasaCat> This isn't mwscript
2026-03-31T20:15:50  <OpenMW-bridge> <assumeru> Presumably you know the current cell so you can get the worldspace id from it
2026-03-31T20:15:51  <OpenMW-bridge> <S3c:tor> Fascinating aside
2026-03-31T20:16:06  <OpenMW-bridge> <S3c:tor> So do we have a binding on CellT that gives the world space ID?
2026-03-31T20:16:14  <OpenMW-bridge> <assumeru> Maybe?
2026-03-31T20:16:30  <OpenMW-bridge> <DaisyHasaCat> https://openmw.readthedocs.io/en/latest/reference/lua-scripting/openmw_core.html##(Cell).worldSpaceId
2026-03-31T20:16:52  <OpenMW-bridge> <S3c:tor> We do.
2026-03-31T20:16:57  <OpenMW-bridge> <S3c:tor> Yeah, alright.
2026-03-31T20:17:05  <OpenMW-bridge> <S3c:tor> Although, wait, no
2026-03-31T20:17:11  <OpenMW-bridge> <Capo> the collision mask thing looks extremely scary
2026-03-31T20:17:24  <OpenMW-bridge> <S3c:tor> This doesn't address the problem of not having a reference to the cell in the first place
2026-03-31T20:17:40  <OpenMW-bridge> <S3c:tor> So it still has the same problem
2026-03-31T20:17:45  <OpenMW-bridge> <Capo> it changes the saved game format, even
2026-03-31T20:17:57  <OpenMW-bridge> <assumeru> Getting cells is easy though
2026-03-31T20:18:10  <OpenMW-bridge> <DaisyHasaCat> Or just a cell id
2026-03-31T20:18:14  <OpenMW-bridge> <S3c:tor> Mostly, but not if you're in a local script
2026-03-31T20:18:19  <OpenMW-bridge> <S3c:tor> And want an unloaded cell
2026-03-31T20:18:31  <OpenMW-bridge> <S3c:tor> Local -> global -> local, just to get a height
2026-03-31T20:18:40  <OpenMW-bridge> <DaisyHasaCat> You can just use a cell id
2026-03-31T20:18:46  <OpenMW-bridge> <DaisyHasaCat> there's no need for that hop
2026-03-31T20:18:50  <OpenMW-bridge> <S3c:tor> Sure, where from?
2026-03-31T20:18:58  <OpenMW-bridge> <S3c:tor> Usually I use world.cells
2026-03-31T20:19:09  <OpenMW-bridge> <assumeru> self.cell exists no?
2026-03-31T20:19:25  <OpenMW-bridge> <S3c:tor> Not if you want a cell other than that
2026-03-31T20:19:32  <OpenMW-bridge> <DaisyHasaCat> If you're assuming the default worldspace then you can use a string like "Esm3ExteriorCell:-3:-2"
2026-03-31T20:19:44  <OpenMW-bridge> <DaisyHasaCat> it doesn't matter if that cell has your position or not
2026-03-31T20:19:55  <OpenMW-bridge> <S3c:tor> I am not telling modders to construct worldspace IDs themselves but you're welcome to
2026-03-31T20:20:10  <OpenMW-bridge> <assumeru> It's no different from using hardcoded cell coordinates
2026-03-31T20:20:33  <OpenMW-bridge> <assumeru> If you know what cell you want but it's apparently not dynamic, then that's what you're going to have to do. I don't really see the problem
2026-03-31T20:21:04  <OpenMW-bridge> <assumeru> And if you derived it from something then... you've got everything already?
2026-03-31T20:21:18  <OpenMW-bridge> <S3c:tor> Mostly just that second param doesn't really do any good, it's not so much about capability
2026-03-31T20:21:29  <OpenMW-bridge> <S3c:tor> 16K, 16K is 2, 2 every time
2026-03-31T20:21:45  <OpenMW-bridge> <S3c:tor> It can take that and just grab a cell
2026-03-31T20:21:54  <OpenMW-bridge> <DaisyHasaCat> You still need the worldspace
2026-03-31T20:21:58  <OpenMW-bridge> <S3c:tor> Yes
2026-03-31T20:22:32  <OpenMW-bridge> <assumeru> You could pass 0,0 for everything if you know you're dealing with TES3 cells
2026-03-31T20:23:29  <OpenMW-bridge> <S3c:tor> Like, by hardcoding the id somewhere?
2026-03-31T20:23:47  <OpenMW-bridge> <S3c:tor> Ugly, but I guess if the string format is not expected to change it can be acceptable.
2026-03-31T20:24:39  <OpenMW-bridge> <assumeru> It's the same level of hardcoding as going x.recordId == 'rat'
2026-03-31T20:24:51  <OpenMW-bridge> <S3c:tor> Yea.
2026-03-31T20:25:08  <OpenMW-bridge> <assumeru> Whether that's acceptable is really contextual 🤷
2026-03-31T20:25:39  <OpenMW-bridge> <S3c:tor> It's weird and I don't like it but it's not weird enough to complain about more
2026-03-31T20:25:59  <OpenMW-bridge> <S3c:tor> nil second param should fall back to sys::default worldspace
2026-03-31T20:26:30  <OpenMW-bridge> <S3c:tor> It's not actually a breaking change and covers pretty much every current usage and isn't actually all that tes3 centric since ESM4 plugins define worldspaces
2026-03-31T20:27:04  <OpenMW-bridge> <assumeru> I'm not convinced sys::default should exist. Having TES3's exterior worldspace id be nil seems more elegant
2026-03-31T20:29:33  <OpenMW-bridge> <S3c:tor> That's fine too, sys::default is an archaic zini construct
2026-03-31T20:29:50  <OpenMW-bridge> <S3c:tor> I'm not even aware it still exists at the engine level
2026-03-31T20:30:42  <OpenMW-bridge> <S3c:tor> I just mean that if the user passes nil as the second param, we assume sys::default, which to me means the TES3 worldspace that can't alternatively identify itself. Not that we actually ask people to pass sys::defualt
2026-03-31T20:33:40  <OpenMW-bridge> <S3c:tor> Well, it needs format changes because of persistence. If they don't persist you'll load the game and someone's falling out of the sky. Potential regressions I spotted included breaking adjacent magic effects which is accounted for. There will be an intermediary period where it's kind of weird as the scripted state will override game defined states, similar to animation, but once effects are dehardcoded that's gone. It also
2026-03-31T20:33:40  <OpenMW-bridge> facilitates dehardcoding the effects it """breaks""" in the first place.
2026-03-31T20:41:10  <OpenMW-bridge> <assumeru> It does end up in saves so probably. But yeah, I'm just kinda reiterating my position on namespaces here
2026-03-31T21:46:46  <OpenMW-bridge> <S3c:tor> Absolutely fair. The namespace and exact implementation isn't important so much as the second parameter being worldspaceId?