{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifbdzsfifptk6dyzjz36z64jtsrpwfdpcx7pqs757klgyk4kmaqhy",
    "uri": "at://did:plc:pvz7ox4x2ehjiezsahttqyyz/app.bsky.feed.post/3mgnxtbfjoxi2"
  },
  "path": "/viewtopic.php?p=449938#p449938",
  "publishedAt": "2026-03-09T09:55:49.000Z",
  "site": "https://forum.luanti.org",
  "tags": [
    "16302",
    "changelog",
    "tracker",
    "Blockhead"
  ],
  "textContent": "> Thanks for the suggestion. For my use case, the batch/.cmd approach feels a bit cumbersome (for example, no straightforward icons and a console window appearing, unless additional tools are used), and many typical Windows users may not feel very comfortable working with .bat/.cmd files.\n\nWhat can I say? I'm used to working this sort of way I guess, as a Linux user. Windows is to blame for opening a terminal for every script, too, that's not how it goes on Linux.\n\n\n> I see what you mean about using the .zip, but in my case the .zip ends up mixing Luanti data and configuration with the software binaries, so it doesn’t really fit the setup I’m aiming for.\n> Ideally, the user would be able to choose where Luanti data and configuration are stored. Because of that, I went with the .exe, which at least allows a clear separation between Luanti data/config and Luanti binaries via MINETEST_USER_PATH. The downside is that this approach is no longer fully portable, since it depends on an environment variable.\n>\n> I’m actually trying to keep a nicely separated data/binary portable installation, and the current options make that a bit harder than it could be.I think it’s generally good practice to separate binaries from configuration and data (in Luanti’s case, for example, the worlds).\n\nAgain, consider it my own bias as a Linux user, but in times gone I would have suggested the .zip, but using directory junctions (or soft/hard links, but junctions were always my preference on Windows, nowadays I am an ex-Windows-user). Nowadays, Luanti won't follow some links as a security measure, especially not out of the top level directory. See #16302.\n\nI get your desire to separate binaries from data. Luanti hasn't done this well historically, rather Windows users would typically copy the relevant subdirectories out of their old version directory into their freshly unzipped new version directory, like my own old list of subdirs:\n\nCode:\n\n\n    depr_minetest-5.1.0-win64minetest-0.4.17.1-win64minetest-5.0.0-win64minetest-5.2.0-win64minetest-5.3.0-dreambuilderminetest-5.3.0-win64minetest-5.4.0-win64minetest-5.5.0-win64minetest-5.6.1-linuxminetest-5.6.1-win64minetest-forks\n\nFor separate copies of data that you can see I used, I considered it negligible to just make a copy of the binaries, being only 22 MiB for Minetest 5.6.1. But of course space is more precious on a USB drive than a hard disk.\n\nEdit2: At this point, it's also worth discussing the fact that there are changes inside of the 5.x series that are backwards-incompatible (changelog:\n\n\n  1. Worlds made on 5.12.0 have a new schema that divides x, y and z into separate fields\n  2. 5.9.0 requires nodeboxes and mesh nodes to use_texture_alpha definitions to render transparently\n  3. 5.5.0 stores mod storage inside of a database instead of text, and also mapblocks are now saved compressed with zstd instead of zlib.\n\n.. so mixing and matching engine versions is not a great idea.\n\n\n> Would it be possible to consider something like a --run-dir argument, or a luanti.config file with a line such as LUANTI_USER_PATH=D:\\xxx\\? This is a pattern I’ve seen in many other portable programs, and it works quite well in practice. It keeps installation simple for users who don’t care about separating data and binaries, while also giving those who do care the flexibility to organise their data as they prefer.\n\nThose are both valid suggestions you could add to the tracker, where you'll get more discussion happening too (sorry, we're kind of fragmented between platforms). Those would obviate the need for batch files where you could just have shortcut files instead. Mind you, another feature of Windows .lnk files is that you can set up a different running directory, but I couldn't tell you if that works for your use case.\n\nOh and it's definitely MINETEST_* still for the environment variables, changing those was considered too breaking, nor were new aliases added - that adds the chance of both being set too, for one thing. But for a new variable it makes sense to use the new name.\n\nEdit1: FWIW, and I don't think it works on Command Prompt, but bash lets you prefix a command with some environment variables, so this works:\n\nCode:\n\n\n    MINETEST_USER_PATH=/path/to/userdir luanti\n\nbut probably not on a Windows .lnk file, Command Prompt has a separate \"set\" command IIRC.\n\nStatistics: Posted by Blockhead — Mon Mar 09, 2026 09:55\n\n* * *",
  "title": "General Discussion • Re: In Windows, is there a luanti.exe argument to specify what the MINETEST_USER_PATH environment variable specifies?",
  "updatedAt": "2026-03-09T09:55:49.000Z"
}