MWEdit

[Spastic Hamburger]

Looks like MinGW supports them in resource files. Not sure about standalone ones but referencing them in the resource file with

#include "winuser.h" // required for RT_MANIFEST constant
CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "application.manifest"

should be fine. Not sure which method I prefer but it looks like it’ll work regardless for cross-compiling. Not sure if we’ll want anything else in the manifest. Maybe the runtime version since we’re using the newest? On Linux, that’s handled by the package manager settings file

Still need to research InitCommonControlsEx(const INITCOMMONCONTROLSEX *picce) and figure out how that works

• This reply was modified 1 month, 3 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 3 weeks ago by Spastic Hamburger.

[DeVaultSetter]

Sounds good. 🙂
In the debug builds I would tend to ditch WIN32_LEAN_AND_MEAN in favour of stdafx.h until other issues are sorted, WIN32_LEAN_AND_MEAN can knock out other things if they are tweaked or decoupled. Your call.
In ScrollCall there’s:

    static const INITCOMMONCONTROLSEX commonCtrls =
    {
    sizeof(INITCOMMONCONTROLSEX),
    ICC_STANDARD_CLASSES | ICC_BAR_CLASSES
    };

    InitCommonControlsEx(&commonCtrls);

HTH 🙂

[Spastic Hamburger]

Unfortunately, without that flag, it exposed a known bug in the Windows API where it tries to use WinSock 1 even though it’s unneeded where MFC needs version 2 and refused to build. Release had no issues so it’s something on Microsoft’s end with the _DEBUG flag and disabling everything extra and manually adding only the stuff we use was the only way to fix it (I hope, we’ll find out once I finish adding the headers and try to build it). Here are the details. It’s a bit of a mess. If it gets too frustrating, I may fast track ripping out the Windows API but I hope to do that later once the code quality has improved more.

Where do we need to call InitCommonControlsEx?

Thanks, I’ll work on getting together the control categories in use 🙂

• This reply was modified 1 month, 3 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 3 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 3 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 3 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 3 weeks ago by Spastic Hamburger.

[DeVaultSetter]

See what you mean, using #include <windows.h> automatically includes winsock.h so our marvellous AI suggests:

#include <winsock2.h>
#include <windows.h>

AFAIKS there are six instances where this wants to be changed.
Put it where, for example, a file is to be opened so you get the file name – here’s the function. 🙂

Edit: No _WIN32 directive for xml_file.cc. Apparently MWEdit and native Morrowind don’t use xml, OpenMW does … interesting.
WindowsHModular is an experimental alternative to windows.h – might be best to use that for project creation rather than restoration. 😛

• This reply was modified 1 month, 3 weeks ago by DeVaultSetter.
• This reply was modified 1 month, 3 weeks ago by DeVaultSetter.

[Spastic Hamburger]

Yeah, I’m not sure what the XML parser is for at the moment. Even in the other projects, I didn’t see anything that used it. From what I could tell, CSV was the only file parser that was used in the extra file support but I haven’t finished going through all of the code in detail yet (I’m currently on the undo stack support).

What does OpenMW use XML for? I must have missed that

Made some compatibility changes:
I swapped out a non-portable standard library extension with functions in the standard library:

if (!(/*__iscsym(pUndo->GetChar())*/std::isalnum(pUndo->GetChar()) || (pUndo->GetChar() == '_'))) {
	break;
}

The commented function is what was there before. It was an extension to cctype so I removed it in favor of the combination that exists on all platforms. Minor change but I figured, “Why the hell not? I’m adding the include anyways”. 🙂

Thanks. Will make a note of adding the control style commands 🙂

I haven’t been including windows.h so we’ll see what happens with the Windows integer types (MSDN didn’t specify that I had to include that file for their type-defs). Was never a fan of how Microsoft made things more complicated than needed but we’ll get it sorted out. 🙂

• This reply was modified 1 month, 3 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 3 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 3 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 3 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 3 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 3 weeks ago by Spastic Hamburger.

[Spastic Hamburger]

