K4thos

it does the same thing, although BGEE classic movies may be of better quality (according to author, I have not compared them)

thanks, fixed locally

do you still have weidu.log and saves made in this installation? If yes please upload them. Mods you've mentioned shouldn't break worldmap. If you mean that there is some inconstancy with in-game dialogue and areas placement on EET wordlmap it's something that can be fixed, but I will need a detailed description what exactly is wrong. vanilla joinable NPC retains their stats from BG1 and SoD portion of the game. If you got them killed and left dead on field they also won't show up in later campaigns (unless plot critical). Even without EET_Tweaks you could optionally kept some items (or all if you're power gaming) since you can visit BG1 areas from within BG2. You can do many of the remaining BG1/SoD quests during BG2 portion of the game but there are no quests that are affecting more than 1 campaign content (sans minor stuff like Pantalons) - at least on vanilla games, there may be mods that adds such quests

thanks, fixed locally

The option to install this component shows up ONLY ONCE per installation (the first time you run EET_end). The reason for this is that you can uninstall/re-install EET_end many times, but saves patching is not something that you should repeat (until next installation). Doing so by mistake could lead to serious problems. And since it's risky process (there are no backup) As for the FILE_CONTAINS checks - they are added to override/EET.flag file the first time you run EET_end on the current installation (that's how installator detects it)

Uninstalling EET_end is fine and should be safe (sans rare weidu uninstallation bugs, so always make a backup copy beforehand, regardless). In future to save yourself time in situations like this have the EET_end mod installed after SCS, not before. Yes, because anything involving dialogues (e.g. for the smithy) needs to be installed before EET_End. Among other things EET_end merges some NPC dialogue files so it's crucial for mods that append or reference original dialogue files to be installed before it. When it comes to "anything involving dialogues" part it's only critical for generating correct files for save patching that can be used during next installation: saves.tra and saves.txt located in saves directory after EET_end installation (if they are not generated from final dialog.tlk used in saves, save patching may fail). So if someone is not planning to use this feature having some small mod like itempack 1.8 installed after shouldn't break anything (my assumption based on name alone, I have not checked its tp2 file) But yeah, unless you are 100% sure that the mod doesn't mess with the same files as EET_end it's always safer to uninstall it. The process should be fast as long as it's really last mod in your install order (as it should be)

Release 13 solved installation problems on patch 2.6: #60 #61 complete German translation by by jaydee2k, Shai Hulud and Weigo: #62 updated French translation by Jazira33: 916df43 fixed bug with conversion of the BG:EE kitlist.2da PROFICIENCY column fixed small problems in macros resource conversion code fixed cpmvars Beregost_House08 name (duplicated entry instead of L1/L2 variant) fixed typo in transition script: #51 fixed continuity problem with SoD Minsc and Dynaheir: #55 removed journal overriding function small correction in polish translation: #59 removed compatibility patches for mods that received native support for post-EET installation (kept BG1 NPC Project as installable for now, in case some mod still needs this order) folder structure as requested by Project Infinity maintainers changed version naming convention (dropped "Release Candidate") WeiDU updated to version 247

@morpheus562 your changes have been merged, thanks once again! Thank you for support, work done on adding EET compatiblity to mods and updating compatibility list Done, thanks!

this is good idea. I've included your changes already. Once the proofreaded translation is ready I will post small update to the current build (13.1), so no need to rush now.

thanks, this is fixed in new release

Thanks! I'm almost ready with new release but will wait for your translation update before posting it.

They are displayed in game in main menu (book with campaign titles). 4000115 is warning that shows up in-game. All those string can use non-English characters. %col1% is replaced with mod name. This string show up in weidu during installation, so English only.

