[Spastic Hamburger]

So that error is now gone even though it was showing up all the time the other day and I didn’t change anything in the build script. Meson didn’t get an update either. Looks like an obscure parsing bug.

No idea how to upload the log. Added the upload commands to the action file but apparently it stops the run at the first error so I’m unable to generate it from the CI.

Edit:

Got the log file. Was looking in the wrong spot. And got it uploaded. I’ll review it shortly!

End Edit

Now we’re back to figuring out how to link DLLs to the executable in the build script. There’s zero documentation on this and nothing I’ve found online works 🙁

With CMake, it’s as simple as this. I have yet to determine how to do it in Meson….Will get back to seeing if I can dig up the answer. If I can’t figure it out, we’ll probably need to switch to CMake as at least I know I can likely get it working in it. I’m starting to get a bit frustrated with trying to make Meson work

As near as I can tell, the Meson script is properly set up. :/

There may be something else going on. It looks like the other DLLs are being linked. At least, I think so. It’s complaining about those two specific symbols for some reason. Currently investigating and doing some trial and error. It’s also possible that the more stringent compilation commands are breaking something due to some bad DLL data. In which case, we’d need to rebuild the DevIL libraries. Unfortunately, NimrodPSI didn’t include any documentation or build scripts for those changes. We may need to totally overhaul how the build system uses DevIL. We’ll need to change things anyways for better 64-bit support

For reference, here are the errors:

[198/198] "link" @MWEdit.exe.rsp
FAILED:  MWEdit.exe 
"link" @MWEdit.exe.rsp
project_EsmIconFrame.cpp.obj : error LNK2019: unresolved external symbol __imp_ilutWinLoadImage referenced in function "public: void __cdecl CEsmIconFrame::SetEsmIcon(char const *,bool)" (?SetEsmIcon@CEsmIconFrame@@QEAAXPEBD_N@Z)
project_MWEdit.cpp.obj : error LNK2019: unresolved external symbol __imp_ilInit referenced in function "public: virtual int __cdecl CMWEditApp::InitInstance(void)" (?InitInstance@CMWEditApp@@UEAAHXZ)
D:\a\MWEdit\MWEdit\IL\DevIL.lib : warning LNK4272: library machine type 'x86' conflicts with target machine type 'x64'
D:\a\MWEdit\MWEdit\IL\ilu.lib : warning LNK4272: library machine type 'x86' conflicts with target machine type 'x64'
D:\a\MWEdit\MWEdit\IL\ilu-l.lib : warning LNK4272: library machine type 'x86' conflicts with target machine type 'x64'
D:\a\MWEdit\MWEdit\IL\ILUT.lib : warning LNK4272: library machine type 'x86' conflicts with target machine type 'x64'
MWEdit.exe : fatal error LNK1120: 2 unresolved externals

And here are the grep results for those two symbols:

$ grep --recursive --line-number "ilutWinLoadImage"
IL/ilut.h:212:		ILAPI HBITMAP ILAPIENTRY ilutWinLoadImage(const ILstring FileName, HDC hDC);
grep: IL/ILUT.exp: binary file matches
grep: IL/ILUT.dll: binary file matches
grep: IL/ILUT.lib: binary file matches
project/EsmIconFrame.cpp:142:		hBMP = ilutWinLoadImage(FileBuffer, pDC->GetSafeHdc());
project/EsmIconFrame.cpp:144:		hBMP = ilutWinLoadImage((char *const)pFilename, pDC->GetSafeHdc());

And:

$ grep --recursive --line-number "ilInit"
grep: IL/DevIL.exp: binary file matches
IL/il.h:528:ILAPI ILvoid ILAPIENTRY ilInit(ILvoid);
grep: IL/DevIL.dll: binary file matches
grep: IL/DevIL.lib: binary file matches
project/MWEdit.cpp:320:	ilInit();

If we were to enable Unicode support, that would change the first error slightly. ILstring becomes a wchar when _UNICODE is defined:

#ifdef _UNICODE
	#ifndef _WIN32_WCE
		#include <wchar.h>
	#endif
