[Spastic Hamburger]

And 0.7.0 has been released 🙂

And all of the appropriate announcements have been made 🙂

[Spastic Hamburger]

Nope. Wasn’t able to find much on the community forums: just about everything I found dealt with doing restoration on your own, which isn’t feasible for me. I’ll probably need to reach out to that list and see what they say

In related news, this got announced last week: https://www.nintendo.com/us/store/products/legend-of-zelda-limited-edition-vinyl-8lp-set-127813/

No details about the pressings but I’m sure they’ll be fine

Used to have that happen all the time with old mice that simply used the rubber ball since it’d suck dirt up into the works. A simple cleaning always did the trick 🙂

Much harder now as it’s not as easy to access the mechanism 🙁

[Spastic Hamburger]

Sure, we can mirror it. That would definitely help.

Redistribution is definitely allowed per the license:

 For example, if you distribute copies of the library, whether gratis
or for a fee, you must give the recipients all the rights that we gave
you.  You must make sure that they, too, receive or can get the source
code.  If you link other code with the library, you must provide
complete object files to the recipients, so that they can relink them
with the library after making changes to the library and recompiling
it.  And you must show them these terms so they know their rights.

Yep. Went ahead and uploaded it here. GitHub is cranking away now so I’ll fix the tags tomorrow and finish publishing the new version 🙂

And updated the description of the DevIL mirror to comply with the license

[Spastic Hamburger]

So, new error today: looks like SourceForge is blocking the automatic download of DevIL from the CI but I can grab it fine with wget locally. Will need to come up with a new way of getting it. I’d rather not add DevIL back into the repository if I can help it. And I was just about to publish version 0.7.0, too 🙁

[Spastic Hamburger]

Looks like we have msitools over here. Will need to look into it

Looks like the fee is only required if the organization is making money so we should be good for now. 🙂

The biggest blocker to having support for other compilers at the moment is the generated code. VS uses its Class Wizard to generate it which isn’t supported by other setups. That’s still on the list. As I recall, MinGW required additional libraries to build stuff that makes heavy use of the Windows API so we’ll need to sort it all out when we get there.

Works for me. I’ll go ahead and start cleaning things up in preparation for 0.7.0 and then squash the CMake branch since the commit log is so messy. Afterwards, I’ll make a new commit bumping up the version number to 0.7.0.

For future versions, I’ll be setting things up to use CMake’s configure file command so that we can just pass the version number to the CMake build command. The code uses several different macros to handle the version number so we’ll need to do some hunting. It’ll also mean adjusting the resource file to use the variables as well but that’s a fairly simple matter (will reply to the resource file comment shortly!) 🙂

Edit:

Added a link to the cross-compilation issue 🙂

[Spastic Hamburger]

MSIX is for the Windows Store as opposed to a standard downloadable installer. May be something to consider down the road, however. It would require more work to get things running and I’m not entirely sure how to set the CI up for it. We can certainly add it to the tracker, though, as a long-term goal. It took Gimp years before they submitted it to the Windows Store, for instance 🙂

Edit: added to the tracker 🙂

I can ask the LOOT folks about the pros and cons as I’m sure they’ve done some consideration already. 🙂

Here’s the list of software that the Windows CI supports out of the box: https://github.com/actions/runner-images/blob/main/images/windows/Windows2025-Readme.md

There are some package managers in there but I’m unfamiliar with them so I’m not entirely sure how they work.

Anything in there that seems useful, in addition to what we’re already using? As wget isn’t included, we’re using aria2 which supports a similar syntax as wget.

Been a bit of a rough week so I haven’t been able to look too much into the installers yet. Hopefully next week will be better!

[Spastic Hamburger]

I have yet to watch Sweeney Todd. Missed out on the stage version, too. 🙁

Really need to fix that

Florida oranges aren’t doing so hot lately. Citrus greening is hitting the state pretty hard, even home grown ones. On the bright side, the fig trees are doing great

I generally don’t have issues with the wildlife beating me edibles in the wild: plenty of beauty berries still available. Really need to try making jam one day…

Used to harvest blackberries but the city cleared the bushes that I have access to, as well as most of the low hanging grape vines. Fortunately, I can still find some grapes that I can reach 🙂

[Spastic Hamburger]

It looks like you can use wine cmd <batchfile>.bat to run it under wine but I don’t currently have Wine installed.

Should run the same on Windows server as it does on regular Windows. Just a thought: any plans on a PowerShell version? It looks like Microsoft is trying to replace the batchfile language with PowerShell scripts.

Sorry, been busy with trying to figure out how to proceed with MWEdit. The installer business has kind of thrown me for a loop.

[Spastic Hamburger]

Yeah, we may need to forgo CPack as its feature set seems rather limiting. Its Inno support does look better than its WiX support, even though it is very much in the early stages (the docs definitely need some proof-reading). Wouldn’t give us the pretty MSI integration but the docs on using WiX (even the ones on the official Firegiant site) aren’t the best and it was hard for me to follow them when I read them yesterday. I’m just not very good at release engineering.

CPack also has decent NSIS support if we want to try to continue using it instead of simply splitting out the operation.

[Spastic Hamburger]

CMake sets up their shortcuts via template files: https://gitlab.kitware.com/cmake/cmake/-/tree/master/Utilities/Release/WiX?ref_type=heads

Not yet sure how they do it, I’m still analyzing things. It would help if this stuff were documented but alas.