fair. I'm planning to release IWD:EE portion of the mod on Github soon (on the fly conversion code). Should have done it years ago considering how things went. And I'm perfectly ok with anyone working on it. The question now is if it makes sense for me to update this codebase to IWD:EE patch 2.6, open a public beta test and actively maintain it, considering alternative in @tipun's work is already available, being tested and actively maintained for quite some time. It would be 2 mods doing pretty much the same thing, competing for the same audience, so not necessarily a time well spent (I could invest it on remaining work needed for IWD2 side of things instead), especially if tipun would be interested in integrating content prepared for IWD-in-EET by various contributors in his mod (at least @AWizardDidIt writing, if he is ok with it). Personally at the moment I'm leaning more to taking this opportunity to scale down IWD-in-EET mod content significantly, but the other option is also open. Let's wait for some feedback from community and see what are tipun's plans for his IWD mods in the first place (should have contact him via PM first, now that I'm thinking about it) this take is also fair. With how things went development wise, having whole dedicated subforum for it seems excessive. Archiving it and moving further discussion to single topic within EET section may be a good idea going forward.

Quick summary how things are. I've been burned out of IE modding for quite some time (I'm actually shocked checking my last post date), so I'm afraid there was not much progress made. The mod is still in a state that it somewhat playable and yet still far from something that could be released. - IWD:EE content - on-the-fly conversion code is very similar to EET, so should be very playable, although the testing has been done only on surface level and the codebase has not been updated to latest patch yet. Awesome vanilla NPC banters by @AWizardDidIt are implemented (although not tested). - IWD2 content - ongoing testing of story content, finding bugs and improving conversion code based on those tests. Rise and repeat over and over. This one still require massive amount of work before being ready for release and is what led to my recent hiatus. On the other hand experimenting with EEex, porting 3E rules and gameplay systems is a lot of fun Dialogue side of things has been started by @Grimo but only Targos was covered as far as I remember. There have been some good points raised in the comments and interesting alternatives surfaced, so let's move on to replies. With the current state of things this is something I'm now considering for IWD:EE portion of the mod for 2 reasons: - I'm still not ready to give a release date for the whole mod and yet IWD:EE content is sitting here for a long time now. With some external testing effort and help, preparing a mod out of it seems doable in reasonable time frame. - patch 2.6 due to migration from 32bit to 64bit executable broke compatibility with EEex to the point that according to @Bubb new version is at least months away (my reading: could be years). So it's either keeping the mod at patch 2.5 (at the expense of BG and IWD1 content and engine improvements), or separating them ,since EEex is crucial part of my IWD2 conversion. I've just checked it and... it's true @tipun has a working betas of both IWD1 and IWD2 content for EET. That's super impressive. While I have not been able to test it yet, from the impressions on Roxanne's forum it sounds legit: http://baldursextendedworld.com/Vanilla_Forums/discussion/comment/12359#Comment_12359 At this turn of events I'm not even sure if it makes sense to continue IWD-in-EET as envisioned or maybe it would be better to collaborate with tipun, share assets, dialogues etc. The advantage of EET style IWD1 conversion is possibility of automatically bringing over mods installed directly on IWD:EE previous to installing IWD-in-EET (same way as mods can be installed on BG:EE before EET), but realistically there are not that many mods worth porting over this way, so if tipun's implementation is in better shape maybe his mod should be used by players interested in experiencing this story instead of me offering pretty much the same thing? Especially if he would be interested in collaborating with @AWizardDidIt (whose writing effort is core of IWD1 in BG experience, imo - otherwise one could still play clean IWD:EE) When it comes to IWD2 content I'm pretty sure that our approaches differ enough that there could be a place for both mods - one requiring EEex, being closer to IWD2, offering lots of 3E mechanics. And another as a content adaptation to ad&d rules, using clean BG2:EE engine. So yeah, I'm not ready to give up on this one But I think this version existence pulls away some pressure from me considering there is viable alternative available already. @tipun, feel free to open a topic about your mods on this subforum or discuss them here, if you would like to share some details about thier content or your future plans with English community. I'm updating EET for latest patch as we speak. Missed the patch release, sorry.

Just noticed @jastey's recent activity on compatibility list and decided to review what's going on. I've been out of IE modding for quite some time and it looks like I've missed patch release. Sorry everyone for this situation and thank you for providing hotfixes. I'm downloading games right now and will merge pull requested changes on Github as soon as I will be able to test the installation (max tomorrow). Considering my activity has been very irregular, to avoid situation like this in future, I think it may be a good idea to transfer repository ownership to either Gibberlings3 (if @Mike1072 is ok with it) or InfinityMods (@AL|EN?) github organization, or at least give someone access to the repository.

Just wanted to say thanks and show appreciation for the work done on this update

not sure if you've read it: it's a very old change and I no longer remember exact reasoning behind choosing this implementation over another. Any change to this would require lots of testing, so don't expect it any time soon. Not sure if it's even worth it considering: - component 66 probably already works if it uses vanilla Find Familiar spl files, - component 67 should already work (from what I understand from description) if you use vanilla CRE names (just extend this patching to familiar CRE files imported from BG1 - in EET they have _ suffix) - component 68 could be implemented by patching just K#FAMSUM.BCS (which is pretty self explanatory how to do it if you open the file and look what's in there) - component 69 is very similar to EET Tweaks component "Familiar death consequences"

