MWEdit

[Spastic Hamburger]

Not really. Ideally, that kind of thing needs a native environment or you could get weird results.

I’m not really seeing much in the commit log. Even the changes necessary to the Windows API and for C++20 compliance look relatively benign so I’m not sure why it works in 0.6.3 but not in 0.7.0. Right now, the best I can say is that the ongoing overhaul should fix it as that will pretty much rewrite most of the internals and replace the GUI.

Haven’t thought about it too much, been busy with other tasks. We could simply replace the list with a standard open file dialogue box that other programs use. If we want to keep it, we’ll definitely want to fix it to actually search in the path specified by the settings window (why it was written otherwise is beyond me). That could be fixed by simply passing the path variable to it, will check on that. There’s also a third, more complex option: implement project workspaces where each workspace saves a list of plugins to filter out based on configuration. Many new land projects have a set grouping they work with, for instance.

[DeVaultSetter]

In most cases (for me at least) 0xc0000005 emitted by the VS debugger gives a pretty good indication of the source in the code of the invalid memory write. YMMV. 🙂
Yeah it’s a funny one, pathing back then was limited by issues such as 8.3 filenames and the like, so I think Dave was motivated by dealing with the “root” path for Morrowind, and not worrying about anything else. Fortunately, things have moved on since then. 🙂
Sounds an interesting range of options. 🙂

[Spastic Hamburger]

Looks like we can turn on experimental Unicode support by just setting up the _UNICODE and UNICODE macros in CMake and replacing the DevIL libraries with the Unicode versions. The code already has checks for those to use the wide-character version of TCHAR (it may be done in the Windows API already but I haven’t gotten there yet) if the macros are present. Will add it to test list at some point.

At the basic level, we could have config files that simply list the files associated with a project and then have a separate list-view for each. Wouldn’t be hard to implement for someone more familiar with GUI programming. After the windows are set up, you’d simply populate them with a loop, going until you reach EOF.

Working on more cleanup tasks now. Adding missing includes and splitting up headers into headers and source files. We’ll need to look at replacing NULL with nullptr and nullptr_t once we learn the differences.
A bit slow-going due to the nature of hunting down all of the include nesting. Worth it, though. When it’s done, we’ll be able to see at a glance where all of the symbols are coming from, making things easier to work with.

Putting the loading troubles on the back-burner for now as I can’t see anything in my changes that would have caused the problems (I even did a deep dive into the project files (both the old VS project files and the vcxproj files) and didn’t see anything that I missed), unless it has to do with the DevIL changes. Which is quite possible as we may be using an incompatible version and I never did hear back from NimrodPSI or rfuzzo about their changes after we got the initial permissions to edit their code.

[Spastic Hamburger]

Almost got the includes sorted out for the Containers library in common. We’ll definitely want to review the directory structure at some point. We can do that now or later, doesn’t really matter when. If we do it later, though, that’ll mean I’ll need to adjust some include paths again. Will already need to do that anyways since I had to add the directories to them when I was setting up the build script

Regarding the containers library, I’d like to remove it in favor of the containers in the standard but we’ll need to see how they compare first.

Additionally, I’m adding some notes about other tasks that need doing, such as namespacing stuff that replaces things in the standard library and swapping out the byte typedef for std::byte

And here’s the full diff of stuff that changed between 0.6.3 and 0.7.0 if you want to take a look and see if anything stands out.

[DeVaultSetter]

Sounds good. The compare list for the changes is really neat – tried reversing the order for newest first – it’s up to date. 😛
Ok, asked about options – no – really helpful over there btw. 🙂
The two-dot compare is massive with overflow on display limits no doubt.

[Spastic Hamburger]

Most of those are readability changes: a lot of unneeded comments were removed as they were just clutter, for instance. There are some functional changes but the trick is to determine what in the diff broke things. Maybe you’ll see something that I missed 🙂

How does the two-dot version differ? To me, things look the same. 😛

Think I’m done with the Common container library but I want to give it another look before I commit it in case I missed something. I’m also tempted to enable dev builds just to help with testing, CI limits be damned

Once that’s done, I may open a new issue for the directory layout so that we can start figuring out what to do with it 🙂

[Spastic Hamburger]

Okay, the container directory has had its includes fixed so it’ll be in the next push. I’ll open a directory layout thread soon

[Spastic Hamburger]

Okay, got that commit pushed up. Just realized that I need to fix the order of the files in the CMake script but I’ll do that later on as I continue.

And got the issue up for the directory layout: https://github.com/Walrus-Tech/MWEdit/issues/40

Let me know if I missed any important points!

[DeVaultSetter]

Good ideas, definitely in terms of a user running a portable MWEdit, if it is ever to be offered. There’s also MO2 which uses a virtual system, Wrye Bash has a fairly straight-forward looking directory structure.
What is the purpose of the files with the esm prefix I wonder?

[Spastic Hamburger]

The directory structure changes would be for the code repository to make working with the source files easier. As it is, things are mostly lumped together. The icons are buried under the generic project directory instead of having their own directory, the old build files were dumped in with the source files and hard to find, etc. NimrodPSI did do some organizing but we may be able to take it a step further to make it even easier to locate stuff.

No idea why everything is prefixed with Esm but the esm/ directory is for the binary file format, while the project/ directory is assorted stuff, mostly the GUI shell but with some algorithm processing mixed in, such as the script editor. As we know, Common/ is a lot of reimplementation of standard features, some of which didn’t exist at the time of original creations and others which are just “there”.

Yep, a portable option would be nice. Will create an issue later but part of it may require a better installer and changing the settings from the registry to config files instead (necessary anyways to support other operating systems)

