K4thos

sounds nice, feel free to create a topic in this forum section, once you have something to share regarding your mod

good question, considering IWD2 won't be needed on you computer to install IWD-in-EET (which has all the IWD:EE and IWD2 content). Unlike IWD:EE portion of the mod, which is converted almost exactly the same as BG:EE is in EET (100% on the fly, using resources copied directly from the game installed on your computer), all IWD2 resources are included in the mod package. As long as there is no enhanced edition of IWD2, I don't think additional IWD2 directory check is necessary. Converting IWD2 on the fly would be a pain - currently it takes almost 2 hours locally and it's done with "spaghetti" code, so not something that I would feel comfortable sharing. Historically copyright holders didn't care about using resources from classic IE games in mods (even whole games - see NEJ mod).

thanks, I will update the readme file

if the quest mod works on BG2:EE, then you don't have to worry about compatibility with EET, other then evaluating chapter numbers during mod installation (see documentation for hints how to implement it in weidu code) and ensuring that the GAME_IS (if its used) recognizes the platform. no

While it can be done, I think this convention doesn't make sense in EET. Reasons: - none of the vanilla NPCs with romances have 2 fate spirit responses (and especially none of them use string remotely similar to "bring me my lover"), so lines like these screams "mod added content" (which is bad, imo) - unlike vanilla game, in EET your old BG2 party members summoned by Fate Spirit are moved from areas, even if you didn't have them in your final SoA party, instead of being created from scratch, so those NPCs will already have all the romance variables set and don't require additional fate spirit line to set them, - the only instance that EET creates a new NPC in ToB is if NPC has never been in your BG2 party (and you decide in function code that the NPC should be considered as always summonable, no matter what - normally such NPC wouldn't even be present on the FATESP list) - but in such case why there should be an option for pretending that romance has been active in SoA, when it wasn't? Additional lover line doesn't make sense in such situation, - while I can understand that modder would like to allow player to start the romance when a new game is started in ToB campaign, such situation seems extremely unlikely (who plays just ToB, and wants to experience just a small part of the mod added romance?) and it wasn’t an option in vanilla game (none of the vanilla NPC romances trigger when the game is started in ToB) That's why I didn't add option for "bring me my lover" line to EET_NPC_TRANSITION by default. All the NPCs that I've created patches for use a single fatesp line. What do you think about this reasoning? Should I adjust the function to allow 2 responses per NPC? I haven't checked it yet but the problem likely lies here - the function is not expecting that you will use it twice with the same DV (unless you use an option for cleaning old NPC entries or change the transition type).

@Leeux, thanks for report, the problem has been fixed in v1.9 now available on Github.

if you still have them, please upload the problematic BCS file (and BAK file as well). I will try to run the component locally and see if it the error will show up. I should be able to figure what's up if I will be able to reproduce it.

I didn't know that NI produces such files. I think this option is not enabled by default. which version of the mod you're using? From what I see most recent version has following regexp code, which should skip BAK files (I think). Not sure if this has been changed recently ACTION_FOR_EACH ext IN BCS DLG BEGIN COPY_EXISTING_REGEXP GLOB ~.+\.%ext%$~ ~override~ //patch code END

relative path to the mac os executable that the tp2 file expects has been posted in my previous post (and from what I understand it's wrong). To avoid further confusion and misunderstandings please post the weidu code for coping the file on mac os. Please make sure it's the correct file, used to execute the game on mac os, not linux (depending on the store, some builds contain multiple executables for different OSes). Weidu --noautoupdate --no-auto-tp2 --logapp --use-lang "en_us" --out "strings.tra" --traify-tlk and compare files for example with Beyond Compare: https://www.scootersoftware.com

From what I understand above is the exact game directory - it's not needed by weidu mods (and wouldn't be reliable either way since you can change install directories). What is needed is the relative executable location (in relation to default directory that weidu is using). Let's say I want to copy the executable in weidu. In windows that would be: COPY ~./Baldur.exe~ ~./Baldur.exe~ for linux it is: COPY ~./BaldursGateII~ ~./BaldursGateII~ //or BaldursGateIIEnhancedEdition, not sure which one is used in the most recent patch ~./BaldursGateII64~ ~./BaldursGateII64~ //or BaldursGateIIEnhancedEdition64 and for mac os I assumed the location is: COPY ~./BaldursGateIIEnhancedEdition.app/Contents/MacOS/BaldursGateIIEnhancedEdition~ ~./BaldursGateIIEnhancedEdition.app/Contents/MacOS/BaldursGateIIEnhancedEdition~ or this (not sure which one is correct, both have been sent to me by users) COPY ~../MacOS/BaldursGateIIEnhancedEdition~ ~../MacOS/BaldursGateIIEnhancedEdition~ if it's not the case I need correct location of the mac os executable together with the executable file name. Please paste the code that you would use in weidu mod to copy that file.