Gimp, on the other hand, uses Inno Setup (as does LOOT) but Inno doesn’t create MSI files, which would be nice for integration. BOSS used NSIS but the syntax was pretty ugly.

[Spastic Hamburger]

CPack has an option, CPACK_WIX_PATCH_FILE, to add a WiX XML fragment to the files. We may be able to leverage that feature. Will take a look at that article when I get the chance and will poke around the web some as well. 🙂

There isn’t a whole lot of information regarding the features to use fragments, though. We may need to do some trial and error.

[Spastic Hamburger]

Okay, made those changes: https://github.com/deathssoul/MWEdit/actions/runs/18993040962

All files should now go in MWEdit/ instead of MWEdit/bin/ and I updated the commands for shortcut creation. 🙂

[Spastic Hamburger]

Perfect! Will get that fixed and then we can do a final test before the version bump and the update script test 🙂

No idea how to get the executable in the root of the MWEdit directory using CPack but I’ll add it to the wishlist!

Edit:

Looks like it’ll take the . option to the destination setting. Will try that for the next test to clean up the layout some

[Spastic Hamburger]

Did the shortcuts work before? We definitely want the options. Apologies, the shortcuts are probably the least documented part of CPack.

Does the license show up properly now?

[Spastic Hamburger]

Okay, here’s a new attempt: https://github.com/deathssoul/MWEdit/actions/runs/18967509920

It should put all files in the bin directory (will add a note to look for the extra data files elsewhere on the tracker later) and hopefully it fixes the issues with desktop shortcuts and Start Menu entries. I also changed the LICENSE file to LICENSE.txt as the docs make it sound like a file extension is required for importing even though standard practice is to leave the extension off on *nix.

[Spastic Hamburger]

Thanks. That’s probably due to me using the DATA file type. The install system on CMake is poorly documented for anything other than *nix, sadly. I may be able to force them into the same directory, will look into it. Eventually, we’ll want to clean up the directory structure some but that requires more work in the code to look for the required data files elsewhere. Windows is a bit restrictive on DLLs so we’re probably out of luck on that front.

Did some looking yesterday and it looks like I used the wrong commands for the Start Menu and Desktop shortcut options. WiX has its own options but you need to use properties instead of variables for it: https://cmake.org/cmake/help/latest/manual/cmake-properties.7.html#properties-on-installed-files

Don’t know how to use them yet but I’ll see if I can figure it out. Hopefully those fix that issue. My guess is the poor documentation is a result of CPack just not being used a whole lot: most projects write their own installer scripts separate from CMake.

[Spastic Hamburger]

Linux doesn’t support Batch files but Shell syntax is similar: https://www.gnu.org/software/bash/manual/bash.html

Most of the basic commands have similar versions on Linux, too. May not be too difficult to put together a Shell script, as well? 🙂

[Spastic Hamburger]

Crumpets. The license should be getting imported. I’ll have to take a closer look at the commands. I definitely have that option set but I may need to update the file format

What’s in the Config directory? That’s new.

Are the DLLs anywhere? May need to tweak the directory layout. What’s the directory structure look like? They’re definitely getting bundled into the file, sounds like they’re just not getting in the right spot. Where are the .dat files? They should be getting dumped to the same place

Is the option for a desktop shortcut not working, then? Will look into the Start Menu stuff. It’s possible I used the wrong options

Haven’t had to chance to look at it yet but I’m not sure Linux can run Windows style Batch scripts.

Edit:

Provided some compatibility information in the other thread. May not be too hard to update it for Linux 🙂

Removed the installer from the other sites for now as it doesn’t sound like it’s working properly

[Spastic Hamburger]

We now have an installer in the MSI format: https://github.com/deathssoul/MWEdit/actions/runs/18903584084/artifacts/4403855739

If possible, could you do a test run and report back as to its behavior? I have no clue if it’s set up properly. 😛

I’ll put out a testing call on the other sites later. 🙂

Edit:

Posted to the other sites. Additionally, the CMake script is now cross-platform compliant even if MWEdit still builds only on Windows. Still need to add the options to build a static executable when cross-compiling. That’ll be a bit hairy as things stand right now so I’ll add that to the to-do list.

Edit 2:

Looks like I may need to pass the Unicode macro after all as it’s used in dl_base. Missed that earlier. Of note, the old VS project file doesn’t have Unicode set to on. Will wait to see what the test results come back as. Enabling Unicode may be a thing for 0.7.1

Edit 3:

New package: https://github.com/deathssoul/MWEdit/actions/runs/18935772066

Has some DevIL updates 🙂

[Spastic Hamburger]

We now have a 64-bit build of MWEdit. Swapping out the 32-bit version of DevIL did the trick. Now I just need to clean everything up and we can decide on a build system. The packaging script needs fixing: apparently, GitHub Actions preserves the directory structure during packaging so we have an unusable archive without moving the files around after download. Maybe it’s time to set up an install script? CMake supports WiX through CPack for MSI creation, along with RPMs and DEBs for Linux. Perhaps we can start with the provided options before looking at custom install scripts, depending on how difficult CPack is?

Leaning towards CMake. While Meson is definitely cleaner it lacks features and it’s a bit cumbersome to do more than the basics. That said, I’m definitely open to other opinions. 🙂

Probably worth doing a release after the packaging is sorted out as 64-bit support is a rather important change

Edit:

Just updated the threads with the latest news 🙂

[Author]

Posts