Jump to content

Cross-platform Infinity Engine Mod Package - brainstorming


AL|EN

Infinity Engine Mod Package file extension  

10 members have voted

You do not have permission to vote in this poll, or see the poll results. Please sign in or register to vote in this poll.

Recommended Posts

@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 by Wisp
Link to post

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).

 

Link to post
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 by subtledoctor
Link to post
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 by subtledoctor
Link to post
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 by AL|EN
Link to post

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 by subtledoctor
Link to post

Well, there is one more issue with the concept of setup-modname.app:

Mac OS Mojave, after launching .app:

- first window with confirmation:

image.png.1a5cf2266203d1bc028398822c86fea4.png

- after clicking "OK" another window for confirmation:

image.png.37223c6951f52698c72eb84ac782c354.png

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 by AL|EN
Link to post
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 by AL|EN
Link to post
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 by AL|EN
Link to post
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 by subtledoctor
Link to post
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 by AL|EN
Link to post
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.

Link to post
Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...