not sure what you mean by installing in "iOS game folder" - you've mentioned that you successfully installed on Mac OS, so why not just copying the files to iOS device? As for the error it's this part of code: OUTER_SET found_exe = 0 ACTION_IF ~%WEIDU_OS%~ STR_EQ ~win32~ BEGIN ACTION_IF FILE_EXISTS ~Baldur.exe~ BEGIN COPY ~Baldur.exe~ ~Baldur.exe~ AT_NOW ~%lua% %MOD_FOLDER%/lib/binary.lua Baldur.exe~ OUTER_SET found_exe = 1 END END ELSE ACTION_IF ~%WEIDU_OS%~ STR_EQ ~osx~ BEGIN ACTION_IF FILE_EXISTS ~BaldursGateIIEnhancedEdition.app/Contents/MacOS/BaldursGateIIEnhancedEdition~ BEGIN OUTER_SPRINT exec ~./BaldursGateIIEnhancedEdition.app/Contents/MacOS/BaldursGateIIEnhancedEdition~ END ELSE ACTION_IF FILE_EXISTS ~../MacOS/BaldursGateIIEnhancedEdition~ BEGIN OUTER_SPRINT exec ~../MacOS/BaldursGateIIEnhancedEdition~ END ACTION_IF VARIABLE_IS_SET exec BEGIN COPY ~%exec%~ ~%exec%~ AT_NOW ~%lua% %MOD_FOLDER%/lib/binary.lua %exec%~ OUTER_SET found_exe = 1 END END ELSE BEGIN //unix ACTION_FOR_EACH file IN BaldursGateII BaldursGateII64 BaldursGateIIEnhancedEdition BaldursGateIIEnhancedEdition64 BEGIN ACTION_IF FILE_EXISTS ~%file%~ BEGIN COPY ~%file%~ ~%file%~ AT_NOW ~%lua% %MOD_FOLDER%/lib/binary.lua ./%file%~ OUTER_SET found_exe = 1 END END END ACTION_IF found_exe = 0 BEGIN FAIL ~Baldur's Gate II executable not found~ END it's used for the previously mentioned executable patching. If this code can't find the correct file in Mac OS then it's a bug - in such case please share where exactly is the executable (the file with compiled game) on Mac OS in relation to main game directory (where you extract mods)

thanks! I've removed section 3 of the list all together since it's no longer needed.

same is true for vanilla BG:EE+SoD installation (BDDIALOG.2DA), so in this instance I think it would be more reliable to just read campaign variants PDIALOG file names from CAMPAIGN.2DA. Same is true for other 2da files modified by EET_end (all have vanilla SoD variants, so a code to read them is needed anyway, if the mod supports BG:EE). If it helps with compatibility I can add code that appends all SoD and BG1 PDIALOG.2DA entries during main component installation instead of waiting with it until EET_end (will be done in the next version). I really doubt it, considering the nature of EET_end changes (described here). But if anyone is aware about such conflicts please let me know.

regardless of what other readme files say installing EET_end as the last mod will never break anything in your game (or at least it won't have negative effects compared to installing it before other mods, I can't promise that some regression won't slip up to the code at some point). Instead of thinking which mod may be installed after and risk problems, you can install other mod earlier and don't worry about it. btw. unreleased IWD-in-EET mod optionally appends chunk of code to EET_end that I think would conflict with SCS and other tweak mods, if it's installed before it (but won't if installed after) - it's a code that converts all class related stuff in all resources to use bitwise stat checks instead of current hardcoded class implementation (why it's needed has been disused here). There will likely be more code related to IWD-in-EET to ensure that all mod added content works with this mod changes to the game.

I cleaned up some of the files from my dropbox and don't have a copy of those example fullsize maps right now. Either way the concept didn't receive much feedback (from which I assume there is not much enthusiasm for a completely new worldmap mod) and it turned out 1 of the supported mods places areas far beyond the working area presented here (near Thay), so this idea is currently put on hold. I've managed to fit the IWD-in-EET areas on the BP-BGT Worldmap after all, so there is no immediate need for a replacement.