Ugh…those includes in common may be an issue. I’m trying to avoid using WinSock entirely as MWEdit doesn’t use any kind of network code and that would cause unneeded bloat. Can be added if needed, though, if things can’t be whittled down enough.

Unless I’m mistaken, shouldn’t WinSock 2 be used after the basic Windows header so it overrides the old version? Of course, as we know, most OS-specific code is arcane to me as I rarely work on code that needs to interface directly with the underlying system.

Common will be rewritten eventually. The large integer union looks like an artifact from the days where 64-bit numbers were a novelty and can probably be replaced with std::uint64_t or std::int64_t. As for the other stuff, that’ll need some additional investigation.

Trying to get the Windows code working properly is beginning to get a little discouraging. 🙁

Edit:

Just opened a task item to fix the loss of precision in the UI code. We have stuff like this:
pEnchantData->MagMax = (short)(std::atoi(Buffer));
Here’s the struct for it:

typedef struct {
	short EffectID;
	byte SkillID;
	byte AttributeID;
	long RangeType;
	long Area;
	long Duration;
	long MagMin;
	long MagMax;
} enchanteffect_t;

Essentially, it’s converting the string first to a 32-bit integer, then casting it as a 16-bit integer, and finally storing it in a 64-bit integer. This sort of thing occurs frequently in the code. That could cause some issues. Ideally, we’d convert the string directly to the correct type so that all data is properly preserved. We’ll want to investigate things to determine the correct integer types and change the code accordingly.

• This reply was modified 1 month, 3 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 3 weeks ago by Spastic Hamburger.

[DeVaultSetter]

This should make sense of it, or as someone suggested put #define _WINSOCKAPI_ in stdafx.h, or pch.h if using it. Out of interest, Unreal engine uses MinWindows.h. 🙂
Yep, atol might do it, and then convert it to either of these. Or bitshift?

[Spastic Hamburger]

Thanks! Will try that if adding just what we need doesn’t do the trick 🙂

There are also some comments suggesting that the long types may in fact be intended as short integers so we’ll definitely want to do an investigation to determine what they should be. Yep, std::atol would do the trick for 64-bit integers. There’s no corresponding function for 16-bit integers so we may want to see if we can set the control to a limiter if we do in fact need 16-bit integers after the investigation just to make sure we don’t get an integer overflow or out of range bug. The other option would be to first convert them to a 32-bit integer and then check to see if they are out of range for a 16-bit one. If so, we set it to the max or min allowed for the type. The limiter would be cleaner in that case, though.

Edit:

snprintf() in common/dl_str.h is almost identical to std::snprintf() in cstdio save for the fact that the former uses TCHAR * instead of char *. We may be able to swap it out for swprintf() in cwchar without issue since TCHAR is just a type-def for wchar_t. Other changes may be doable as well but that is a 1-for-1 swap down the road.

Edit 2:

Also found this doc which could be useful: https://learn.microsoft.com/en-us/windows/win32/winprog/windows-data-types

Will start adding the headers for those types as I go and will go back through later and add it to the ones I missed at some point. It’s a shame a lot of this information is hard to track down.

• This reply was modified 1 month, 3 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 3 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 3 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 3 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 3 weeks ago by Spastic Hamburger.

[Spastic Hamburger]

Messed up the include order for several files. I’ll fix it when I go back through to add the correct headers for the Windows macros.

All of this is necessary work even if it’s tedious and not at all exciting

Still need to get an issue open regarding visual styles. Shouldn’t be hard to implement and it’ll be a nice upgrade until we switch GUI toolkits. Just been buried under tracking down all of these symbols

Haven’t given much thought to TES3Gecko either for similar reasons (or even browsed the TES4Gecko code) but were still a long ways off from even having MWEdit ready for that sort of thing

• This reply was modified 1 month, 3 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 3 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 3 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 3 weeks ago by Spastic Hamburger.

[DeVaultSetter]

adding the headers for those types

The dilemma of having one Header file for all types, or having the types all over the place. For example Igor the 7-zip guy had them all in one file, a file that was pulled in by most of the other headers.

