Jump to content

K4thos

Modders
  • Content Count

    1,380
  • Joined

  • Last visited

Everything posted by K4thos

  1. Reference image updated with Fishing For Trouble areas.
  2. when the same stuff is added to both BALDUR25.BCS and BALDUR.BCS than it's actually harmless to leave that code in 25 file too, since it's not used at all (I've changed it in exe file to force BALDUR.BCS even if the game is started from ToB menu, now occupied by SoA). !GAME_IS ~eet~ condition in the above mentioned patches is just a cosmetic change to not slow down Near Infinity when doing global BCS search, not print unrelevant matches etc. If the code is indeed unique than you should always check if the script blocks are filtered enough to only show up in ToB (for example with some unique global set by ToB script or area reference check etc.). If yes than it's a matter of this: ACTION_IF GAME_IS ~eet~ BEGIN EXTEND_BOTTOM ~Baldur.bcs~ ~Angelo/Scripts/Baldur25.baf~END ELSE BEGIN EXTEND_BOTTOM ~Baldur25.bcs~ ~Angelo/Scripts/Baldur25.baf~END if no than some additional filter is needed (see Xan patch) or unique files depending on platform. Either way it always requires some time to check the code when BALDUR25.BCS is used, so adding some warning to the converter may be a good idea. On the other hand mod authors knows when they patch global script, so if they are aware that the file is not used in EET than it's pretty obvious what to do, without additional warnings.
  3. it doesn't merge them, so it's up to modders. Usually mods adds the same code to both BALDUR.BCS and BALDUR25.BCS, so we would end up with tons of usless junk by doing so. All relevant code from BG1 BALDUR.BCS script (4 blocks) and ToB BALDUR25.BCS (6 blocks) is appended during EET installation (first component). I've updated all patches to append into proper file (or don't append at all if it's not needed) as you can see in this commit.
  4. No problem. I would appreciate if someone could help with describing it properly, to make the documentation (quoted in this post) less confusing. btw. Roxanne, not sure if you are aware but it's also possible to start scripted conversation using different dialogue file than the JOIN one, without replacing the dialogue file attached to CRE file: StartDialogOverride(S:DialogFile*,O:Target*)
  5. it doesn't matter at all. When you use CHAIN command than it ends up as a state block without any trigger filtering, which is than called by external dialogue file. That state will be available after merging regardless of the file that you appended it to. That is why merged dialogue files no longer have problem with interjections, but still work properly because they have proper filtering added in states that can be initiated by scripts or by starting dialogue (those states that already had top level conditions). ----- but you can use common files for Sandrah's join/post/banter dialogues and dream script if you like instead of relaying on automated merging (just like Keeping Yoshimo mod simply uses SoA dialogues in ToB too, so it doesn't need any changes). This way you have full control over trigger filtering, which means you can for example code a dialogue that can be triggered by script regardless of the portion of the story. It's your decision though.
  6. no, you still work with vanilla files. Merging is done at the end, after your mod is installed. Before it takes place all vanilla and mod added files looks exactly the same as they look now in your installation or in vanilla games (separate files for SoA and ToB, same states, no additional triggers required). again no. See above. Just keep in mind that some BG1 files are renamed due to conflicts with BG2 files. it would be less work for you (in fact no work at all) if you simply append your NPC to be merged by setup-EET_end.exe at the end of installation for both join/post/banter dialogues and dream scripts, so it's not really needed. But yes, you can use single file in your mod and filter it as you wish instead of relaying on automated solution. ------------- just forget that files are even merged. Don't think about state numbers. Work with files that are available before merging takes place.
  7. tell me exactly what the problem is and I will write a macro to change it automatically. For now I don't see anything in this change that would affect your mod. once again, override scripts are not merged and IMOEN2J.DLG after merging (with those 20 BG2 NPC mods installed as well as BG1 NPC Project) has 5442 states - no performance issue observed when she is interjecting, so I doubt that there will be a problem for Sandrah.
  8. Let's take Minsc as an example: - he starts in BG1 with MINSC_.BCS override script (MINSC.BCS from vanilla BG:EE, just renamed due to conflict with BG2 resources) - during BG2 transition his script is changed to MINSC.BCS (vanilla BG2:EE script) - during ToB transition (or later when he is summoned by Fate Spirit) MINSC25.BCS is assigned to him. Why would you add CHAPTER filtering there? It's not needed at all. We have full control on what script is assigned and when. You can assign whatever you wish for RTF or continue to use ToB script - it doesn't matter. Only Dream scripts are merged because they are forced on us by PDIALOG.2DA, and we no longer use MoveToExpansion() to switch into ToB files. correct, if creature doesn't have multiple dialogue or dream files than it doesn't need any merging. For example Sarevok from ToB or Yoshimo from SoA (even if "Keeping Yoshimo" mod is installed because that mod still uses vanilla SoA files even in ToB).
  9. this literally changes nothing in your mod. Sandrah should be installed before the merging takes place. You can even still use seprate ToB files for your mod and than add them for merging. They will work exactly the same as before merging, just with working interjections during whole game. yes you can (although currently we are appending max 3 files - or 4 if SoD will have separate dialogue files), that's the point. 1. This will be true only in BG2: GlobalGT("CHAPTER","GLOBAL",14) GlobalLT("CHAPTER","GLOBAL",22) 2. This in BG1: GlobalLT("CHAPTER","GLOBAL",8) 3. This in ToB GlobalGT("CHAPTER","GLOBAL",21) And these triggers are added automatically based on which point of the story the dialogue comes from (which means nothing is changed compared to situation if those file were separate and assigned in different part of the story), exactly in places that needs them (so not in blocks that didn't have any triggers). Just to be sure I will repeat it again - NPC override scripts are NOT merged. Currently the pre-made function that adds NPCs to merging pool only does it for BG2 NPCs but it's a matter of 5 lines of code to append all Sandrah files (including BG1 ones) manually into the tph file. Or you can switch to using merged dialogue files from the get go and have full control over trigger filtering, although that would be some additional work.
  10. Hmm, I see I have a problem with describing clearly what I mean. Merging JOIN, POST, BANTER dialogue files and DREAM scripts (so only things that are controlled by PDIALOG.2DA and INTERDIA.2DA, override scripts are not merged) doesn't mean just combining files. It means: - reading whole content of the file and adding proper trigger filtering depending on which part of the story they come from, based on what is stored in EET/lib/EET_end.tph. Currently it's done with "endofbg1" and "endofbg2" variables that are set by EET, but in future it will be changed to less confusing "chapter" variable. Dialogue file only receives filtering if the state can be called by script (which means already has some triggers). Dream scripts receivs filtering in each block. - combining these files together - updating all DLG, BCS and CRE files that exists in game to change references to files and updating old state numbers into new ones All of this is done by this file. Notice that it also uses EET macros. Before conversion you will see messages like this printed on the screen: Preparing NEERAJ.dlg source file (540 states starting from 0) Appending NEERAJ_.dlg to NEERAJ.dlg (172 appended states starting from 540) Appending NEERA25J.dlg to NEERAJ.dlg (173 appended states starting from 712) And than tons of prints like: Patching BMONTA.DLG: BMINSC_ => BMINSC - dlg; 419 => 778 - state Patching BIMOEN2.DLG: BJAHEI25 => BJAHEIR - dlg; 166 => 1275 - state and so forth. As for the mods that adds new NPCs to the pool of files for merging, here is what is generated when you install 20 BG2 NPCs that uses the new EET_NPC_ENDMERGE function that appends data based on what is found in PDIALOG.2DA and INTERDIA.2DA into EET/lib/EET_end.tph: Does this make sense, or should I try to clarify it more? Maybe someone would like to help me explaining the process in less confusing manner - that would be helpful for writing documentation.
  11. Roxanne, thank you for testing. agb1, nice. Are you planning to make it compatible with EET too? If yes than I've just prepared a patch for you with all EET related changes to the FFT code (also listed in Changes.txt): https://www.sendspace.com/file/yvpmpq It's cross platform coding, so these changes won't break compatibility with BG2 and BG2:EE (once you add support for it).
  12. yep, sounds like a known BG:EE bug reported before: https://forums.beamdog.com/discussion/comment/554793 https://forums.beamdog.com/discussion/comment/520654 not entirely sure if I understand. You mean DSotSC Bub Snikt content? I'm surprised there is any considering how underdeveloped these NPCs are.
  13. After spending some time analyzing how problematic the old implementation is when it comes to mods and vanilla content I have to disagree with this. It would be extremely likely to break dialogues when the dialogue file no longer matches what is called by interjection. Of course I don't mean bugs like the one reported here but situation in which we return to BG1 areas from BG2 when the character have different dialogue assigned (or from ToB to BG1 and BG2). For example Imoen from BG1 NPC Project interjects like crazy with everybody. Let's say you missed some dialogues with random people during BG1 and than go back there during BG2. Now all those missed dialogues are broken if you have Imoen in party. Ok, this may not sound so bad. But what about situations when player forgets to do some huge optional quest (or simply decide to delay it)? Now when the party travels back during ToB the quest will be broken very soon by either interjection done by vanilla NPC or some modded one (interjections are not really limited to main story quests - see "Cult of the Unseen Eye", Trademeet etc.). Should EET clean out all quest givers just because of this problem? That's the opposite of the goal here - finishing each part of the story is meant to be treated like finishing any other chapter. Let's say we add additional trigger filtering to all vanilla interjections and force it on modders (which would be a mess for compatibility with mods btw.), so that they don't show up when the dialogue is no longer valid. But now we ended up with dumbed down version of the quest where there are no interjections whatsoever. Another example: IWD-in-EET is meant to be played in any part of the story. Should modders patch BG1 dialogue, BG2 dialogue and ToB dialogue to interject properly if they wish to add such content? ----------- This implementation is flawed in my opinion and would be long gone if not for my previous lack of understanding how compiled EXTERN command is interpreted by the engine. Merging JOIN/POST/BANTER dialogue files is better approach in this situation, imo. Like I mentioned before there is no need to revolutionize how the mods are written. Also the new implementation doesn't have quirks from BGT where you need to manually add filtering for merged dialogues and watch out for changed state numbers. Modders can work with vanilla files without complicating it. At the end of installation (after any other mod is installed) EET will do the merging automatically and add proper filtering to script initiated dialogues, so everything works exactly like now, but with always available interjections. Since we are no longer relaying on ToB PDIALOG.2DA and INTERDIA.2DA entries whole MoveToExpansion() no longer makes much sense, imo. I think it's better to integrate the ToB properly instead of treating it differently than other parts of the story. Here are some benefits of this change: - ToB now uses the same GUI and saves as other parts of the story, - I've patched executable to run BALDUR.BCS even during ToB, so the main menu slot became open for another game - I've placed Shadows of Amn there, so you can now start EET in either BG1 or BG2 from the main menu, - Returning from ToB to old areas no longer breaks conversations due to not valid dialogues Quote from updated documentation regarding these changes: In other words not really a problem when it comes to compatibility with other mods. Only BG2 NPCs are affected but they just need 1 additional line in code to add them into merging pool (I couldn't use 2DA entries because BG1 NPCs don't need any merging unless they are characters that migrates to BG2 with separate dialogues). Things like one time ToB override script assignining has been implemented to the existing EET_NPC_TRANSITION function (already used by BG2 NPC mods that supports EET). Installation of that second EET component on vanilla EET without any mods takes about 1 minute and with BG1 NPC Project (larger than whole BG1 text wise) + 20 additional BG2 NPCs from the compatibility list - about 3 minutes on my slow laptop, so not the end of the world, imo. If it's not installed than following screen is visible instead of the main menu, so there is no way that someone will forget to install it: Of course nothing is set in stone, so feel free to criticise the current implementation. We can change it back if you convince us that it's not really a good idea. Sorry for the "wall post" edit: forgot to mention the obvious - new EET beta supporting this system is available on GitHub. BG2 NPCs also received proper patches update.
  14. not related to EET. I've just tested it on vanilla BG:EE and there is the same animation issue. Please report it to DH author.
  15. Not sure if I understand your post. You mean merge all join files related to a single NPC? That's exactly what I proposed in the second suggestion. Filtering and coding it without breaking the content (even added by mods) is not really a problem. In fact the code would be probably already ready for test if not for the negative feedback on this idea. I can't think about anything that could go wrong when it's done automatically at the end of the installation process (after all other mods are installed). The question is - is it really needed? If you meant something else than please clarify.
  16. Thanks for feedback. nope, this is not about it. Only things posted today are related to the proposed change. In short - when EXTERN is used in dialogue and refers to dialogue file that is not assigned to CRE than the dialogue is broken. We do have full control on script assignment. What is problematic is a JOIN dialogue file. Join dialogue files would need to be merged to make EET 100% reliable even if you're going back to old areas later in game, when dialogue file may no longer be valid but could be still called by some other dialogue via EXTERN (interjection). But from Roxanne words this may not be such a huge issue to warrant a treatment mentioned in second suggestion when most of such interjections are related to previous story content. Could you please share a list of such changes (not related to joinable NPCs since that case is already handled). Currently EET filters out random dialogues (tavern rumours, random folks talks) about Iron Crisis and the ceremony in Duchal Palace and Sarevok after finishing BG1 storyline. Scripts get rid of the CRE related to Sarevok (story related encounters). Also here is a list of CRE that are currently planned to be disabled since they also appear in BG2 (will do it after full SoD implementation, just to be sure that they are not used there): Brennan Risling, Bubbles, Calahan, Dradeel, Drizzt, Neb, Volothamp Geddarm. More cleaning obviously will be needed so any help would be appreciated.
  17. there is no need to append BCS files. Each part of the story can use unique one like it does now. Only JOIN and POST dialogue files would be appended. BGT already does it for BG1 files, so it's not an alien concept. The difference would be doing so also for ToB dialogues - all handled automatically by EET during installation (after any other mod). to be honest I have no idea. I pretty much always play vanilla content and there are indeed just few interjections here and there related to the story. Not sure how it looks like in mods, especially those that adds MBs of text. If the amount of required changes wouldn't frighten off modders than the situation may not be as bad as I envisioned after analyzing consequences of your report. the easiest solution would be a way to alter CRE death variable during game. An actions that would simply (?) overwrite what is stored in the local copy of the GAM file inside the save file. But like Roxanne said chances for such thing are marginal when Beamdog don't need such functionality, especially if such changes are not desired in vanilla game (without EET changing DV mid game doesn't even make sense).
  18. This problem showcased a bigger issue that I didn't anticipated. The engine broke on that EXTERN shutting down the dialogue window even though there were available other responses. This means that when you go back to old areas from BG2 and start doing some missed BG1 quests dialogue could brake if you have NPC in party that already uses BG2 dialogue variant but is called by EXTERN to use different dialogue. Something has to be done to deal with this stuff. 1. Either leave the current implementation and let modders know that additional ENDOFBG trigger may be needed along with usual IsValidForPartyDialogue / InParty / CD_STATE_NOTVALID to make sure that interjection won't show up when the dialogue file is no longer valid. EET would need to patch vanilla content in the same vein. 2.Or append all dialogue files, including ToB ones, so that all states are always available The second option sounds like nightmare when it comes to cross-platform coding. This is why I think it may be a good idea to do it automatically after every mod is installed with relatively simple code that would analyze all dialogue files and scripts in game, append BG1 and ToB ones (using filenames stored in PDIALOG.2DA) and modify all EXTERN calls to these now appended files. Also similar changes in scripted dialogue calls. Benefits: - no chance for bugs in cutscenes like the one you reported - any EXTERN and dialogue call would be valid during whole game. Only dialogues that can be normally initiated (those with proper trigger statement) would automatically receive additional filtering based on what game it comes from, so for example that cutscene with Teven would still show Viconia interjection, even if you would see it in ToB instead of BG1. - no additional work for modders to implement this new system. Your tp2 file would be able to still append to unique BG1 and ToB dialogue files (no Fluidstates needed, no additional variables like in BGT). Merging them with BG2 ones would be done at the end by EET itself Cons: - EET would need to be installed in 2 steps - first on clean BG2:EE. Than separate component after all mods are installed - that separate component would need to be uninstalled when you decide to install some additional mods later (and than installed again of course) - very large dialogue files. Not sure if there is a limit, but if yes than we are risking reaching it People usually don't read readme files, so something like this would guarantee tons of reports. In order to prevent it EET main component would install custom in-game main menu start screen that would inform that the installation is not finished and what to do (later replaced with proper one after you install that second component). Opinions?
  19. Thank you very much for this report. Tested it and it's indeed a problem if Viconia is in party. Assigning dialogue directly in the dialogue block that calls the EXTERN doesn't work but it can be fixed directly in the cutscene script with this code: COPY_EXISTING ~BANCUT01.BCS~ ~override~ ~BANCUT02.BCS~ ~override~ DECOMPILE_AND_PATCH BEGIN REPLACE_TEXTUALLY ~StartMovie("CAMP")~ ~StartMovie("CAMP") ActionOverride("Viconia",SetDialog("VICONJ"))~ END I think we should consider dropping this workaround considering there may be more vanilla game cutscenes like this one and who knows how many mods add new ones to the game in similar way. If this is widespread issue than maybe it's not worth it. Possible solutions: 1. Someone hacks the exe file to get rid of auto PDIALOG.2DA dialogue swap when LeaveAreaLua is used. 2. I will create a topic on Beamdog forums requesting a new opcode that could disable PDIALOG.2DA dialogue file swap if the effect is present on the creature. In other words something like this. Unlikely that they will add it, because it's not really needed from their perspective. 3. Maybe patch 1.4 will work differently 4. Leave it as it is, find all other cutscenes in vanilla game that forces LeaveAreaLua without giving time for local NPC override script to re-assign correct dialogue. Warn about it in Developer's Documentation and wait for bug reports like the one you posted... 5. Go back to appending files just like in BGT with following rules: - BG1 dialogues appended at the end of BG2 files filtered with Global("ENDOFBG1","GLOBAL",0) - Siege of Dragonspear dialogues appended after BG1 ones filtered with Global("ENDOFBG1","GLOBAL",1) - BG2 dialogues filtered with Global("ENDOFBG1","GLOBAL",2) where it's needed (will check BGT code where exactly it added such filtering) Mods like BG1 NPC Project (if there will be a version with native compatibility in future) would still need to use standard Fluidstates.tpa to figure out the first state number of BG1 files that had been appended, just like in BGT. The last option sounds the worst to me. Not only silly stuff like "fluidstates" variables but also filtering and files that may end up weighting several MBs. In other words BGT jankiness all over again... Damn.
  20. K#PDIALOG variable is no longer used anywhere with this implementation. Are you sure it's related to this? The only code now present is: IF ActionListEmpty() InPartyAllowDead(Myself) THEN RESPONSE #100 SetDialog("%dlg%") Continue() END IF ActionListEmpty() !InPartyAllowDead(Myself) GlobalGT("HASBEENINPARTY","LOCALS",0) THEN RESPONSE #100 SetDialog("%dlg_1%") Continue() END I've tested it in various circumstances (walking, fighting, casting, some cutscenes) and no action was interrupted, so not sure why she would stutter after that cutscene. Maybe the patching code from previous post didn't work? Please check her override script. We could fix it for vanilla content by adding SetDialog right into the script but that would be against the goal of this workaround - it's meant to make modders life easier, not to force them adding junk whenever they write a BG1 cutscene like the quoted one. If there will be no way around it than appending dialogue files like in BGT will be easier to handle than this (although with additional Siege of Dragonspear dialogues the files would have awful large size and confusing structure ). What I don't understand is why this even happens. I_C_T code looks like this (example from weidu documentation): INTERJECT_COPY_TRANS TOLGER 75 AquaTolger == AQUALUNJ IF ~IsValidForPartyDialogue("Aqualung")~ THEN ~Hey, that's a really crummy offer! Where did those little girls go? I could be sitting on a park bench, I don't need this aggravation! Who are you, anyway?~ == TOLGER IF ~IsValidForPartyDialogue("Aqualung")~ THEN ~You poor old sod, you see it's only me. Now, did anyone else have a smart remark they wanted to make?~ END So, if Aqualung is around, we’ll hear from him and then Tolgerias will respond to him. After that, the game will look for the presence of Edwin, Jaheira, Yoshimo, and Korgan and we’ll get their responses to Tolgerias as well. so from what I understand "== AQUALUNJ" points directly to the dialogue file, just like if you would use EXTERN. That's why I didn't expect this problem. Are you sure you used correct dialogue file name there, not BG2 one? Also please send me whole code you used to patch dialogue, so I can check how it looks like after decompiling and test that whole cutscene in game (in vanilla game there are no Jaheira interjections there if I remember correctly).
  21. The variable is called "K#DISABLE_PC_CAN_DIE". btw. in overview topic you can find a link that always points to latest version of the readme file (the variable name is mentioned there).
  22. here it is in tp2: https://www.sendspace.com/file/ynudwj
  23. Thanks for the report. I was worried that current implementation is not enough. Please install this code to integrate new PDIALOG workaround. It will clean old code and replace it with new (simpler) one. BG2 override scripts, DPLAYER2 and PDIALOG.2DA no longer need any changes. There are only 2 blocks in BG1 override scripts related to this workaround now. If this won't be reliable than nothing will. <<<<<<<< .../DIALOG_FILE-old.baf IF OnCreation() THEN RESPONSE #100 SetGlobal("K#PDIALOG","LOCALS",0) END IF Global("K#PDIALOG","LOCALS",0) InPartyAllowDead(Myself) THEN RESPONSE #100 SetDialog("%dlg%") SetGlobal("K#PDIALOG","LOCALS",1) Continue() END IF Global("K#PDIALOG","LOCALS",1) !InPartyAllowDead(Myself) THEN RESPONSE #100 SetDialog("%dlg_1%") SetGlobal("K#PDIALOG","LOCALS",0) Continue() END >>>>>>>> <<<<<<<< .../DIALOG_FILE-new.baf IF ActionListEmpty() InPartyAllowDead(Myself) THEN RESPONSE #100 SetDialog("%dlg%") Continue() END IF ActionListEmpty() !InPartyAllowDead(Myself) GlobalGT("HASBEENINPARTY","LOCALS",0) THEN RESPONSE #100 SetDialog("%dlg_1%") Continue() END >>>>>>>> <<<<<<<< .../DPLAYER2-old.baf IF Global("K#PDIALOG","LOCALS",0) GlobalLT("ENDOFBG2","GLOBAL",2) !InParty(Myself) NumInParty(6) ActionListEmpty() OR(8) Name("Dorn",Myself) Name("Edwin",Myself) Name("Imoen2",Myself) Name("Jaheira",Myself) Name("Minsc",Myself) Name("Neera",Myself) Name("Rasaad",Myself) Name("Viconia",Myself) THEN RESPONSE #100 SetGlobal("K#PDIALOG","LOCALS",1) END >>>>>>>> <<<<<<<< .../blank.baf >>>>>>>> ACTION_DEFINE_ASSOCIATIVE_ARRAY table_transition_DIALOG_FILE BEGIN DORNJ_ , DORNP_ => DORN_ //BG1 Dorn EDWINJ_ , EDWINP_ => EDWIN_ //BG1 Edwin IMOEN2_ , IMOENP_ => IMOEN_ //BG1 Imoen IMOENJ , IMOENP => IMOEN //BG2 Irenicus Dungeon Imoen JAHEIJ , JAHEIP => JAHEIRA_ //BG1 Jaheira MINSCJ_ , MINSCP_ => MINSC_ //BG1 Minsc NEERAJ_ , NEERAP_ => NEERA_ //BG1 Neera RASAADJ_ , RASAADP_ => RASAAD_ //BG1 Rasaad VICONJ , VICONP => VICONIA_ //BG1 Viconia END ACTION_PHP_EACH table_transition_DIALOG_FILE AS dlg => res BEGIN COPY_EXISTING ~%res%.BCS~ ~override~ REPLACE_BCS_BLOCK EVALUATE_BUFFER ~.../DIALOG_FILE-old.baf~ ~.../DIALOG_FILE-new.baf~ BUT_ONLY END ACTION_DEFINE_ASSOCIATIVE_ARRAY table_transition_DIALOG_FILE2 BEGIN DORNJ , DORNP => DORN //BG2 Dorn EDWINJ , EDWINP => EDWIN //BG2 Edwin IMOEN2J , IMOEN2P => IMOEN2 //BG2 Imoen JAHEIRAJ , JAHEIRAP => JAHEIRA //BG2 Jaheira MINSCJ , MINSCP => MINSC //BG2 Minsc NEERAJ , NEERAP => NEERA //BG2 Neera RASAADJ , RASAADP => RASAAD //BG2 Rasaad VICONIJ , VICONIP => VICONIA //BG2 Viconia END ACTION_PHP_EACH table_transition_DIALOG_FILE2 AS dlg => res BEGIN COPY_EXISTING ~%res%.BCS~ ~override~ REPLACE_BCS_BLOCK EVALUATE_BUFFER ~.../DIALOG_FILE-old.baf~ ~.../blank.baf~ BUT_ONLY END COPY_EXISTING ~DPLAYER2.BCS~ ~override~ REPLACE_BCS_BLOCK EVALUATE_BUFFER ~.../DPLAYER2-old.baf~ ~.../blank.baf~ BUT_ONLY COPY_EXISTING ~PDIALOG.2DA~ ~override~ PRETTY_PRINT_2DA SET_2DA_ENTRY 1 0 1 multig PHP_EACH table_transition_DIALOG_FILE2 AS dlg => res BEGIN REPLACE_TEXTUALLY ~^%res%[ %TAB%]+\*[ %TAB%]+\*~ ~%res% %dlg_1% %dlg%~ END PRETTY_PRINT_2DA BUT_ONLY
  24. RevealAreaOnMap simply sets area flag in your local WMP file, so you would need to use it again for the area to show up. But you don't have to explore the map gain. I've written a code for you that can be used to update local WMP file based on what has been stored in old one. 1. Load your last save game and save it to new slot 2. In Near Infinity, open that new save -> baldur.sav -> Decompress -> Worldmap.wmp -> Delete file -> Save changes 3. Uninstall BP-BGT Worldmap, place that wmp file I've mentioned before to override, install newest BP-BGT Worldmap v.10.2.1 (if you already done it than you can skip this step) 4. Now start EET and load your edited save game without wmp file. Save it again (this will attach new and fixed WMP file to your save) 5. Use this code to update flags: OUTER_SPRINT source_save ~000000047-source_save_dir~ OUTER_SPRINT dest_save ~000000048-dest_save_file~ COPY - ~%USER_DIRECTORY%/save/%source_save%/baldur.sav~ ~.../%USER_DIRECTORY%/save/%source_save%~ EDIT_SAV_FILE 1 BEGIN SPRINT file ~%SAV_FILE%~ PATCH_IF (~%file%~ STRING_EQUAL_CASE ~worldmap.wmp~) BEGIN PATCH_PRINT ~Reading flags from %USER_DIRECTORY%/save/%source_save%/baldur.sav *%file%* ...~ GET_OFFSET_ARRAY are_array WMP_AREAS PHP_EACH are_array AS are_num => are_offset BEGIN READ_ASCII are_offset are_name READ_LONG are_offset+0x30 are_flags DEFINE_ASSOCIATIVE_ARRAY are_name_flags BEGIN ~%are_name%~ => ~%are_flags%~ END END END END COPY ~%USER_DIRECTORY%/save/%dest_save%/baldur.sav~ ~%USER_DIRECTORY%/save/%dest_save%~ EDIT_SAV_FILE 1 BEGIN SPRINT file ~%SAV_FILE%~ PATCH_IF (~%file%~ STRING_EQUAL_CASE ~worldmap.wmp~) BEGIN PATCH_PRINT ~Writing flags to %USER_DIRECTORY%/save/%dest_save%/baldur.sav *%file%* ...~ GET_OFFSET_ARRAY are_array WMP_AREAS PHP_EACH are_array AS are_num => are_offset BEGIN READ_ASCII are_offset are_name PHP_EACH are_name_flags AS dest_name => dest_flags BEGIN PATCH_IF ~%are_name%~ STRING_EQUAL_CASE ~%dest_name%~ BEGIN READ_LONG are_offset+0x30 are_flags PATCH_IF are_flags != dest_flags BEGIN WRITE_LONG are_offset+0x30 dest_flags PATCH_PRINT ~Patching %are_name% flags: %are_flags% => %dest_flags%~ END END END END END END 000000047-source_save_dir - instead of this paste the name of the directory with the save file you want to use as a base for wmp flags 000000048-dest_save_file - and replace this with directory name that already has fixed clean WMP in it. After installing the code your save will have fixed WMP file and all flags will be set like in old save.
  25. you're playing with BP-BGT Worldmap, right? There may be a problem there due to how Beamdog named the entrances in new areas (with whitespace). Wisp mentioned in the changleog that this should be fixed, but maybe his current implementation didn't work. Check what OH2000 entrance name is referred in BG5000 area section of WMP file. It should be "Entrance 1". edit: you probably use outdated version of this mod. Latest one is not 10.1 that hangs on download page but 10.2.1 available here: http://www.shsforums.net/topic/58385-worldmap-1021-released/ -------------- This is unrelated to your problem but if you're going to re-install BP-BGT Worldmap you could as well fix the base wmp file. Please first uninstall the mod than place this WMP file inside override directory: https://www.sendspace.com/file/7b3134 And than install the latest BP-BGT Worldmap version. The reason for this is the problem mentioned here. It has been fixed already on GitHub but the wmp in your game still has data which become corrupted after saving wmp in NI.
×
×
  • Create New...