In that case, I’ll get started on the file names. There are about 300 – 400 code files in the project so this will be a bit….painful without doing it via a script (don’t know enough about Bash scripting and some may need to remain the same) 😛
We do have GDB over here and there’s a MinGW version as well to let me debug Windows binaries but that will require compatibility with MinGW. As we know, the code still requires VS to build due to the code generation, which is rather annoying.
As far as IDEs go, there aren’t a lot of them that are based on GTK that I like (currently use Geany which is a lightweight and minimal hybrid of text-editor and IDE) but I’ll take another look at the package repository after the OS upgrade 🙂
Never really been a fan of Qt. Not sure if it’s changed but, in the past, it was bloated and had a variety of performance problems compared to GTK. One of these days, I should probably give KDE another try to see if things have improved since then
At some point, an IDE may become necessary to do some of the overhauling that will be a pain to do by hand, such as changing up symbol names, so I’ve been periodically looking for one. I try to stick with the official repositories to minimize the change that something will break
Cool, GDB looks like it could be useful. Just curious, can the build be performed successfully through VSCode?
Really not sure. Looks like VS Code leverages the system’s compiler via settings so it would depend on whether or not it handles the code generation as well. Based on it being a trimmed down VS, I would assume not but could be worth a try. Not in the repos over here (it was in one of the distros I used, not sure which one (never mind, it was listed under code instead of vs-code or some such so it is in the repos)) but may be worth grabbing the official DEB at some point to give it another test run after the OS upgrade. It looks like it uses GTK3 (at least, the maintainer of the AUR version are building it with GTK3 support) so it does mean no Qt. I do seem to recall that it was using Electron at one point but don’t see it listed under the AUR entry for some reason. Not a big fan of Electron as I always felt it was slow. Not sure if it’s still using it, though.
It does look like it has some handy features, though. I’ve been using text-editors for so long (I used Notepad initially) that I’m not used to using IDEs 😛
Sorry, I don’t mean to sound so resistant to these suggestions 🙂
Also, looks like EsmBase.cpp and EsmDefs.h were meant to go together so I’ll rename them as such. Should we use defs or base as the grouping name?
I’m also changing all files to lower case and replacing the cpp extension with cc as that’s become the more common standard used 🙂
At some point, we’ll want to comb through this thread and make sure everything is on the tracker that needs to be to help us keep up with what needs doing. I know I haven’t been very good about keeping them in sync.
For now, I went with defs.h and defs.cc but can change it later. All files in the old esm/ directory have been overhauled and pushed up. Will update the paths at the end just in case there wind up being additional changes (it’ll also help keep the commit log tidy) 🙂
Here’s the full commit message:
File changes:
- Remove <code>Esm</code> prefix
- Change file names to lower case
- Change source file extensions to <code>.cc</code> to be more in line with current practices
- Fix some spelling errors in file names
- Move miscellaneous files to new <code>mwedit/</code> directory
🙂
Fixed up a few more file names in game/morrowind/ and moved a cursor file from project/res/ to data/. Not sure why it wasn’t in the old project/res/ directory and was living in project/ but that’s been fixed. I’ll probably start on the other directories next week. Taking a break to browse through Atlas Obscura 🙂
Not the fastest job to do with how mind numbing it is but it’s coming along 🙂
It’d be easier if I could just rename the file in the file manager and have Git recognize it 😛
Okay, the files in common/, file/, and windows/ have all been renamed according to the new naming convention. Next is to wrangle the new ui/ folder, renaming the files and determining which ones belong in the mwedit/ directory before fixing up all of the paths (that will be even more painful 😛 ). All of those renames have been pushed up 🙂
In the file/ directory, there’s some extra code for Autodesk’s other programs besides 3DS Max that we may want to keep around if it’s not currently being used just in case we add some extra features. Not entirely sure, though, as CDxfFile isn’t used anywhere currently and is for AutoCAD, which may have limited use in a program for modding a game.
PCX support can be removed: it’s not used in the code and is for an old, obsolete, and defunct DOS image editor.
The BmpFile class isn’t used either nor is the 3DS support code.
In fact, most of the code that’s not the CSV support is unused. Which is weird. I suspect a lot of this support code is left over from features not yet implemented so we’ll want to give things a good review before we yank it out. I’m leaning towards removing the obsolete file formats and those we know aren’t used in the workflow for now, leaving the rest until we’ve made a decision further along in development. I’ve asked the AFK graphics folks to chime in on which graphics files are used in the workflow in Beth’s games to help with this task 🙂
Edit:
Once I get more information from the digital graphics folks, I’ll add it to the unused files ticket so we can keep track of things
The XML code can likely be replaced with something like expat or libxml, including one of their bindings, assuming it’s even used, which I’m currently unsure of
Okay, looks like the bitmap code isn’t used in the workflow so I’ll tag it for removal with PCX support. For bitmap icons, the code uses CBitmap in the Windows API instead, which will be replaced with whatever the new GUI toolkit uses.
Updated the tracker 🙂
Okay, started on the ui/ directory this morning and reached the dialogue boxes that go with the game files so I need to remove the prefix from them as well
Yep, I’m slow these days but at least I’m getting back into it after almost a decade 🙂
There are two sets of CreaturePage files in ui/: those with the Esm prefix and those without. The ones without don’t appear to have their classes used in the project but the files are included in the ones with the prefix. Both make heavy use of the MFC code generation stuff so it’s a little hard to tell if the ones without the prefix are actually being used in the project. For now, I won’t rename the ones with the prefix but we’ll definitely want to sort this out at some point as it’s really confusing.
For example:
CCreaturePage1 defines a new dialogue property, IDD_CREATURE1_VIEW, which is then mapped to number 137 in ui/Resource.h. This property isn’t used elsewhere and the class doesn’t define any other properties. Also, the file uses a weird header guard compared to the file with the prefix so it appears to have been redone but not removed at some point in the past and then included in the new file for whatever reason. Based on this reasoning, it sounds like it may be safe to tag these redundancies for removal? We’ll want to make a not of the stuff they add to the resource files as well if that’s the case so that we can make sure we catch everything. We’ll want to clean up the resource files anyways at some point so that they’re more manageable. The source files are also pretty much empty so I think we can safely tag them for removal
Sounds good. I’ll go ahead and tag both of the older files for the dialogue and remove them from the build script. 🙂
That’s bound to fix a bug or two!
Okay, old CreaturePage files have been removed from the repository and their properties have been removed from ui/Resource.h locally so they’ll be in the next push. I also confirmed that the new creature page views were being used in the project before I removed the old ones just to be thorough:
ui/EsmCreatureDlg.cpp: m_Page1.Create(IDD_CREATURE_VIEW1, &m_MainTab);
So the old ones were never set up to be used as windows anyways.
And the basic overhaul of the directory structure has been pushed up. Next step is to update the paths 🙂
Wasn’t sure where to put ui/mwedit.h as it both defines the main view and sets up the main function entry point so I left it in ui/ for now. It may be moved to mwedit/ at some point down the road.
The 3DS Max code may be related to this tool: https://github.com/uesp/mwnifto3ds
Some of Dave’s other tools may be worth merging in at some point in the future but we may want to use updated libraries for some of them to take advantage of newer developments. I do have an end-game in mind but we’ll definitely want to keep feature creep in mind. More on my ultimate goals later 🙂
CMake paths have been updated, Wasn’t painful, I just used ls -1Q <directory>/*.cc to list everything in quotes with the path prefix. 🙂
And more information on the color static files: we want to use the one in windows/ as that one is more complete. I’ve already removed the other two files from the CMake script so they’ll be in the next upload and will update the includes to use the correct one as I go through.
Slowly, but surely, the code base is shaping up and becoming easier to manage 🙂
And I’ve attempted to update the paths in the resource files. I had trouble with that previously so there’s a good chance that they’ll need to updated yet again once the CI spits out an error. The resource compiler seems to have a limited ability to do includes while MWEdit uses the pre-processor in them extensively. But, as we already know, the resource files on the list for clean up 🙂
The attempt will also be in the next upload 🙂
Making good progress. The only directories left to update the paths are game/, mwedit/, ui/, and windows/ 🙂
Then I can go back to what I was doing before I got sidetracked and continuing adjusting the missing includes.
Edit:
As long as we’re using CPack and dynamic builds, we may want use this module: https://cmake.org/cmake/help/latest/module/InstallRequiredSystemLibraries.html
Essentially, it’ll ensure that the language runtime is included in the installer that the code links against to make sure that things work. And it makes sure MFC is included as that’s an optional package.
Of course, we may decide to remove it down the road but, initially, it probably doesn’t hurt to use it until we’re more comfortable with the setup 🙂
It sounds like it may fail on the free version of Visual Studio so it’s something to keep in mind
And game/morrowind/ has been taken care of 🙂
Sounds good. 🙂
Just installed VS2026 along with the Linux and embedded development with C++ component, will be interesting – give me a bit.
Sounds good 🙂
Edit:
mwedit/ is now done. Just need to tackle ui/ and windows/ now.