Nope, it's still not enough. From what I see BG:EE is missing SPL files with HLA abilities (I didn't find SPCL910+ spells referenced in LUBA0.2DA in game resources). And if you just copy them from BG2 you will end up with messed up text since they are referencing BG2 string numbers (different then BG1). Whole weidu mod is needed in order to implement HLA for BG1 content. edit: of course if you install EET you don't have to worry about this.

Grimo, PM sent.

I don't think you would be able to choose HLAs in BG:EE, even after removing the XP cap. If I remember correctly BG:EE and SoD UI.MENU files (responsible for GUI) is missing whole HLA section, so HLA window never shows up. This could be bypassed by installing some mod that adds the missing code to UI.MENU, but this is outside scope of EET Tweaks. edit: if you're asking if I want to add UI.MENU patching and missing LU***.2DA and SPL files that should be added when the component is installed on BG:EE, then I'm afraid no (I think it's outside scope of XP cap component and I'm not interested in adding more tweaks).

hmm, I don't remember any changes related to macOS but maybe I forgot about something when writing the changelog. Anyway, since I didn't have any reports regarding this OS please upload your SETUP-EET.DEBUG file, so I can check if lua code worked correctly. Also please check if BG1 movies plays as expected (installed using external ffmpeg tool). -------------- Keep in mind that if you're going to play on mobile you will need to patch the mobile executable, in order to disable some hardcoded stuff, using this file: https://github.com/K4thos/EET/blob/master/EET/lib/binary.lua You can run it like this: EET/bin/osx/lua EET/lib/binary.lua path_to_your_mobile_executable It disables hardcoded movies (so that correct ones can be played via scripts), and removes hardcoded references to Slayer Change and Pocket Plane spells (don't remember what the hardcoded aspect of it was, probably some minor stuff like removing those spells after importing character or something like that). There is also SOD => BG1 change in executable, which I also no longer remember why it was needed (likely something related to hardcoded GUI functions). So the game should be still playable, even if you skip this step. -------------- In order to skip graphic resources and wav files biffing you should run the installation with b parameter (see Auto-installation section in readme file)

I'm afraid I don't understand your request.

Sergio recently reviewed this version of the mod: http://www.shsforums.net/topic/60457-reviews/#entry606638 I don't think he is active here but you can PM him on SHS.

If you add missing stuff to ADD_ITEM_EQEFFECT / ADD_SPELL_CFEFFECT I don't see a reason why not include your variants of all these functions officially in weidu (alongside ADD_SPELL_HEADER, ADD_ITEM_HEADER from this topic). I doubt Wisp will be against it considering your variants are well documented in this topic, works as expected and greatly expands the inital functionality (the functions support for ALTER effects is fantastic addition). btw. yes, I need parameter2a / b distinction for ADD_ITEM_EQEFFECT in my mod, but of course I can modify the code myself to add this one feature. I just think your functions should be internalized officialy in weidu.

mostly due to laziness. Doing it in EET is a matter of adding 1 line to conversion library which automatically handles every single instance of these spell references in all kind of resources, regardless of what Beamdog decides to change via patches in future. Since those 2 innate spells are BG1 only and specific enough to be extremely unlikely to be referenced via symbolic name in mods installed after EET, I've chosen this approach. Does it conflict with your mod? Ideally it would be great if Beamdog would clean BG1 innate junk from level 9 spell range via patch. edit: of course EET won't be bundled with IWD-in-EET.

Thanks, @DavidW for this awesome addition. Editing params via functions works great. I've noticed that you didn't include ADD_ITEM_EQEFFECT in your altered macros file. Are you planning to add it in future?

EXECUTE_LUA - Action and patch functions used for executing Lua code and retrieving the outcome back into WeiDU Example usage: LPF EXECUTE_LUA STR_VAR lua = ~3 / 2~ RET return END LPF EXECUTE_LUA INT_VAR seed = 1 STR_VAR lua = ~math.random(1, 100) / 100~ RET return seed END LPF EXECUTE_LUA INT_VAR seed = seed STR_VAR lua = EVAL ~loadfile "%MOD_FOLDER%/someFile.lua"~ RET return seed END https://github.com/K4thos/IE-code-repository/blob/master/execute_lua.tpa Here you can find compiled Lua executable for Windows, Linux and Mac OS: https://github.com/K4thos/EET/tree/master/EET/bin