[DeVaultSetter]

Oh right, a massive job then. Another thing will be the git repo – all the old folders will still appear in the code section – one way around it is to create a branch with the new structure and then make that master.
Get it now, why do they all have to be prefixed esm if already in an ESM directory? As a matter of interest the mvccommon header and cpp which retrieve the game installation paths are in there as well. A practical workaround would be to assign that kind of info to a class property in a class module. VB also had .cls file extensions which helped navigation greatly. 🙂

[Spastic Hamburger]

git mv renames files and directories and git rm removes them from the repo. Once stuff is removed from Git, or renamed, it no longer shows up in the current state, just the historical state. 🙂

Yeah, it’s a bit of a mess. There are macro constants littered everywhere, including some duplicates, instead of being in a single place. That’s also on the list to take care of to make it easier to find everything.

I also want to set up a better way to handle versions but I keep second guessing myself. Here’s what I’ve been thinking: set it up so that we store the version numbers in variables in the GitHub Actions configuration, which are then passed to CMake. In the CMake script, we’d check to see if the variables are set and, if not, set them to 0. Then we run configure_file on a config.h.in file, setting up the variables for the headers and source files. Additionally, we do it for the resource files as well. If possible, we’d pass the variables to the file name for the archive upload to set up its final name. In this way, we could do version numbers all with a single edit.

Yep, the classes and such could use some work. That’s a future project since there’s quite a bit of stuff that needs to be done first.

There are also a few files with spelling errors and the general naming conventions aren’t followed in some cases so all of those should probably be corrected as well. I’m leaning towards having subdirectories in the esm/ directory (or whatever it winds up being called) for game specific stuff for when we finally bring in Dave’s other repos for other games, with the root being for common parameters. Of course, it may change down the road if I can resurrect my system of using config files to describe the file formats. That’s far future, however. Additionally, I’m leaning towards renaming the esm/ directory to game/ to represent the fact that it’s for game format support. How does that sound?

[Spastic Hamburger]

Now that Thanksgiving is over, I’m going to start reviewing the linked directory layouts and get going on some organizing over the next few days. Or try to anyways. We’ll see what kind of progress I make 😛

[Spastic Hamburger]

Okay, I’ve updated the linked issue with the current plan of action. If it looks satisfactory, I’ll start implementing the new layout after I give the linked projects another look-see. Once I start, all builds will be broken for a few weeks until all of the paths are updated 🙂

[DeVaultSetter]

Sounds good. 🙂
Couldn’t resist posting a link onto yet another helpful tool, Sourcebot – could it be this is the one that can magically cure all the ailments of MWEdit?

[Spastic Hamburger]

In that case, I’ll go ahead and start breaking things!

I’m not sure how much help an AI search tool will be in this case as it compiles fine but doesn’t run properly. Unless it can also test it in a Windows instance, it probably needs human analysis.

Another thought just occurred to me: could you run the broken version of MWEdit from the command-line and then make it crash? I want to see if it spits out any error messages to standard-output instead of a log file.

Also, could you check the file properties of the DLLs that were bundled with 0.6.x to see if they contain the version information? That’s something that I am unable to extract on my end.

Edit:

Okay, just made an announcement in the relevant threads 🙂

[DeVaultSetter]

Yeah, there was hope one of the openai-compatible AI providers could provide a cogent answer to questions like “what have the goblins and their durzogs done to our code formatting?” Not all of their chats are working out at present. 😛

Out of luck there, this thread mentions AllocConsole, perhaps try that? Then use CLPs like —console or —headless for output.

Did try these in the PS console for empty output:

& "C:\Program Files\MWEdit 0.6.3\mwedit.exe" | Out-Host
cd \ ; cd "C:\Program Files\MWEdit 0.6.3" ; .\mwedit.exe > ~\Desktop\gui_output.txt 2>&1
cd \ ; cd "C:\Program Files\MWEdit 0.6.3" ; .\mwedit.exe 2>&1 | ForEach-Object { $_ | Out-String }
Start-Process "C:\Program Files\MWEdit 0.6.3\mwedit.exe" -RedirectStandardOutput ~\Desktop\gui_output.txt

Yep, the three DLLs have the same version, “1.8.0.0” with the Product version “1.8.0 Ansi.”

[Spastic Hamburger]

Yeah, we’ll probably want to improve the error logging. MWEdit has two main forms of error logging: a custom assert function and then the error handler. One is supposed to output to the log file while the other sends it to standard out but neither one is fully implemented. In fact, the error logging was already commented out in several places and nonexistent in others. Something we’ll want to look into at some point.

Ugh. Okay, so the best we can hope for at the moment, I guess, is that the cause will materialize as we clean things up. It’s also possible it’s an edge case that only materialized due to updating the compiler version in use and will be fixed as we continue to update the code to modern standards.

[Spastic Hamburger]

The skeleton for the new directory structure has been created on my end. I’ll get it pushed up after I move the resource files to the new build directory. That leaves fixing the file names, the paths, and figuring out what belongs in the new mwedit directory, along with updating the CI and build scripts for the new paths

Edit:

Okay, that’s been pushed up to the dev branch 🙂 GitHub shows nested directories in a weird way. The name isn’t build/windows, for instance. That’s just how GitHub displays it when there isn’t anything alongside the subdirectory. I’ll get started on the other tasks tomorrow if all looks good 🙂

[DeVaultSetter]

Sounds good. 🙂
Btw have you located a handy IDE/debugger yet? Windows Server allows for both VSCode and Windbg – for the current issue VSCode should be enough.

[Author]

Posts