2026-03-08T00:03:46  <OpenMW-bridge> <.arrean> Getting a bit lost in the sauce(docs) need advice.  I have a boolean action. When state of that action changes to true I start a short unsaveable timer. Is there a way to start that timer in such a way that if another function is entered before it runs out - I can stop/remove it?
2026-03-08T00:24:30  <OpenMW-bridge> <gnounc> dunno
2026-03-08T00:24:43  <OpenMW-bridge> <gnounc> looking at the docs, i dont see a way to unregister a callback, or any fields you could set to null
2026-03-08T00:25:02  <OpenMW-bridge> <gnounc> what you can do, is set a boolean
2026-03-08T00:25:06  <OpenMW-bridge> <.arrean> oh I did
2026-03-08T00:25:11  <OpenMW-bridge> <gnounc> and check that boolean in the callback
2026-03-08T00:25:22  <OpenMW-bridge> <.arrean> problem is the original action may be fired before timer from the first runs out
2026-03-08T00:25:36  <OpenMW-bridge> <gnounc> right. so in that action, set a boolean
2026-03-08T00:25:42  <OpenMW-bridge> <gnounc> action_has_fired
2026-03-08T00:25:53  <OpenMW-bridge> <gnounc> then in the timer callback, if(action_has_fired) return;
2026-03-08T00:26:11  <OpenMW-bridge> <gnounc> make sense?
2026-03-08T00:26:56  <OpenMW-bridge> <pwn90> most timers return a function that you can call to stop the timer
2026-03-08T00:28:24  <OpenMW-bridge> <gnounc> most timers? or most timers in the openmw lua api?
2026-03-08T00:29:03  <OpenMW-bridge> <pwn90> or maybe just time.runRepeatedly
2026-03-08T00:30:04  <OpenMW-bridge> <pwn90> maybe its not that much more convenient to have a variable for your timer to bail out immediately
2026-03-08T00:30:05  <OpenMW-bridge> <.arrean> Hmmm,  this may be easier: Here's what I'm doing lua local function performParryStart()     if canParry() and currentWeaponConfig then         inPerfectParryWindow = true         isParrying = true         PerfectParryWindow = Constants.basePerfectParryWindow + {SKILL CURVES HERE}         logging:debug("PerfectParryWindow: " .. PerfectParryWindow .. "s")          async:newUnsavableSimulationTimer(PerfectParryWindow, function()  
2026-03-08T00:30:05  <OpenMW-bridge>           inPerfectParryWindow = false             logging:debug('PERFECT PARRY TIMER RAN OUT')         end) {Animation stuff}     else         logging:debug("can't parry or currently parrying")     end end   Two bools that I set here are checked in the oHitHandler. Do you suggest I create a third one? Or can reuse one of these?
2026-03-08T00:32:45  <OpenMW-bridge> <pwn90> oh i see, when you start parrying again within that window you'd want the timer to restart. if thats the case how about using a timestamp instead?
2026-03-08T00:32:50  <OpenMW-bridge> <.arrean> yup
2026-03-08T00:33:18  <OpenMW-bridge> <gnounc> honestly i never use the timers
2026-03-08T00:33:37  <OpenMW-bridge> <gnounc> i just set a variable to the time an action happened, then check how much time has elapsed
2026-03-08T00:33:44  <OpenMW-bridge> <gnounc> that might actually be easier for you
2026-03-08T00:34:21  <OpenMW-bridge> <.arrean> or, now that I think of it - another bool may work. In the onHit, set it to true if onHit fired, and timer is running, then if true then return in the callback. And set it to false when parry starts. So that any orphaned timers don't reset the "window" bool
2026-03-08T00:34:28  <OpenMW-bridge> <.arrean> I may be overthinking it
2026-03-08T00:34:45  <OpenMW-bridge> <gnounc> now = gametime; cooldown = now + expiration_threshold;
2026-03-08T00:34:47  <OpenMW-bridge> <gnounc> then you can
2026-03-08T00:34:50  <OpenMW-bridge> <.arrean> I'll see if timestamp woks better
2026-03-08T00:35:07  <OpenMW-bridge> <gnounc> if(gametime() > cooldown) do_thing())
2026-03-08T00:35:18  <OpenMW-bridge> <gnounc> or not do thing. adjust as necessary
2026-03-08T00:35:27  <OpenMW-bridge> <.arrean> yeyeye, let me try that
2026-03-08T00:35:32  <OpenMW-bridge> <gnounc> g'luck
2026-03-08T00:35:41  <OpenMW-bridge> <gnounc> thats how i always handle these sorts of things
2026-03-08T00:36:04  <OpenMW-bridge> <gnounc> you could even bump the threshold time each time you hit some event
2026-03-08T00:36:10  <OpenMW-bridge> <.arrean> (timer as a solution seemed elegant). Until I realized that I can reasonable bash parry button faster than the low threshold of the timer
2026-03-08T00:36:11  <OpenMW-bridge> <gnounc> which it sounds like you wan to do
2026-03-08T00:36:12  <OpenMW-bridge> <pwn90> if you want a timer, how about something like this:  local currentlyRunningTimerId = 0  function onParry()      local tempTimerId = math.random()      currentlyRunningTimerId = tempTimerId       async:newUnsavableSimulationTimer(PerfectParryWindow, function()             if currentlyRunningTimerId               inPerfectParryWindow = false             logging:debug('PERFECT PARRY TIMER RAN OUT')         end)
2026-03-08T00:38:02  <OpenMW-bridge> <pwn90> i think the timestamp might be the ideal solution though
2026-03-08T00:38:13  <OpenMW-bridge> <.arrean> I'll try both, Danke! Though assigning an id to timer, somehow feels like most beautiful jank
2026-03-08T00:39:04  <OpenMW-bridge> <.arrean> And then my inner DBA starts talking - "will math random Id's ever overlap?" - "no, not in this case"
2026-03-08T01:01:04  <OpenMW-bridge> <trackpadtimmy> is there an objectively correct order for registering actions? and will things go wrong if its deviated from? currently in my mod the .omwscripts loads settings.lua first, then player.lua. settings.lua has registerPage and registerGroup as should be expected.  player.lua goes in this order (skipping other code): lua local Actions = {     {         key = 'photoModeAction',         type = input.ACTION_TYPE.Boolean,        
2026-03-08T01:01:04  <OpenMW-bridge> l10n = ModInfo.l10nName,         name = 'Key:',         description = '',         defaultValue = false,     }, ... }  for _, action in ipairs(Actions) do     input.registerAction(action) end ... input.registerActionHandler('photoModeAction', async:callback(function(pressed)     if enableMod and pressed and not inMenu() then togglePhotoMode() return true end     return false end))
2026-03-08T01:02:03  <OpenMW-bridge> <trackpadtimmy> wracking my brain for every possibility of why i'm having this conflict with another mod and trying to narrow it down
2026-03-08T01:08:04  <OpenMW-bridge> <.arrean> I don't believe there is( and order I mean)  However, @detaildevil, sorry, for the ping, but any ideas? This is about photomode "conflict" where your's "dress/undress" and photomodegrab each other's hotkeys
2026-03-08T01:09:05  <OpenMW-bridge> <detaildevil> maybe check the event names
2026-03-08T01:09:17  <OpenMW-bridge> <detaildevil> if two scripts use the same event name that could be a problem
2026-03-08T01:09:54  <OpenMW-bridge> <trackpadtimmy> as far as i can tell there's no keys or actions with the same names  [18:48:45.757 I] L@0x4[scripts/quickunequip.lua]:    Registering action:    QUnequipAction [18:48:45.758 I] L@0x4[scripts/photomode/player.lua]:    Registering action:    photoModeAction [18:48:45.758 I] L@0x4[scripts/photomode/player.lua]:    Registering action:    freezeTimeAction [18:48:45.758 I] L@0x4[scripts/photomode/player.lua]:    Registering
2026-03-08T01:09:54  <OpenMW-bridge> action:    resetCameraAction [18:48:45.758 I] L@0x4[scripts/photomode/player.lua]:    Registering action:    moveUpAction [18:48:45.758 I] L@0x4[scripts/photomode/player.lua]:    Registering action:    moveDownAction [18:48:45.758 I] L@0x4[scripts/photomode/player.lua]:    Registering action:    rollLeftAction [18:48:45.758 I] L@0x4[scripts/photomode/player.lua]:    Registering action:    rollRightAction [18:48:45.758 I]
2026-03-08T01:09:55  <OpenMW-bridge> L@0x4[scripts/photomode/player.lua]:    Registering action:    zoomInAction [18:48:45.758 I] L@0x4[scripts/photomode/player.lua]:    Registering action:    zoomOutAction [18:48:45.758 I] L@0x4[scripts/photomode/player.lua]:    Registering action:    dofAction
2026-03-08T01:10:23  <OpenMW-bridge> <.arrean> Imma jsut post your earlier troubleshooting: https://discord.com/channels/260439894298460160/854806553310920714/1479633591494381600
2026-03-08T01:10:42  <OpenMW-bridge> <detaildevil> hmm, I'm not sure what could be causing it
2026-03-08T01:12:32  <OpenMW-bridge> <.arrean> Like, I'm not sure, but maybe you've found an engine feature?
2026-03-08T01:12:53  <OpenMW-bridge> <realtralalerotralala_69> I dont think I can comprehend this as of yet
2026-03-08T01:15:34  <OpenMW-bridge> <detaildevil> I don't fully understand the setting scripts either, it's just testing and copying what works and hoping for the best
2026-03-08T01:19:55  <OpenMW-bridge> <S3c:tor> Can I see DD'S menu too
2026-03-08T01:19:55  <OpenMW-bridge> <trackpadtimmy> im not sure how much it matters, but your script does it in this order: registerGroup registerAction registerActionHandler registerPage  it seems to work though, and re ordering those elements into action > page > group > actionhandler didn't seem to alter any functionality
2026-03-08T01:19:58  <OpenMW-bridge> <S3c:tor> Just for clarity
2026-03-08T01:20:45  <OpenMW-bridge> <trackpadtimmy> https://cdn.discordapp.com/attachments/854806553310920714/1480012365566181550/QuickUnequip.lua?ex=69ae206d&is=69acceed&hm=40c8f42174633c1b0c9a1e6e2ef1966f8ac2cf6ee8e7034448aa4a2c0c01b99d&
2026-03-08T01:25:42  <OpenMW-bridge> <trackpadtimmy> heres mine just in case
2026-03-08T01:25:42  <OpenMW-bridge> <trackpadtimmy> https://cdn.discordapp.com/attachments/854806553310920714/1480013599249535148/player.lua?ex=69ae2193&is=69acd013&hm=23038f53caf07d35f4a48c8b7516c0d6717e5dcb3401da37a5f025aca4db963a&
2026-03-08T01:25:43  <OpenMW-bridge> <trackpadtimmy> https://cdn.discordapp.com/attachments/854806553310920714/1480013607189221577/settings.lua?ex=69ae2195&is=69acd015&hm=10f4f74df34cf7bf609e7464060a96ec1b6f7db6db75ec5782d51cdd5787d962&
2026-03-08T01:32:23  <OpenMW-bridge> <S3c:tor> Have you tried manually resetting any of the storage sections in the console
2026-03-08T01:35:04  <OpenMW-bridge> <trackpadtimmy> not through the console, but i have been deleting player_storage.bin and global_storage.bin while testing to start fresh
2026-03-08T01:35:57  <OpenMW-bridge> <S3c:tor> It's interesting that your actions are registered chronologically after the settings which rely on them
2026-03-08T01:36:17  <OpenMW-bridge> <S3c:tor> That's a bit odd and I'm not quite sure if I expect that to work. It should throw, on that.
2026-03-08T01:37:10  <OpenMW-bridge> <S3c:tor> The usage of none as an l10n name is also kinda sus but I wouldn't expect it to do this.
2026-03-08T01:38:04  <OpenMW-bridge> <S3c:tor> Where's the one doing registerPage? Are there any groups defined there too?
2026-03-08T01:38:32  <OpenMW-bridge> <S3c:tor> Oh.
2026-03-08T01:38:45  <OpenMW-bridge> <trackpadtimmy> he has it all in that one file
2026-03-08T01:39:27  <OpenMW-bridge> <trackpadtimmy> there is a settingMenu.lua in another folder but i think it was deprecated, since its not referenced in his omwscripts file it just has PLAYER: scripts/QuickUnequip.lua
2026-03-08T01:43:57  <OpenMW-bridge> <S3c:tor> Yeah, I just didn't notice registerPage at the bottom.
2026-03-08T01:44:26  <OpenMW-bridge> <pwn90> "none" is still better than this...
2026-03-08T01:44:26  <OpenMW-bridge> <pwn90> https://cdn.discordapp.com/attachments/854806553310920714/1480018323155714129/message.txt?ex=69ae25f9&is=69acd479&hm=21e8f0366dc652fd86ebeeec159aaaa87338db091637c5b6bf7807899039e65d&
2026-03-08T01:45:23  <OpenMW-bridge> <.arrean> That's on lua for not having a proper logger with log levels and stuff
2026-03-08T01:45:27  <OpenMW-bridge> <pwn90> every time you reloadlua
2026-03-08T01:45:30  <OpenMW-bridge> <.arrean> that, I mean
2026-03-08T01:46:07  <OpenMW-bridge> <pwn90> oh yeah of course, guess who shut down my ticket where i suggested to let people disable this spam
2026-03-08T01:46:28  <OpenMW-bridge> <S3c:tor> Good golly I mean I could never just stop using l10n for that
2026-03-08T01:46:37  <OpenMW-bridge> <S3c:tor> If you're gonna talk shit at least do it properly, son
2026-03-08T01:46:51  <OpenMW-bridge> <trackpadtimmy> i just recently changed the load order so settings loads first and then player i had it reversed before and on first time startup the settings menu would have no buttons to click to change the keybinds until you did reloadlua
2026-03-08T01:46:51  <OpenMW-bridge> <trackpadtimmy> https://cdn.discordapp.com/attachments/854806553310920714/1480018930478223472/image.png?ex=69ae268a&is=69acd50a&hm=83247e62f90b154408c4c4e106a6e9f98d8edc88fe8d524aab5f6c00ea22fc60&
2026-03-08T01:46:52  <OpenMW-bridge> <S3c:tor> Using l10n for that is stupid and makes no sense because track names don't get localized
2026-03-08T01:46:57  <OpenMW-bridge> <S3c:tor> Which I fixed this morning
2026-03-08T01:46:58  <OpenMW-bridge> <S3c:tor> Now then
2026-03-08T01:47:47  <OpenMW-bridge> <detaildevil> Did I do something wrong? I barely understand how the settings lua works, I just try and see what works or copy from others
2026-03-08T01:47:56  <OpenMW-bridge> <pwn90> my ticket on gitlab was asking for disabling the general l10n spam for people who have many many lua mods installed
2026-03-08T01:48:18  <OpenMW-bridge> <S3c:tor> Yes, yes
2026-03-08T01:48:35  <OpenMW-bridge> <S3c:tor> Anyway, the settings menu is fine, I just didn't really understand how it was laid out at first.
2026-03-08T01:54:17  <OpenMW-bridge> <S3c:tor> I get what you mean. It's just, the only thing about this setup that really stands out is when those actions are being registered. It doesn't have to be in the player script, at all.
2026-03-08T01:54:45  <OpenMW-bridge> <S3c:tor> I would try moving the calls to registerAction into the menu script, prior to groups which make use of those actions.
2026-03-08T01:55:17  <OpenMW-bridge> <S3c:tor> I'm not really confident it's a direct solution to your problem but it is the only thing that seems obvious, anyway. Do you have a log, by chance? Anything weird in there?
2026-03-08T01:56:50  <OpenMW-bridge> <trackpadtimmy> i havent noticed anything weird in the console this whole time sometimes i can get the two mods to work on different keys and persist through doing reloadlua, but they would still display in the menu as being set to the same key even when one of them is bound to something else
2026-03-08T01:57:42  <OpenMW-bridge> <S3c:tor> I wanna see a log file, I think there's something going wrong in there.
2026-03-08T01:58:14  <OpenMW-bridge> <S3c:tor> I'm a little skeptical it's even directly related to the code of either of the two mods I just read. They don't look broken.
2026-03-08T02:00:21  <OpenMW-bridge> <trackpadtimmy> openmw.log right?
2026-03-08T02:00:26  <OpenMW-bridge> <S3c:tor> ye
2026-03-08T02:02:21  <OpenMW-bridge> <trackpadtimmy> https://cdn.discordapp.com/attachments/854806553310920714/1480022832388899067/openmw.log?ex=69ae2a2c&is=69acd8ac&hm=fed24c729a09c03923ae960152b1862daef9cd3ba961601aefea8d34073e475a&
2026-03-08T02:03:37  <OpenMW-bridge> <trackpadtimmy> might be a bit messy looking because i had at one point used mo2 for tes3mp, then the launcher for a playthrough on .49  its loading those directories but all are disabled in game except photomode and devilish undress
2026-03-08T02:04:41  <OpenMW-bridge> <trackpadtimmy> in this i loaded the game with wiped storages, set the keybinds for both mods, reloadlua, saw the error happen, then quit
2026-03-08T02:05:16  <OpenMW-bridge> <S3c:tor> This is messy to you? Hahahahaha
2026-03-08T02:07:53  <OpenMW-bridge> <S3c:tor> okay well you're not really even running anything else and this log is like, spotless, so, actually I'm starting to maybe think this actually could be the problem
2026-03-08T02:08:46  <OpenMW-bridge> <S3c:tor> I'm a little fuzzy on the exact technical semantics of this because we never really wrote it down and I sorta just figured it out through guesswork but AFAIK the order in which you do actions triggers is registration -> setting -> Handler
2026-03-08T02:09:13  <OpenMW-bridge> <S3c:tor> Here you have setting -> registration -> handler, I don't quite know if that's supposed to work or not
2026-03-08T02:11:51  <OpenMW-bridge> <trackpadtimmy> the log is after i moved the actions registering to the top of settings.lua, before registerPage and registerGroups
2026-03-08T02:12:23  <OpenMW-bridge> <trackpadtimmy> ill try moving them under the settings
2026-03-08T02:12:45  <OpenMW-bridge> <S3c:tor> you should want for actions to be registered before settings which depend upon them
2026-03-08T02:12:57  <OpenMW-bridge> <S3c:tor> but I guess that's more of a formatting than a technical thing
2026-03-08T02:13:31  <OpenMW-bridge> <S3c:tor> Okay, well, it IS a bit weird that the group names in yours use /, but, now I'm really reaching
2026-03-08T02:13:52  <OpenMW-bridge> <S3c:tor> Parser should be able to handle that, special chars are all nonprintable range.
2026-03-08T02:14:10  <OpenMW-bridge> <S3c:tor> I think I need calories to debug this.
2026-03-08T02:14:36  <OpenMW-bridge> <trackpadtimmy> no effect
2026-03-08T02:16:39  <OpenMW-bridge> <trackpadtimmy> i got that formatting from seeing other mods doing it if i remember correctly
2026-03-08T02:16:40  <OpenMW-bridge> <trackpadtimmy> https://cdn.discordapp.com/attachments/854806553310920714/1480026431802314883/image.png?ex=69ae2d86&is=69acdc06&hm=6898a1a15410efb2ae963d1652b4116422eb8a8d1ebf11770c58ec6aa067344e&
2026-03-08T02:17:29  <OpenMW-bridge> <S3c:tor> Huh. Uh. Well. Yeah, I guess.
2026-03-08T02:18:44  <OpenMW-bridge> <S3c:tor> I gotta eat, but, at this point I would start examining the contents of the storage sections themselves
2026-03-08T02:18:56  <OpenMW-bridge> <.arrean> > arrean@Seldon:~/.config/openmw/Data Files$ grep -ir --include *.lua "Settings/" * | wc -l > 57 not even uncommon
2026-03-08T02:19:00  <OpenMW-bridge> <S3c:tor> the two from the mods involved and the built in section where actual binding info goes
2026-03-08T02:19:26  <OpenMW-bridge> <S3c:tor> I'm not in the habit of reading anyone else's code unless they need help 😛
2026-03-08T02:20:06  <OpenMW-bridge> <S3c:tor> I forget the name, but, you should be able to navigate them with storage.allPlayerSections
2026-03-08T02:20:16  <OpenMW-bridge> <S3c:tor> which I think is an array, so, maybe this will prove useful
2026-03-08T02:21:45  <OpenMW-bridge> <S3c:tor> lua luap for sectionName, section in ipairs(storage.allPlayerSections()) do for k, v in pairs(section:asTable()) do print(sectionName, section, k, v) end end 
2026-03-08T02:22:14  <OpenMW-bridge> <S3c:tor> The docs only state allPlayerSections gives a table, I'm not sure what the keys would be here but I think we'd have annotated a Section[] differently if that's what it were
2026-03-08T02:24:42  <OpenMW-bridge> <trackpadtimmy> something like this?  Lua[Player] view(storage.allPlayerSections()) table: 0x028433c0aa90 {   OMWInputBindings = userdata: 0x028425e59a70,   S3maphoreActivePlaylistSettings = userdata: 0x028425e5dfd0,   Settings/PhotoMode/EnableArguments = userdata: 0x028425e5e090,   Settings/PhotoMode/GamepadArguments = userdata: 0x028425e5d370,   Settings/PhotoMode/GeneralArguments = userdata: 0x028425e5d9d0,  
2026-03-08T02:24:42  <OpenMW-bridge> Settings/PhotoMode/KeybindsArguments = userdata: 0x028425e5ca10,   SettingsOMWCameraHeadBobbingArguments = userdata: 0x028425e5ddf0,   SettingsOMWCameraThirdPersonArguments = userdata: 0x028425e5cad0,   SettingsOMWControlsArguments = userdata: 0x028425e5f1d0,   SettingsPlayerQuickUnequipArguments = userdata: 0x028425e5e3f0,   SettingsS3MusicArguments = userdata: 0x028425e5e990,   SettingsS3MusicPlaylistActivityArguments = userdata:
2026-03-08T02:24:43  <OpenMW-bridge> 0x028425e5eb10,   SettingsS3MusicPlaylistSelectionArguments = userdata: 0x028425e52b70,   SettingsS3MusicSilenceConfigArguments = userdata: 0x028425e53890,   SettingsPlayerQuickUnequip = userdata: 0x028425e5f290,   SettingsS3MusicPlaylistActivity = userdata: 0x028425e5f6b0,   SettingsS3Music = userdata: 0x028425e5e870,   OmwSettingGroups = userdata: 0x028425e5d4f0,   Settings/PhotoMode/Enable = userdata: 0x028425e5d8b0,  
2026-03-08T02:24:43  <OpenMW-bridge> SettingsOMWCameraThirdPerson = userdata: 0x028425e5deb0,   Settings/PhotoMode/Keybinds = userdata: 0x028425e5dc70,   SettingsOMWCameraHeadBobbing = userdata: 0x028425e5ca70,   Settings/PhotoMode/Gamepad = userdata: 0x028425e5d310,   Settings/PhotoMode/General = userdata: 0x028425e5d910,   SettingsOMWControls = userdata: 0x028425e5e390,   SettingsS3MusicSilenceConfig = userdata: 0x028425e534d0,   SettingsS3MusicPlaylistSelection = userdata:
2026-03-08T02:24:44  <OpenMW-bridge> 0x028425e52750, } Lua[Player] view(storage.playerSection("Settings/PhotoMode/Keybinds"):asTable()) table: 0x028433c09be0 {   resetCameraBinding = Slash,   zoomOutBinding = DownArrow,   moveUpBinding = Space,   moveDownBinding = LeftCtrl,   photoModeBinding2 = U,   tiltLeftBinding = LeftArrow,   freezeTimeBinding3 = I,   tiltRightBinding = RightArrow,   dofBinding = L,   zoomInBinding = UpArrow, } Lua[Player]
2026-03-08T02:24:44  <OpenMW-bridge> view(storage.playerSection("SettingsPlayerQuickUnequip"):asTable())  table: 0x028433c0c3e0 {   UNDRESS_WHEN_SWIMMING = false,   BLACKOUT = false,   Hotkey = U, }
2026-03-08T02:25:57  <OpenMW-bridge> <trackpadtimmy> something im notiving is that right now i dont have half the keybinds set for photo mode, but it's still listing all of them there those are using the ones i have set as the default key in the settings menu
2026-03-08T02:26:16  <OpenMW-bridge> <S3c:tor> I believe OMWInputBindings is the builtin section I was thinking of
2026-03-08T02:26:27  <OpenMW-bridge> <S3c:tor> Don't let the values of your input binds deceive you, lol
2026-03-08T02:26:45  <OpenMW-bridge> <S3c:tor> It also seems notable that I'm still in here, these files haven't been flushed since you last cleared the content list
2026-03-08T02:27:10  <OpenMW-bridge> <S3c:tor> maybe doesn't mean anything but caught my eye
2026-03-08T02:27:13  <OpenMW-bridge> <trackpadtimmy> yeah, im not sure why s3maphore is being loaded when i had it disabled in the launcher
2026-03-08T02:28:16  <OpenMW-bridge> <S3c:tor> It isn't:  [19:57:45.411 I] Loading content file builtin.omwscripts [19:57:45.421 I] Loading content file Morrowind.esm [19:57:45.634 I] Loading content file Tribunal.esm [19:57:45.663 I] Loading content file Bloodmoon.esm [19:57:45.706 I] Loading content file Devilish Dress Undress Hotkey.ESP [19:57:45.706 I] Loading content file Devilish Dress Undress Hotkey.omwscripts [19:57:45.706 I] Loading content file
2026-03-08T02:28:17  <OpenMW-bridge> PhotoMode.omwscripts 
2026-03-08T02:28:57  <OpenMW-bridge> <trackpadtimmy> Lua[Player] view(storage.playerSection("OMWInputBindings"):asTable())  table: 0x028407428420 {   U = table: 0x028407428970,   L = table: 0x0284074288d0,   I = table: 0x028407428880, }
2026-03-08T02:29:04  <OpenMW-bridge> <S3c:tor> Do you still have an MO2 setup you use? Like, maybe bounce between the two, or something?
2026-03-08T02:29:27  <OpenMW-bridge> <S3c:tor> The fact that my setting groups are present but the mod is certainly not is throwing alarm bells
2026-03-08T02:29:30  <OpenMW-bridge> <S3c:tor> I smell OpenMW Player
2026-03-08T02:30:15  <OpenMW-bridge> <S3c:tor> Take all three sections and reset them: storage.playerSection("OMWInputBindings"):reset()
2026-03-08T02:30:58  <OpenMW-bridge> <trackpadtimmy> i did use it before, but i havent since last year when i stopped playing tes3mp and moved to the launcher because it was a lot easier to work with. i did use openmwplayer as well back then i think
2026-03-08T02:31:56  <OpenMW-bridge> <S3c:tor> Eh, maybe you just left that one on during debugging for a bit
2026-03-08T02:32:00  <OpenMW-bridge> <S3c:tor> OH
2026-03-08T02:32:06  <OpenMW-bridge> <S3c:tor> Oh, yes, you did, actually :todd:
2026-03-08T02:32:18  <OpenMW-bridge> <S3c:tor> That's my :todd: bullshit nevermind
2026-03-08T02:32:46  <OpenMW-bridge> <S3c:tor> I guess I should... fix.. that...
2026-03-08T02:34:39  <OpenMW-bridge> <trackpadtimmy> not sure im following, but i reset the OMWInputBindings section
2026-03-08T02:36:00  <OpenMW-bridge> <S3c:tor> get the ones from your mod and DD's too
2026-03-08T02:36:26  <OpenMW-bridge> <S3c:tor> Oh, uh, it's just, I replace some of the builtin scripts, so uh. I guess technically you can't actually disable this mod lol
2026-03-08T02:36:53  <OpenMW-bridge> <S3c:tor> I thought maybe that was a hint something funky was happening but no just me 😅
2026-03-08T02:36:58  <OpenMW-bridge> <trackpadtimmy> ahahaha, yeah the only other thing enables is the builtins :P
2026-03-08T02:38:01  <OpenMW-bridge> <trackpadtimmy> reset them all
2026-03-08T02:38:51  <OpenMW-bridge> <S3c:tor> try to reset them in the actual Settings menu now and see if you get anything
2026-03-08T02:40:04  <OpenMW-bridge> <trackpadtimmy> still the same linking effect
2026-03-08T02:50:18  <OpenMW-bridge> <trackpadtimmy> heres a video of it happening https://youtu.be/xQCWeMh0vKc?t=74 first minute is just showing clearing the storage sections for the mods and omwinputbindings
2026-03-08T02:56:31  <OpenMW-bridge> <detaildevil> What if you close the menu inbetween? Does it still copy the keybind from Devilish Undress?
2026-03-08T02:56:40  <OpenMW-bridge> <detaildevil> does reloadlua in between make a difference?
2026-03-08T02:56:46  <OpenMW-bridge> <trackpadtimmy> it also happens in the reverse way where dress undress will inherit U from photomode
2026-03-08T02:56:48  <OpenMW-bridge> <detaildevil> I don't know why this is
2026-03-08T02:56:51  <OpenMW-bridge> <detaildevil> I have no idea
2026-03-08T02:57:24  <OpenMW-bridge> <trackpadtimmy> yea 1 sec
2026-03-08T02:57:27  <OpenMW-bridge> <detaildevil> It could even be borked from the engine side 😄
2026-03-08T02:59:00  <OpenMW-bridge> <S3c:tor> I'm still trying to motivate myself to get dinner, it's been a hard week, but, I also am wondering if I shouldn't be checking the settings script
2026-03-08T02:59:11  <OpenMW-bridge> <S3c:tor> If you have the energy yourself it might be a smart idea
2026-03-08T02:59:20  <OpenMW-bridge> <S3c:tor> I am running low on spoons
2026-03-08T03:00:11  <OpenMW-bridge> <S3c:tor> Most or perhaps all of the Settings implementation is Lua, in the resources dir
2026-03-08T03:00:24  <OpenMW-bridge> <S3c:tor> Settings is low level stuff you should find in VFS and not vfs-mw
2026-03-08T03:02:35  <OpenMW-bridge> <trackpadtimmy> it only happens after doing a reloadlua, just closing the menu after setting some binds doesnt seem to cause it to happen heres it transferring to dress undress
2026-03-08T03:02:36  <OpenMW-bridge> <trackpadtimmy> https://cdn.discordapp.com/attachments/854806553310920714/1480037989705842688/2026-03-07_21-00-16_openmw.mov?ex=69ae384a&is=69ace6ca&hm=76c3935f65216d6a3de0e5d9d48273c86cb6166a8df6ad81dc2defd27a96e126&
2026-03-08T03:03:58  <OpenMW-bridge> <detaildevil> It's just odd
2026-03-08T03:04:26  <OpenMW-bridge> <detaildevil> is "none" maybe considered a key
2026-03-08T03:04:43  <OpenMW-bridge> <detaildevil> 😄
2026-03-08T03:05:30  <OpenMW-bridge> <.arrean> either on my end, or discord is having trouble with encoding, only first frame is playing
2026-03-08T03:05:42  <OpenMW-bridge> <detaildevil> I genuinely don't know. This is beyond me
2026-03-08T03:06:14  <OpenMW-bridge> <trackpadtimmy> might be an encoding thing, my OBS is set to record as fragmented mov
2026-03-08T03:08:35  <OpenMW-bridge> <trackpadtimmy> https://www.youtube.com/watch?v=Rs-kmvclY2k
2026-03-08T03:08:37  <OpenMW-bridge> <.arrean> When it happens
2026-03-08T03:08:52  <OpenMW-bridge> <.arrean> What does Lua[Player] view(storage.playerSection("OMWInputBindings"):asTable()["K"] or whatever key, shows?
2026-03-08T03:09:19  <OpenMW-bridge> <.arrean> specifically for the key that is currently assigned to both
2026-03-08T03:11:08  <OpenMW-bridge> <trackpadtimmy> ah i was wondering how to look into those. right now its showing this when U is being displayed in both mods Lua[Player] view(storage.playerSection("OMWInputBindings"):asTable()["U"]) table: 0x0283a4c8cf90 {   device = keyboard,   key = photoModeAction,   button = 24,   type = action, }
2026-03-08T03:13:16  <OpenMW-bridge> <.arrean> hmmmm
2026-03-08T03:13:18  <OpenMW-bridge> <trackpadtimmy> the interesting part is, its showing only U, L, I L isnt even a key that's bound, i have U V and I bound in photomode. but L is the default for what i have V bound to
2026-03-08T03:13:18  <OpenMW-bridge> <trackpadtimmy> https://cdn.discordapp.com/attachments/854806553310920714/1480040685162991747/image.png?ex=69ae3acd&is=69ace94d&hm=29fa68a1e998650079a1fd2575eeead6353fe5b45e167737912ab361a7feb51a&
2026-03-08T03:13:47  <OpenMW-bridge> <trackpadtimmy> table: 0x028383cc93d0 {   U = table: 0x028383cc98d0,   L = table: 0x028383cc9790,   I = table: 0x028383cc9740, }
2026-03-08T03:14:24  <OpenMW-bridge> <trackpadtimmy> https://cdn.discordapp.com/attachments/854806553310920714/1480040963333296230/image.png?ex=69ae3b0f&is=69ace98f&hm=2b3c2a4b6cd2c23bfa4087c0302741ba499c721fd8e5d6c795a70d6482bed411&
2026-03-08T03:15:36  <OpenMW-bridge> <.arrean> Yeah, those keys in the table are odd
2026-03-08T03:16:29  <OpenMW-bridge> <.arrean> They are not showing a "key that' bound", rather it's a key(in a table sense, not keyboard sense") that gets created from "defaults" you apply to your mod.
2026-03-08T03:18:34  <OpenMW-bridge> <.arrean> And you can "reset" them individually,storage.playerSection('OMWInputBindings'):set('U', nil) though no sense in testing that I think. reset on the entire section covers it
2026-03-08T03:21:33  <OpenMW-bridge> <trackpadtimmy> when i set the dress undress hotkey to K, and then reset the keybinds in photomode, the photomode hotkey turns to K and the rest are unaffected. this happens the other way around too, i set the key in photomode and reset dress undress and it becomes the photomode key. its like they're acting as one, but there shouldnt be any name collisions
2026-03-08T03:23:30  <OpenMW-bridge> <.arrean> I mean, at this point - /resources/vfs/scripts/omw/settings in the install dir.  I've been poking around, but I don't think I understand what to look for. Maybe try and see what you can find on how it writes to storage
2026-03-08T03:23:58  <OpenMW-bridge> <trackpadtimmy> i have it pulled up but i also don't really know what i'm looking for
2026-03-08T03:25:11  <OpenMW-bridge> <.arrean> I have a feeling that on reloadlua something happens. Can you add prints to both scripts onLoad and onInit with this? storage.playerSection("OMWInputBindings"):asTable()["K"])?   for k, v, in pairs(view(storage.playerSection("OMWInputBindings"):asTable()["K"])) do print (k..":"..tostring(v)) end
2026-03-08T03:25:35  <OpenMW-bridge> <.arrean> in the onLoad, don't need it in onInit
2026-03-08T03:25:38  <OpenMW-bridge> <.arrean> and then check the log
2026-03-08T03:26:19  <OpenMW-bridge> <.arrean> edit: no view bad copy-paste
2026-03-08T03:26:21  <OpenMW-bridge> <trackpadtimmy> is it weird that the inputBinding renderer is registered in /vfx/scripts/omw/input and not with the rest of them?
2026-03-08T03:26:41  <OpenMW-bridge> <.arrean> Possibly, but then it is a bit special
2026-03-08T03:28:05  <OpenMW-bridge> <.arrean> if type(id) ~= 'string' then error('inputBinding: must have a string default value') end this line raises an eyebrow immediately. What connection does id has to default value  It then addresses it via id local binding = bindingSection:get(id)
2026-03-08T03:28:46  <OpenMW-bridge> <.arrean> But you said, changing defaults, didn't change anything?
2026-03-08T03:29:25  <OpenMW-bridge> <.arrean> Maybe change the default on one or both of them to "modname_default_key" or something.  And then do whole dance with resetting settings and reloadng lua again?
2026-03-08T03:31:07  <OpenMW-bridge> <trackpadtimmy> Lua error: [string "scripts/photomode/player.lua"]:338: '<name>' expected near 'in'
2026-03-08T03:31:30  <OpenMW-bridge> <.arrean> hold on a sec, let me see where I've fucked up
2026-03-08T03:31:37  <OpenMW-bridge> <trackpadtimmy> i think it was the extra comma before it
2026-03-08T03:31:48  <OpenMW-bridge> <.arrean> ye
2026-03-08T03:32:35  <OpenMW-bridge> <.arrean> for k, v in pairs(storage.playerSection("OMWInputBindings"):asTable()["K"]) do print (k..":"..tostring(v)) end works, as long as key exists
2026-03-08T03:32:57  <OpenMW-bridge> <.arrean> can do it from console, but I'm specifically interest in what happens on startup
2026-03-08T03:34:09  <OpenMW-bridge> <.arrean> and do that before messing with the defaults, unless you did already
2026-03-08T03:37:41  <OpenMW-bridge> <trackpadtimmy> giving an error saying its returning nil
2026-03-08T03:38:43  <OpenMW-bridge> <.arrean> which mod is first in load order?
2026-03-08T03:38:57  <OpenMW-bridge> <trackpadtimmy> oh if its looking at the defaults, then K isnt a default anywhere let me try having it search for U since that's shared between mods
2026-03-08T03:39:25  <OpenMW-bridge> <.arrean> yeah, that should be keys, I've just typed whatever came to mind
2026-03-08T03:43:41  <OpenMW-bridge> <trackpadtimmy> when i was resetting the storages i was getting this in the console: [21:40:26.355 I] Menu[scripts/omw/settings/menu.lua]:    Setting photoModeBinding2 renderer "inputBinding" error: [string "scripts/omw/input/settings.lua"]:97: inputBinding: must have a string default value  reloadlua after resetting gives nil errors for the onload code set photomode key to U, dress undress to K in that order console: [21:43:02.046 I]
2026-03-08T03:43:41  <OpenMW-bridge> L@0x4[scripts/quickunequip.lua]:    device:keyboard [21:43:02.046 I] L@0x4[scripts/quickunequip.lua]:    key:QUnequipAction [21:43:02.046 I] L@0x4[scripts/quickunequip.lua]:    button:14 [21:43:02.046 I] L@0x4[scripts/quickunequip.lua]:    type:action [21:43:02.047 I] L@0x4[scripts/photomode/settings.lua]:    Registering action: photoModeAction [21:43:02.047 I] L@0x4[scripts/photomode/settings.lua]:    Registering action: freezeTimeAction
2026-03-08T03:43:42  <OpenMW-bridge> [21:43:02.047 I] L@0x4[scripts/photomode/settings.lua]:    Registering action: resetCameraAction [21:43:02.047 I] L@0x4[scripts/photomode/settings.lua]:    Registering action: moveUpAction [21:43:02.047 I] L@0x4[scripts/photomode/settings.lua]:    Registering action: moveDownAction [21:43:02.047 I] L@0x4[scripts/photomode/settings.lua]:    Registering action: rollLeftAction [21:43:02.047 I] L@0x4[scripts/photomode/settings.lua]:   
2026-03-08T03:43:42  <OpenMW-bridge> Registering action: rollRightAction [21:43:02.047 I] L@0x4[scripts/photomode/settings.lua]:    Registering action: zoomInAction [21:43:02.047 I] L@0x4[scripts/photomode/settings.lua]:    Registering action: zoomOutAction [21:43:02.047 I] L@0x4[scripts/photomode/settings.lua]:    Registering action: dofAction [21:43:02.048 I] L@0x4[scripts/photomode/player.lua]:    device:keyboard [21:43:02.048 I] L@0x4[scripts/photomode/player.lua]:   
2026-03-08T03:43:43  <OpenMW-bridge> key:QUnequipAction [21:43:02.048 I] L@0x4[scripts/photomode/player.lua]:    button:14 [21:43:02.048 I] L@0x4[scripts/photomode/player.lua]:    type:action
2026-03-08T03:46:27  <OpenMW-bridge> <.arrean> What I'm suspecting happening -   Looking at OpenMW/resources/vfs/scripts/omw/input/settings.lua is that it's using defaults that we provide to "RegisterGroup" when we register an "inputBinding" as keys in the table that stores the actual values.  Hence on first load - let's say after a reset, one mod puts value in the setting table, then the other overwrites it, both mods look for the same key.
2026-03-08T03:47:00  <OpenMW-bridge> <.arrean> key argument that we provide is used as key in player section
2026-03-08T03:47:17  <OpenMW-bridge> <.arrean> I think
2026-03-08T03:47:35  <OpenMW-bridge> <.arrean> It's 4 am, and I'm fried after trying to make animations, so I'm not at my best
2026-03-08T03:47:57  <OpenMW-bridge> <trackpadtimmy> understandable, youve been a massive help in furthering this
2026-03-08T03:48:35  <OpenMW-bridge> <.arrean> So, my suggestion - provide a complex text key, that is more likely to be unique when you register your input bindings
2026-03-08T03:48:57  <OpenMW-bridge> <.arrean> modInfo.name .. "inputs".. {inputName} something like that
2026-03-08T03:49:06  <OpenMW-bridge> <.arrean> then wipe the settings via reset() and try again
2026-03-08T03:49:13  <OpenMW-bridge> <.arrean> one or both mods,
2026-03-08T03:49:17  <OpenMW-bridge> <.arrean> one should be enough
2026-03-08T03:49:20  <OpenMW-bridge> <.arrean> if it's what I think it is
2026-03-08T03:49:40  <OpenMW-bridge> <.arrean> provide that key as your default I mean
2026-03-08T03:50:55  <OpenMW-bridge> <trackpadtimmy> change the default = 'U'. to something like default = 'PhotoModeInputPhotoModeKey'?
2026-03-08T03:51:00  <OpenMW-bridge> <.arrean> Lua[Player] view(storage.playerSection("OMWInputBindings"):asTable()) table: 0x586b86007ea0 {   holidaysandbirthdaysshowMessageTriggerKey = table: 0x586b1a098b80,   scriptsParryKey = table: 0x586b7cb86960,   $ = table: 0x586bc5a669b0,   LoadoutsshowLoadoutsWindowRes = table: 0x586ba1b13eb0,   Loadouts3 = table: 0x586b4132f960,   Q = table: 0x586b1dfaa300,   scriptsparry_input_key = table: 0x586bb699f6e0,   Loadouts4 = table:
2026-03-08T03:51:00  <OpenMW-bridge> 0x586bc4be8200,   i = table: 0x586b929fdea0,   NCG_show_logs_default = table: 0x586bc5fe6af0,   Loadouts5 = table: 0x586ba14a3ab0,   u = table: 0x586b65b057b0,   Loadouts7 = table: 0x586bc0384fe0,   a = table: 0x586ba2a1db50,   ^ = table: 0x586bc6c5fd60, }  example
2026-03-08T03:51:14  <OpenMW-bridge> <.arrean> e.g. the top one is one of my mods - do something like that
2026-03-08T03:51:40  <OpenMW-bridge> <.arrean> Or, you see Loadouts also does unique keys, etc
2026-03-08T03:51:55  <OpenMW-bridge> <.arrean> but a couple other mods don't which is why there are all those a,Q etc in there
2026-03-08T03:52:32  <OpenMW-bridge> <.arrean> yes
2026-03-08T03:55:53  <OpenMW-bridge> <trackpadtimmy> Lua[Player] view(storage.playerSection("OMWInputBindings"):asTable()) table: 0x0283838b7e50 {   PhotoMode_PhotoModeAction = table: 0x0283838b90c0,   PhotoMode_FreezeTimeAction = table: 0x0283838b8df0,   PhotoMode_DoFAction = table: 0x0283838b8c10,   PhotoMode_ResetCameraAction = table: 0x0283838b7ea0,   PhotoMode_MoveUpAction = table: 0x0283838b8fd0,   PhotoMode_MoveDownAction = table: 0x0283838b8f30,  
2026-03-08T03:55:54  <OpenMW-bridge> PhotoMode_RollLeftAction = table: 0x0283838b7f40,   PhotoMode_RollRightAction = table: 0x0283838bc400,   PhotoMode_ZoomInAction = table: 0x0283838bc130,   PhotoMode_ZoomOutAction = table: 0x0283838bc630,   U = table: 0x0283838bbff0, } no conflicts between the mods now
2026-03-08T03:56:16  <OpenMW-bridge> <.arrean> arlight, and does the issue persist?
2026-03-08T03:57:41  <OpenMW-bridge> <trackpadtimmy> i can use both mods without them breaking, they dont seem to be inheriting each other anymore
2026-03-08T03:57:52  <OpenMW-bridge> <trackpadtimmy> that must be it
2026-03-08T03:57:55  <OpenMW-bridge> <.arrean> 🤜 🤛
2026-03-08T03:59:35  <OpenMW-bridge> <.arrean> Now, you'll either need to come up with a migration script, or push and update and tell your users that they'll need to rebind the keys
2026-03-08T03:59:50  <OpenMW-bridge> <.arrean> But if it doesn't come back - we good
2026-03-08T04:00:30  <OpenMW-bridge> <trackpadtimmy> that is not how i expected default to work, as far as i understoond it it was supposed to be for setting default keybinds for the input bindings and it wasnt fully implemented yet so everyone had to set it manually. not for setting the name in OMWInputBindings lmao
2026-03-08T04:00:37  <OpenMW-bridge> <.arrean> Neither did I
2026-03-08T04:01:21  <OpenMW-bridge> <.arrean> @detaildevil you still awake? I'd recommend changing defaults on your inputBinding settings too, or you're bound to get more bug reports of this nature
2026-03-08T04:02:03  <OpenMW-bridge> <detaildevil> I'd probably work on it tomorrow. Could you summarize what's wrong?
2026-03-08T04:02:13  <OpenMW-bridge> <trackpadtimmy> all you should need to do is set default = "U" to something more specific that wont get used by any other mod
2026-03-08T04:02:40  <OpenMW-bridge> <detaildevil> how about no default?
2026-03-08T04:02:49  <OpenMW-bridge> <detaildevil> if default is problematic
2026-03-08T04:02:49  <OpenMW-bridge> <trackpadtimmy> there needs to be a default of some sort
2026-03-08T04:02:50  <OpenMW-bridge> <.arrean> the defaul you pass when you create an InputBinding setting is not a "default" it's used as a key in OMWInputBindings - hence if it's a single letter "Q" or something - it will have conflicts
2026-03-08T04:03:06  <OpenMW-bridge> <.arrean> 97:     if type(id) ~= 'string' then error('inputBinding: must have a string default value') end yeah, nah
2026-03-08T04:03:20  <OpenMW-bridge> <.arrean> in OpenMW/resources/vfs/scripts/omw/input/settings.lua
2026-03-08T04:03:25  <OpenMW-bridge> <detaildevil> I mean this sounds like a problematic way the engine does it 😄
2026-03-08T04:03:27  <OpenMW-bridge> <trackpadtimmy> see what i did here
2026-03-08T04:03:36  <OpenMW-bridge> <.arrean> Oh, definitely
2026-03-08T04:03:42  <OpenMW-bridge> <trackpadtimmy> im not an engine guy but id have to agree lmao
2026-03-08T04:03:52  <OpenMW-bridge> <.arrean> If any of ya'll feeling up to writing an issue - please do
2026-03-08T04:03:59  <OpenMW-bridge> <.arrean> I think I'll head to bed
2026-03-08T04:04:04  <OpenMW-bridge> <detaildevil> Nobody would expect a default "U" to cause issues with other keybind mods
2026-03-08T04:04:05  <OpenMW-bridge> <trackpadtimmy> thanks for your help!
2026-03-08T04:04:15  <OpenMW-bridge> <.arrean> yup
2026-03-08T04:04:17  <OpenMW-bridge> <detaildevil> so this problem will occur again, and again and again
2026-03-08T04:04:22  <OpenMW-bridge> <.arrean> yup
2026-03-08T04:04:27  <OpenMW-bridge> <detaildevil> everytime somebody creates a keybind mod
2026-03-08T04:04:44  <OpenMW-bridge> <.arrean> Cause "default" doesn't mean "default"
2026-03-08T04:04:50  <OpenMW-bridge> <.arrean> I've no clue why it's like this
2026-03-08T04:04:55  <OpenMW-bridge> <detaildevil> so did we both use "U" as a default?
2026-03-08T04:04:59  <OpenMW-bridge> <.arrean> ye
2026-03-08T04:05:12  <OpenMW-bridge> <.arrean> which was then the key in the table, and both mods were accessing it
2026-03-08T04:05:19  <OpenMW-bridge> <trackpadtimmy> ill have to look at my backed up player storage to see what mods also use keybinds to spot any potential conflicts
2026-03-08T04:05:26  <OpenMW-bridge> <detaildevil> maybe I'll just use the German "Ü" 😄
2026-03-08T04:05:32  <OpenMW-bridge> <.arrean> lmao
2026-03-08T04:06:06  <OpenMW-bridge> <.arrean> https://discord.com/channels/260439894298460160/854806553310920714/1480049031861506078 ^ initial hypthesis, that we, I think, proved
2026-03-08T04:06:55  <OpenMW-bridge> <detaildevil> @S3c:tor to summarize if two mods choose the same default hotkey -> the keybinding will become connected (not sure if this is wanted)
2026-03-08T04:07:16  <OpenMW-bridge> <.arrean> and default is not default :ur:
2026-03-08T04:07:44  <OpenMW-bridge> <.arrean> On that cheery note, I'll go and catch some sleep, have a good one folks
2026-03-08T04:07:59  <OpenMW-bridge> <trackpadtimmy> ty so much, have a good night!
2026-03-08T04:17:36  <OpenMW-bridge> <detaildevil> I uploaded 1.2.1 with "Ä". That should prevent most issues
2026-03-08T04:17:49  <OpenMW-bridge> <detaildevil> It's a game of picking a weird hotkey now
2026-03-08T04:19:05  <OpenMW-bridge> <.arrean> I use modname..actionname..key or something like that. More entropy :)
2026-03-08T04:19:24  <OpenMW-bridge> <trackpadtimmy> yeah theres really no harm in making it very long or specific to your mod only
2026-03-08T04:23:22  <OpenMW-bridge> <trackpadtimmy> whats funny is i was trying to debug this with chatgpt earlier and it kept suggesting the event/key names as being the issue, but i was like "no, i know all the names and events are unique, stop suggesting namespacing" because this technically was a namespacing issue after all, just not in the way it was saying lmao
2026-03-08T04:23:45  <OpenMW-bridge> <detaildevil> https://cdn.discordapp.com/attachments/854806553310920714/1480058416687878174/image.png?ex=69ae4b50&is=69acf9d0&hm=ecdb096633bfc8b7793da77c12abc8197664478d280f615539fa4fa302621bc1&
2026-03-08T04:23:48  <OpenMW-bridge> <detaildevil> Do you mean 1
2026-03-08T04:23:53  <OpenMW-bridge> <detaildevil> I just changed 2 for now
2026-03-08T04:24:53  <OpenMW-bridge> <.arrean> 2, 1 is unique to whatever  namespace you're storin your settings in
2026-03-08T04:25:36  <OpenMW-bridge> <trackpadtimmy> you want the default to be something very specific that wont conflict with any other mods change it to something like default = "DevilishDressUndress_QuickUnequipAction"
2026-03-08T04:26:26  <OpenMW-bridge> <trackpadtimmy> that default value will show up in the OMWInputBindings storage section
2026-03-08T04:27:34  <OpenMW-bridge> <S3c:tor> Oh
2026-03-08T04:27:52  <OpenMW-bridge> <S3c:tor> So this is why urm laugh reacted when I said I use input.KEY for the default key
2026-03-08T04:27:56  <OpenMW-bridge> <S3c:tor> Goddamnit.
2026-03-08T04:28:20  <OpenMW-bridge> <S3c:tor> Well
2026-03-08T04:28:43  <OpenMW-bridge> <S3c:tor> Man, I've been wondering about that for like a week now.
2026-03-08T04:28:55  <OpenMW-bridge> <S3c:tor> We have to document this API.
2026-03-08T04:29:10  <OpenMW-bridge> <.arrean> I was wondering why defaults don't do anything. Well apparently they do 'something '
2026-03-08T04:29:22  <OpenMW-bridge> <.arrean> Just not what anyone would expect
2026-03-08T04:29:46  <OpenMW-bridge> <trackpadtimmy> looking at my backed up playersection before debugging this looks like narrowly a conflict between z and Z from some mods
2026-03-08T04:29:46  <OpenMW-bridge> <trackpadtimmy> https://cdn.discordapp.com/attachments/854806553310920714/1480059929011421274/image.png?ex=69ae4cb9&is=69acfb39&hm=98b276644e9109d17a93a63d1d9024c2bdc67fedb42004809a793b55bb162af7&
2026-03-08T04:29:51  <OpenMW-bridge> <S3c:tor> Happening to know the design and intent of the input actions API that actually is kinda exactly what I expect it to do unfortunately 🤣
2026-03-08T04:30:10  <OpenMW-bridge> <S3c:tor> Because the whole thing actually is meant to be agnostic of any specific type of input device
2026-03-08T04:30:15  <OpenMW-bridge> <.arrean> Oh
2026-03-08T04:30:19  <OpenMW-bridge> <.arrean> Oooh
2026-03-08T04:30:39  <OpenMW-bridge> <S3c:tor> There are a few spots it says "key" and you naturally go "key on keyboard", but it apparently literally always means "key in a table"
2026-03-08T04:30:57  <OpenMW-bridge> <S3c:tor> I thought default was an exception to that but it seems not
2026-03-08T04:31:09  <OpenMW-bridge> <.arrean> I mean... I don't know if I would ever suspect default to mean id
2026-03-08T04:31:16  <OpenMW-bridge> <.arrean> In any context
2026-03-08T04:31:24  <OpenMW-bridge> <.arrean> Without previous knowledge
2026-03-08T04:32:05  <OpenMW-bridge> <S3c:tor> Even having said previous knowledge I was wrong about what it meant, mind 🤣
2026-03-08T04:32:26  <OpenMW-bridge> <S3c:tor> Interesting.
2026-03-08T04:32:43  <OpenMW-bridge> <.arrean> Fair Especially considering that what default means for all other settings renderers
2026-03-08T04:32:56  <OpenMW-bridge> <S3c:tor> The input actions API is legitimately awesome but widely criticized for documentation issues 😅
2026-03-08T04:33:36  <OpenMW-bridge> <S3c:tor> Actually interesting lessons learned during this debugging session
2026-03-08T04:33:43  <OpenMW-bridge> <.arrean> I'm new here, I'll hild my opinions for another day
2026-03-08T04:33:52  <OpenMW-bridge> <.arrean> :36vehks:
2026-03-08T04:34:36  <OpenMW-bridge> <S3c:tor> I come from TES3MP scripting so I let a lot of stuff here slide 😄
2026-03-08T04:34:47  <OpenMW-bridge> <S3c:tor> I probably have a very warped perception of it
2026-03-08T04:35:33  <OpenMW-bridge> <trackpadtimmy> !8883
2026-03-08T04:35:33  <Expandor> https://gitlab.com/OpenMW/openmw/-/merge_requests/8883 – 404 Not Found
2026-03-08T04:35:43  <OpenMW-bridge> <S3c:tor> We're not that far yet
2026-03-08T04:35:44  <OpenMW-bridge> <.arrean> Haven't interacted with tes3mp at all, so no context for that. But I smell spaghetti
2026-03-08T04:35:46  <OpenMW-bridge> <trackpadtimmy> oops
2026-03-08T04:35:53  <OpenMW-bridge> <S3c:tor> #8883 ?
2026-03-08T04:35:54  <Expandor> https://gitlab.com/OpenMW/openmw/-/issues/8883 “inputBinding default values not applying” (opened)
2026-03-08T04:35:59  <OpenMW-bridge> <trackpadtimmy> https://gitlab.com/OpenMW/openmw/-/issues/8883 funnily enough references the dress undress mod as an example of defaults not working
2026-03-08T04:36:19  <OpenMW-bridge> <S3c:tor> Amazing
2026-03-08T04:36:23  <OpenMW-bridge> <S3c:tor> Yeah this is not a bug
2026-03-08T04:36:49  <OpenMW-bridge> <.arrean> Weird (to any user) undocumented behavior
2026-03-08T04:37:55  <OpenMW-bridge> <S3c:tor> If you browse around this channel you'll find this whole API segment is widely considered to be weird undocumented behavior
2026-03-08T04:38:07  <OpenMW-bridge> <.arrean> Lmao
2026-03-08T04:38:27  <OpenMW-bridge> <S3c:tor> I thought I knew how it worked pretty well but after having had this discussion I have come to the conclusion that only one person really gets it
2026-03-08T04:38:41  <OpenMW-bridge> <.arrean> I've tasted some of that so far :36vehks:
2026-03-08T04:39:01  <OpenMW-bridge> <S3c:tor> Most of the whole thing is much simpler than it's given credit for imo
2026-03-08T04:39:16  <OpenMW-bridge> <S3c:tor> Just need to be good at filling the, uh, many, documentation gaps in yourself
2026-03-08T04:39:53  <OpenMW-bridge> <S3c:tor> There legitimately are a lot and they're hard to navigate. I've tried to show people how to navigate them but I need like a whole TED Talk to do it.
2026-03-08T04:40:21  <OpenMW-bridge> <.arrean> Seriously for a minute. Coming from outside with programming experience but no knowledge of openmw lua or lua in general. It's not as bad. Quirks are ther, but docs are better than for some languages I've seen
2026-03-08T04:41:38  <OpenMW-bridge> <S3c:tor> I don't know how to say this in a way that doesn't seem condescending, so just like, be aware I'm not trying to be, but I think people who are used to navigating API docs already don't have this problem, whereas if the distinction between a type and a field is a new concept to you, you're probably in for a bad time.
2026-03-08T04:42:22  <OpenMW-bridge> <S3c:tor> I remember I thought the docs were kinda weird at first but like it just took a couple hours and I was like "Oh, these ones are types' and it just, it was fine
2026-03-08T04:42:59  <OpenMW-bridge> <S3c:tor> Maaaaaaannnyyyy people struggle with our docs, just all the time.
2026-03-08T04:43:09  <OpenMW-bridge> <.arrean> As I said, docs are fine. It's what is not in the docs that gets you
2026-03-08T04:43:30  <OpenMW-bridge> <S3c:tor> Yeah.
2026-03-08T04:43:46  <OpenMW-bridge> <S3c:tor> I'd like more coverage of the builtins in general. I'm not sure what to do about it tbh.
2026-03-08T04:44:07  <OpenMW-bridge> <S3c:tor> I kind of just want to make my own doc site when I think about the problem 😄
2026-03-08T04:44:29  <OpenMW-bridge> <S3c:tor> But, seriously, there are not a ton of discussions that go around on it
2026-03-08T04:44:44  <OpenMW-bridge> <S3c:tor> Most of the energy going into docs is around getting LLS annotations working
2026-03-08T04:45:16  <OpenMW-bridge> <S3c:tor> We need more examples, and just, demonstrations of things
2026-03-08T04:46:28  <OpenMW-bridge> <S3c:tor> I've noticed that my style is very different than many people's and I have  a handful of specific patterns I've picked up that I thought everyone did but I'm noticing seem to be teaching opportunities when I read mods
2026-03-08T04:46:43  <OpenMW-bridge> <S3c:tor> Everyone always uses :get all the time for everything and I can't stand it
2026-03-08T04:47:15  <OpenMW-bridge> <S3c:tor> But, I think this is because I started when the API was much less mature, less mods were being made, most of the stuff I cut my teeth on was literally made by other OpenMW devs
2026-03-08T04:47:17  <OpenMW-bridge> <trackpadtimmy> +1 for more examples/demonstrations the ones that are there are really helpful for understanding stuff
2026-03-08T04:47:40  <OpenMW-bridge> <S3c:tor> We actually do kind of have a bunch of such demos, just, in the form of old mods
2026-03-08T04:48:27  <OpenMW-bridge> <.arrean> For any new modder it's finding those that would be an issue
2026-03-08T04:48:33  <OpenMW-bridge> <S3c:tor> Yeah, exactly!
2026-03-08T04:48:47  <OpenMW-bridge> <trackpadtimmy> also true, when first creating photo mode I was looking at peoples code to see what was being done just sometimes it can be hard to understand when there’s like no comments or easily readable sections
2026-03-08T04:49:24  <OpenMW-bridge> <S3c:tor> For example, here is very nearly a "perfect" settings menu, I've made additional refinements on this, but literally all of mine function more or less like this and I'd tell literally everyone to do them this way also: https://gitlab.com/modding-openmw/ui-modes/-/blob/master/scripts/uimodes/settings.lua?ref_type=heads
2026-03-08T04:50:19  <OpenMW-bridge> <S3c:tor> input actions, you, almost can't use without examples such as this lol
2026-03-08T04:50:29  <OpenMW-bridge> <.arrean> That is going into notes. Now, I really need to get off my phone and sleep
2026-03-08T04:50:42  <OpenMW-bridge> <.arrean> Goodnight people
2026-03-08T04:51:01  <OpenMW-bridge> <S3c:tor> ^ eventually becomes this
2026-03-08T04:51:28  <OpenMW-bridge> <S3c:tor> There's a tonna stuff like this, UI, input actions, one people bring up fairly often I love is mwscript equivalents
2026-03-08T04:51:41  <OpenMW-bridge> <S3c:tor> "If I do X in mwscript what does that look like in Lua?"
2026-03-08T15:00:02  <OpenMW-bridge> <Foal (Mads)>           {             type = ui.TYPE.Text,             props = {                 textColor = util.color.rgb(1, 1, 1),                 text = 'TestText',                 textSize = 16,                 autosize = false,                 size = V2(356, 18),                 position = V2(8, 7),                 textAlignH = ui.ALIGNMENT.Center,                 textAlignV = ui.ALIGNMENT.Center,             },         },  Does
2026-03-08T15:00:03  <OpenMW-bridge> textAlignH and textAlignV just not work? This should center it within the size i gave it (as i understand it), but it just gets put in the top left no matter what.
2026-03-08T15:09:36  <OpenMW-bridge> <Foal (Mads)> I've wrapped it in a sized Widget and used relativePosition/anchor instead for now.
2026-03-08T15:41:32  <OpenMW-bridge> <Foal (Mads)> Same question for multiline and wordWrap They appear to do nothing. The text just continues on one line without wrapping at the width of the widget
2026-03-08T15:41:53  <OpenMW-bridge> <Foal (Mads)> doesn't matter if i explicitly size the text itself, or wrap it in a sized widget.
2026-03-08T15:48:24  <OpenMW-bridge> <Foal (Mads)> Looks like they do work on TextEdit, just not Text. https://openmw.readthedocs.io/en/latest/reference/lua-scripting/widgets/text.html Badly needs updating if those options don't actually exist for this widget type.
2026-03-08T15:49:46  <OpenMW-bridge> <Foal (Mads)> (use of non-existing properties should maybe also generate a warning)
2026-03-08T15:55:05  <OpenMW-bridge> <Foal (Mads)> Now I'm also confused: what is the use case of ui.TYPE.Text? It seems to be just a TextEdit with readOnly fixed to true with fewer features.
2026-03-08T15:55:15  <OpenMW-bridge> <S3c:tor> Yeah.
2026-03-08T16:09:38  <OpenMW-bridge> <dreamhour> I think I was able to make it work with Text under some specific conditions. I'll try to recover an example and get back to you
2026-03-08T16:10:45  <OpenMW-bridge> <Foal (Mads)> With TextEdit they work where they don't work with Text, so either way the docs need updating.
2026-03-08T16:15:56  <OpenMW-bridge> <maxyari> it seems like i cant get a playerSection from storage from within my global script - what the intended way to access mod settings in globa lthen?
2026-03-08T16:17:10  <OpenMW-bridge> <.arrean> I was doing local globalSettings = storage.globalSection(constants.globalSettingsStorageKey) And stuff that needs to be accessed globally is in that section
2026-03-08T16:17:30  <OpenMW-bridge> <Foal (Mads)> If global needs to know about a player setting then it should communicate it with a player script via events i think.
2026-03-08T16:17:45  <OpenMW-bridge> <.arrean> or that
2026-03-08T16:17:52  <OpenMW-bridge> <maxyari> erm, ok, how do i make global settings then? Ugh
2026-03-08T16:18:00  <OpenMW-bridge> <maxyari> so they are in global section
2026-03-08T16:18:10  <OpenMW-bridge> <.arrean> GLOBAL: scripts/modname/settings/global_settings.lua
2026-03-08T16:18:16  <OpenMW-bridge> <Foal (Mads)> I think any settings registered via a global script go in global
2026-03-08T16:18:20  <OpenMW-bridge> <maxyari> i tried using I.Settings.registerPage in global context but that failed
2026-03-08T16:19:47  <OpenMW-bridge> <.arrean> yeah, can't register page in global, only in player or menu.  My global_settings: The page is registered in another script in MENU context lua local core = require('openmw.core') local I = require('openmw.interfaces') local constants = require('scripts.holidaysandbirthdays.constants')  -- Load localization local modInfo = require('scripts.holidaysandbirthdays.modinfo') local l10n = core.l10n(modInfo.name) if I.Settings then    
2026-03-08T16:19:47  <OpenMW-bridge>  print("[HolidasAndBirthDays] Registering Global Settings")     I.Settings.registerGroup({         key = constants.globalSettingsStorageKey,         page = modInfo.name,         order = 0, -- Explicit ordering         l10n = modInfo.l10n,         name = l10n('daedric_settings_name'),         permanentStorage = true,         settings = {             {                 key = constants.enableDaedricLimitersKey,                 default =
2026-03-08T16:19:48  <OpenMW-bridge> constants.enableDaedricLimitersDefault,                 renderer = 'checkbox',                 name = l10n('enable_daedric_limiters_name'),                 description = l10n('enable_daedric_limiters_desc'),                 trueLabel = l10n('true_string'),                 falseLabel = l10n('false_string')             },          }     }) end 
2026-03-08T16:20:50  <OpenMW-bridge> <Foal (Mads)> register page once in menu (or player if you want) page doesn't contain any of your settings so it doesn't affect player vs global
2026-03-08T16:20:58  <OpenMW-bridge> <Foal (Mads)> it's registerGroup that needs to be in player vs global context
2026-03-08T16:21:38  <OpenMW-bridge> <Foal (Mads)> docs also need to be updated on this, i think it's really badly documented
2026-03-08T16:22:06  <OpenMW-bridge> <.arrean> I don't know if there's a cleaner way than what's Ive been doing. But seems I stumbled into exactly what Foal is suggesting too :D
2026-03-08T16:23:00  <OpenMW-bridge> <Foal (Mads)> https://openmw-vr.readthedocs.io/en/latest/reference/lua-scripting/interface_settings.html##(Settings).registerPage Shows that the interface is available to global, menu, and player, but each context only has a subset of the features.
2026-03-08T16:23:24  <OpenMW-bridge> <Foal (Mads)> But none of the latter or what we've discussed is actually documented anywhere
2026-03-08T16:24:25  <OpenMW-bridge> <.arrean> It was just this morning - https://discord.com/channels/260439894298460160/854806553310920714/1480063296672628859
2026-03-08T16:24:38  <OpenMW-bridge> <.arrean> 😆
2026-03-08T16:25:00  <OpenMW-bridge> <maxyari> so, I registerPage in global and then registerGroup in player, and whatever i registered with registerGroup will be in global? Huh!?
2026-03-08T16:25:10  <OpenMW-bridge> <Foal (Mads)> no
2026-03-08T16:25:13  <OpenMW-bridge> <.arrean> registerPage in Menu or Player, not in global
2026-03-08T16:25:15  <OpenMW-bridge> <Foal (Mads)> registerPage in Menu or Player
2026-03-08T16:25:25  <OpenMW-bridge> <Foal (Mads)> registerGroup in the context you want the settings in that group to be associated with
2026-03-08T16:25:35  <OpenMW-bridge> <maxyari> ah i see
2026-03-08T16:25:44  <OpenMW-bridge> <Foal (Mads)> registerGroup in Player -> Player settings registerGroup in Global -> Global settings
2026-03-08T16:25:45  <OpenMW-bridge> <maxyari> so page in player group in global, makes sense kinda maybe
2026-03-08T16:25:59  <OpenMW-bridge> <maxyari> if i squint hard it makes sense
2026-03-08T16:26:02  <OpenMW-bridge> <maxyari> thanks a lot though
2026-03-08T16:26:17  <OpenMW-bridge> <Foal (Mads)> I can't remember off the top of my head what registerGroup in Menu does. If that makes it global or not.
2026-03-08T16:26:39  <OpenMW-bridge> <.arrean> I think it makes it "player" interestingly
2026-03-08T16:27:34  <OpenMW-bridge> <Foal (Mads)> I'm not sure how that could make sense, given that no player is loaded in the main menu and you can register groups with menu scripts during the main menu.
2026-03-08T16:27:37  <OpenMW-bridge> <.arrean> I didn't dig deep, but before I had to separate my settings - I had all of them in Menu - and they were available via PlayerStorage
2026-03-08T16:27:55  <OpenMW-bridge> <.arrean> 🤷‍♂️
2026-03-08T16:31:19  <OpenMW-bridge> <.arrean> Completely unrelated.   I'm trying to detect when player equips a new weapon without spamming onUpdate  I've added a custom   lua I.ItemUsage.addHandlerForType(types.Weapon, function(weapon, actor)  However, it seems it only fires when I equip an item throguh the inventory - it specifically ignored the next weapon, previous weapon stuff we can do via hotkeys.  Anyone know of a way to intercept those too?
2026-03-08T16:34:25  <OpenMW-bridge> <Foal (Mads)> Here's how to frame Global vs Player: Player is one type of Local context. The Global/Local divide in our Lua scripting exists to better function in a multiplayer context. Global in a multiplayer context is the server. While Local is any entity active on the server. NPCs etc. are also Local just to make things consistent. This is why there is a hard divide between Player instances, NPC instances, Global, etc. where you have
2026-03-08T16:34:26  <OpenMW-bridge> to send messages/events instead of editing things directly. In terms of settings, therefore. A global setting is a server wide setting that affects everyone, while a Player setting is a single users' preference that needs to be compatible with other users having different preferences for the same settings.
2026-03-08T16:38:09  <OpenMW-bridge> <Foal (Mads)> Menu vs Player affects when a settings page appears. If you register the page in a Menu script, the setting can be edited in the main menu before loading/launching a game. Similarly, setting groups registered in Global or Menu appear in the main menu before loading a game, and therefore also cannot be stored in a per-character way. Settings registered in Menu and Global MUST therefore have permanentStore=true (affects all
2026-03-08T16:38:10  <OpenMW-bridge> saves). While settings/pages registered in Player scripts will not appear until a character has been loaded. These settings can have either permanentStorage=true (affects all characters) or permanentStorage=false (affects only this save).
2026-03-08T16:39:46  <OpenMW-bridge> <dreamhour>  ui.create {     type = ui.TYPE.Widget,     layer = "Windows",     props = {       textAlignH = Center,       textAlignV = Center,       size = util.vector2(400,400)     },     name = "Mer_ScenarioSelectorDescription_wrapper",     content = ui.content {       {         name = "Mer_ScenarioSelectorDescription",         type = ui.TYPE.Text,         content = ui.content {},         props = {           textAlignH = Center,       
2026-03-08T16:39:46  <OpenMW-bridge>    textAlignV = Center,           text = "You are in the swamps of the Bitter Coast, searching for ingredients. SOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO LOOOOOOOOOOOOOOOOOOOOOOOOOOONG",           textSize = 16,           autoSize = false,           size = util.vector2(400,400),           multiline = true,           wordWrap = true,         },         template = I.MWUI.templates.textNormal       }     }   } 
2026-03-08T16:39:58  <OpenMW-bridge> <dreamhour> This should work, you can paste it directly to luap
2026-03-08T16:41:29  <OpenMW-bridge> <dreamhour> Some parts of it are probably excessive, that's just how my aproach with porting mwse ui works - every mwse widget actually consists of inner and outer layout, so padding and other stuff can be aplied
2026-03-08T16:46:55  <OpenMW-bridge> <dreamhour> The align = Center part definitely doesn't work, I forgot to add an import 😅
2026-03-08T16:48:47  <OpenMW-bridge> <Foal (Mads)> yeah, it does work if i change them to ui.ALIGNMENT.Center
2026-03-08T16:49:04  <OpenMW-bridge> <Foal (Mads)> But i cannot tell what you're doing differently from what i was
2026-03-08T16:49:52  <OpenMW-bridge> <dreamhour> autoSize = false and Widget as an outer type maybe? Oh, and also explicit sizes everywhere
2026-03-08T16:50:09  <OpenMW-bridge> <Foal (Mads)> I was doing exactly that
2026-03-08T16:50:34  <OpenMW-bridge> <dreamhour> I remember I spent a whole day until finally make that MWSE UI work as intended in OMW
2026-03-08T16:50:49  <OpenMW-bridge> <dreamhour> oh, and also      template = I.MWUI.templates.textNormal
2026-03-08T16:51:13  <OpenMW-bridge> <Foal (Mads)> removing your template doesn't break it
2026-03-08T16:51:39  <OpenMW-bridge> <Foal (Mads)> if i remove the Widget wrapper from yours, it stops working. But i am using TextEdit without a Widget wrapper /shrug
2026-03-08T16:52:38  <OpenMW-bridge> <Foal (Mads)> actually it does work without the wrapper, i just had to specify the layer again
2026-03-08T17:11:11  <OpenMW-bridge> <Foal (Mads)> Argh. I am going to double down on > use of non-existing properties should maybe also generate a warning I just had a typo autosize -> autoSize
2026-03-08T17:26:51  <OpenMW-bridge> <Foal (Mads)> https://gitlab.com/OpenMW/openmw/-/issues/9002
2026-03-08T17:32:36  <OpenMW-bridge> <blurpandra> I thought LTEX indexes were globally unique but now I think I'm wrong. are these namespaced by .esm for their attached LAND vtexes?
2026-03-08T17:52:27  <OpenMW-bridge> <qlonever> yes
2026-03-08T17:52:43  <OpenMW-bridge> <blurpandra> ah thanks for the clarification 🙏
2026-03-08T17:52:45  <OpenMW-bridge> <qlonever> though 0 always refers to the default texture for morrowind
2026-03-08T17:54:03  <OpenMW-bridge> <qlonever> so 1 in VTEX refers to LTEX 0 for that plugin iirc
2026-03-08T18:48:34  <OpenMW-bridge> <blurpandra> that worked perfectly, thank you 😄
2026-03-08T18:48:34  <OpenMW-bridge> <blurpandra> https://cdn.discordapp.com/attachments/854806553310920714/1480276054533865513/image.png?ex=69af1601&is=69adc481&hm=135076b7917a9ec7280327544bad4ee6b8e457a5d61e87b3e07ec92be24d25a8&
2026-03-08T18:55:30  <OpenMW-bridge> <qlonever> sugoi
2026-03-08T18:57:47  <OpenMW-bridge> <qlonever> are you just using a single average color for each land texture?
2026-03-08T18:57:56  <OpenMW-bridge> <qlonever> it looks kind of cell-shaded, which is cool
2026-03-08T18:59:44  <OpenMW-bridge> <blurpandra> I'm using the average hue and saturation for each texture, but I'm choosing the lightness of the color based on the elevation. I'm also doing a subtle warm/cool shading depending on the normal direction
2026-03-08T19:00:11  <OpenMW-bridge> <blurpandra> the vtex colors are blurred before all that, too
2026-03-08T19:00:35  <OpenMW-bridge> <qlonever> neat
2026-03-08T19:01:19  <OpenMW-bridge> <blurpandra> details are all in https://github.com/erinpentecost/LivelyMap/blob/main/internal/hdmap/colormap.go if you want to read my ugly code
2026-03-08T19:04:31  <OpenMW-bridge> <qlonever> whatever you wrote, I'm sure I've written something far uglier