typedef wchar_t *ILstring;
#else
typedef char *ILstring;
#endif //_UNICODE

TCHAR is a typedef of wchar, as I recall, so things may work differently.

Regarding the second symbol, I’m not sure. ilInit() looks like it’s being used properly.

I’ll try reaching out to NimrodPSI via email to see if they can shed any light on the DLLs they built.

The Meson log is also complaining about the install script but we’ll worry about that later. That’s minor in the scheme of things. Worst case scenario, we simply write a shell script or something.

[Spastic Hamburger]

Good list! Yep, many of the sites are definitely recent. I do notice that they leave off artificial lakes that store power for hydropower plants.

Found it! I see that that kit comes in O-scale. Model trains, anyone? Still want to get into the hobby, just don’t know where I’d put the table! 😛

[Spastic Hamburger]

Whelp. They just added yet another gameplay mechanic to Lorcana, increasing its complexity. I may drop it at the end of this season. I like it because it’s simple and it’s a way to relax when I’m don’t want to deal with a lot of stuff going on like I do with other card games that I play

[Spastic Hamburger]

Progress on MWEdit is currently on hold as I wait to see if the Meson devs can help with the issues. If we can’t get Meson working, I’ll go ahead and use CMake. It isn’t as user friendly but it’s more mature so it should work better. I’ll give them a good week or so to get back to me before I start re-learning how to use CMake

[Spastic Hamburger]

Still banging about. There’s not much about how to link an included binary. When I thought I figured that out, Meson then complained that it wasn’t running under a VS environment even though it was running in a VS environment….

So I changed the backend to use VS as an experiment and then Python crapped out with missing file errors. You can see that one here.

At this point, I think I need to file a bug report and see what the Meson devs have to say.

Edit:

Opened.

In the meantime, progress is pretty much stalled

[Spastic Hamburger]

Sorry, was focused on MWEdit and missed some of this.

We’ve had some Labubus cropping up here but definitely not the intensity that other areas are seeing. In fact, it’s mostly died out here after a few weeks of interest.

Ugh, messing up post history like that is always a pain in the rear. 🙁

On the old site, we actually did a lot of work to merge post histories from several sites just to keep it from getting lost. Took the two of us a few months of work but was definitely worth it. One more reason why vast archives are needed in this day and age

[Spastic Hamburger]

Okay, esm/EsmWinUtils contains only a few things and they’re duplicates of those in project/EsmUtils. The latter is used more often so I’ve commented out the stuff in the former. Not going to delete it just yet as we may change up the structure once things are working but I’ll go ahead and add the two files to the dead code review issue.

Not sure about the other errors right now with the unresolved symbols in the image library (the grep results say that they’re all there) but I’ll need to take a look at them another day. I need a bit of a break 🙂

Looks like those unresolved symbols are the last errors to sort out, though

Edit:

Looks like we may need to add the DLLs to the build script.

Meson doesn’t have a clean way of linking to provided libraries. That’s going to be a tad annoying in the future. Will keep investigating to see what the best way of doing it is. It’ll get figured out. May just go better when I’m not so tired 🙂

[Spastic Hamburger]

Okay, almost got it. Now we’re left with some linking logs after the obvious source issues have been taken care of:

