Jump to content

subtledoctor

Modders
  • Content Count

    3,051
  • Joined

  • Last visited

About subtledoctor

Profile Information

  • Gender
    Male
  • Mods Worked On
    Scales of Balance
    Might & Guile
    Faiths & Powers
    NPC_EE
    APR on Spec
    Hardcore Dual
    Mac Weidu Launcher

Recent Profile Visitors

16,893 profile views
  1. You know AL|EN, if you are handy with shell scripts as you seem, maybe you can help me convert the Weidu Launcher to a .command file. There's no technical reason it won't work, and a shell script would be more efficient than my Applescript. The only thingbit would lose vs. an .app package would be the ability to bundle Weidu with it. (And the ability to give it a fancy icon.)
  2. I have Mojave, and my Weidu Launcher doesn't have this issue... :shrug:
  3. 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.
  4. 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.
  5. 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.
  6. You mean if the mod is bg2_folder/cdtweaks/setup-cdtweaks.tp2 ...then I can invoke it by ./weidu cdtweaks/cdtweaks.tp2
  7. 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.
  8. 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. Setup-modname.zip
  9. As mentioned elsewhere, I dislike the idea of curated .command files for every mod. It is archaic and silly. You could probably write a .command script that does exactly what my Launcher does - poll for any .tp2 files present, and ask the user which one they want to install they run the command. This could be done in Perl or Python or whatever scripting language you like - macOS allows them to hook into the filesystem and UI for simple interactions like that. There's nothing magical or particularly great about my Weidu Launcher; it only uses AppleScript because AppleScript is the only scripting language I've ever worked with (apart from Weidu, I guess). Note, this does not just apply to macOS. The same holds for Windows - do we really need to ship a separate Weidu executable with every mod? Using its filename to tell it what to execute?? It's a bit ridiculous. At least in windows the launcher and the Weidu source are together in one package! If we are to have a distinct .command file for every mod, I would prefer Weidu to ship with them, and combine the install script and the Weidu source in a single little .app package. Then at least Windows and Mac users would be on the same footing... And in an ideal world, both of those ideas would be combined. Every mod could ship with a single item: the mod folder. And Weidu executables on every platform would work with all mod folders. tl;dr: I don't really care because whatever a hypothetical .command looks like, I've never actually used one before and I don't plan to start using them now. There is a better way.
  10. subtledoctor

    Progress

    Time is money but money is not time. A small donation would not afford any contributors the ability to take time away from their day jobs, so it would not get the mod made any faster. And taking time away from *making the mod* in order to put together a trailer or gameplay preview is not a great idea either. There's no rule against accepting donations, but almost every modder has declined them when offered, IMHO for good reason.
  11. ^ What he said. I don't disagree that it might be interesting if the AI could do that stuff. But it can't. AI scripts cast spells every 6 seconds. They cannot cast earlier than that in order to counterspell, and I cannot imagine a script that would let them wait longer (how much longer??) in order to attempt a counterspell. Every caster has an individual round timer - they are not sync'd up. If an enemy caster's round starts when he sees your front-liner and your back-line caster's round begins a split second later, then your caster will always be casting a split-second after the enemy. Which means you can always counterspell, and the enemy can never counterspell. The human has the ability to pause, to manipulate that timing; the AI does not. A counterspell kind of mage duel mechanic can only work if the rounds are simultaneous. Or, even better, if there was a 5E-style reaction/bonus action system. But those are impossible to implement in this engine. Attempts to simulate that kind of system would only introduce ways for human players to easily stun-lock enemy casters. If you really want to remove your informational advantage over the AI, then like I say, the most effective and realistic way would be to remove the information. Which would be super easy to do.
  12. subtledoctor

    Dealing with anti-spell protections

    With II, Nondetection preserves the massive +4 bonuses to saves and AC. With regular invisibility, yeah, someone who can see invisible things can see you when you are invisible. Nondetection stops your invisibility from being out-and-out dispelled. It's more SI:Div than Nondetection. (We discussed elsewhere the possibility of changing its name to "Protection from Divination" or the like, which I support.) EDIT - worth noting: with SR, Nondetection stops basic invisibility from being dispelled, which means enemies have no sprite and no selection circle, so even with opcode 193 you cannot target them. This seems to be a 'truer' version of Nondetection... but if you turn on party AI, the character with 193 can auto-attack the invisible person. And I believe AI mages can target you right through Nondetection, because their AI targeting does not have the limitation of the player's need to click a sprite on the screen. So TnB evens the playing field, at the cost of kinda-sorta nerfing Nondetection. (This might be an alternative place where we can add some external benefit, like Spell Evasion or a save bonus or something, to offset the nerf. That would be easy enough to add.)
  13. subtledoctor

    Dealing with anti-spell protections

    SR's use of 193 allows you to penetrate Improved Invisibility, but not basic invisibility. TnB covers both - someone with basic invisibility + nondetection in a TnB game could be targeted by a mage who casts See Invisible, but not by the mage's companions. The code used to achieve that is limited to the EE engine, so I don't recommend that SR do the same thing. EE players who want the more comprehensive version can just install TnB.
  14. subtledoctor

    Dealing with anti-spell protections

    To be clear, I'm not suggesting anyone change anything. (Well, I think SR's use of 193 could be more comprehensive, but players can get that in Tome & Blood when installed on top of SR, so I don't think SR itself needs to change.) SCS is a bit different but they work fine together - SCS doesn't totally circumvent SR's mechanic because even if it Pierces your Deflection while you are invisible, it still cannot target you with Breach or other spells. So the AI can work well with the long-tested SCS spell battle mechanics but the player can have the consistency of SR/TnB invisibility mechanics. In other words, "it's just so inconsistent" is not a knock on anything - it's just an explanation why I prefer to add SR and/or TnB to SCS. They work fine together; changing SR is unnecessary.
  15. subtledoctor

    Feedback: IR v4 Beta

    My personal answer is to set them to do crushing damage, making them unique among missile weapons. But that's not for everyone.
×