openmw issueshttps://gitlab.com/OpenMW/openmw/-/issues2024-03-28T21:22:04Zhttps://gitlab.com/OpenMW/openmw/-/issues/7906Lua setting renderer 'inputBinding' assumes the trigger's/action's 'key' as l...2024-03-28T21:22:04ZtravLua setting renderer 'inputBinding' assumes the trigger's/action's 'key' as l10n name instead of their 'l10n' parameter## Issue
I made this Lua player script, which uses the `input.registerTrigger` functionality alongside the inputBinding built-in settings renderer to let player execute an action (display a textbox) on any keyboard input they configure ...## Issue
I made this Lua player script, which uses the `input.registerTrigger` functionality alongside the inputBinding built-in settings renderer to let player execute an action (display a textbox) on any keyboard input they configure in the script settings window. I'm also using `core.l10n` to define setting descriptions in a en.yaml file.
I noticed that not all of these descriptions are taken from my yaml file. Pictures should show what I expect best. My thoughts on what's wrong IMO are after, then the script itself:
### Expected:
![obraz](/uploads/47e82157d353463255ee44a74bf29167/obraz.png)
### Actual:
![obraz](/uploads/03e792042a8646f5a02aedc150ced90d/obraz.png)
## Possible correction
Script seems to be looking for the l10n context named exactly as I named the trigger key. To me it's odd, because AFAIK both [ActionInfo](https://openmw.readthedocs.io/en/latest/reference/lua-scripting/openmw_input.html##(ActionInfo)) and [TriggerInfo](https://openmw.readthedocs.io/en/latest/reference/lua-scripting/openmw_input.html##(TriggerInfo)) (parameters used in `input.registerTrigger` / `input.registerAction` functions) have the `l10n` parameter and it seems to me that this should be used, not the key.
I'm pretty sure (at least I tested it locally) that just changing this line in
https://gitlab.com/OpenMW/openmw/-/blob/master/files/data/scripts/omw/input/settings.lua#L105
from
```
local l10n = core.l10n(info.key)
```
to
```
local l10n = core.l10n(info.l10n)
```
shall fix the issue (the "Expected" picture above was taken after I made that exact change)
Or am I completely wrong? Please let me know if I am.
## Script used to reproduce the issue
### 1.: `l10n/troubleshooting_input_issue_with_l10n/en.yaml`
```
travTroubleshootingSettingsPageName: "Main settings title for this issue"
travTroubleshootingSettingsPageNameDescription: "Description for the page for this issue"
travSettingsSectionName: "Settings section with the input changing option"
travSettingName: "Name of the setting where you change the input"
travSettingNameDescription: "Description of this setting"
travTriggerName: "Click here ->"
travTriggerDescription: "then press the new button"
```
### 2.: `scripts/player3.lua`
```
local input = require('openmw.input')
local storage = require('openmw.storage')
local async = require('openmw.async')
local I = require('openmw.interfaces')
local ui = require('openmw.ui')
local l10nKey = 'troubleshooting_input_issue_with_l10n'
local defaultButtonForTrigger = "u"
local triggerKey = "travTriggerKey"
local triggerName = "travTriggerName"
local triggerDesc = "travTriggerDescription"
local settingKey = "travSettingsKey"
local settingName = "travSettingName"
local settingsPageKey = "travTroubleshootingSettingsPageKey"
local settingsPageName = "travTroubleshootingSettingsPageName"
local modSettingsKey = "SettingsCustom_0travSettings"
local settingSectionName = "travSettingsSectionName"
input.registerTrigger({
name = triggerName,
description = triggerDesc,
l10n = l10nKey,
key = triggerKey,
})
input.registerTriggerHandler(triggerKey, async:callback(function ()
print("I see you, hello")
ui.showMessage("I see you, hello")
end))
I.Settings.registerPage({
key = settingsPageKey,
l10n = l10nKey,
name = settingsPageName,
description = settingsPageName.."Description",
})
I.Settings.registerGroup({
key = modSettingsKey,
page = settingsPageKey,
l10n = l10nKey,
name = settingSectionName,
permanentStorage = true,
settings = {
{
key = settingKey,
renderer = "inputBinding",
name = settingName,
description = settingName..'Description',
default = defaultButtonForTrigger,
argument = {
type = "trigger",
key = triggerKey
}
}
},
})
```
### 3.: omwscripts file
It just points to the player script:
`PLAYER: scripts/player3.lua`https://gitlab.com/OpenMW/openmw/-/issues/7905Game freezes after leaving ship. (Only openMW no mods)2024-03-28T19:05:25ZLeah AndreiGame freezes after leaving ship. (Only openMW no mods)Describe the issue as detailed as you can. Below is a list of questions that should be answered in the description (if they apply).
- Is the problem OpenMW specific or does it also happen in vanilla Morrowind?
- **Only in OpenMW**
-
- ...Describe the issue as detailed as you can. Below is a list of questions that should be answered in the description (if they apply).
- Is the problem OpenMW specific or does it also happen in vanilla Morrowind?
- **Only in OpenMW**
-
- What is your operating system?
- **Windows 10**
-
- What version of OpenMW are you using? If you used a bleeding edge build, state the exact revision used.
- **0.48**
-
- What version of Morrowind are you using (i.e. retail CD or Steam)? What addons (Tribunal, Bloodmoon) do you have installed? What language is your Morrowind install?
- **I use the gamepass version of GOTY Morrowind**
-
- Do you use any mods? If so, does the problem also occur in a clean vanilla install without any mods?
- **Problem only happens with freshly installed openMW**
-
- What are the exact steps to reproduce the problem?
- **I exit the ship at the begining and it pops a random loading screen tool-tip then freezes. every time, i get to move or look 2 seconds and then i get that**
-
- What did you expect to happen? What happened instead?
- **Expected to wait for the loading screen to finish, maybe it was loading shaders or something but instead it freezes**
-
- Are there any error messages in your `openmw.log` file? If you're not an OpenMW team member, it's best to upload it.
- **I sometimes get the message "openMW appears to have frozen" but now i just get the message that it encounters a fetal error and i should report this and check the crash dump file**
-
- What settings do you use? If you're not an OpenMW team member, it's best to upload your `settings.cfg`.
- **Uploading settings.cfg[openmw-crash.dmp](/uploads/e19682c768017938e258e53de673bf84/openmw-crash.dmp)
[settings.cfg](/uploads/7281245216cc556aab85bf65d6c1830c/settings.cfg)**
- Where is the in-game location this problem can be observed? Avoid vague statements such as "west of town X". Instead, open the console (`` ` `` key by default, the key above Tab), click on the problematic object, then use the betacomment (`bc`) instruction to get useful information about the object that you can copy and paste into the bugreport:
- **At the begining of the game, i get out of the ship i dont even know the game locations yet**https://gitlab.com/OpenMW/openmw/-/issues/7904Installation Failure of The Elders Scrolls - Anthology - Morrowind GOTY Editi...2024-03-27T20:18:49ZLuk-karInstallation Failure of The Elders Scrolls - Anthology - Morrowind GOTY Edition from CD Using OpenMW on Ubuntu 22.04## Expected Behavior:
Installing Morrowind with expansions from the CD
## Actual Behavior:
Cannot install the game from the CD
## Environment
### OS:
```
Ubuntu 22.04.4 LTS
Release: 22.04
Codename: jammy
```
### OpenMW version:
`...## Expected Behavior:
Installing Morrowind with expansions from the CD
## Actual Behavior:
Cannot install the game from the CD
## Environment
### OS:
```
Ubuntu 22.04.4 LTS
Release: 22.04
Codename: jammy
```
### OpenMW version:
```
OpenMW 0.48.0 release
```
### Morrowind:
```
GOTY Morrowind - The Elders Scrolls - Anthology
PL and ENG languages avaible
Most files with the date 30-11-2013
```
## Steps to reproduce:
1. Installed required packages for OpenMW via [terminal commands](https://openmw.readthedocs.io/en/latest/manuals/installation/install-openmw.html#the-ubuntu-way):
```
$ sudo apt-get install software-properties-common
$ sudo add-apt-repository ppa:openmw/openmw
$ sudo apt-get update
$ sudo apt-get install openmw openmw-launcher
```
2. Inserted the first CD of the "GOTY Morrowind - The Elder Scrolls Anthology" and ensured the content was readable. ![Morrowind_CD1](/uploads/af4ab6cbcaeeb4c7a938eec496536fe6/Morrowind_CD1.png)
3. Executed `openmw-launcher` from the terminal, which opened the installation wizard.
![Wizard_redirected](/uploads/c6d88dc76722c710dec9cdedc5623215/wizard_redirected.png)
4. In the Wizard, selected:
- `Retail CD/DVD` option.
- Default installation path: `/home/user/.local/share/openmw/basedata`
- Language: `English`
- Components to install: `Morrowind`, `Tribunal`, `Bloodmoon`
- CD path: `/media/user/MORROWIND_D1`
5. Received a warning about a potentially more recent version of Morrowind being available.
![Warning](/uploads/4f4ebe2ce6472ee509b405a447348450/Warning.png)
6. Proceeded with the installation despite the warning.
7. The installation failed, with error messages indicating `Failed to extract: Morrowind.bsa`
![log](/uploads/6d80a2ab116f2d58f1789f0ac3ff0b12/log.png) ![error](/uploads/60f8a4af5b28a28d9f12a9d30e720e74/error.png) ![extracted_files_so_far](/uploads/09a4b2cbc0ee6791a1584ab3ce633409/extracted_files_so_far.png)
## Attempts to Solve the Problem:
- Restarted the PC
---
Thanks for your time!https://gitlab.com/OpenMW/openmw/-/issues/7902Crashed after reload, died from fatigue dash2024-03-26T16:23:37ZLarry BurdenCrashed after reload, died from fatigue dashIf you're reporting an issue specific to a fork, e.g. [TES3MP](https://github.com/TES3MP/openmw-tes3mp/issues) for multiplayer or [OpenMW-VR](https://gitlab.com/madsbuvi/openmw/-/issues) for OpenXR VR, please report it to that fork's aut...If you're reporting an issue specific to a fork, e.g. [TES3MP](https://github.com/TES3MP/openmw-tes3mp/issues) for multiplayer or [OpenMW-VR](https://gitlab.com/madsbuvi/openmw/-/issues) for OpenXR VR, please report it to that fork's author instead of here.
If you're reporting an issue specific to an open merge request, the comments for the merge request are probably a good place to report.
Describe the issue as detailed as you can. Below is a list of questions that should be answered in the description (if they apply).
- Is the problem OpenMW specific or does it also happen in vanilla Morrowind? OpenMW Specific
- What is your operating system? Win 11 Build 22631
- What version of OpenMW are you using? If you used a bleeding edge build, state the exact revision used. OpenMW development (82bc6674dc)
- What version of Morrowind are you using (i.e. retail CD or Steam)? What addons (Tribunal, Bloodmoon) do you have installed? What language is your Morrowind install? GOG, Tribunal+Bloodmoon, English
- Do you use any mods? If so, does the problem also occur in a clean vanilla install without any mods? Yes (Total Overhaul modlist), no
- What are the exact steps to reproduce the problem? Randomly crashed after trying to reload, died from low fatigue dash
- What did you expect to happen? What happened instead? To not crash on reload, I crashed
- Are there any error messages in your `openmw.log` file? If you're not an OpenMW team member, it's best to upload it.
- What settings do you use? If you're not an OpenMW team member, it's best to upload your `settings.cfg`.
- Where is the in-game location this problem can be observed? Avoid vague statements such as "west of town X". Instead, open the console (`` ` `` key by default, the key above Tab), click on the problematic object, then use the betacomment (`bc`) instruction to get useful information about the object that you can copy and paste into the bugreport: It was directly outside of Thelas Ancestral Tomb
[openmw-crash.dmp](/uploads/cdb100ab15284e71be86edb911b7b330/openmw-crash.dmp)
[openmw.log](/uploads/e7a19dda4744b8749d9a69d04b009805/openmw.log)
[settings.cfg](/uploads/ddad97ceed496c07c8851a8daca0c2c5/settings.cfg)https://gitlab.com/OpenMW/openmw/-/issues/7901Editor: Teleport-related fields shouldn't be editable if a ref does not teleport2024-03-26T09:31:11ZDave Corleycorleycomputerrepair@protonmail.chEditor: Teleport-related fields shouldn't be editable if a ref does not teleportWhen a `cellref` is saved, it will check itself to determine whether it teleports or not before saving `DODT` / `DNAM` subrecords. Much like TESCS does, and !3982 does with lock level/key values, these fields should be noninteractive if ...When a `cellref` is saved, it will check itself to determine whether it teleports or not before saving `DODT` / `DNAM` subrecords. Much like TESCS does, and !3982 does with lock level/key values, these fields should be noninteractive if the door does not actually teleport. This would be more intuitive and also save accidental cases where a door is assigned a destination without actually being marked as a teleport door.openmw-0.49Dave Corleycorleycomputerrepair@protonmail.chDave Corleycorleycomputerrepair@protonmail.chhttps://gitlab.com/OpenMW/openmw/-/issues/7900Melee hit targeting innacuracies2024-03-25T13:36:33ZQloneverMelee hit targeting innacuraciesCompared to vanilla Morrowind, OpenMW seems to detect melee hits inaccurately. Whereas OpenMW attempts to directly evaluate an attack's angle in two planes using relevant GMST values as degrees of tolerance (fCombatAngleXY & fCombatAngle...Compared to vanilla Morrowind, OpenMW seems to detect melee hits inaccurately. Whereas OpenMW attempts to directly evaluate an attack's angle in two planes using relevant GMST values as degrees of tolerance (fCombatAngleXY & fCombatAngleZ), Morrowind.exe seems to use the sines of the attack's angles multiplied by 90 when comparing with those GMSTs. This results in OpenMW allowing attacks to hit at wider angles on the XY plane. As for the Z component, OpenMW is even more inaccurate:
![2024-03-22_10-10-26](/uploads/510a13b1c19a6bde6a75b68b4f6a804a/2024-03-22_10-10-26.mp4)
![2024-03-22_10-13-28](/uploads/0ba491b0ee46cc4a8e5ba78a3b61ad07/2024-03-22_10-13-28.mp4)
It seems that Morrowind.exe considers the entire height of the target's bounding box when checking if an attack's ZY angle is within the allowed range, but I'm not entirely sure.
I did a bit of tinkering with GMSTs to try and determine how Morrowind.exe calculates valid attack angles; here is a diagram with my findings:
![mwhits](/uploads/6b25642959edb37b4509c5671c074481/mwhits.png)openmw-0.49Alexei KotovAlexei Kotovhttps://gitlab.com/OpenMW/openmw/-/issues/7897Open main menu does not suspend onUpdate scripts2024-03-24T14:09:42ZelsidOpen main menu does not suspend onUpdate scriptsIt's possible to reproduce this by a benchmark like https://gitlab.com/elsid/openmw/-/commit/306b327f11a99f1daabfafee82fe69b735cede2e . `onUpdate` script controls player's movement and it's not suspended when Esc is pressed and main menu...It's possible to reproduce this by a benchmark like https://gitlab.com/elsid/openmw/-/commit/306b327f11a99f1daabfafee82fe69b735cede2e . `onUpdate` script controls player's movement and it's not suspended when Esc is pressed and main menu is shown. This is different from 0.48 behaviour and has been changed by https://gitlab.com/OpenMW/openmw/-/merge_requests/3398 (23a7661d0b58c976593f549d5d048e5291aead54).
![open_menu](/uploads/591a18a79c5a4c944e8caf35147f4f34/open_menu.mp4)https://gitlab.com/OpenMW/openmw/-/issues/7896Editor: Loading cellrefs incorrectly transforms refNums, causing load failures2024-03-26T09:31:36ZDave Corleycorleycomputerrepair@protonmail.chEditor: Loading cellrefs incorrectly transforms refNums, causing load failuresI've demonstrated this multiple times over other MRs and in discord discussions while working other issues. A simple explanation:
Perfectly normal refNums will often fail to load because CS has incorrectly marked the originating content...I've demonstrated this multiple times over other MRs and in discord discussions while working other issues. A simple explanation:
Perfectly normal refNums will often fail to load because CS has incorrectly marked the originating content file and thus cannot find the reference. One example can be seen simply by loading the Starwind ESM files:
![image.png](/uploads/c40321cc79214880a2c106df38152e54/image.png){width="1197" height="681"}
but it gets even nastier than just this. When modifying references, which were modified by ANOTHER plugin, duplicates are created. The MOMW team attempted to make a patch for `adanumuran reclaimed`, which locks some doors added by Morrowind.esm. At present, the output of openCS does this to the references in our output plugin:
````
Record: CELL "punammu" Flags:0x0000 ()
NAME: Name:Punammu
DATA: (Interior) Fog_Density:1.00 Flags:0x0003 (Has_Water)
NAM0: Reference_Count:2
*FRMR: ObjIdx:411348 MastIdx:4
NAME: Name:door_cavern_doors00
FLTV: Lock_Level:2147483647
DATA: X:-286.439 Y:-63.321 Z:-34.148 X_Angle:0.0000 Y_Angle:0.0000 Z_Angle:4.8124
*FRMR: ObjIdx:94779 MastIdx:4
NAME: Name:door_cavern_doors10
FLTV: Lock_Level:2147483647
TNAM: Trap_Spell:touchdrain block DATA: X:-2148.165 Y:1985.416 Z:-30.825 X_Angle:0.0000 Y_Angle:0.0000 Z_Angle:4.782```
````
the mastIdx of the object is ``4``, even though this was actually defined by ``1`` (``Morrowind.esm``, not ``Adanumuran Reclaimed.esp`)``https://gitlab.com/OpenMW/openmw/-/issues/7895(QT): System themes are not accurately detected on some platforms2024-03-22T11:00:02ZDave Corleycorleycomputerrepair@protonmail.ch(QT): System themes are not accurately detected on some platformsMostly applies to windows users from my experience of it. After some discussion about it on Discord, priestofillunibi shared this with us: https://www.qt.io/blog/dark-mode-on-windows-11-with-qt-6.5 wherein QT's somewhat longwinded explan...Mostly applies to windows users from my experience of it. After some discussion about it on Discord, priestofillunibi shared this with us: https://www.qt.io/blog/dark-mode-on-windows-11-with-qt-6.5 wherein QT's somewhat longwinded explanation is effectively to just use their fusion style instead of whatever the system provides. I did confirm that this works with the construction set on Windows. Further explanation to come in the MRhttps://gitlab.com/OpenMW/openmw/-/issues/7893Unify conventions for release naming, especially architecture (x64, arm64, ...)2024-03-23T13:02:06ZMartinspleefer90@gmail.comUnify conventions for release naming, especially architecture (x64, arm64, ...)At the time of writing, there is a mix of lower case and upper case for both the architecture name, OS name and even OpenMW naming itself.
The architecture is defined set somewhat randomly, the closest to correct is the macOS releases....At the time of writing, there is a mix of lower case and upper case for both the architecture name, OS name and even OpenMW naming itself.
The architecture is defined set somewhat randomly, the closest to correct is the macOS releases.
Here are the contenders for architecture names:
* `AArch64`/`aarch64` || `ARM64`/`arm64`
* `AMD64`/`amd64` || `Intel 64` || `x64` || `x86-64` || `x86_64`
Here is their [industry usage](https://en.wikipedia.org/wiki/X86-64#Industry_naming_conventions) as per Wikipedia.
---
Every operating system supports multiple 64-bit architectures:
* Linux can run on arm64, x64, risc64, loong64 and who knows what else.
* macOS can run on arm64 and x64
* Windows can run on arm64 and x64
Using "64-bit" is plain out bad, I had no idea whether the releases will run on Asahi Linux(arm64) or not, turns out they won't.
Using the processor brand for an architecture naming greatly confuses people who own a competitor brand CPU and are unfamiliar with the somewhat odd convention.
Using x86 naming for programs that are actually 64-bit is also confusing, and people using 32-bit systems will think they're supported.
Therefore I suggest to use:
* Capitalized OpenMW
* Capitalized, full OS names, they're short, no reason to kneecap Windows
* Uncapitalized `arm64` and `x64`, so they stick out, and uncapitalized is how they're usually used anyway.
Turning [this](https://gitlab.com/OpenMW/openmw/-/releases/openmw-0.48.0):
```
openmw-0.48.0-Linux-64Bit.tar.gz
OpenMW-0.48.0-macos-arm64.dmg
OpenMW-0.48.0-macos-amd64.dmg
OpenMW-0.48.0-win64.exe
```
Into this:
```
OpenMW-0.48.0-Linux-x64.tgz
OpenMW-0.48.0-macOS-arm64.dmg
OpenMW-0.48.0-macOS-x64.dmg
OpenMW-0.48.0-Windows-x64.exe
```
Which unified everything, is clear and legible, and adding more architectures in the future won't make things worse.
There is also [OpenMW.org](https://openmw.org/downloads/) website to keep in mind, which should probably be linked from the git releases page, as it contains more architectures.
It has similar issues and also refers to a dead Fedora RPM.
Throughout both pages, the fact that OpenMW supports Linux arm64 is not mentioned.
Flatpak linked on the website is also x64 only.
The website's "Other Download Locations" would probably look better as a table.https://gitlab.com/OpenMW/openmw/-/issues/7892Lua UTF-8 conversion probably doesn't work for code points above 65536 on Win...2024-03-26T09:33:59ZAnyOldName3Lua UTF-8 conversion probably doesn't work for code points above 65536 on WindowsThe following discussion from !3950 should be addressed:
- [ ] @AnyOldName3 started a [discussion](https://gitlab.com/OpenMW/openmw/-/merge_requests/3950#note_1817072543):
> @Kuyondo are you still around? This is broken on Windows...The following discussion from !3950 should be addressed:
- [ ] @AnyOldName3 started a [discussion](https://gitlab.com/OpenMW/openmw/-/merge_requests/3950#note_1817072543):
> @Kuyondo are you still around? This is broken on Windows as `wchar_t` is UCS2/UTF-16 there thanks to Microsoft implementing support for Unicode before UTF-8 or UCS4/UTF-32 were invented (for some reason, The Unicode Consortium thought sixteen bits were enough to represent every human alphabet for a while). The conversion needs to go via a fixed-size type big enough to hold a whole code point, i.e. `char32_t`.
>
> https://gitlab.com/OpenMW/openmw/-/merge_requests/3327#note_1542230814 looks relevant. We use C++20 now (although not all of it yet as some of the older compilers in CI only support a subset) so `std::codecvt<char32_t, char8_t, std::mbstate_t>` is available.https://gitlab.com/OpenMW/openmw/-/issues/7890No UI mode changed for the persuasion dialog2024-03-26T09:32:22ZMehdi Yousfi-MonodNo UI mode changed for the persuasion dialogHello,
I'd like to get an "UI mode changed" event for the Persuasion dialogue, but there is none.
Would it be possible to add it?
Or how can I know when the Persuasion dialogue is opened or closed?
Works fine with the main dialog, bart...Hello,
I'd like to get an "UI mode changed" event for the Persuasion dialogue, but there is none.
Would it be possible to add it?
Or how can I know when the Persuasion dialogue is opened or closed?
Works fine with the main dialog, barter and training already.https://gitlab.com/OpenMW/openmw/-/issues/7888Lua UI widget mousePress event generates an additional focus state, persistin...2024-03-17T21:31:42ZtravLua UI widget mousePress event generates an additional focus state, persisting even with mouse out of focusI noticed that after clicking on a custom Lua UI widget element the game keeps calling focus events alongside mouse press events on every click even if the mouse is well away from the problematic element.
### Reproducing the problem us...I noticed that after clicking on a custom Lua UI widget element the game keeps calling focus events alongside mouse press events on every click even if the mouse is well away from the problematic element.
### Reproducing the problem using the mod I made
I created a mod with a player Lua script which helps to reproduce the problem. It replaces the Morrowind journal window with a custom window. There are two buttons in that window -- I added debug logs to focusGain/focusLoss/mousePress/mouseRelease events for both buttons to see when each event is called exactly. The mod is available here:
https://gitlab.com/trav5/openmw-widget-troubleshooting/-/commit/a4ede152a76fbb82d50f73df9e2e6ef0e6685c6e
or just the player script:
https://gitlab.com/trav5/openmw-widget-troubleshooting/-/blob/a4ede152a76fbb82d50f73df9e2e6ef0e6685c6e/scripts/player2.lua
#### Steps
When I say "a debug log should appear", I mean in the the openmw.log / F10 Log Viewer. Here are the steps:
1. [OK] Open the Morrowind journal in-game -- a custom window with buttons [click me] and [Close] should appear
2. [OK] Hover the mouse over [click me] -- a debug log `onEvent focusGain for: [click me]` should appear, indicating the focusGain event was called
3. [NOT OK] Press the mouse button but don't release it. **Two** debug logs appear - one for focusGain, another for mousePress. Why is the focusGain called again when the element under mouse cursor was already in focus?
4. [OK] Release the mouse button -- Debug log for mouseRelease should appear. This seems okay.
5. [OK] Move the cursor away from [click me] -- Debug log for focusLoss should appear. This seems okay.
8. [NOT OK] Click on anything (you don't even have to release the mouse press) except the two buttons -- every mouse press now generates two debug logs for [click me]: one for focusLoss, one for focusGain.
9. [NOT OK] Closing the journal generates one last focusLoss debug log for [click me] - most likely because the last 'state' for [click me] was focus gain.
### OpenMW version
I'm running a compiled openmw on Windows:
```
$ git log
commit b5b6744321e11332870f9d17a25aae41a420bc55 (HEAD -> master, origin/master)
Merge: 0557a649ce eba4ae94b0
Author: psi29a <psi29a@gmail.com>
Date: Mon Mar 11 11:14:26 2024 +0000
```https://gitlab.com/OpenMW/openmw/-/issues/7886Equip and unequip animations can't share the animation track section2024-03-15T07:06:32ZAlexei KotovEquip and unequip animations can't share the animation track sectionAttach/detach keys will be handled as a part of the wrong section with whichever comes later winning. This messes with [Riders](https://www.nexusmods.com/morrowind/mods/46868). While the mod doesn't work in Morrowind without MCP, there's...Attach/detach keys will be handled as a part of the wrong section with whichever comes later winning. This messes with [Riders](https://www.nexusmods.com/morrowind/mods/46868). While the mod doesn't work in Morrowind without MCP, there's no particular reason for this not to be supported as I doubt this is something that relies on the MCP fix.openmw-0.49Alexei KotovAlexei Kotovhttps://gitlab.com/OpenMW/openmw/-/issues/7883I cannot find revision information for my daily build.2024-03-16T04:38:21ZDraxissI cannot find revision information for my daily build.If you're reporting an issue specific to a fork, e.g. [TES3MP](https://github.com/TES3MP/openmw-tes3mp/issues) for multiplayer or [OpenMW-VR](https://gitlab.com/madsbuvi/openmw/-/issues) for OpenXR VR, please report it to that fork's aut...If you're reporting an issue specific to a fork, e.g. [TES3MP](https://github.com/TES3MP/openmw-tes3mp/issues) for multiplayer or [OpenMW-VR](https://gitlab.com/madsbuvi/openmw/-/issues) for OpenXR VR, please report it to that fork's author instead of here.
If you're reporting an issue specific to an open merge request, the comments for the merge request are probably a good place to report.
Describe the issue as detailed as you can. Below is a list of questions that should be answered in the description (if they apply).
**I cannot find the revision information for my current daily build of OpenMW. I've got the openmw and openmw-daily ppa's, I've installed everything, and I'm not getting the info I need.**
- Is the problem OpenMW specific or does it also happen in vanilla Morrowind?
- **OpenMW Specific**
- What is your operating system?
- **Pop!_OS 22.04**
- What version of OpenMW are you using? If you used a bleeding edge build, state the exact revision used.
- **0.49.0, and the problem is that I can't find the current version. I can tell you with certainty that it's the most recent Daily as of March 13th, 2024 at 10:00 AM PST.**
- What version of Morrowind are you using (i.e. retail CD or Steam)? What addons (Tribunal, Bloodmoon) do you have installed? What language is your Morrowind install?
- **Irrelevant**
- Do you use any mods? If so, does the problem also occur in a clean vanilla install without any mods?
- **Yes, but probably irrelevant.**
- What are the exact steps to reproduce the problem?
- **Be on Pop!_OS, run openmw, check openmw.log.**
- What did you expect to happen? What happened instead?
- **I expected to be able to find the revision information anywhere in any of my logs or files. I did not.**
- Are there any error messages in your `openmw.log` file? If you're not an OpenMW team member, it's best to upload it.
- Error messages are irrelevant to this.
- **The is is a lack of a 'revision' line near the top of the log.**
- What settings do you use? If you're not an OpenMW team member, it's best to upload your `settings.cfg`.
- **Likely irrelevant. Yell at me if it's not.**
- Where is the in-game location this problem can be observed? Avoid vague statements such as "west of town X". Instead, open the console (`` ` `` key by default, the key above Tab), click on the problematic object, then use the betacomment (`bc`) instruction to get useful information about the object that you can copy and paste into the bugreport:
- **Irrelevant**https://gitlab.com/OpenMW/openmw/-/issues/7882Precompiled headers disable all warnings2024-03-21T16:02:01ZAnyOldName3Precompiled headers disable all warningsWe have warnings disabled for system/external headers, for obvious reasons. We have warnings enabled in OpenMW, also for obvious reasons. This is an example of a header intended for precompilation that has been generated by CMake:
```cpp...We have warnings disabled for system/external headers, for obvious reasons. We have warnings enabled in OpenMW, also for obvious reasons. This is an example of a header intended for precompilation that has been generated by CMake:
```cpp
/* generated by CMake */
#pragma system_header
#ifdef __cplusplus
#include <sol/sol.hpp>
#include <osg/State>
#include <osg/StateSet>
#include <osg/Node>
#include <osg/Drawable>
#include <osg/Camera>
#include <MyGUI_Widget.h>
#include <algorithm>
#include <filesystem>
#include <fstream>
#include <functional>
#include <memory>
#include <ostream>
#include <string>
#include <vector>
#endif // __cplusplus
```
For some reason (either a CMake bug or an MSVC bug, or both), the `#pragma system_header` directive is leaking out of the precompiled header and into every file that consumes it, which means that once you turn off precompiled headers, e.g. for your Ccache Ninja MSVC build, you get buried under a mountain of warnings that have been suppressed since mid-2022.
We need to:
* Figure out why this is happening, and hopefully address it (maybe we can just stop CMake putting the `#pragma` there) so people get yelled at when they're supposed to be.
* Deal with the existing warnings, either by fixing them, or by disabling them because we've clearly got the equivalents disabled on other platforms.https://gitlab.com/OpenMW/openmw/-/issues/7880MyGUI EXCEPTION : widget not found2024-03-28T19:04:28ZMehdi Yousfi-MonodMyGUI EXCEPTION : widget not found- What is your operating system?
Linux Debian Trixie
- What version of OpenMW are you using? If you used a bleeding edge build, state the exact revision used.
Dev build commit dce0a9e11e94b3785df9d90934b1dfcf9d5b09f2
Last MyGui dev b...- What is your operating system?
Linux Debian Trixie
- What version of OpenMW are you using? If you used a bleeding edge build, state the exact revision used.
Dev build commit dce0a9e11e94b3785df9d90934b1dfcf9d5b09f2
Last MyGui dev build 17d66baea79b415fec94412d2bb94d847f81696c
- Do you use any mods? If so, does the problem also occur in a clean vanilla install without any mods?
Expanded Vanilla + BTB Necro edit and patches + few others
- What are the exact steps to reproduce the problem?
Create a new game, go to Arrille Tradehouse, save and load.
- What did you expect to happen? What happened instead?
I get the following log (with "lua enable = true"):
```
[10:22:28.396 E] Error in DelayedAction Update UI: MyGUI EXCEPTION : widget not found
[10:22:28.396 E] in MyGUI at /home/myo/src/mygui/MyGUIEngine/src/MyGUI_Gui.cpp (line 271)
[10:22:28.396 E] Caller stack traceback:
[10:22:28.396 E] [C]: in function 'update'
[10:22:28.396 E] [string "scripts/omw/settings/menu.lua"]:355: in function 'renderPage'
[10:22:28.396 E] [string "scripts/omw/settings/menu.lua"]:468: in function 'resetPlayerGroups'
[10:22:28.396 E] [string "scripts/omw/settings/menu.lua"]:532: in function <[string "scripts/omw/settings/menu.lua"]:527>
```
Then on exit I get a crash log:
```
*** Fatal Error ***
Address not mapped to object (signal 11)
Address: 0x58
```
- Are there any error messages in your `openmw.log` file? If you're not an OpenMW team member, it's best to upload it.
[openmw.log](/uploads/45f977e404d64973b12a78eff493c70f/openmw.log)
[openmw.cfg](/uploads/1996f565f517bf592fe44e68559d0ae3/openmw.cfg)
[settings.cfg](/uploads/14df3256e94c7de44883460cce74376c/settings.cfg)
The crash log when I exit the game:
[openmw-crash.log](/uploads/8a29d17a8e2aa4e41dfa100ff1e2cdf2/openmw-crash.log)https://gitlab.com/OpenMW/openmw/-/issues/7879Lua: Region record store bindings2024-03-17T21:30:55ZJosef KleinLua: Region record store bindings**Is the problem OpenMW specific or does it also happen in vanilla Morrowind?**
This is specific to OpenMW 0.49. This issue does not occur in the stable release of OpenMW 0.48.
**What version of OpenMW are you using? If you used a ble...**Is the problem OpenMW specific or does it also happen in vanilla Morrowind?**
This is specific to OpenMW 0.49. This issue does not occur in the stable release of OpenMW 0.48.
**What version of OpenMW are you using? If you used a bleeding edge build, state the exact revision used.**
OpenMW 0.49.0, revision 61d01f3b62 (Lua API_REVISION 56)
**Do you use any mods? If so, does the problem also occur in a clean vanilla install without any mods?**
This problem occurs without any mods, just using the Morrowind.esm is enough to reproduce the issue.
**What are the exact steps to reproduce the problem?**
Travel to any exterior cell, then open the console. Enter the "lua player context" (`luap`) and then check the string returned from the command `self.cell.region`. The issue is that ~~the string is returned as all lowercase characters~~ the used ID cannot be used to determine the region's displayed name.
**What did you expect to happen? What happened instead?**
~~The string was expected to be returned as a title case string but returned as lower case (e.g. expected "Bitter Coast Region", received "bitter coast region").~~ It's expected that there should be a way to determine the region's displayed name based on the ID provided by the cell.https://gitlab.com/OpenMW/openmw/-/issues/7878RFC Do we even need a local/global openmw.cfg for a non-portable install2024-03-23T02:04:36ZAnyOldName3RFC Do we even need a local/global openmw.cfg for a non-portable install# What the local/global `openmw.cfg` does
This is the `openmw.cfg` in the same directory as the `openmw` binary (if one exists), or the one in a system-wide directory like `/etc/openmw` if there isn't one next to the binary. This `openm...# What the local/global `openmw.cfg` does
This is the `openmw.cfg` in the same directory as the `openmw` binary (if one exists), or the one in a system-wide directory like `/etc/openmw` if there isn't one next to the binary. This `openmw.cfg` can contain stuff specific to an individual OpenMW build, so needs to either be at a fixed relative path to the binary, or at a fixed absolute path and be managed by the system package manager.
By default, this file contains the following [local](https://gitlab.com/OpenMW/openmw/-/blob/master/files/openmw.cfg.local) or [global](https://gitlab.com/OpenMW/openmw/-/blob/master/files/openmw.cfg). The only difference is that for the global variant, `${OPENMW_RESOURCE_FILES}` is set by CMake, whereas for the local variant, it's just `./resources`.
This breaks down into two categories:
* A long list of entries that should be overwritten by what the INI importer gets from `Morrowind.ini`.
* A few actual settings we expect to use.
The list of `Morrowind.ini` settings are there basically so that the Example Suite doesn't have a requirement on `Morrowind.ini`. There's a decent argument to be made that these shouldn't be here and should instead come from the OpenMW Template. How that would take shape is a little unclear, just like with many things about distributing the Example Suite. A bunch of these settings are potentially going to disappear over time anyway as they're more sensible as part of a content file, but that's a discussion for elsewhere.
The remaining few settings are as follows:
```
content=builtin.omwscripts
data-local="?userdata?data"
user-data="?userdata?"
config="?userconfig?"
resources=./resources
data=./resources/vfs-mw
script-blacklist=Museum
script-blacklist=MockChangeScript
script-blacklist=doortestwarp
script-blacklist=WereChange2Script
script-blacklist=wereDreamScript2
script-blacklist=wereDreamScript3
```
### `content=builtin.omwscripts`
!3925 zaps this as it's what tells the engine to load game-independent parts of the engine, so it always needs to be loaded and should be done implicitly within the engine, just like the game-independent `resources/vfs` directory is. *Side note: currently the file isn't entirely game-independent, but there's nothing stopping `resources/vfs` containing a game-independent `builtin.omwscripts` and `resources/vfs-mw` containing a Morrowind-specific `builtin.omwscripts` if we want to go for that approach.*
### `data-local="?userdata?data"` and `user-data="?userdata?"`
I'm not sure there's a particularly good reason not to set this default value in the engine. Other settings have sensible defaults set in the engine, e.g. `encoding` and `random-seed`.
### `resources=./resources`
This is already set by default in the engine, so the config line is already redundant.
### `config="?userconfig?"`
Unlike the above settings, this is a composing entry, so if you have a value from a lower-priority source, it'd get appended to instead of replaced (like we're all used to with `data` and `content`). We've got a couple of options here:
* just have this as a default that works in the default `boost::program_options` default way, i.e. if nothing else sets it, we use the default, but if something else does set it, we only use this value. This gets a little complicated to explain in the documentation as that would mean the defaults don't just count as a lower-priority config source, and there's the ambiguous case of if the `?userconfig?openmw.cfg` has a `config` line whether it should retroactively be interpreted as meaning that we shouldn't load the config we're loading that gave us that instruction.
* for this one setting, make the default value work a little differently from how `boost::program_options` handles defaults by default, i.e. treat it like it had come from a low-priority config source, and just append any extra paths. This wouldn't break portable installs, as they could just put `replace=config` in their local `openmw.cfg` to discard the lower-priority values, which is an existing working feature we've had for ages.
I think the latter's probably pretty easy to do and it's not like our public documentation says we do exactly the default `boost::program_options` behaviour without deviation, because we already don't.
### `data=./resources/vfs-mw`
I think this line is very naughty and shouldn't be in this file whether or not we keep the rest. It enables Morrowind-specific stuff, so if we're making a multi-game engine, we don't want this to be enabled globally by a system-protected config file. In my mind, it makes more sense for the wizard to put this line in the user config file when it's setting up Morrowind. That has the obvious problem that the relative path will be wrong, but it's simple enough to add another path slug called `?resources?` that evaluates to whatever we're using as the resources directory. The one problem that leaves is users potentially removing it from their user config because they don't know what it is, but then we don't see that as a concern for the bazillion `Morrowind.ini` settings that also go into that file.
The directory's also a little bit OpenMW-version-specific, but maybe not enough to cause a problem.
### `script-blacklist=...`
I'm told this is a silly setting that we could do without, but several other team members presented slightly different ways to get rid of it, and I don't care enough to learn and reiterate the details.
# Why might we want rid of this file
The main reason is that users keep editing the wrong `openmw.cfg` file. On the face of it, this is kind of fine - as long as they're not editing a protected system file, this is something we support, and how you're meant to set up a portable install. However some users, in particular Windows users who think Windows Vista is some far off future operating system and haven't kept up with the bits of the Windows developer manual that say not to put user-editable config files in `C:\Program Files`, and, more numerously, users who've spent years using software written by people in the previous category who've had to learn to bypass any permissions hurdle they encounter automatically without even realising they've done anything, keep bypassing their OS' permissions system and editing it anyway. Also, users running dev builds don't typically run the installer, so don't end up with OpenMW in a protected system directory, and a bunch of people have published guides telling people incorrect ways to use OpenMW that include editing the wrong file.
It's kind of no big deal if users edit the wrong file, as it's a perfectly cromulent location to enable mods etc., but it can really easily lead to load order problems, e.g. if you've got `content=Morrowind.esm` in your user `openmw.cfg` and `content=somemod.esp` in your local `openmw.cfg`, then `somemod.esp` loads first, and if it depends on `Morrowind.esm`, that will just lead to an error being emitted. That's less bad than overwriting default settings in `settings-default.cfg` as it's easy to undo, but it's still a nuisance.
## 'alternatives' to getting rid of it
### Give it a different name
This did nothing to stop users insisting that `settings.cfg` and `settings-default.cfg` were the same file even after we'd explicitly told them otherwise. I think this would be pointless, and make the config system more complicated.
### Put it in a different place
The local `openmw.cfg` has to be at a fixed relative path to the OpenMW binary because it contains things specific to that OpenMW commit. Users will find the new place and then break things just like before, and then say it's our fault for moving the file they've always edited.
### Aggressively obfuscate it à la `defaults.bin`
Not viable as users with a portable install are explicitly supposed to edit the file themselves (provided they've installed OpenMW itself to a user-writable directory).
### Use the OS permissions system to stop users editing it
We already do. It doesn't stop anyone.
### Set the file as hidden (and let portable users unhide it)
* People will write guides saying to unhide it.
* Windows users who like to bypass the permissions system are disproportionately likely to have hidden folders visible.
* We can't do this for dev builds as they just get unzipped, so we can't use fancy file attributes.
### Just stop telling users to install your mod by editing their config files and suggest they use the launcher - people who know they can edit their config file instead should already know which file to edit
I think this would definitely dent the problem, but probably wouldn't solve it. Also, the launcher's not entirely great for this UX-wise.
### Make the installer let users pick between a system-wide and portable install, and explain which config paths they'll need to edit with each option
If we explicitly support users editing the config file they gravitate towards, but only in a particular mode, it'd obviously cause fewer problems if they're already using that mode. This will do nothing for the users who refuse to read anything other than stab at the *Next* or *OK* button.
# Why might we want to keep this file
## We intend third-party games that use OpenMW to not need to recompile the engine if they're not meddling with its guts
I can't think of anything such a game would want to put in the local/global `openmw.cfg`, so I don't think we need to worry about this. I've not thought too hard about it, so could be wrong.
## We want it to be easy to set up a portable install, and having the file already there to make a small edit to is pretty easy
It'd be even easier if we provided separate portable and system-wide packages, or an installer that did both and let you pick at install time. If we're ditching loads of stuff anyway, the magic `openmw.cfg` a user would need to create to turn an install portable would only be four lines long anyway, so hardly a monumental task to create.
## It's how we've always done things, and there must have been a good reason at the start for the file to exist
This is a fair comment, but the config system's evolved quite a lot in the last decade, so the current file isn't really doing what its original incarnation did. It used to just be
```
data=./data
resources=./resources
```
and we've got rid of the random `data` directory in the install path years ago, and the engine already sets that resources directory by default if it's not in any `openmw.cfg`.https://gitlab.com/OpenMW/openmw/-/issues/7875Disable MyGUI windows snapping2024-03-13T19:24:33ZAndrei KortunovDisable MyGUI windows snappingMyGUI has a widgets snapping feature (disabled by default, enabled in OpenMW for some reason). When enabled, it moves MyGUI widget to parent window's border if distance between window border and widget border is 10 pixels or less. This t...MyGUI has a widgets snapping feature (disabled by default, enabled in OpenMW for some reason). When enabled, it moves MyGUI widget to parent window's border if distance between window border and widget border is 10 pixels or less. This threshold does not depend on screen resolution and it does not respect GUI scaling. As a result, it does not allow to have small margins between widget and parent window (useful for console and inventory windows).
I suggest to disable it and use a default MyGUI (and Morrowind one, by the way) behaviour.
A simplest way to reproduce this issue is to use these settings with the 1920x1080 resolution:
```
[Windows]
console x = 0.01
console y = 0.01
```
With this resolution `0.01` is 10 pixels for height (so it is treated as 0), but it is 19 pixels for width, so there is a gap only from left side:
![image](/uploads/2fd0ece192503d2b033e3728db85d757/image.png)Andrei KortunovAndrei Kortunov