[198/198] "link" @MWEdit.exe.rsp
FAILED:  MWEdit.exe 
"link" @MWEdit.exe.rsp
project_EsmUtils.cpp.obj : error LNK2005: "void __cdecl FindMWRegistryPath(void)" (?FindMWRegistryPath@@YAXXZ) already defined in esm_EsmWinUtils.cpp.obj
project_EsmUtils.cpp.obj : error LNK2005: "char const * __cdecl GetMWDataPath(void)" (?GetMWDataPath@@YAPEBDXZ) already defined in esm_EsmWinUtils.cpp.obj
project_EsmUtils.cpp.obj : error LNK2005: "void __cdecl SetMWDataPath(char const *)" (?SetMWDataPath@@YAXPEBD@Z) already defined in esm_EsmWinUtils.cpp.obj
project_EsmUtils.cpp.obj : error LNK2005: "class ATL::CStringT<char,class StrTraitMFC_DLL<char,class ATL::ChTraitsCRT<char> > > l_MWDataPath" (?l_MWDataPath@@3V?$CStringT@DV?$StrTraitMFC_DLL@DV?$ChTraitsCRT@D@ATL@@@@@ATL@@A) already defined in esm_EsmWinUtils.cpp.obj
project_EsmIconFrame.cpp.obj : error LNK2019: unresolved external symbol __imp_ilutWinLoadImage referenced in function "public: void __cdecl CEsmIconFrame::SetEsmIcon(char const *,bool)" (?SetEsmIcon@CEsmIconFrame@@QEAAXPEBD_N@Z)
project_MWEdit.cpp.obj : error LNK2019: unresolved external symbol __imp_ilInit referenced in function "public: virtual int __cdecl CMWEditApp::InitInstance(void)" (?InitInstance@CMWEditApp@@UEAAHXZ)
..\IL\DevIL.lib : warning LNK4272: library machine type 'x86' conflicts with target machine type 'x64'
..\IL\ILU.lib : warning LNK4272: library machine type 'x86' conflicts with target machine type 'x64'
..\IL\ILUT.lib : warning LNK4272: library machine type 'x86' conflicts with target machine type 'x64'
MWEdit.exe : fatal error LNK1120: 2 unresolved externals

Will take a look at those later. The DevIL errors are expected as the repo bundles in the 32-bit DLLs when we’re using 64-bit. Not entirely sure how to go about that. I may need to tell the CI to build the 64-bit version of DevIL. The rest, I’m not sure about at the moment. Will need to look at them later. It sounds like it’s missing an include guard, though

Edit:

Just realized what the duplicates are about: just that, they’re defined several times. Made a mental note a while ago but it didn’t click until just now. If they’re the same, we’ll remove one. Later on, namespaces will keep this sort of thing from happening again. Will fix when I’m back to the computer

Not sure about the other two, those look like issues with the image library. Will take a closer look

[Spastic Hamburger]

Thanks. 🙂

Ultimately, they’ll be swapped out when we switch GUI toolkits but we can revisit things then 🙂

Looked at it more closely and ON_WM_TIMER() is supposed to map to an UINT_PTR while the code is trying to use just UINT. Probably a change in MFC signatures at some point over the last couple of decades. That fixed that error when I changed the type. Got some more, which isn’t unexpected. It was able to work through 92 files this time so we’re definitely getting closer. There will be more const types to correct but I’ll let it point me to them so I don’t have to go on a treasure hunt 🙂

Yeah, I’m not entirely sure what all of the stuff in Common is for. It could be for other projects totally unrelated to the community as I haven’t seen it used anywhere else. With the time stuff, he’s using it to profile stuff in debug mode and in general in the script compiler but those all use dl_time instead. Lately, he’s pretty focused on admin duties at UESP but does update the Edit code from time to time for compatibility. He even added some stuff to it for Starfield in a separate repository. 🙂

Edit:

We’re getting some pointer truncation warnings in project/mwrecordmap.h that are annoying to see in the log so I’ll look at fixing them up at some point. Just tired of seeing them 😛

Still working through compatibility errors. It’s also caught some missing includes, which is nice. Once it’s building, I’ll clean things up a tad before squashing the commits and merging 🙂

[Spastic Hamburger]

So it sounds like there’s a switch being used for MSVC to relax the casting rules for C++. Sorry, things are still coming back to me but I’m getting there. 🙂

Would be better to fix it manually, anyways, so I guess I’ll fix up the required casts for now. Was hoping to do them later but, hey, it’s all part of improving the code quality. It’ll also help with getting it ready for cross-platform support as compilers on Linux are extremely strict. 🙂

What does the message map do, anyway? The documentation I found on MSDN on the block didn’t link to an explanation of what a message block is in the context of MFC

Eventually, I hope to replace much of the time functions with those from ctime but there may still be some OS specific stuff needed. Right now, that class isn’t used in the program so it’s a likely candidate for removal at some point after we get the basic changes done for building.

We can definitely add it to the issue tracker, though. 🙂

Who knows? We may find a use for some of the miscellaneous capabilities of the common support library down the road

