2026-05-30T19:05:20  <OpenMW-bridge> <Foal (Mads)> Running into a problem dehardcoding world tooltips. They're supposed to move up/down the screen as you tilt up/down, to match the engine behavior, but if i implement that the result appears wobbly because of all the things that are off by 1 frame. First the there's no way to get a rendering ray with the same-frame camera info. With sync rays in onFrame, onFrame happens before camera info is updated by the engine so
2026-05-30T19:05:21  <OpenMW-bridge> it'll still be 1 frame off. With async rays you'll always be off by 1 frame, 2 if you start it from onFrame. And then element:update() is also a delayed action so it will also be off by 1 frame. Guess i'll have to make world tooltips appear at a fixed location instead.
2026-05-30T19:05:21  <OpenMW-bridge> <Foal (Mads)> https://cdn.discordapp.com/attachments/1230951723443552256/1510358467720909032/Screencast_20260530_203751.webm?ex=6a1c866f&is=6a1b34ef&hm=3d20d64c7c55e7128a06dc6cbca858fbcd7219128402d249c5620b78d335e9a0&
2026-05-30T19:08:39  <OpenMW-bridge> <come1244> But anyway, it's coming? Because i need it for a project and i'm lazy to make my own (aka steal it from sombody 🥷 )
2026-05-30T19:13:02  <OpenMW-bridge> <nox7> > And then element:update() is also a delayed action so it will also be off by 1 frame.  > all the things that are off by 1 frame Both of these things are a bane of existence to many mods 🙁
2026-05-30T19:17:09  <OpenMW-bridge> <S3c:tor> it makes implementing the repair menu really fun
2026-05-30T19:17:59  <OpenMW-bridge> <S3c:tor> The, uh. Like if you have any kind of inventory manipulation where you're updating UI state at the same timem
2026-05-30T19:18:05  <OpenMW-bridge> <S3c:tor> this also becomes very problematic
2026-05-30T19:18:14  <OpenMW-bridge> <nox7> 😮‍💨
2026-05-30T19:18:31  <OpenMW-bridge> <S3c:tor> There's a sort of, uh, I forget the pipeline tbh
2026-05-30T19:19:10  <OpenMW-bridge> <nox7> -# silently taking notes to avoid these situations in the OpenSH2 project
2026-05-30T19:19:13  <OpenMW-bridge> <S3c:tor> It's like. You consume your last repair item. But you can't redraw yet because the consumption has to happen in another context so you bounce that over and do the :remove, but then, that's also delayed, so once you bounce that back to the player, then they bounce another back to themselves, then you redraw
2026-05-30T19:20:13  <OpenMW-bridge> <S3c:tor> A lot of these issues arise from machinery that exists to sidestep scenegraph ops not being safe from the Lua thread, but it has a bunch of usages
2026-05-30T19:20:50  <OpenMW-bridge> <S3c:tor> Even that is dicey to say, there are multiple ways for multiple reasons
2026-05-30T19:23:07  <OpenMW-bridge> <S3c:tor> I kind of thought maybe we should just have some kind of LookAt bind
2026-05-30T19:23:28  <OpenMW-bridge> <S3c:tor> multiple modders including myself are making up their own solutions to do that and the engine naturally will too
2026-05-30T19:24:16  <OpenMW-bridge> <S3c:tor> I know it's kind of counter to design but if it's actually utilized by some interface, similarly to how openmw.camera/I.Camera work, it could be overrideable
2026-05-30T19:24:42  <OpenMW-bridge> <S3c:tor> You're always looking at something, everybody wants to know if there is a thing looked at and what the thing is, etc
2026-05-30T19:26:21  <OpenMW-bridge> <S3c:tor> camera.lookingAt(actor: openmw.types.Actor): openmw.core.GameObject? eg
2026-05-30T19:26:47  <OpenMW-bridge> <S3c:tor> doesn't have to be camera
2026-05-30T19:26:52  <OpenMW-bridge> <Foal (Mads)> Yeah I'm gonna put them in a fixed position for now and we can fix it later if it's even possible.
2026-05-30T19:27:32  <OpenMW-bridge> <Foal (Mads)> Getting the object being looked at isn't the problem. That's easy. Getting it's screen position for the same frame is the problem
2026-05-30T19:28:02  <OpenMW-bridge> <S3c:tor> Yes, wouldn't the above proposal alleviate that?
2026-05-30T19:28:32  <OpenMW-bridge> <S3c:tor> If C++ is always checking the looked at object, which it already is, I think we could shave off the extra latency from the way like ^
2026-05-30T19:29:08  <OpenMW-bridge> <Foal (Mads)> i suppose, if it's updated by the engine and then made available to be read during onUpdate(). But this still leaves the element:update() problem, so it will still be wobbly.
2026-05-30T19:29:47  <OpenMW-bridge> <S3c:tor> Yeah....
2026-05-30T19:30:09  <OpenMW-bridge> <Foal (Mads)> element:update() could be made selectively synchronous in onFrame. But not in onUpdate, as this will race and crash
2026-05-30T19:32:04  <OpenMW-bridge> <Foal (Mads)> If we did both and moved camera update to before onFrame that would likely fix it, but is a much bigger task and idk what i could do to existing camera mods.
2026-05-30T19:33:05  <OpenMW-bridge> <S3c:tor> Well uh I know T4rg3t5 is pretty messed up as a result of that
2026-05-30T19:33:21  <OpenMW-bridge> <S3c:tor> I think it's probably the same cause for a bunch of issues in Dynamic Camera too
2026-05-30T19:34:32  <OpenMW-bridge> <urm> This might have some confusing behavior if multiple update() calls interact in some way
2026-05-30T19:34:39  <OpenMW-bridge> <urm> But it's probably fine
2026-05-30T19:35:26  <OpenMW-bridge> <urm> It will likely break the current optimizations (e. g. if it's already queued for update - it won't try to update), so not a completely trivial change
2026-05-30T19:36:03  <OpenMW-bridge> <Foal (Mads)> most elements will only be updated by one script so i don't think that's a big problem
2026-05-30T19:40:43  <OpenMW-bridge> <urm> It's going to be a bigger problem long term, when we have dehardcoded UI APIs which assemble the final result out of multiple elements
2026-05-30T19:46:01  <OpenMW-bridge> <Foal (Mads)> I suppose. Could have two different calls and blame modders if they overuse the unoptimized one.
2026-05-30T19:46:15  <OpenMW-bridge> <nox7> > and blame modders lol
2026-05-30T20:05:16  <OpenMW-bridge> <come1244> Can't we get the tooltip without the looking at part?
2026-05-30T20:07:05  <OpenMW-bridge> <S3c:tor> No, that wouldn't be a Morrowind tooltip
2026-05-30T20:07:25  <OpenMW-bridge> <S3c:tor> Do you want one? I have some
2026-05-30T20:07:49  <OpenMW-bridge> <S3c:tor> what would even be the point of a tooltip that didn't know what it was targeting, though
2026-05-30T20:17:52  <OpenMW-bridge> <Foal (Mads)> I'm not sure what you mean? Do you want just the UI element? We need to know what's beeing looked at to create the correct ui element, so not having a lookat part doesn't make sense unless you just want a library for making tooltips (which already exists as mods).
2026-05-30T20:51:26  <OpenMW-bridge> <come1244> I just want a function with an object as an argument that return an UI ^^. But nevermind, it looks like it's not the topic.
2026-05-30T20:52:54  <OpenMW-bridge> <come1244> I have some laying around too, but i have hard time reading/understanding how it works (Ralts' one in IE). Having one shipped with openMW could have saved me some trouble.
2026-05-30T20:53:28  <OpenMW-bridge> <S3c:tor> you'd have to read how that one works, too, right..?
2026-05-30T20:53:39  <OpenMW-bridge> <S3c:tor> I'd really like to help you here but I'm not understanding what I could offer
2026-05-30T20:57:14  <OpenMW-bridge> <come1244> I try, i try. But reading code is hard when it's not part of the everyday job.
2026-05-30T20:57:40  <OpenMW-bridge> <S3c:tor> Yes but I was not asking if it was easy or hard
2026-05-30T20:57:51  <OpenMW-bridge> <S3c:tor> I was asking how the two things are different, so I can understand what you're saying, and help you
2026-05-30T20:57:57  <OpenMW-bridge> <S3c:tor> I know it is not easy for you
2026-05-30T20:58:27  <OpenMW-bridge> <S3c:tor> Like, why would ours be easier to use?
2026-05-30T20:58:30  <OpenMW-bridge> <S3c:tor> Because we document it?
2026-05-30T20:59:29  <OpenMW-bridge> <come1244> Yes, because you would not have nested it for a one purpose use. And probably with a nice api.
2026-05-30T21:02:00  <OpenMW-bridge> <S3c:tor> Do you have any specific wants out of the tooltip API itself?
2026-05-30T21:02:10  <OpenMW-bridge> <S3c:tor> like, layout options, or something
2026-05-30T21:04:08  <OpenMW-bridge> <Foal (Mads)> That's what i'm making. Now that i've clarified that screen position can't track smoothly without major rewrites, i'm not gonna spend more time on it and the rest of the dehardcoding effort is to just complete the tooltips. So i'll be working on it
2026-05-30T21:04:11  <OpenMW-bridge> <come1244> Just the gameObject as an argument is enough for me. An maybe the relative position too.
2026-05-30T21:04:14  <OpenMW-bridge> <Foal (Mads)> If you want it right away, it already exists as a mod. It was discussed yesterday in #lua-scripting , you could ask there what the name of the mod is. I believe it was Inventory Expanded.
2026-05-30T21:05:55  <OpenMW-bridge> <come1244> Yeah, it's in Ralts' mod. But he is a bit busy this times.tooltip
2026-05-30T21:09:24  <OpenMW-bridge> <S3c:tor> that's the one he was just talking about
2026-05-30T21:13:41  <OpenMW-bridge> <come1244> Nice, i haven't seen pwn post.  But anyway, there is no doors, actor and activators in Ralt's tooltips. They are not the hardest but an all in one could be so satisfying.
2026-05-30T21:20:50  <OpenMW-bridge> <S3c:tor> But we wouldn't make tooltips for those anyway
2026-05-30T21:21:01  <OpenMW-bridge> <S3c:tor> Other than... the name, I guess
2026-05-30T21:21:06  <OpenMW-bridge> <S3c:tor> that does count
2026-05-30T21:22:48  <OpenMW-bridge> <come1244> The teleport cell on doors?
2026-05-30T21:43:28  <OpenMW-bridge> <Foal (Mads)> Every object with a tooltip will get their tooltip
2026-05-30T21:43:38  <OpenMW-bridge> <S3c:tor> yes
2026-05-30T21:44:14  <OpenMW-bridge> <S3c:tor> I do not require further explanation
2026-05-30T21:46:30  <OpenMW-bridge> <Foal (Mads)> By default i will match the vanilla tooltips but i'm gonna make sure it has a reasonable interface for mods to make their additions and deletions similar to what's possible with IE, without having to completely recreate every tooltip.
2026-05-30T23:12:00  <OpenMW-bridge> <hyacinth2199> If you keep tooltips in a fixed position, you'll be able to replace these tooltips which is honestly what we need the most since right now they can't be separated from world tooltips in mygui/and we don't have access to these without replacing the windows entirely. But these tooltips seem to only appear on windows (training, alchemy, enchanting, spell creation) and on the player's active magic effects in the Magic
2026-05-30T23:12:01  <OpenMW-bridge> window and in the list of active spells, so nothing with the camera is required.
2026-05-30T23:12:01  <OpenMW-bridge> <hyacinth2199> https://cdn.discordapp.com/attachments/1230951723443552256/1510420544883785798/discord_2026-05-30_19-00-09.mp4?ex=6a1cc040&is=6a1b6ec0&hm=b983c94d7f2531a01ec688eab82f4669917dcd93158cb94e8bd419d32a23361a&
2026-05-30T23:28:17  <OpenMW-bridge> <hyacinth2199> I think the ones for spells and magic effects have been partially dehardcoded since we can change descriptions, icons, names, etc. with magic effects, but we can't manipulate the UI itself. Currently, me and 2 other modders (maybe more?) use a shared library for an onFrame render raycast for world tooltips/UIs and keep them in a fixed position as you can see in the first 2 examples (quickloot and the world interaction
2026-05-30T23:28:17  <OpenMW-bridge> from Sun's Dusk). Ralts' (the third example) are different and adjust their position based on where the cursor is, which I'm assuming is how he did world tooltips although he hasn't shared his code for those after discovering they're inseparable from the magic tooltips
2026-05-30T23:28:18  <OpenMW-bridge> <hyacinth2199> https://cdn.discordapp.com/attachments/1230951723443552256/1510424638931341504/discord_2026-05-30_19-04-27.mp4?ex=6a1cc410&is=6a1b7290&hm=14f6a93ddc45a7ee44fde3fe3f0b481dbeb5b8af6ce95ba2929f42966369dbf1&
2026-05-30T23:29:55  <OpenMW-bridge> <hyacinth2199> Also in that video, you can see why it’s necessary to replace tooltips on windows/interfaces and the world tooltips, since we get plenty of bug reports about modified tooltips being different from tooltips in the world :todd:
2026-05-30T23:40:08  <OpenMW-bridge> <Foal (Mads)> To clarify, the fixed position issue is only about (in)correctly placing world tooltips wrt how the engine does it, nothing else. The engine places the tooltip at the screen position of the top middle of the bounding box, which moves across the screen as you pan your camera, which appears wobbly in lua because of the 2 frame delay. I'm gonna make a dehardcode MR regardless of whether world tooltips are accurately placed
2026-05-30T23:40:08  <OpenMW-bridge> or not. If anyone feels strongly about the inaccuracy we can introduce an engine vs lua tooltip toggle. Any other tooltip can be placed accurately because the wobble isn't discernible with mouse movements (otherwise you would see wobbliness in your examples, as they have the same frame delays), because it's the movement of the scene as you turn the camera that creates the illusion of a wobble.
2026-05-30T23:47:43  <OpenMW-bridge> <pwn90> how does the render ray affect the latency? i mean it would be really cool having the activation ray exposed in lua, but i dont really see how that adds to the delay
2026-05-30T23:48:23  <OpenMW-bridge> <pwn90> anyway, im very excited we might be getting that plus some latency optimizations, floating healthbars are also pretty wobbly if your framerate isnt 100+