From the Sourceforge page:
An alternate editor for the Elder Scrolls: Morrowind computer game. Similar in appearance to the official construction set editor but with the edition of many features to make mod editing easier.
Snip from the SW thread:
Do wonder how difficult it’d be to swap DeviL out for something more supported like GraphicsMagick (assuming I understand the usage of the image library in this instance; if not, there are others to choose from).
Due to its age, the code may need some additional updates to be compatible both with modern compilers and the APIs of modern systems. Quite a few things have changed in the standard in the last twenty years. Running a compiler in dry run mode would help track all of that down along with Cppcheck which we’ve used before.
It’d be nice to get working cross-platform as well since OpenMW works across several platforms. That’d require something like GTK or Qt.
Another thing missing is the code license and the headers don’t give much clue either. Should still be possible to contact Dave over at UESP, though.
I know CMake has a VS plugin that integrates it with Visual Studio. Not sure about Meson about I’ll definitely take a look.
It is the most excited I’ve been about a project in years. May be worth looking into more 🙂
Found the solution if you want to see what happens. I’d be a little surprised if it builds out of the box, though.
As I recall, if it’s under GPL then all future changes need to be under the GPL unless permission is granted from all parties who contributed code to change the license. Other licenses aren’t as strict about it. Not too familiar with the MIT license, even though I’ve seen it around a lot. Just never really got around to reading up on it 😛
Will look at sending him a note. 🙂
Will get it going on the other machine soon!
One of the first issues is to convert to vcxproj and another is to ditch the vcclcompilertool, then, after a few moves, ultimately get to the bugs. 🙂
Here’s what I’m thinking of in terms of priorities:
How does that look? I’ll grab the repository just as soon as we get permission to start editing but that doesn’t mean we can’t try building it and start making notes. Just that we can’t modify the code 🙂
Will have more to post later but we’re going to want to use this repository: https://github.com/uesp/mwedit
That seems to be the latest official one. At least, I think so. Will need to review things more when I’m not so tired but wanted to pass it along before you got going too much 🙂
Edit:
Waiting to confirm the license. He thought it was under the Apache License but it looks like the newer repo’s license file has it set to the MIT License. No problem with either, we just want to make sure we know what we’re working with is all
Got confirmation that the code is actually under the MIT license. He didn’t have any comments regarding the code so we’ll probably just need to figure it out as we go. Just cloned the repository so I’ll start going through it 🙂
Definitely want to look at doing some rearranging of the directory structure. I’m just not a big fan of having a lot of code files all in one folder. Makes it hard for me to find what I’m looking for but we’ll get there
As a note: it looks like it uses the one-class-per-file structure.
I’m pretty rusty so bear with me!
Edit:
A cursory glance shows that there may be some headers missing from the includes. That may take some time to update. We’ll have a better handle on things once you’re able to try building it, though 🙂
Edit 2:
We’ve got a mixture of C-style types as macros and C++-style types, such as BOOL and bool respectively, that should be made consistent. There are also some code blocks that are generated by the VS class wizard that should probably be copied (if we’re allowed to, not sure how that’s handled by licensing) into the main code to allow it to be more portable. Additionally, some stuff needs the proper namespaces assigned.
Took a closer look at all three code repos just now. There are definitely some missing files. Should I ask Dave about them? That would explain why I haven’t been able to follow the newest repo, such as the IO operations. The newest one appears to be mostly the GUI implementation and not the backend stuff.
I’d leave Dave’s for the moment, Nimrod actually has the solution, however conversion of the vcproj to vcxproj is the first port of call. All the included files will be in there – have you got to that stage yet?
Re-arranging the dir structure is critical, as you know.
That repository looks better but there isn’t a license associated with the code. Any way we can contact them to see about getting permission to use their fork?
Yeah, we can use the project files to extract the includes and add them into the C++ source. That’s what I did with the BOSS code. 🙂
Still need to finish setting up my Geany workspace. Some that is done on a per-project basis, though, so part of it will need to wait until we finalize which repo we’re going to use. Geany is pretty manual oriented 😛
Dave also has a few other projects that could be worth exploring down the road: https://github.com/uesp/obedit and https://github.com/uesp/tes4lib along with https://github.com/uesp/skyedit and https://github.com/uesp/tes5lib
The former looks like a GUI shell but it may use the latter. Not sure, haven’t looked at the code yet. Definitely something to look into later, though.
Edit:
Looks like Nimrod has done a lot of the updating I had in mind. Excellent. That definitely would help if we can use their fork.
Edit 2:
It may only be worth doing the bare minimum on the VS project files since they’ll be generated during configuration by CMake or Meson when we get to that step. 🙂
Okay, just did some digging to try and clear up what happens when a license isn’t applied and came across this post. Basically, even though Dave intended the original to be Apache or MIT but, since he didn’t explicitly mention the licenses in the project, we can’t go ahead and use Nimrod’s fork because they didn’t apply a license to their own work as they weren’t required to since Dave didn’t require it, even if it was unintentional. We already have permission from Dave to work with all of his code but we’ll need Nimrod’s as well if we want to work with their code. If not, we’d need to redo the work that they’ve already done. Hopefully that clears things up a bit 🙂
Can contact Nimrod if you like, although we’re not sure whether he received explicit permission in the first place, see the post. The project is so old, there’s a good chance no-one will be worried about it all that much. Does Nimrod’s licence permit a third party copying his code, and then attributing his work in the updated project?
Sorry, been tired again. Probably just trying to take on too much.
Anyways! Yeah, let’s try to contact them. Dave did say I could use a fork but didn’t have the details handy so that may be permission from him on that front.
Without a license in the code, it means that anyone who wants to work on our version, even though we got permission, would have to ask us, Nimrod, and Dave. We can license any new code, however, but any other code, changed or original, is still without a license. I’m not sure of how retroactive relicensing works off the top of my head but Dave doesn’t seem inclined to go back to the original repo to correct the error (don’t blame him: it’s set up with CVS and the world has mostly moved on from that). So, the only code explicitly under a license currently is the GUI shell, which I’d like to swap out with GTK down the road anyways if I wind up being able to work with GTK (never tried, honestly). Yeah, things get complicated in open source world!
Any luck with reaching Nimrod?
In the meantime, I went ahead and ran the repository through cppcheck using the following options:
cppcheck --enable=all --platform=win64 common Windows esm IL File project
As expected, there are lots of messages about the use of the virtual bits. The log is surprisingly sparse otherwise. Here’s the full log.
Other items of note are unfinished features, which are unused functions, and the code generated by VS that’s already been noted. Most of the other lines are nit picky things that will still want to be investigated.
Yeah, style, warnings, virtual functions in base class, override’ specifier required, function in derived class etc.
esm/EsmBase.cpp:28:3: error: There is an unknown macro here somewhere. Configuration is required. If DEFINE_FILE is a macro then please configure it. [unknownMacro]
DEFINE_FILE(“EsmBase.cpp”)
^
🙂 Contacted Nimrod at NexusMods with a link on here, sorry for the delay. 🙂
Never had a C++ course (learned on my own) or used virtual functions before so I’ll need to brush up on them before they go on the list
I suspect most of the macro issues will vanish once the code is changed so that it’s no longer being generated. I don’t even know what the generated commands tell it to make
This could be a useful utility to run on the source tree: https://include-what-you-use.org/
Not a big fan of bloating the system with several compilers so manual investigation may still be done. Will need to think on it
No worries! Maybe they’ll join us on this. 🙂
Great! Another fork….? Not sure of some of the changes from the diffs, such as changing some of the types from ints to shorts and long to long long. Would need to look at the surrounding code or even ask them about it. Other than those things, the changes look minimal so we may be able to just use Nimrod’s fork and go from there. Definitely worth asking rfuzzo about things first before we make a decision. 🙂
Not a huge fan of GitHub but I’ll use it if I absolutely have to. I’m going to look at some stuff regarding the licensing. If we could possibly add a license, that could help streamline things in the future if things take off. Only took that brief look a few weeks ago but it’s probably time for a deeper dive now that we’ve got the permissions coming in. Brushed up on virtual functions this morning and I think I understand them now. Always had a hard time wrapping my head around objects so it’ll mostly be trial by fire. Hopefully not a literal fire. 😛
We can probably forgo 32-bit support as 32-bit systems have mostly gone the way of the dodo. Morrowind was written for 32-bit systems but few of those are likely to still be alive and the program was designed to work with plugins instead of the executable. That’s not to say we don’t need to support the data types, just the compiled objects. I forget if that changes the data type limits and sizes, though. It’s been a while. Will look, though
I’ve started adjusting the font sizes on my system so I’m able to spend more time looking at things now. Still have some fonts to adjust but I got the editor and that’s the important one 🙂
Anyways! Started to take a deeper dive into the cppcheck log and there are some things that it picked up that aren’t optional. It picked up a couple type mismatches with printf with trying to pass a long integer type while using the main integer specifier and most, if not all, of the memory operations are using floating points instead of integers, which could lead to wonky behavior. Not sure if this is the same stuff that rfuzzo picked up as I haven’t compared everything yet, though. Haven’t started looking at the main code yet but will get there in time. I like to check the logs first to get a better handle on things instead of diving right in. 🙂 I’ll also need to track down the main function. Tried a couple of weeks ago without success but I’ll need to try again
Any luck with Visual Studio?
Actually somewhat of a bum steer,
This branch is up to date with NimrodPSI/MWEdit:master
Just an example of forking a project, we could do that, or simply start a “new” one. 🙂
Sorry about Github, it’s just all our repos are in there. Hate having to foist something like that on an unhappy subscriber. Other web clients like Gitlab would certainly be fine, the only reason for being lothe to use them is simply opening up more accounts. Gone down the rabbit hole of opening too many accounts in the past, not so many recently, fortunately. If there is a convincing argument to open an account in an alternative client, then why not?
Isn’t the current build of MWEdit 32 bit? Think we will be in a world of pain trying to pass 32 bit structures to and from a 64 bit framework.
Give me a bit with VS, there are a few things that want to be done concurrently, like actually setting up and playing MW. 😛
Sorry, they’ve got things under a new branch: https://github.com/rfuzzo/MWEdit/tree/dev
Some of the changes make sense but others are lost on me. May make more sense later on, though. We could merge the changes later on if that’s the case. Most of the changes in rfuzzo’s seem to deal with the Windows API, which is pretty foreign to me. Most OS APIs are as I generally stick to platform independent code.
No worries, I can use GitHub if needed. 🙂 Just need to set things back up. Don’t know why, using it just isn’t a pleasant experience is all. Always felt better when using GitLab. Really can’t explain it.
I think it’ll be fine as we’re not using it as an API or anything but there are some memory operations in the code. Hopefully they’re part of the program and not trying to access anything in memory separately.
The code is twenty years old so who knows how much we’ll want to change it.
Couldn’t find the main function but there’s this one: https://github.com/NimrodPSI/MWEdit/blob/master/project/MWEdit.cpp#L461
Does Windows generate the main function at compile time for GUI programs, then? GTK doesn’t so if that’s the case, we’ll need to add one later.
No hurry! Just wanted to ask to see how progress was coming along 🙂 Been pretty slow myself. Just general moodiness. 😛
Started looking into setting up a build script (got Meson installed this morning) and got a little stuck on account of the lack of a main function so it’ll need to wait a bit 🙂
Meson looks pretty straightforward and cleaner than CMake so I’m currently leaning towards it.
So, I lied. I’m moving forward with the skeleton build script 😛
Ford defining macros in the build script, we’ll want this: https://stackoverflow.com/questions/79162315/how-do-i-define-a-c-c-preprocessor-variable-in-meson
Probably could have found it in the documentation but I had trouble with the layout of the Meson website. We may want to use that for defining things like the version number just to make things tidier. Or we could simply set up the macros in header files. Same result, just a couple of different ways of doing it. Will need to give it some thought to decide on a method.
I’m kind of all over the place, I know
