Forum Replies Created
-
Yeah, I’m sure some of them have fallen into disrepair by now. There may be others opening up over the course of the next few decades as the USAF builds new silos. And let’s not forget all of the fallout shelters! Atlas Obscura has a few articles 🙂
iNaturalist is currently down for maintenance so will need to read it later 🙂
Really enjoy nature articles like that. There’s also Mammoth Cave and the Hoh Rainforest in Washington, which is impressive for its location.
Okay, I just finished moving the macros from
common/dl_base.hto the proper files. Now I need to go through the entire codebase and correct all of the includes, making sure everything is where it needs to be.This is a downside to making heavy use of the preprocessor: it can cause conflicts due to how compilers work.
- The preprocessor runs, doing full text replacement in the order that things appear
- The compiler runs, converting everything into an AST and object code
- Code is linked together into a single unit
Ultimately, we’ll want to pare things down to limit the potential for bugs in the future. I don’t have an issue on the tracker but I did mention it sometime last year in the thread, it just hasn’t made it over to GitHub yet. Will get it added at some point.
I also need to go through and remove the boolean macros and swap them out for
bool,true, andfalse. Going to take a bit as the UI makes heavy use the macrosOh, cool. Didn’t realize Skeptic was still around (sorry, haven’t had a chance to catch up on the SETI thread yet). Have fond memories of seeing their ‘zines on the newsstand years ago, back when they were still a thing here. Looks like a physical sub isn’t a whole lot: 36 USD annually. May be worth it 🙂
My mom has started relying on AI for some writing tasks. I haven’t seen the results so I can’t comment on it. I did experiment with it the other day for some research and wasn’t overly impressed. It just gave me a generic overview that I could have gotten on my own and with more insight had I done the research myself in the same amount of time that it took to read the overview.
Yeah, we’re doing the same thing: increasing biofuel output to make up the shortfall. Not a bad idea, honestly, and hopefully it helps spur R&D in that field, which has been sorely lacking. Electric is great and all but there are cases where it just doesn’t work out, such as during a grid failure (especially problematic here in Florida with our hurricanes). Unlike with other fuels, it’s hard to store enough power in batteries to charge things up to usable during an outage. I’ve long said that we need dual fuel vehicles where we can use either or. Different from hybrid as you still need both instead of being able to choose how the vehicle is powered.
Had this come in this morning: https://www.architecturaldigest.com/gallery/the-most-beautiful-places-in-the-world
It does have what I’d consider some major omissions, such as this cave complex, but still worth a read.
Ooh, lookie. MAD is going to be riffing on DC in a few days: https://bleedingcool.com/comics/mad-about-dc-1-preview-dc-universe-gets-a-comedic-wedgie/
May need to pick up that special!
British comedy is some of the best!
And while we’re talking Benny Hill:
😀FiM is a blast!
Okay, community threads have been updated 🙂
Got more details on the syntax highlighting bug that was mentioned in issue 10. Went ahead and added the screenshot and post link to help us keep track of it. It should get fixed when we overhaul the GUI 🙂
Yep, changing the include order fixed it. Going to need to fix the rest of the places where it shows up. Give me a bit.
We’ll want to fix things up at some point to make sure that we don’t run into this problem again. The fix isn’t pretty but it’s a temporary solution until the refactoring is further along.
We’ll want to move the string functions to
common/dl_str.has they use symbols from that file.common/dl_base.hcannot include that file becausecommon/dl_str.hrequires symbols fromcommon/dl_base.hin order to function. I guess I could include it at the very end ofcommon/dl_base.h, though. Essentially, the work on the includes has exposed a couple of circular dependencies that were already in the code. This will take some time to fix. Messy, messy, messy.I’ll update the community threads when I get the chance
-
This reply was modified 1 month, 1 week ago by
.
-
This reply was modified 1 month, 1 week ago by .
-
This reply was modified 1 month, 1 week ago by .
-
This reply was modified 1 month, 1 week ago by .
-
This reply was modified 1 month, 1 week ago by .
-
This reply was modified 1 month, 1 week ago by .
-
This reply was modified 1 month, 1 week ago by .
Edit:
Ignore the post! The include order is messed up in the base file. The preexisting spaghetti code threw me for a loop earlier: it doesn’t set up the definitions until after it tries to include the files that need them in the same file that defines them. Why I didn’t see it before is beyond me. Fixing now.
End edit!
Yep, CMake is correctly setting things up properly:
Run mkdir builddir; cmake -G "Visual Studio 17 2022" -B builddir mkdir builddir; cmake -G "Visual Studio 17 2022" -B builddir shell: C:\Program Files\PowerShell\7\pwsh.EXE -command ". '{0}'" Directory: D:\a\MWEdit\MWEdit Mode LastWriteTime Length Name ---- ------------- ------ ---- d---- 3/28/2026 7:47 AM builddir -- The C compiler identification is MSVC 19.44.35225.0 -- The CXX compiler identification is MSVC 19.44.35225.0 -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: C:/Program Files/Microsoft Visual Studio/2022/Enterprise/VC/Tools/MSVC/14.44.35207/bin/Hostx64/x64/cl.exe - skipped -- Detecting C compile features -- Detecting C compile features - done -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio/2022/Enterprise/VC/Tools/MSVC/14.44.35207/bin/Hostx64/x64/cl.exe - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- Looking for MFC -- Looking for MFC - found -- Could NOT find DevIL (missing: IL_LIBRARIES ILU_LIBRARIES IL_INCLUDE_DIR) -- Configuring done (21.0s) -- Generating done (0.0s) -- Build files have been written to: D:/a/MWEdit/MWEdit/builddirAnd
MSBuild version 17.14.40+3e7442088 for .NET FrameworkHere’s the new log file after that playing about with the conditionals: https://github.com/deathssoul/MWEdit/actions/runs/23680640909/job/68991840433
Didn’t seem to change anything.
This would be easier to diagnose using a local VS install but my system is no longer able to run Windows.
I added the
_WIN32macro to the definition list in CMake to no avail. I have no idea what’s going on. It was working before I added the includes so that operation clearly broke something.Fixed it! For some reason, MSVC wasn’t bringing in
tchar.hfromcommon/dl_base.h. I added#include <tchar.h>tocommon/dl_str.hand the error went away. Looking at the new error log, it looks like_WIN32isn’t being brought in from MSVC for whatever reason even though it’s a compiler level macro. That should be easy enough to fix: I’ll just add it to the definition list in the build script. Could be a bug in MSVC or whatever but we can easily deal with it 🙂That said, we now have two options: add
tchar.hto all the files (my preference as it makes things clear that we’re using the header) or leave it incommon/dl_base.h. It should be noted that the latter option won’t work on non-Windows systems anyways even if it is in an OS level check due to this line:
#define _stricmp(string1, string2) stricmp(string1, string2)
stricmp()is a Windows extension tostring.hand isn’t in the standard (there is a similar function in the C++ standard,std::strcmp(), that provides a slightly different comparison value so we can swap out the function easily enough temporarily) so we’ll need to rewrite all of the Unicode handling anyways for cross-platform support once we get there. We can leave it in for now but we’ll just have to remember that we’ll need to change things.The complaints about the boolean types are because they’re in a
_WIN32check, which is broken for whatever reason. That said, those need to be swapped for the standard boolean keywords,bool,true, andfalseanyways (which are treated as typeintso should be fine to swap in) for portability.If that plan sounds good, I’ll start work on the fixes in the next few days 🙂
Where do you see the error about the missing
main()function? I missed that. I never did figure out how things were working withoutWinMain()It is missing the
Run()function and is supposed to use the inherited one instead. I noticed it during the initial audit a year ago but I don’t think I put it on the tracker. Sorry about that. It’ll need one or the equivalent anyways for GTK support since it does things in a standard C++ way. Will look at the structure of it and will probably have questions about it 🙂Will also try the
stdafx.hfile and see what happens 🙂We knew going in that the cleanup would break most everything until completion so I’m not all that worried. Most of what’s broken is the Windows code. The rest remains intact 🙂
Though, why adding the needed includes would cause this issue is beyond me when things were working before. I’ll take another look at the previous log file from before I added the offending header and see if it has any additional insight.
-
This reply was modified 1 month, 1 week ago by .
-
This reply was modified 1 month, 1 week ago by .
-
This reply was modified 1 month, 1 week ago by .
-
This reply was modified 1 month, 1 week ago by .
-
This reply was modified 1 month, 1 week ago by .
-
This reply was modified 1 month, 1 week ago by .
-
This reply was modified 1 month, 1 week ago by .
-
This reply was modified 1 month, 1 week ago by .
-
This reply was modified 1 month, 1 week ago by .
The syntax error may or may not be there. Oftentimes, during an error, the compiler craps out and spits out bad data after the initial error so it’s very hard to debug things all at once. C++ is a lot more type safe than C and requires that you specify the return and parameter types everywhere 🙂
I was getting that error in
common/dl_str.hfor the parameters so it sounded likeTCHARwasn’t being brought in for whatever reason, even though it was being set incommon/dl_base.hthrough a Windows macro check. That’s when I tried adding the Windows headerwinnt.hto it to see if that fixed the issue. According to Microsoft’s list, that’s the header we want.Sounds good. Let me know what you find out 🙂
We do have options, fortunately, but let’s see what you come up with before we start considering the other alternatives 🙂
Something’s broken with the
TCHARimplementation: https://github.com/deathssoul/MWEdit/actions/runs/23533305041/job/68502145150It started by complaining about the
TCHARtypedef incommon/dl_str.hnot being a type so I added thewinnt.hheader to it since the typedef wasn’t being picked up fromcommon/dl_base.h(probably being overridden somewhere in the spaghetti code) and then it started complaining about the system header itself.I’ll set it aside for right now but any ideas? It was building before so one of the overrides is borked. I could try narrowing it down by removing the redefinition from
common/dl_base.hor even making it a global typedef in a new namespace and adjusting the type in the project (will take a while but should fix it).That said, we do have a task item to switch over to proper Unicode handling anyways but I’m not exactly ready to tackle the conversion between character encodings as OpenMW differs from regular Morrowind
Things are moving right along. I hit the
game/morrowind/directory the other day so we’ll be able to do another test build soon. Once the push is done, we’ll see if anything else needs to be fixed to get things working without using thewindows.hheader.Any luck with getting VS up and running?
It’s possible things will build on MinGW now (or at least soon if they don’t already) so that’s something worth testing at some point. I’ve checked off everything that was on the list, at least. Further investigation revealed that the markers that I thought were generated code markers were in fact markers telling you that that code was stuff generated by the Class Wizard and they’re needed to properly use the Class Wizard. Since we’re working with the code instead, we’ll be able to remove those artifacts without issues (I think) and make the code more readable with less clutter in the way.
I’ve also added notes about non-standard extensions that we’ll want to swap out for portable functions. I’ve also already swapped out a few of them where they were relatively simple.
I’m also exhausted 😛