Jump to content

MAC OS weidu launcher mod_order.txt


Recommended Posts

22 minutes ago, AL|EN said:

One of the possible solutions to the "install SCS IWD Spells early" challenge would be to use SCS IWD spells component labels, '--ask-only' + some additional logic. This would require some coding work and other stuff but it's definitely possible.

Indeed. In fact I am the one who requested that option be added to Weidu, specifically with this app in mind. With a really well-curated list and code added to the app to support parsing it, it would be glorious! But, I don't know if I will ever get around to implementing it.

Link to comment
2 hours ago, AL|EN said:

Tell me, does this feature is worth replacing your app with something new, along with the new data format for mod_list.txt?

I don’t think I understand the question. 

To clarify, this is my idea:

— For mods that are installed in one go, nothing changes, the list simply contains the .tp2 name and brings up the usual command line Weidu installer

— In some cases like IR, SCS, NPCs with separated cross-mod content, I would use some special delimiter like :: that the Applescript can recognize; and when it is present, it would modify the Weidu command to include the --ask-only parameter with all components that are listed after the delimiter. Practically speaking, I would probably only use the -- ask-only parameter the first time a mod appears, and bring up the normal Weidu prompt the second time. 

The mod list would need more/better curation than it has right now (!), and the script to recognize the delimiter and component numbers would need to be added. But those things could easily be added to the app as it exists right now - the only thing stopping me is the cost/benefit analysis of the time required to do so. 

As far as “something new” goes… well, as I said a couple years ago, if PI was cross-platform I couldn’t have bothered to make this. But here we are. 

EDIT - another option would be, after choosing a mod, bring up a list of components and have the user choose one or more to install via --force-install-list. The catch here is, while the app could do this fairly easily, I don’t think I have the abilities to code it to parse .tp2/.tra component names/numbers/labels. More likely I would use a static list in a separate text document, which would then also have to be curated. And revert to existing behavior if the chosen mod is not in the secondary list. This would be even better for users than --ask-only, but definitely harder to implement.

Edited by subtledoctor
Link to comment

My question was about the MWL-specific workflow that you have used for so long: having a list of mods in a tiny window> launching the weidu console > interacting with it> repeating until the last mod. Some things aren't easy to let go. The alternative workflow proposal indicates that you already have a better idea in your mind. This is great except for the part where you rely on a 'static component list' - even if it's doable, don't go that road. 

Let me play with applesctipt + bash, but I fear that it might be too much of a challenge.

Link to comment
51 minutes ago, AL|EN said:

My question was about the MWL-specific workflow that you have used for so long: having a list of mods in a tiny window> launching the weidu console > interacting with it> repeating until the last mod. Some things aren't easy to let go. The alternative workflow proposal indicates that you already have a better idea in your mind. This is great except for the part where you rely on a 'static component list' - even if it's doable, don't go that road. 

Let me play with applesctipt + bash, but I fear that it might be too much of a challenge.

Ah, well that came about for several reasons. 1) I have some little experience with Applescript (invented an Airplay system 10 years before Airplay existed); 2) the aim was simple, as i say, just to launch Weidu for a particular mod rather than having to manually navigate through the Terminal and type in the install command; and 3) most importantly, as Apple has progressively clamped down on what users can do in the OS, this has to stay very lightweight and NOT be an actual app. That "tiny window" is not actually a window; it is just a displayed list generated by a script. That's why the Applescript outputs a text result in an actual .txt file and then runs it as a .command. Or whatever. There are no actual windows or UI elements... just some shell scripts triggered by an Applescript. It has to stay that lean in order for everyone on different versions of the OS to run it without tripping over security measures. And I'm not about to shell out a fee for a developer license - not least because I am in no way shape or form a developer! :laugh:

Finally, as far as being attached to a workflow, more important than any of that, is the fact that it works well now and I enjoy using it, and every time I think about improving it I there are 10-15 other things I could do that are more important and/or enjoyable. :p So we end up with the status quo...

Link to comment
On 10/16/2023 at 4:21 AM, subtledoctor said:

There is possibly 4udr4n's project, but when I went to see if I might take it as an example, they seem to be waving people off

Big update done over the last 24 hours, should be a good starting point, has a lot more compatibility data now.

If anyone has time to review their own mods on there and comment or reply in the thread with any suggestions that would be great.

Link to comment

So even after seeing the recent shit regarding the install order that you are facing, I see no way to move forward with AppleScript. It's just too limited if you want to do something more than "a list of items" even with shenanigans and workarounds. The amount of time that would be required is far greater even when rewriting from scratch by learning and using popular tech like Python+QT, Electron etc. So if you ever questioned yourself about "Should I try to add yet one more tiny feature" and your answer was 'Nope', it was the correct answer 😉

Link to comment
On 10/17/2023 at 3:26 PM, DavidW said:

The short response to this is that if people want the spells earlier they can get them from IWDification. There will be some more to address this when v35 releases, but one thing I won't do is just remove the IWD spells from SCS entirely - plenty of people would not know about them and would miss that content, even though IWD spell use is a significant part of the mod content and most SCS players use it. (It's worth noting that plenty of people play SCS-only, or SCS+Ascension+Tweaks Anthology only, or other very small boutique installs - I want to cater to them as well as people doing PI megamods.)

SCS IWD having globally unique labels would provide strong fundamentals for dealing with this challenge in the future.

Link to comment

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.

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