[Spastic Hamburger]

The Windows API has most of its type-defs and macros in three main files: windef.h, winnt.h, and winuser.h. It’s mostly a matter of searching that list for those specific ones and adding the correct header(s). 🙂 The other symbols (the classes and structs) require more work to track down, partly because search engines have gotten so bad that they can’t understand what you’re looking for anymore.

Edit:

I just attached the diff between 0.6.3 and 0.7.0 so that we don’t lose sight of the crash that was introduced as the code is overhauled and so that others can share insight.

Edit 2:

Just added an item to the tracker for the visual style support. Feel free to add to it! 🙂

Edit 3:

Went ahead and reached out regarding TES3Gecko. Now to get back to fixing up the includes.

Edit 4:

ui/journal_dlg.cc is missing:

void GetFuncData(const int Index, int &FuncIndex);
void SetFuncData(const int Index, CEsmSubSCVR *pFuncData, CEsmSubRecord *pValue);

It’s unclear whether or not these were meant to be defined in the source or if they were included in the header by mistake. If the latter, they can be removed. If the former, we’ll want to implement them. The only comment for them is for the two functions above them that get and set the control data, which are implemented in the source.

• This reply was modified 1 month, 2 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 2 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 2 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 2 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 2 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 2 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 2 weeks ago by Spastic Hamburger.

[DeVaultSetter]

We may need it, it may be along the lines of this. Not quite sure how all this works yet. 🙁
This file uses CEsmInfo, all referenced here, as a matter of interest func_help_view... does not, referencing CEsmScrFunc and CEsmScrFunc…, running this in a live build with the game might shed more light on what it actually does. 🙂

• This reply was modified 1 month, 2 weeks ago by DeVaultSetter.

[Spastic Hamburger]

Figured it out, to some degree. The journal dialog is supposed to set up the quest sub-records (QSTN, QSTF, and QSTR) with the INFO record. It’s possible the script stuff is meant to link it up but those are only in the parent INFO so I’m not entirely sure. We’ll definitely need to review the community documentation on the file format (and I’ll need re-learn a lot of stuff). A good starting place is the UESP’s page on it but it’s pretty short on details so we’ll want to hunt down some of the other community documentation. There are similar pages for the other games and we’ll want to hunt down reference sheets for Fallout and Starfield at some point.

Also, we’ll want to add a lot of explanation to the file comments to help folks understand what each file, class, function, etc are for. The code lacks good documentation so that’s something we’ll definitely want to work on. I’ll get an item on the tracker for it!

And on the tracker 🙂

Edit:

Turns out the documentation task was already there and I just didn’t see it. Closed the new one and marked it as a duplicate 😛

Edit 2:

Not a whole lot shows up in search results so I’ll ask the Morrowind community and OpenMW folks for links to references when I get the opportunity. It doesn’t hurt to start getting other puzzle pieces together even if they won’t be used for a while 🙂

• This reply was modified 1 month, 2 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 2 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 2 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 2 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 2 weeks ago by Spastic Hamburger.

[DeVaultSetter]

Another thing is the Get/SetFuncData pulls up all the script variables, SCVR also enumerated here.
One supposes journal records can be referenced in scripts, if not, it’s less to worry about.
What’s clear as a pea soup fog is why SCVR is used only in info_dlg and not in any other UI modules – even the scr_... ones. Dave has explained much of it rather well in the Format of Morrowind’s ESM Plug-In File found on the UESP Portuguese Mod Format page. A curious recurrent logged error can be generated from some mods:

Found malformed SCVR rule in INFO “some_alpha-numeric_id”

Rule?
Bleh, something happened on the DIAL page- might be a thing for Robin later.
Do have a soft spot for the old UESP format. 🙂

[Spastic Hamburger]

The scr files are related to the script compiler. Like I said, poorly documented. 😛

At some point, I may look into replacing the parser with something like flex or bison. Not sure if it’s possible, though, as I’ve never used them before

Good catch on the text file reference. Will need to add the link somewhere for reference

