Wisp Posted July 15, 2019 Share Posted July 15, 2019 (edited) @AL|EN In that case, I don't understand. You want to propose a second new packaging convention, only this one retains platform-specific stuff inside the mod archive? And at that, one that does not include WeiDU in the mod archive, but instead downloads a mod-specific WeiDU at run-time? It seems nonsensical. You are still including WeiDU in the mod archive, just in a roundabout way. Or have I misunderstood? Edit: yes, I have. The WeiDU would be shared amongst mods. Perhaps also relevant is that the interactive-installer parts that setup-mymod.exe and equivalent solutions rely on are slated to be removed (when this happens is, of course, a fun guessing game). Edited July 15, 2019 by Wisp Quote Link to comment
lynx Posted July 15, 2019 Share Posted July 15, 2019 The first linux command line has an errant "fi". There's no need for the exports. The test for weidu is incorrect — would only work from the same dir. If you force the dependency on bash, then it could be looked up via hash (shell builtin), otherwise "which" is the standard approach and just running it and inspecting the return value the one that will definitely work everywhere (rc is 127 in case of failure). Quote Link to comment
subtledoctor Posted July 15, 2019 Share Posted July 15, 2019 (edited) On 7/15/2019 at 10:20 AM, AL|EN said: So you basically want to exclude all weidu/weidu launchers from mod packages, right? My point is that there's something to be said for overwriting a single thing that can work with all mods, rather than copying a separate instance for each mod. You seem to be very against overwriting, and I'm not sure why. (Note, this of course would have no effect on mod managers, which can get Weidu on their own and only need the mod folder.) ------------------------------------- Okay, you made me waste an hour fiddling around with my Weidu Launcher. Here is a specialized variant. Unzip the attached file into your game folder in MacOS, rename it to whatever mod you want to install ("setup-cdtweaks" or whatever - make sure it includes "setup-" at the beginning). Then, with that mod folder present, double-click this app. If I did it right, this should work exactly like a Windows "setup-modname.exe" executable: rename it to match the mod, and go. It includes Weidu v246, copying it into the mod folder as a file called "weidu" (* see below), then makes a symlink for the mod matching its name, then opens Terminal and begins to install the mod, then cleans up after itself by deleting the symlink. Modders can include this with their mod, and don't have to do anything except 1) rename it just like the Windows version, and 2) if necessary, put an updated version of Weidu into "setup-modname.app/contents/resources/." * I use the filename "weidu" with no extension because that is how Weidu ships on MacOS. The point here is, if a modder includes an out-of-date version of Weidu in this package, a player can go grab the most recent version, and this package will defer to the player-supplied version instead of the bundled one. Players get an easy way to insure against mods going out-of-date, and don't have to rename anything to get that benefit. Again I don't think this will interfere with Linux because the .app won't run, and thus won't copy "weidu" into the game folder, on Linux. Edited May 14, 2020 by subtledoctor Quote Link to comment
AL|EN Posted July 15, 2019 Author Share Posted July 15, 2019 @subtledoctor Quick tip: instead of creating symlink/alias, can you try to simply execute bundled weidu with parameters? Like this: ./weidu ${mod_name}/${mod_name}.tp2 --log "${mod_name}.debug" Quote Link to comment
subtledoctor Posted July 15, 2019 Share Posted July 15, 2019 (edited) 29 minutes ago, AL|EN said: @subtledoctor Quick tip: instead of creating symlink/alias, can you try to simply execute bundled weidu with parameters? Like this ./weidu ${mod_name}/${mod_name}.tp2 --log "${mod_name}.debug" Isn't Weidu pretty finicky about where it runs? How do I make the internal copy run from the game folder? EDIT - whoops, you mean run the copy that is already in the game folder. Interesting. Let me see. EDIT 2 - that's going to be annoyingly finicky, due to the lack of uniformity regarding the inclusion of "setup-" in .tp2 filenames. By running Weidu as a symlink with the modname directly, I can much more easily handle that by making sure it always includes "setup-" because in that instance, it actually should. Edited July 15, 2019 by subtledoctor Quote Link to comment
AL|EN Posted July 15, 2019 Author Share Posted July 15, 2019 @subtledoctor You don't have to care about 'setup-', trust me on this. Just use replace function from this https://stackoverflow.com/a/38042023 and remove 'setup-' from mod_name variable and execute the code above. Quote Link to comment
subtledoctor Posted July 15, 2019 Share Posted July 15, 2019 2 minutes ago, AL|EN said: @subtledoctor You don't have to care about 'setup-', trust me on this. Just use replace function from this https://stackoverflow.com/a/38042023 and remove 'setup-' from mod_name variable and execute the code above. You mean if the mod is bg2_folder/cdtweaks/setup-cdtweaks.tp2 ...then I can invoke it by ./weidu cdtweaks/cdtweaks.tp2 Quote Link to comment
AL|EN Posted July 15, 2019 Author Share Posted July 15, 2019 (edited) 5 minutes ago, subtledoctor said: You mean if the mod is bg2_folder/cdtweaks/setup-cdtweaks.tp2 ...then I can invoke it by ./weidu cdtweaks/cdtweaks.tp2 Yes Ups... not goona work Well, the nonsense bullish of 'setup-' strikes again...Just screw this, I guess this will enforce the standardization even more. Edited July 15, 2019 by AL|EN Quote Link to comment
subtledoctor Posted July 15, 2019 Share Posted July 15, 2019 (edited) Doesn't seem to work. If I rename "might_and_guile/might_and_guile.tp2" to "might_and_guile/setup-might_and_guile.tp2" then this: ./weidu Might_and_Guile/Might_and_Guile.tp2 --log Might_and_Guile.debug ...fails. EDIT - but I can probably work around it. Edited July 15, 2019 by subtledoctor Quote Link to comment
AL|EN Posted July 15, 2019 Author Share Posted July 15, 2019 (edited) Well, there is one more issue with the concept of setup-modname.app: Mac OS Mojave, after launching .app: - first window with confirmation: - after clicking "OK" another window for confirmation: then finally console appears. And from what I've found, there is no way to avoid it (please correct me if I'm wrong, I'm not familiar with macOS at all) thus .command files still have one advantage of not requiring such confirmation (if using 'setup-modname' approach, I'm much more of a fan of separate 'mod manager') Edited July 15, 2019 by AL|EN Quote Link to comment
AL|EN Posted July 15, 2019 Author Share Posted July 15, 2019 (edited) 3 hours ago, lynx said: The first linux command line has an errant "fi". There's no need for the exports. The test for weidu is incorrect — would only work from the same dir. If you force the dependency on bash, then it could be looked up via hash (shell builtin), otherwise "which" is the standard approach and just running it and inspecting the return value the one that will definitely work everywhere (rc is 127 in case of failure). Sorry but I didn't understand any of this, my command works so I was counting on the feedback regarding 'How convince is to use it for linux players' under the assumption that they want to have the same, easy way of installing weidu mods as windows users. Edited July 15, 2019 by AL|EN Quote Link to comment
AL|EN Posted July 15, 2019 Author Share Posted July 15, 2019 (edited) 14 hours ago, Wisp said: @AL|EN In that case, I don't understand. You want to propose a second new packaging convention, only this one retains platform-specific stuff inside the mod archive? And at that, one that does not include WeiDU in the mod archive, but instead downloads a mod-specific WeiDU at run-time? It seems nonsensical. You are still including WeiDU in the mod archive, just in a roundabout way. Or have I misunderstood? Edit: yes, I have. The WeiDU would be shared amongst mods. Perhaps also relevant is that the interactive-installer parts that setup-mymod.exe and equivalent solutions rely on are slated to be removed (when this happens is, of course, a fun guessing game). Yes, the idea is to have two packages: one iemod with only mod files and zip with addition of three platform-specific stuff inside the mod archive: mymod.desktop, mymod.command and mymod.bat. The motivation is: currently, there is no released mod manager which works on macOS/Linux so the modders can't repack their mods and require mod manager which would open the .iemod files. So there is a need for temporary solution: creating two types of packages until there will be mod manager for macOS/Linux. So far, my proposed solution combines two worlds: not including per-mod weidu and at the same time keeping "Double-Click to install" feature. As for removing "interactive-installer parts" you said it: a fun guessing game, we have to confront today's reality, not some undecided future. Besides: it would be a matter of removing 3 files from mod package, that's all. P.S. AFAIK, "Zeigeist" support double-click for .iemod files and has "global weidu" support. Why not just release it and make the secondary package unnecessary? Edited July 16, 2019 by AL|EN Quote Link to comment
subtledoctor Posted July 15, 2019 Share Posted July 15, 2019 (edited) 2 hours ago, AL|EN said: there is no way to avoid it (please correct me if I'm wrong, I'm not familiar with macOS at all) Just don't do this stuff in the root directory. EDIT - it's a good place to point out another benefit of MacOS: anything can run from anywhere, and copying the game into a user folder is a great way to keep a pristine backup of the unmodded game. Just something like: - Install the game from the client of your choice... - Find the game's .app file... - Copy that to your desktop, or ~/documents, or ~/Applications, or anywhere you like. - Mod the crap out of your new copy. - It will run no problem from wherever you put it. - If you need to do a clean install, the original version is still right there. This is a good way to make sure that app updates like Steam's don't mess up your modded game. Edited July 15, 2019 by subtledoctor Quote Link to comment
AL|EN Posted July 15, 2019 Author Share Posted July 15, 2019 (edited) 3 minutes ago, subtledoctor said: Just don't do this stuff in the root directory. But I'm extracting "setup-mymod.app" into game directory, then I'm launching it. How I can do it otherwise? Do you have the same popups/Mojave? Ok, I've read beamdog reply Edited July 15, 2019 by AL|EN Quote Link to comment
subtledoctor Posted July 15, 2019 Share Posted July 15, 2019 1 minute ago, AL|EN said: But I'm extracting "setup-mymod.app" into game directory, then I'm launching it. How I can do it otherwise? Do you have the same popups/Mojave? I don't understand. Extracting != launching. I meant above, move your BGEE game out of the root directory. Just like Windows: the OS doesn't like it when you mess with official applications in official locations, like /Applications. Move or copy the game itself into /Users/you/Applications, or /Users/you/Desktop, or something like that. Then put the Weidu .app into the game folder and it should run without a hitch. Quote Link to comment
Recommended Posts
Join the conversation
You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.