Jump to content

khelban12

Members
  • Content Count

    136
  • Joined

  • Last visited

About khelban12

Recent Profile Visitors

3,524 profile views
  1. Wasn't there a debate a long time ago about which is the correct value for grandmastery ? Something that it shouldn't give +1.5Apr but only +1 Apr (or +0.5 from specialization like greenhorn said). The readme said +1 and the implementation gave +1.5. I don't think a consensus about which is the correct value was reached and in the end the readme changed to reflect the implementation. I may misremember though.
  2. Greetings. Thank you for another great mod. All mods that give more content to Imoen are welcome. I have some questions: 1) Is there a different story incentive to go to Brynnlaw if you have Imoen in the party ? 2) Do you have any idea about compatibility with the "Imoen Friendship" and "Imoen Romance" mods ? I guess since the dialogs start when you rescue Imoen from Spellhold, the mods should work fine (but you won't get any dialogs during your travels before brynnlaw ofcourse) ? 3) The mods that mess with Imoen2 and Imoen variables like "Eternal Imoen" or "Continuous Imoen" are incompatible i guess ? Thank you
  3. More a question rather than a bug. The usual installation order until now was Ascension -> Wheels of Prophecy -> Edwin Romance at least according to BWP because Edwin Romance has different dialog has code that accounts for WoP so it should be installed after it. The readme in v2.0.6 has been updated and says that WoP should be installed after ascension (as always) but ER should be installed before ascension and therefore before WoP too. Will this new order pose a problem for the interaction of ER and WoP ?
  4. I read in your weidu.log that you have ascension 2.0.3 installed. Is it possible that you have the same problem as me with opcode 282 ? @DavidW does the later installation of SCS 32.2 which has the fixed Detectable Spells version undo the damage from the ascension DS ?
  5. Bugs will always slip through. Don't sweat it. If it wasn't clear from my message i am grateful for all your effort and for the great mods you give us. I wasn't trying to put blame or something like that. As a temporary workaround, i copied all .spl files and ran DELETE_SPELL_EFFECT with opcode_to_delete=282 and (at least up to the point i have played) i don't have any crashes.
  6. Does anyone else get crashes on classic BG2 with tobex engine ? I started a new playthrough and in Waukeen's Promenade after the cutscene ends, i immediately got a crash. I tracked it down to the mod ruad. It uses a script that runs the wizard spells "protection from fire / cold". I removed every mod but tobex, bg2fixpack, ascension and i can still trigger the crash. I tracked it down to the DS component of ascension that adds a set scripting state (282 opcode) with BUFF_PRO_DAMAGE to some spells. If i remove this effect, everything works correctly. I tried to understand what the problem is but couldn't and IESDP doesn't have much information. In my case, the BUFF_PRO_DAMAGE stat gets the number 233 so the effect uses the number 77 (156 + 77 = 233). If i modify spwi319 and try to set other states, i get crashes with some numbers (e.g 50, 60) but it works with others (e.g 49, 65). If i give BUFF_PRO_DAMAGE the number 236 in stats.ids and modify the effect accordingly (to 80 so that 156+80 = 236) it works without crashing. It seems to work with some numbers and crash with others. It is likely that the crash happens with other spells too and i just happened to notice it with Protection from Fire (at least all the BUFF_PRO_DAMAGE spells should crash). If someone has a classic BG2 installation and wants to test it, some rough steps are the following: a) install tobex, fixpack and ascension b) start a TOB game (to avoid the lengthy Irenicus cutscene), import TOBMAGE character c) clua in scrl6h (which runs spwi319.spl) d) use it on yourself.and see if it crashes. Also, does anyone know a fix for this ? Thank you
  7. Greetings. Does wheels of prophecy 8.2 fail to install on someone else ? When i have only installed ascension components 0, 10, 20, 30, 40, 50, 60, then WoP fails to clone balelit creatures because they don't exist. I had to install ascension component 1100 (Tougher Balthazar) and then WoP installs correctly. Edit: I did a quick browse of the old weidu ascension and it copied a folder with a bunch of creatures (including balelit*.cre) regardless of what components you installed, so the creatures would always exist. The new 2.0.X ascension only copies the creatures when Tougher Balthazar is installed. Can ascension account for this or is the correct action for WoP to change and account for the new ascension ? Thank you
  8. Thank you for replying. If my post can be read as implying that DavidW didn't know what he was doing then i apologize. At no time i even thought of something like that. I just wanted to avoid having two codebases being developed independently.
  9. Forgive me for hijacking the thread but i don't know where else to post it. SHS is down and this thread is the most recent thread about DS and has all the relevant people in it. Feel free to move it elsewhere if this is the wrong place for it. Over the years i have noticed many DS versions being used by mods (some of them messing with stats when reordering them so that some mods cannot be installed because they can't find some stat they want). I haven't followed the progression to the letter but it seems there are 3 versions used by major mods. At least from the git repos that i follow, i notice the following: 1) Many mods use a version named v3-20180512 (for example atweaks, rogue rebalancing) 2) Other mods use a version named v3.1 (for example item revisions). I am not a weidu expert but this version seems better to me than the 20180512. Some differences are that it uses some inline tables of spells and stats, the function names have the prefix ds_, a file that is used by the mod is named ag#dsal2.2da instead of ag#dsalt.2da, and it uses the function sort_array instead of SORT_ARRAY_INDICES. 3) spell revisions use version v3.95 with many changes by Ardanis which looks even better to me. Some differences are that the inline tables have many more values in them, some stats are named differently (for example 166 is changed from DMWW_SLOT_166 to MELEE_THACO_BONUS, etc). Until here, everything is ok. I thought that eventually every mod will settle using the 3.95 version that spell revisions does but a few days ago, when i ran git pull on the ascension mod, i saw a commit that copied a new version of DS called v3.95_dw from the upcoming 32 version of SCS. One change is that instead of inline tables, it uses associative array. It doesn't look very different to me but i can't say for sure. So i have some questions about this: 1) Is there a problem if a mod that is installed earlier uses an earlier (and presumably buggy) version of DS ? When a later mod is installed, does the DS run again (and presumably fix the bugs) or it sees that DS is installed and doesn't run (locally i have modified all the mods in game to use v3.95 but i ask out of curiosity). 2) Is there a central development location (let's call it "upstream") so that changes can be shared and avoid having in the future 2-3 codebases which have diverged very much from each other ? Thank you for your time.
  10. I don't know what this means. Maybe it is a case issue ? I think it tried to copy bolt01.itm from the items.bif file but it can't access the bif file.
  11. If you read the file lib/bg1npc_always.tpa, the first line checks for the file dlc/sod-dlc.zip and if it exists, it prints the error message you got. I am not familiar with modmerge so i don't know how it works. If i understood the GO code in github, it is supposed to rename the zip file to .zip.disabled when it finishes, so maybe modmerge didn't install completely ? Try re-running modmerge if you want or wait to hear from someone more knowledgeable than me.
  12. Is it possible that you ran weinstall not from the base EE directory but from the bg1npc directory ? In your screenshot you have weidu.log and setup-bg1npc.debug files inside the bg1npc folder. This gave me the impression that you ran weinstall from inside bg1npc and when i tried it, i indeed get the same translation errors you got.
  13. Weird. in my case it seems to work ok (though i can't install it because i only have BG2EE and not the first game) % weinstall bg1npc weidu --log "setup-bg1npc.debug" "bg1npc/bg1npc.tp2" [weidu] WeiDU version 24600 Choose your language: 0 [English] 1 [Espanol (traducido por Clan DLAN)] 2 [Francais (traduit par les d'Oghmatiques)] 3 [Polski (Tlumaczenie przez Children of Bhaal)] 4 [Deutsch (Teiluebersetzung vom Kerzenburgforum, teilweise noch in englisch)] 0 Using Language [English] Using ./lang/en_us/dialog.tlk Would you like to display the readme? [Y]es [N]o n Would you like to display the components from [The BG1 NPC Project: Banters, Quests, and Interjections]? [Y]es, [N]o? Here is what weidu gives me. As you see i don't get that it can't find the translations. With a quick look, the only difference i can find is the first line. I get "bg1npc/bg1npc.tp2" where you get just the tp2 without folder. Edit: It also says that it can't find "bg1npc/lib/bg1npc_always.tpa". I don't know much about weidu so it may be irrelevant but is it possible that the mod wasn't correctly extracted ? Or maybe the files in the bg1npc directory have uppercase letter. Try running tolower inside the bg1npc directory. This way it will not mess with the EE files. Edit2: I was in a hurry and i didn't explain ciopfs. There is an infrastructure in the linux kernel called FUSE which permits you to implement filesystems. ciopfs leverages this infrastructure to allow case-insensitive access. Let's see an example. # mkdir tmp1 tmp2 # echo test > tmp1/one # cat tmp1/ONE cat: tmp1/ONE: No such file or directory # cat tmp1/OnE cat: tmp1/OnE: No such file or directory Linux filesystems are case-sensitive so ONE, OnE are different files than one. # ciopfs tmp1 tmp2 # cat tmp2/OnE test # cat tmp2/ONE test ciopfs allows you to "mount" the tmp1 directory to the tmp2 directory and present it like it was a new filesystem (if you used DOS in the old days, we used to do the same with virtual drives so we could make a directory appear like a cdrom to fool games that needed a cdrom). You use ciopfs to mount the drive (maybe you need sudo in debian) and then, as you see, you can access the file with any combination of uppercase-lowercase letters. # echo test2 > tmp1/TwO # ls tmp2 one The only requirement is that the files in the original directory must have all lowercase letters for ciopfs to work. There is another way but is more cumbersome than using ciopfs. I don't use the EE engine because i don't like it but when i was testing BG2EE i didn't know about ciopfs so i did something different. I again used tolower and made every mod lowercase. Then the linux binary segfaulted because it couldn't find the bif files. I traced it to the entries in the chitin.key file. So i made a script that opened chitin.key and lowercased the appropriate fields. After that everything ran correctly I think i reported it to the weidu forum and asked if weidu could only produce lowercase filenames in chitin.key because then everything would work out of the box but i think it was an enormous work squashing all the bugs that would appear just for the small number of users running EE on linux.
  14. While there are unix versions of weidu, there isn't a unix version of the vanilla engine. So the most logical cause is that when the readme template was modified to include linux instructions, they had the vanilla engine in mind. You would use tolower, weinstall to install the mods and then run bgmain from within wine. Since the EE has native binaries, of course you can run them and not use wine. Regarding your errors: Your first screen shows that weidu can't find dialog.tlk. When you copied it (or you could symlink it so that you don't keep copying it), it says that it "can't match a directory for dialog.tlk". The error message is a bit confusing so i ran strace to see what weinstall does. In my case it tried to access the directory lang/en_us and it failed. So weidu recognised that the game is EE and tried to access the dialog.tlk from the proper location but couldn't because the directory is named en_US. You can try the following (from the base directory): ln -snf en_US lang/en_us This will create a symlink named en_us in the directory lang that will point to en_US. This way you don't need to copy the dialog.tlk to the base directory. weidu will automatically recognise it (at least it did in my case) and you will no longer get the errors you got. However, i don't know if it will eliminate all problems. Some mods may still not be able to get installed and that is why many people advise to use ciopfs. ciopfs is a program that allows you to mount a simple directory under a different path and allows you to have case-insensitive access.
  15. Nice work. Thank you. I did the following changes: diff --git a/gemrb/core/Scriptable/Actor.cpp b/gemrb/core/Scriptable/Actor.cpp index b65ed5d49..b0b0a1e96 100644 --- a/gemrb/core/Scriptable/Actor.cpp +++ b/gemrb/core/Scriptable/Actor.cpp @@ -274,7 +274,7 @@ static void InitActorTables(); //TODO: externalise #define TURN_PANIC_LVL_MOD 3 #define TURN_DEATH_LVL_MOD 7 -#define REPUTATION_FALL 7 +#define REPUTATION_FALL 60 static ieResRef d_main[DAMAGE_LEVELS] = { //slot 0 is not used in the original engine I tried to trigger it but couldn't. When i read the wiki to find which console function changes the reputation so that i could quickly test changes, i read that "reputation will be divided by 10 when reported". So for some reason, the reputation has values multiplied by 10 and indeed when i changed the variable to 70, i could trigger it fine. In vanilla, when your rep reaches 7, you remain paladin and only fall when you drop to 6. So i changed the value to 60. diff --git a/gemrb/core/GameScript/Actions.cpp b/gemrb/core/GameScript/Actions.cpp index d86e0bc84..e27608a0b 100644 --- a/gemrb/core/GameScript/Actions.cpp +++ b/gemrb/core/GameScript/Actions.cpp @@ -3944,6 +3944,7 @@ void GameScript::FullHeal(Scriptable* Sender, Action* parameters) scr->Heal(0); } +static EffectRef fx_disable_button_ref = { "DisableButton", -1 }; void GameScript::RemovePaladinHood(Scriptable* Sender, Action* /*parameters*/) { if (Sender->Type!=ST_ACTOR) { @@ -3952,6 +3953,8 @@ void GameScript::RemovePaladinHood(Scriptable* Sender, Action* /*parameters*/) Actor *act = (Actor *) Sender; act->ApplyKit(true, act->GetClassID(ISPALADIN)); act->SetMCFlag(MC_FALLEN_PALADIN, OP_OR); + Effect *fx = EffectQueue::CreateEffect(fx_disable_button_ref, 0, ACT_TURN, FX_DURATION_INSTANT_PERMANENT); + act->fxqueue.AddEffect(fx, false); if (act->InParty) displaymsg->DisplayConstantStringName(STR_PALADIN_FALL, DMC_BG2XPGREEN, act); } In gemrb while i lost the paladin abilities, i could still turn undead where in vanilla the button is grayed. So i made the above change to disable the button. With limited testing it seems to work. I didn't test if i can still turn undead with hotkeys or scripts though. Another discrepancy that remains is that in vanilla when you press R to view the character tab, the first line says "Fallen Paladin Level 7" where in gemrb it just says "Paladin Level 7". I didn't fix it because i didn't know how to change the string. Offtopic: If you remember, some time ago, i bothered you to implement a variable in cmakelists.txt for installing to a different libdir. You implemented it as "LIBDIR_SUFFIX" when every other project uses is "LIB_SUFFIX". I didn't mention it before because i didn't want to impose on you more.
×
×
  • Create New...