Jump to content

Loriel

Modders
  • Posts

    39
  • Joined

  • Last visited

About Loriel

  • Birthday 01/04/1977

Profile Information

  • Gender
    Male

Contact Methods

  • Website URL
    http://loriel.quixjote.com/
  • MSN
    loriel.macinfinity@hotmail.com
  • ICQ
    22537168

Loriel's Achievements

  1. First of all, thanks to CamDawg for compiling this tutorial and for helping to make all the G3 mods Mac-friendly! All four of us that download and use them are extremely appreciative! Second, I'd like to give a (hopefully) better solution for listing all the .ogg files in the .command script. I'm going to assume that the reasoning behind listing the files in the ogg_files variable is for two reasons: expansion of wildcards doesn't work with sox (as stated in the tutorial) and that you only want to affect the .ogg files used by this particular mod (not all .oggs by any mod). While listing all the oggs will work, there is a much simpler way of doing it that will save on potential install issues from spelling errors. #!/bin/sh ogg_files=`ls path/to/audio/folder | grep '.ogg'` for file in $ogg_files; do echo Converting $file... path/to/sox path/to/audio/folder/$file override/${file%.ogg}.wav done Notice the backquotes used in the ogg_files variable (same key as the tilde). They tell the script to use the output of this unix command. This will simply make a listing of all the files in your mod's audio folder that have .ogg in the filename, thus eliminating the need to manually type each one. For uninstalling the wavs, you will need a slightly modified version: #!/bin/sh wav_files=`ls path/to/audio/folder | grep '.ogg' | sed s/.ogg/.wav/g` for file in $wav_files; do if [ -e override/$file ]; then echo Removing $file... rm -f override/$file fi done This time, the script took the list from the audio folder and substituted the .wav suffix (instead of .ogg). Then, it checked for the existence of the file in the override folder before deleting each one. Finally, I have run into a problem with early versions of OSX that makes the script choke. The problem comes from the fact that it runs as if located at the root of the system (which isn't where BG2 is!). To compensate for this problem, you can simply add this snippet to the top of the script: #!/bin/sh command_path=${0%/*} cd "$command_path" # rest of the script below... I use this in all my scripts that must affect files relative to the script's location (such as installing the mod/ogg/tiz, etc). It simply assigns the absolute path of this script's location to the $command_path variable, then cd's to it. Makes life easier for the tech support people...
  2. Ditto on the Disable Button... For the spell slots, can't you use effect #62 Priest Spell Slots Modifier? Just use one effect for every level and give negative spell levels.
  3. But the kit would still be available by using AddKit() wouldn't it? You just couldn't select it at character creation. Or does AddKit() also check for race restrictions?
  4. Let me just clarify - when I'm making my kit with Weidu, what do I put in the section for race restrictions? Will Weidu choke at that point if the 2da's don't exist? Do I need to put the K_M_X stuff even though the files aren't present or do I leave it blank? I'm not worried about it not being selectable at character generation, but I would rather not have to do a stupid jester dance (pun intended) just to apply a mage kit.
  5. You mean we don't have to assign the K_M_X to mage kits? <frustration>*Commences hair pulling and screaming*</frustration> I share the common sentiment of "Why did they all say it was hardcoded, darn it!" This is what I've been doing for all my mage kits: Create a bard kit Create a script for changing to mage kit: IF blah THEN RESPONSE #100 ChangeClass(Myself,BARD) AddKit(BARDKIT) // Add my kit ChangeClass(Myself,MAGE) ApplySpellRES("kitspell",Myself) // This spell fixes all the problems that changing to a bard created. END Wish I had seen this earlier!
×
×
  • Create New...