I’ll flip on all of the warnings after we get the build working to help us with compiling our list of stuff to fix. May be worth rerunning cppcheck and cpplint, too. Afterwards, we may want to get the stuff added to the issue tracker by warning type to help keep everything in one place. Up until now, most of the work has been related to updating the style, syntax, and infrastructure but once the build script is working, that’ll unlock capabilities that we didn’t have before. We’re definitely getting there! 🙂

I’ll update the threads tomorrow with an update on where things stand with the build script 🙂

[Spastic Hamburger]

I’ve temporarily turned off all of the extra warnings until we get things working.

New issue! This has to deal with the message maps that the MFC API uses. It’s complaining about bad casting even though it works in the VS project files, just not the Meson script so I suspect there’s a setting in there that may need to be transferred over as well. Any ideas on that? Here’s the error I’m looking at
Yep, the CI script is fully set up to work with Ninja and VS 🙂
meson setup --buildtype release --vsenv build
That’s where we tell it which back-end to use. I can also tell it to use MSBuild instead of Ninja but it looks like Ninja is working and the issues have to do with missing some special overrides that were done twenty years back.

[Spastic Hamburger]

Okay, got that minor issue fixed. Had to add this to the Meson script:

add_project_arguments('-D_AFXDLL',
                      language: 'cpp')

Now that it’s using C++20 as the standard, it’s exposed a few other real code errors that I’m working on fixing. 🙂

Got one that’s an issue with the Windows API that I’m unfamiliar with:

../Common/Time/tasktime.cpp(231): error C2664: 'MMRESULT timeSetEvent(UINT,UINT,LPTIMECALLBACK,DWORD_PTR,UINT)': cannot convert argument 3 from 'void (__cdecl *)(UINT,UINT,DWORD,DWORD,DWORD)' to 'LPTIMECALLBACK'
../Common/Time/tasktime.cpp(231): note: None of the functions with this name in scope match the target type

Here’s the line it’s crapping out on: https://github.com/deathssoul/MWEdit/blob/meson/Common/Time/tasktime.cpp#L231

After doing some looking, that file may not be needed anyways so I’ve temporarily commented it out of the build script which fixed that issue as it’s no longer trying to compile it. Still working through the updates to the code. The old project file was using the C++14 standard but C++20 is much better. Also stricter, which is why there are a lot of kinks to work out.

[Spastic Hamburger]

Yep, the boar of soap was near the end. Yep, the turtle portion was fun! Duck and cover! 😀

Saw Night Tide yesterday. Wasn’t bad but it didn’t do much to actually build the conflict. It felt more like a narrative than a film

Haven’t seen No Country for Old Men but, then again, Westerns aren’t exactly my cup of tea.

[Spastic Hamburger]

Hit a bit of a snag while updating the build scripts. Now I’m getting this error in the Meson branch while the main branch builds without issue:

[1/199] "cl" "-IMWEdit.exe.p" "-I." "-I.." "/MD" "/nologo" "/showIncludes" "/utf-8" "/Zc:__cplusplus" "/W4" "/EHsc" "/std:c++20" "/permissive-" "/O2" "/Gw" "/FdMWEdit.exe.p\Common_File_CfgFile.cpp.pdb" /FoMWEdit.exe.p/Common_File_CfgFile.cpp.obj "/c" ../Common/File/CfgFile.cpp
FAILED:  MWEdit.exe.p/Common_File_CfgFile.cpp.obj 
"cl" "-IMWEdit.exe.p" "-I." "-I.." "/MD" "/nologo" "/showIncludes" "/utf-8" "/Zc:__cplusplus" "/W4" "/EHsc" "/std:c++20" "/permissive-" "/O2" "/Gw" "/FdMWEdit.exe.p\Common_File_CfgFile.cpp.pdb" /FoMWEdit.exe.p/Common_File_CfgFile.cpp.obj "/c" ../Common/File/CfgFile.cpp
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.44.35207\ATLMFC\include\afx.h(24): fatal error C1189: #error:  Building MFC application with /MD[d] (CRT dll version) requires MFC shared dll version. Please #define _AFXDLL or do not use /MD[d]

