K4thos

8 hours ago, Daxtreme said:

Well the quest starts in SoA and continues into ToB but then you have to return back to SoA to finish it, which is impossible in BG2EE.

That's why I'm making it for EET!

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

On 6/24/2019 at 9:52 AM, Arthas said:

Question: wouldn't copyright issues arise when converting this 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.

Quote

Are there any problems that can arise from skipping BG1 when testing?

no

Quote

I'm using this thread for another question. I am using @CamDawg's genius code to add two fate spirit entries for EET, one romance case and one none-romance case.

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?

Quote

But, if I do the following: generating two entries, one for a fake DV and one for the real, then patching the fake DV to the real one (plus disapling the doubled script blocks):

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.

Quote

Sadly I forgot to report it at that moment and now I lost the logs for the failure... but it should be easy to verify, just change something in an area/creature BCS that grants XP with NI and save it, and run the patcher and that .BCS.BAK that NI generates should come up as one of the files patched in the process.

I didn't know that NI produces such files. I think this option is not enabled by default.

Quote

I found during my last installation that the XP patcher process BCS.BAK files generated by Near Infinity, since it seems to match them as part of the general globbing pattern? 

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

Quote

From what I can tell, the actual BG2 executable is sitting right there at the top level, in what is effectively the game folder.  I guess eet_core is looking for it somewhere else?  So, like I say, if I find the part of the EET code is doing this (thanks k4thos), I can go in and adjust it for my testing.

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

Quote

** Actually, do you know if there's a reasonably easy way to test whether the .tlk files match?  Is there some way in NI to go to the last entries, to compare them?  That could put my mind at ease, and/or allow us to sync them up ourselves.

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

5 hours ago, Luke said:

The iOS executable (i.e., where @subtledoctor extracted the mod in order to mod the actual iOS game) should be here => /Users/%Username%/Music/iTunes/Previous iTunes Libraries/iTunes Media/Mobile Applications/Baldur's Gate 2 2.5.16/Payload/Baldur's Gate 2.app

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.

8 hours ago, subtledoctor said:

I get this error when trying to install eet_core in the iOS game folder:

 

FAILURE:
Baldur's Gate II executable not found
Stopping installation because of error.

 

Any idea what the problem it?  Or, what part of the EET code this is at, so I can poke around and see what it was trying to do?

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.

Quote

PDIALOG.2DA. That table is not populated fully until EET_end is installed, so not all NPCs are detected if SCS is run before EET_end.

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

Quote

 I think there are probably other such issues: certainly I had a range of odd bugs reported by players testing SCS release candidates on EET that I couldn't reproduce, at least some of which I suspect are about these sorts of issues.

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.

Quote

From your thread on the beamdog forums....SCS should go after EET_End now. Does this mean aTweaks should as well? I usually use both together but I thought the general rule of thumb is that majority of mods should go before EET_End. I guess that leads to the next question of is v32 still compatible with atweaks?

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