0.6.3 should be usable for playing with. As we know, 0.7.0 is currently broken due to Windows API changes but the last version before the overhaul started should work.

Edit:

I’ve updated some information in a couple tracker items and closed the item for the directory structure. I forgot to do the latter when I finished it a month ago. I still haven’t gotten the hang of using an issue tracker. 😛

• This reply was modified 1 month, 2 weeks ago by Spastic Hamburger.

[Spastic Hamburger]

Doesn’t look like there’s a community resource for the file formats for Fallout and Starfield. May add the resource to the to-do list at some point as it’s something that the community is sorely lacking. We need a place to describe the processes and such so that we know what all is going on and don’t rely on a singly tool as gatekeeper. We went through this when Skyrim launched initially and it was a disaster.

In any case, it was suggested that we poke through the xEdit source code for file format information. Not ideal but it seems to be what’s available. I’ll poke the Edit devs at some point and ask them for more details. Still haven’t decided how to handle the multiple game support in what I’m currently calling ESEdit, though. There are several ways of doing it so we’ll want to discuss it as we get closer to having things ready for that (we’re still a long ways off) 🙂

Edit:

CAboutDlg needs to be split out into its own header and source as it’s currently buried in ui/mwedit.h. Will do that at some point.

• This reply was modified 1 month, 2 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 2 weeks ago by Spastic Hamburger.

[Spastic Hamburger]

Going through some old stuff and re-discovered Ortham’s (previously known as WrinklyNinja, name changed while I was away from the overall community) list of links: https://blog.ortham.net/buddah/
A lot of the tools on it are old and haven’t been updated in a decade but there may still be some useful stuff we can use for reference. Specifically, the BSA stuff as I haven’t found a good reference for the BSA format outside of UESP (Fallout and Starfield have alluded me so far).

My preference is not to lean too heavily on existing code for reference, however. That risks us using the same algorithms when we could do things differently to get the same result. Personally, I’d prefer a breakdown of the actual formats and processes so I’ll keep investigating.

• This reply was modified 1 month, 1 week ago by Spastic Hamburger.
• This reply was modified 1 month, 1 week ago by Spastic Hamburger.

[Spastic Hamburger]

I updated some tracker items with additional information regarding Unicode

Still working on getting the debug build fixed up.

[Spastic Hamburger]

Had to back out some of the compatibility changes regarding iscsym(). The function is supposed to take an integer/character but is being passed a character array instead. A few other uses just checked a single character so I left those in place. I’ve added notes in the code to investigate further to see what’s going on. There’s a good chance something will break with these functions so I can back the changes out if needed. The single character changes look good but we’ll find out. We can probably fix it by just checking the character the code comments say is being checked. I’ll leave that for another commit, though, so I don’t clutter the include commit too much. I’ve already got enough unrelated changes in it as it is.

The code also checks a single character using the pointer version. Pointers always confused me so here’s that line:
if (!iscsym(*pID) && !(*pID == ' ')) {
pID is defined as const TCHAR *pID. So *pID is an array of the array, if I’m reading that correctly?

Still becoming reacquainted with these things. Coming along, though.

For reference, they show up in ui/edit_undo.cc, ui/script_dlg.cc, and ui/utils.cc

• This reply was modified 1 month ago by Spastic Hamburger.
• This reply was modified 1 month ago by Spastic Hamburger.
• This reply was modified 1 month ago by Spastic Hamburger.
• This reply was modified 1 month ago by Spastic Hamburger.
• This reply was modified 1 month ago by Spastic Hamburger.

[Spastic Hamburger]

Another note: the book UI is incomplete as it doesn’t set the book data. The Book class holds book data but nowhere in the code-base is the bookdata_t struct actually used. Looks like it’s an incomplete feature. We’ll probably want a separate tracker item to keep up with this stuff.

New tracker item: https://github.com/Walrus-Tech/MWEdit/issues/46

Feel free to add things to it as you come across them!

• This reply was modified 1 month ago by Spastic Hamburger.
• This reply was modified 1 month ago by Spastic Hamburger.

[Author]

Posts