Any ideas what that error means and how to fix it? Also, why is it complaining now but didn’t before?

You can see the changes in the PR

I’m sure I’m missing something from the Meson script but not sure what

The other warnings you’ll see in the log have been on the list for months 🙂

So it looks like it’s a setting in the project files that needs to be set in the Meson script somehow, which explains why it’s coming up now.

Not sure how to set it in Meson, though. Can’t find much about it. May take it to their GitHub page tomorrow

Another question: what triggers it? Is it something that can simply be fixed in the code or is it inherent in the MFC stuff?

[Spastic Hamburger]

Okay, I updated the Meson PR with the updates to the include paths. Should be ready for testing now if you want to give it a whirl. 🙂

[Spastic Hamburger]

Tron is great. Haven’t seen it in a while, though. Looks like the 4k version is hard to find. Supposedly, a Steelbook was released on Amazon two weeks ago but the listing says it’s unavailable and that they don’t know if it’ll be in. The regular 1080p version is easy to get, however. See something similar with a lot of Disney films. 🙁

Gaslight looks fun, will need to watch it at some point 🙂

Saw The Atomic Cafe yesterday and it both sobering and fun at the same time. Interlaced with the serious message were some very odd scenes that didn’t make much sense in the context, such as a guy in the shower randomly slipping on a bar of soap and happy music while everyone was donning hazmat suits 😛

[Spastic Hamburger]

Merged that in this morning and started on the include paths. 🙂

Ultimately, the pragmas will need investigating to see if they’re needed. Some disable warnings, which can likely be removed. It would be better to fix the issues in those cases instead of suppressing the problems

[Spastic Hamburger]

On Spastic Hamburger said

I think the heightmaps need to be processed before they can be used in the tools for the Elderscrolls but I’m not entirely sure how that works. Can try to find out, though!

Not necessarily! In theory, archive formats support sizes of several exabytes. As for downloading speed, it’d be a pain on anything but a 1 Gbps fiber connection (would only take an hour there) but a download manager would help with that. Storage would also be an issue, as well as unpacking the archive. To work with it and to process all of the files, it’d probably take at least a workstation class system running Linux to do things efficiently. A lot of it depends on how their data is laid out

Excellent! I’ve gotten pretty good at minesweeper over here. Took a while to truly get the hang of it but it’s pretty enjoyable!

Here’s another source: https://opentopography.org/

It’s not fully global, though. Some of the access requires a subscription, too.

[Spastic Hamburger]

As much as I like Redshirts, it’s probably Starter Villain. While it’s a James Bond parody on the surface, it runs much deeper than that.

It may be, too, that he’s referring to the trend in school where instructors insist that you over analyze works and everyone comes up with something totally different. He’s got some other good quotes, too!

Materials science has a come a long way in ninety years. For instance, we now have Kevlar which could help keep the balloons from ripping and is also incredibly lightweight.

We really don’t have enough books that go over futuristic anthropology. It’s such an interesting idea, too. 🙁

One of the science fiction stories I’m currently reading is actually about how extraterrestrial cuckoos play dumb to take over a space station. It’s a pretty fun read. It blends pop culture, a murder mystery, and humor altogether.

Been looking into sand batteries this morning: https://hackaday.com/2022/11/21/making-a-do-it-yourself-sand-battery/

They’re using them on a much larger scale, too. Or at least experimenting with it. In theory, they can be used to store excess capacity to generate electricity later. There would still need to be voltage regulation, though, as they work differently from traditional batteries in that they store thermal energy instead of electrical energy.

[Spastic Hamburger]

The trick is getting the opportunity to watch it 😛

Going to try and watch it today 🙂

Yep, Tubi is a weird place. It’s a gold mine if you love B-movies but quality films do sneak in from time to time. 😛

They’ve also got a decent selection of classics.

Speaking of, it’s been years since I watched the Benny Hill Show. Kind of been in the mood lately but I suspect I’d need something like BritBox. Going to need to check out the British streaming services at some point as the quality of British television is much better than our stuff, in my opinion. Too many soap operas! 😛

[Author]

Posts