2026-04-06T00:05:46 Is it just numbers though? It just seems silly to not let a shader be controlled by lua in some ways while allowing manual reordering in the menu, it seems like it's intentionally locked 2026-04-06T00:26:54 Is the only way to get the region of an interior cell to load all nearby cells and find their regions? Or am I missing something? 2026-04-06T06:08:44 Why do mwse mods not show up in plugins but openmw lau mods show up 2026-04-06T06:27:48 Because MWSE lua is different to OpenMW lua - its not compatible 2026-04-06T06:32:44 @nox7 angles is looking awesome, the front page made me giggle bc i really have spent the past two weeks working on the UI for the damn mod i want to make 😭 regardless, after spending the afternoon figuring out how to do scroll bars, it would be very nice to see such a feature in your library! i think i'll definitely be seeing how easily i can convert my UI to your library after release regardless because 1200 lines for a UI 2026-04-06T06:32:44 is silly (and im not done) 2026-04-06T06:37:31 Sorry meant with something like kezyma openmw player why do they show up 2026-04-06T06:37:32 ah I just saw the thing about not being able to detect engine handlers. alas! 2026-04-06T08:14:38 Yes 2026-04-06T08:15:04 Nice 2026-04-06T08:16:12 Note that some interiors might lead to multiple different regions at the same time 2026-04-06T08:19:40 Yeah that’s fine 2026-04-06T08:47:09 what you working on 2026-04-06T08:54:21 Creating an API so that I can see what region the player is in regardless of whether they’re in an exterior or interior for a few of my mods 2026-04-06T11:15:16 Thank you very much, it's been a long time coming it seems. The only short fall is not having a UI event for the mouse wheel, but you can detect the mouse wheel from an engine handler. I just chose not too for my library because it's supposed to be a drop-in and use library. If I did support it, then the user would have to set up an event for mouse wheels on the engine handler just for them to use my library, and that just isn't 2026-04-06T11:15:17 in the spirit of things. Yes, the scroll canvas functionality that supports any elements in them is a bit of a heavy code segment, but super helpful. And 1200 lines for a single UI? Oh that's... Not fun 2026-04-06T11:16:41 I just saw your UI in the showcase, that's still awesome you got that figured out and got it implemented 2026-04-06T11:38:04 It could be optional, I think. You could provide a snippet with an engine handler in the docs, which basically would resend mouse wheel data as a custom event , and you add an eventHandler for it in your library. If no event is sent, this part of functionality just won't work 2026-04-06T12:00:34 I did consider this, because it is a natural UX. I'd have to find out what window the mouse pointer is at and then what scroll canvas. I don't remember if, when two UIs are stacked on top of each other, there is a Lua way to find out which is rendered over the other. 2026-04-06T12:04:39 Maybe this can be controlled by tracking focus? If nested element of the scroll view has the focus, then mouse wheel events should be handled. In other case, just ignored 2026-04-06T12:14:05 Hmm, that's a decent idea 2026-04-06T12:52:27 the highest one takes priority, it's very annoying my 'fix' is having a top-end nil variable which mouseFocus assigns to the UI element I want to scroll through but it's not perfect, there's a 1 pixel space between each button where it stops registering (I think it might be because of the template border now that I write this out) 2026-04-06T12:53:31 Am I understanding you right when you put "1200 lines" and it's just for that UI? Not all of the code for your mod? 2026-04-06T12:53:55 there's a few small .Lua files but otherwise yeah 2026-04-06T12:54:47 one sec I have a github 2026-04-06T12:55:09 Oh perfect 2026-04-06T12:56:02 https://github.com/nibbyy/openmw-tavern-keeper/blob/main/scripts/nibby/otk/menu/OTKTavernMenu.lua 2026-04-06T12:56:23 I'm certain things can be done better, I'm a novice I was going to ask a few UI folks to take a look at it before release 2026-04-06T12:56:55 Well, I'm just curious about how a UI like that would be implemented in code-only; but just off the bat your code is very clean and well documented. 2026-04-06T12:57:24 I saw @S3c:tor's annotations, didn't know what they were, researched and started using them 2026-04-06T12:57:28 they're awesome 2026-04-06T12:58:05 but I also need to comment a lot because I have memory problems 😭 2026-04-06T12:58:40 Fair, but many people would have "memory problems" when they come back to complex code 3+ months later too. So, no harm. 2026-04-06T12:58:54 <.arrean> git blame, my greatest enemy ;/ 2026-04-06T12:59:13 <.arrean> "who the fuck" "oh, twas I" 2026-04-06T12:59:18 LOL 2026-04-06T13:00:30 the main functions for the scroll bar are addScrollBar and updateScrollBar 2026-04-06T13:00:41 they branch off into a few helpers 2026-04-06T13:02:22 Right, I'm following them around. It's pretty similar to the implementation I did as well - that's cool. What is the performance of your scrollbar? As in, when you start scrolling with the F3 window open how much do Input and/or LuaSync go up? 2026-04-06T13:03:06 when I'm home this afternoon I'll let you know! I was curious how to test performance too, I'll assume the worst 😭 2026-04-06T16:33:24 You can re-order any shaders and there really isn't a real reason we can't just expose everything to Lua. You can change any uniform from Lua that's marked "static = false". Though, we could be open to allowing anything to be set. The reason it wasn't initially was to prevent people from using non-static variables as it forces a shader re-compiliation. 2026-04-06T16:34:11 I think a warning message would suffice if someone set a non static uniform. It's a bit confusing because "uniforms" get turned into const 2026-04-06T17:31:06 <.lelimule> Thank you @skrow42 and @Sosnoviy đŸ…±or, but are you sure that useItem or setEquipment can make a NPC equip his best armor automatically? I can equip the NPC with a given item, but the problem was to make a NPC equip his best protections automatically, like when we do "additem" to the console. Example, i do something like that: chitin_cuirass:moveInto(types.Actor.inventory(fargoth)) => Fargoth now has a chitin cuirass in his 2026-04-06T17:31:06 inventory (but not equipped) Then in the console i do: fargoth->additem "gondolier_helm" 1 => Fargoth automatically equip his best protections (the chitin cuirass (and, for example, if he has a non-equipped chitin mask, he equips that too)) I can't do that with useItem or setEquipment. Did i miss something? 2026-04-06T17:33:40 This specific functionality might not be implemented lua side, I am not sure though 2026-04-06T17:34:53 uhhh, idk about this particular issue 2026-04-06T17:35:34 Might be an actual bug report or an intended "feature" 2026-04-06T18:24:45 Oh okay so can I mark specific things as static false without the entire shader get the dynamic flag that prevents reordering or disabling in the f2 menu? That's what I was missing 2026-04-06T18:35:03 Yes 2026-04-06T18:35:16 Dynamic could technically be deprecated now that we can hide the shdaer from the hud 2026-04-06T18:35:31 or do we, I forget 😁 2026-04-06T18:53:07 <.hemaris> i wish i could bind the debug shader's normals view toggle to a keypress 2026-04-06T19:36:21 Say i have 1000 tiny cells each of whic i want to load and lookup positions of objects inside 2026-04-06T19:36:33 And i only need to do it once on load 2026-04-06T19:36:54 Is that "bad" will doing that have some awful consequences? 2026-04-06T19:39:42 Yeh that's going to be awful 2026-04-06T19:40:12 When you actually load the cell it will take forever and also inflate the save iirc 2026-04-06T19:40:45 What I do when I need to do that is pre-run it on my machine, dump it into a file, and ship the file with the mod 2026-04-06T19:41:09 If you use yaml you can use the builtin markup package to parse it 2026-04-06T19:47:25 i see, thanks, those cells are kind of templates that provide additional positional info about objects (e.g at which height and orientation can character sit on a chair of this type) 2026-04-06T19:47:39 alternative i was thinking of - just rolling out a blender addon that can export it to yaml 2026-04-06T19:47:54 i havent though of exporting cells to yaml though, not sure now which is better hmm 2026-04-06T19:48:28 probably exporting cells, since its probably more modders are familiar with CS rather than with blender? 2026-04-06T19:48:32 Maybe??!! 2026-04-06T19:50:02 Blender is a big ask imo 2026-04-06T19:50:49 Since the cells are small maybe it won't matter 2026-04-06T20:01:33 input goes from ~0.05 to ~0.10-0.20 when scrolling luasync goes from ~0.20 (menu open) to ~0.50-0.60 when scrolling 2026-04-06T20:01:36 i have no idea how good/bad that is 2026-04-06T20:15:19 <.hemaris> this seems like a table that you should just make ahead of time and distribute with the mod. players with super niche ancient mesh replacers that you've never heard of can add their own entries to it 2026-04-06T20:16:11 That's really good 2026-04-06T20:16:23 :clap: 2026-04-06T20:17:17 How about resizing and moving? :36vehks: 2026-04-06T20:18:11 Resizing is my system's kryptonite 2026-04-06T20:18:29 Yeah resizing is always the worst 2026-04-06T20:18:37 ive decided against resizing (for now......) moving does take a slightly larger hit, at least on luasync input only goes up to 0.10 or so, but luasync jumps up to ~1.00 2026-04-06T20:18:56 I think the way we handled it in the cooking UI is okay, it doesn’t bring the engine to its knees at least 2026-04-06T20:19:11 Do you remember your time stats in the F3 chart? 2026-04-06T20:23:08 https://cdn.discordapp.com/attachments/854806553310920714/1490809102086045817/discord_2026-04-06_16-21-10.mp4?ex=69d567ab&is=69d4162b&hm=5156162471f9fc5e9885939773f95d8938cd039ac6cd579e1a4a13dac95cc9b8& 2026-04-06T20:23:43 Not so bad compared to the window replacers haha 2026-04-06T20:24:52 But as far as memory goes, fps is the biggest indicator since people obviously notice that right away 2026-04-06T20:48:33 Oh whoa 2026-04-06T20:48:53 Even with mine recomputing an entire Chromium rendering system it doesn't go that high. That's interesting 2026-04-06T20:48:59 Is this a released mod/source somewhere? 2026-04-06T20:50:24 Well, there are hundreds (or thousands maybe even) of elements in this bad boy and these are inventories as well :’) but yeah my mod is Sun’s Dusk for the cooking and the UI windows are all from ralts 2026-04-06T20:51:30 I mean, fair point, it does scale pretty harshly with tons of elements 2026-04-06T20:52:22 I'll have to look at how browsers are culling their element recalculation checks to see how they handle it - but there's also the possibility it may just be MyGUI draws or something with the way the Lua bridge impl handles it. 2026-04-06T20:53:12 Yeah with a single container with text in it, resizing from mousewheel doesn’t even get clocked 2026-04-06T20:55:37 im planning on having a scrollable catalog of furniture/upgrades the player can purchase would it save performance to make elements visible = false when they've sufficiently scrolled off the visible view area? 2026-04-06T20:57:13 hmm. if performance gets this bad with a lot of elements, it may be better to build it in a way where scrolling just replaces the information on the catalog, like scrolling through lines/pages, rather than having a huge list of elements that gets scrolled through 2026-04-06T20:57:43 hard to say if doing all of that rebuilding/updating would be just as bad though, suppose ill have to test! 2026-04-06T21:04:15 Unfortunately, I actually don't know. I'm about to get home from my office and I might test this with my scrollable canvas/viewport impl if the draw calls are actually having any noticeable impact (my gut says no; but eh - I don't know enough about the MyGUI implementation on the C side). 2026-04-06T21:04:58 The solution on scrolling may be to stop rendering and repositioning them once they're out of viewport (AFAIK, this is what browsers do) and just keep the positions as abtract data. 2026-04-06T21:05:33 I'll put like 100 elements in my scroll canvas and see 2026-04-06T21:05:45 makes sense yeah, just uncertain on whether or not doing the :update()'s and prop changes would end up being any faster performance wise 😭 2026-04-06T21:06:22 regardless let me know what you find out! 2026-04-06T21:48:37 For drag moving you could instead drag a ghost window that is just a border and transparent black background. Only redraw on release 2026-04-06T22:29:47 Okay, so I put 100 elements in for a resize and a scroll baseline benchmark with my Blink-engine port code. 2026-04-06T22:29:47 https://cdn.discordapp.com/attachments/854806553310920714/1490840971376595024/2026-04-06_17-29-06.mp4?ex=69d5855a&is=69d433da&hm=651dcc8dd2bffd6afab0b15edffe6f2f535c0f78addcf1411f5e4f550f96abef& 2026-04-06T22:30:54 Yeah, looks about right 2026-04-06T22:30:54 This is probably not helped by the draw calls of the castle and NPCs in the distance 2026-04-06T22:37:59 Did a test where they just are hidden/invisible from view entirely an when not scrolled in. Did not affect results. So them being not rendered isn't a performance impact @nibstuh 2026-04-06T22:38:00 https://cdn.discordapp.com/attachments/854806553310920714/1490843038334058557/2026-04-06_17-37-11.mp4?ex=69d58746&is=69d435c6&hm=9babe3cd536aae238342704803aa3efd1ea0e56f3aa0eb1b7ea5aabf10154a4f& 2026-04-06T22:38:48 Finally, I'll try just not changing their .position when they go off canvas and making them become static elements so calculation-culling happens. 2026-04-06T22:47:08 Okay, it's a big buggy (my quick position calculation is off by the padding and gapping), but it works as intended (stops moving them when they get to a certain point. 2026-04-06T22:47:09 https://cdn.discordapp.com/attachments/854806553310920714/1490845340855697488/2026-04-06_17-46-24.mp4?ex=69d5896b&is=69d437eb&hm=99672fdabcc558a9e962aec1978d4a4f742d8d720810080c2ce305ca611c1ee2& 2026-04-06T22:47:37 So, final conclusion - it just seems like something outside of what we can actually control is causing bad performance when there are larger amounts of UI elements on the screen - and we can't do anything about it from the Lua side 2026-04-06T22:52:41 damn, well good to know at the very least! I may try that method I mentioned of scrolling through a catalog by just updating the information in the clickable 'panes' of the catalog list, rather than actually moving elements, and see where my testing lands me 2026-04-06T22:52:55 Ah, yeah, paginating them you're saying? 2026-04-06T22:58:44 yeah! but again given how the UI API works, I really don't know if pagination would be faster, since the scrolling element is built once and the patination would require frequently updating the elements 2026-04-06T23:01:45 I think it's a solid idea. You'll be dealing with a lot less elements on more common user-interaction (using your UI rather than adjusting its size/position). Showing the user pagination (and even a search input to filter them) would probably be way more performant. Something like this mock up (I did this in like 30 seconds ignore how ugly it is) 2026-04-06T23:01:46 https://cdn.discordapp.com/attachments/854806553310920714/1490849021789606088/2026-04-06_18-00-35.mp4?ex=69d58cd9&is=69d43b59&hm=38abb5bad6732ab3b7169156b487c1622bd2dc1a8b7043194b6db7581a711c57& 2026-04-06T23:02:33 (I never even thought about pagination as an alternative, good idea) 2026-04-06T23:04:24 https://tenor.com/view/kronk-its-all-coming-together-gif-15058130 2026-04-06T23:25:51 well there be a magical controller support when elements can be marked as like interactable/selectable so controller dpad will focus on those specific elements or something along those lines? 2026-04-06T23:25:58 (cue wishfull thinking) 2026-04-06T23:27:26 I'm not against it at all, I've had controller support in my mind for a while; but I don't know enough about how OpenMW handles UIs with controllers and their focus. I don't know how to say "next focus element" or "what is the current focus element" I know, back in the old days (like 10 years ago for me) when I did Roblox Lua stuff, UI elements had hierarchal properties to tell when a gamepad should select that element. 2026-04-06T23:27:54 i have a strong suspicion that it just doesnt 2026-04-06T23:28:07 that the whole controller shebang is not exposed to lua in any way 2026-04-06T23:28:15 and all that logic needs to be implemented from scratch 2026-04-06T23:28:34 Which I'm 100% okay with doing (clearly, given what I've done with the UI system) 2026-04-06T23:28:44 I just don't want to reinvent the wheel if it exists somewhere in the docs 2026-04-06T23:28:51 (but please dont quote me on that) 2026-04-06T23:29:35 but if we have something like this - this will immensely help with some of say ui-dehardcoding mods, as currently existing ui dehardcoding mods just kind of ignore controller and clash with a recently introduced cool controller ui 2026-04-06T23:30:06 I'm currently trying to get my docs website ready for launch so I can finally get v1 of this out and people can break it over a handful of months. For controller support, I'm slightly worried OpenMW will eventually natively handle it in their UIs 2026-04-06T23:30:07 https://cdn.discordapp.com/attachments/854806553310920714/1490856156577534004/image.png?ex=69d5937e&is=69d441fe&hm=9197030d630f1468dbd31949e569dc8d7f6c0fec5e11aeb291d9e18ceda600fd& 2026-04-06T23:30:20 got a link to that controller ui mod? interested in supporting it 2026-04-06T23:30:42 yea re controllers - might be / i hope 2026-04-06T23:31:07 naw, controller ui - i meant controller ui introduced in 0.5, you just enable it in launcher 2026-04-06T23:31:08 Otherwise, my opinion is that when a window is rendered then we need at least a way to have a controller focus on it. I assume controllers have cursors? But I don't know how to release focus 2026-04-06T23:31:10 its very good 2026-04-06T23:31:15 Have to implement all the gamepad inputs from scratch 2026-04-06T23:31:16 oh i see 2026-04-06T23:31:30 It’s not terrible or anything just a little annoying 2026-04-06T23:31:55 With a complex UI windows it can get very dicey though, definitely wasn’t easy for crafting and cooking 2026-04-06T23:31:59 yeah just have an element highlighted as the default 'starting point' 2026-04-06T23:32:28 This is what Roblox does too 2026-04-06T23:33:04 How did the original Xbox UI work? Like, if you wanted to move from Inventory -> Magic. Just press left/right enough times and it would go? 2026-04-06T23:33:13 Last time I played the xbox version was in like 2002 2026-04-06T23:33:48 in openmw controler ui inventory/magic are now tabulated and you move between them with shoulder buttons 2026-04-06T23:33:52 no idea about xbox 2026-04-06T23:33:59 Sounds like it would’ve been easier to do lua replacement windows instead 2026-04-06T23:34:31 downside - afaik no way to really interact meaningfully with that engine tabulated menu, like you can inject a new menu into it, kinda weird 2026-04-06T23:35:00 just looked at the UESP wiki because i was curious too, felt a pang in my heart at seeing the original xbox 'white/black' buttons 2026-04-06T23:35:03 holy đŸ˜”â€đŸ’« 2026-04-06T23:35:14 But no idea, I just know that the window replacer mods aren’t compatible with the controller setting 2026-04-06T23:35:18 > Sounds like it would’ve been easier to do lua replacement windows instead And the only current problem with this right now is some weird performance barrier between Lua API bridging to the MyGUI API in C. 2026-04-06T23:36:15 Well yeah replacing windows in lua isn’t exactly performance friendly 2026-04-06T23:36:17 After I publish v1 in about a week (expecting a week day next week) I'll look into if there is any feasibility with controller support using the current UI API. I have a gamepad in my closet somewhere 2026-04-06T23:36:56 > Well yeah replacing windows in lua isn’t exactly performance friendly Not right now, but there isn't an obvious reason why it can't be. I keep referencing Roblox, but they're the most successful implementation of a Lua scripting system outside of GTA and Gary's mod; point being, they handle all of this via Lua with no performance impact. 2026-04-06T23:38:31 It may even bother me enough to just clone the OpenMW repo and throw breakpoints on the UI bridge code to see where the biggest time sink is. But that's further down the line. 2026-04-06T23:40:03 And what effect would a solution to this have on existing UI mods? 2026-04-06T23:40:20 Uhhh which one, sorry. Multiple "solutions" in my ramblings above 2026-04-06T23:40:45 Finding and fixing wherever the performance problem for resizing is 2026-04-06T23:41:12 I can only imagine that if there are any UI mods that have a large amount of elements that tank FPS on scroll/move/resize then it would get better 2026-04-06T23:42:02 I haven't pulled the repo down to look at it, but AFAIK OpenMW does: - MyGUI - OpenMW impl And for Lua it's something like - MyGUI - OpenMW - LuaManager - LuaCode 2026-04-06T23:42:27 Wonder if it has to do with the problems that urm ran into with dehardcoding the UI 2026-04-06T23:42:28 And OpenMW's native use of it is very fluid; so some issue is happning in the Lua-bridge part that doesn't happen in other games that implement Lua and have UIs 2026-04-06T23:43:44 Something cursed with resizing I think 2026-04-06T23:44:42 That and moving 2026-04-06T23:45:20 No, the problem urm ran into has to do with resizing the whole UI itself I believe 2026-04-06T23:46:04 Ah, okay. Assumed you were talkin gabout general performance issues 2026-04-06T23:46:27 Although I read what he said about it and others it from my memory because it was very cursed and I wish him the best 2026-04-06T23:49:05 what's funny is you could remake every morrowind window in a day with this framework, so i'm interested to see how it performs 2026-04-06T23:50:11 I just wanted my castle staff and logistics faction to have a flexible, responsive UI with grids, buttons, etc. But here we are. 2026-04-06T23:58:05 <.arrean> https://cdn.discordapp.com/attachments/854806553310920714/1490863195815018526/image.png?ex=69d59a0c&is=69d4488c&hm=49c49ad7662b39e1e8d343390442f899fd5d62e7e570de53599c5c5a4dcc354a& 2026-04-06T23:59:54 Aren’t there already mods for most windows?