you can but in such case you will remove the EET feature that allows summoning different CRE files in different parts of the game. If you prefer it like this you can use this code to get rid of EET implementation: ACTION_FOR_EACH file IN FAMCAT_ FAMDUST_ FAMFAIR_ FAMFER_ FAMIMP_ FAMPSD_ FAMQUAS_ FAMRAB_ FAMCAT FAMDUST FAMFAIR FAMFER FAMIMP FAMPSD FAMQUAS FAMRAB FAMCAT25 FAMDUS25 FAMFAI25 FAMFER25 FAMIMP25 FAMPSD25 FAMQUA25 FAMRAB25 BEGIN COPY_EXISTING ~%file%.CRE~ ~override~ LPF DELETE_CRE_EFFECT INT_VAR opcode = 232 END BUT_ONLY END You will also need to restore vanilla SPCL342.SPL and SPWI123.SPL since EET removes opcode 192 from them and adds script execution instead. Alternatively, if you want to keep EET implementation, you can edit: - K#FAMSUM.BCS - controls which familiar will be spawned and initial bonuses - K#FAMKIL.BCS - controls what happens when your familiar dies - K#FAMREM.BCS - used to manually remove the familiar without negative consequences (for example after importing character that has familiar to new game or at the end of SoD, so that player can summon new one after leaving the cage)

unswered here: all it does is unhardcoding find familliar spell to no longer use opcode 192 but scripts instead, so that different CRE files can be summoned in different parts of the game. And since summoning and removing familiar scripts are meant to work exactly like opcode 192 by default, hence the K#FAMPRO global variable usage.

EET changes find familiar spell to trigger K#FAMSUM.BCS, which does the same thing as original opcode 192 but allows to easily set which CRE file will be spawned (different in BG1, BG2 and ToB). Also vanilla familiars trigger K#FAMKIL.BCS on death (via cast spell on condition opcode) in order to implement the same penalties as opcode 192. This way the system is completely unhardcoded and does what we need using vanilla CRE files with no other changes necessary. I'm all ears.

EET_end.tp2 has this code contribute by Argent77, so I assume nothing else is needed: // Works around a bug in the game engine which fails to load KEY files containing backslashes as pathname separator // Problem shows up after MAKE_BIFF is used on osx and linux games COPY ~chitin.key~ ~chitin.key~ READ_LONG 0x08 numBiffs READ_LONG 0x10 ofsBiffs FOR (idx = 0; idx < numBiffs; ++idx) BEGIN SET curOfs = ofsBiffs + idx*12 READ_LONG (curOfs + 0x04) ofsBiffName READ_SHORT (curOfs + 0x08) lenBiffName READ_ASCII ofsBiffName biffName ELSE ~~ (lenBiffName) NULL PATCH_IF (NOT ~%biffName%~ STRING_EQUAL_CASE ~~) BEGIN INNER_PATCH_SAVE biffName ~%biffName%~ BEGIN REPLACE_TEXTUALLY ~\\~ ~/~ END WRITE_ASCIIE ofsBiffName ~%biffName%~ END END BUT_ONLY just make this line return false to skip biffing: ACTION_IF (~%argv[0]%~ STRING_CONTAINS_REGEXP ~[bB]~ = 1) BEGIN it does patch it for windows, linux and mac (although I don't know if this one works since I haven't received a confirmation, requested earlier in this topic, regarding relative path to mac os game executable). The changes are minor (removes some hardcoded spells references that caused problems in ToB, gets rid of hardcoded DAYNITE / NITEDAY movies and some other stuff that I don't remember what it’s for). Even if you skip executable patching I wouldn't expect huge issues on a tablet. Here are the changes (implemented in lua since using weidu REPLACE_TEXTUALLY on an executable may result in out of memory problem): https://github.com/K4thos/EET/blob/master/EET/lib/binary.lua

this sounds like a very nice mod, indeed. Congratulations! Is this original content? If I remember correctly vanilla game already had unused lines for Elminster that refer to defeating S. btw. same is true for Volo - his new dialogue will show up without any edits, IIRC.

we're in contact, don't worry about it. Patience, please. edit: in fact the feature released today is one of the things I've requested edit2: and another one

We don't usually disclose the percentages or dates. If there is no new post about the progress then there is nothing new to announce (and in such case you definitely should not hold on playing the game). We work on this mod as a hobby, and disclosing too much information could lead to wrong expectations from the community in case of delays and put an unwanted pressure on the EEex author (since further mod development depends on EEex updates).

based on my test with vanilla BG1 link between west edge of Durlag's Tower area and Gullykin (ENTRY_NAME set to N, DEF_ENTRY set to 1) the party ends up in the middle of the northern part of the Gullykin, right here: Not sure what would happen if that part of the map would not be traversable, but in such case you can just use entrance name (btw. BG2 doesn't have a single link that would depend on DEF_ENTRY and in BG1 it's also not that common)