Jump to content


  • Posts

  • Joined

Everything posted by argent77

  1. It depends on your expectations. Using the code snipped provided by CamDawg should be enough to enable fog on maps. However, if you want to have full control over the fog behavior then you also have to add definitions to FOGPT.2DA and/or FOGAREA.2DA. I wouldn't recommend to define FOGPT.2DA entries though, because without it the fog will creep in from the edges which looks more natural. Setting up definitions allows you to specify only a single fog generator location which may look artificial. Btw, fog on maps with active day/night cycle may cause problems because of a bug in the fog implementation. It looks like the engine applies the night lighting incorrectly to the fog which causes some unwanted coloration (see screenshots below).
  2. The mod "Magic store of Vergadain" should definitely be installed before EET_end since it adds new lines to Taerom's dialog.
  3. Variable replacement cannot be performed for instances where WeiDU expects a numeric value or an expression. There are several ways around it though. For SAY you can use WRITE_LONG instead. The ADD_JOURNAL action is more limited, but it's possible to include variable replacements if you build the command dynamically and INCLUDE it. Btw, simply prefixing existing strrefs by "2" can be dangerous if the strref in question is either less than 10000, or greater than 100000. It's much safer to add 200000 as a number instead. ALWAYS OUTER_SET eet_2 = GAME_IS ~eet~ ? 200000 : 0 END // Build ADD_JOURNAL command dynamically <<<<<<<< .../inlined/my_mod/journal.tph >>>>>>>> OUTER_SET title_strref = eet_2 + 59615 APPEND_OUTER - ~.../inlined/my_mod/journal.tph~ "ADD_JOURNAL EXISTING TITLE (#%title_strref%) @10000 @10001 @10002 @10003 @10004 @10005 @10006 @10007 @10008 @10009 @10010 @10011 @10012 @10013 @10014 @10015 @10016 @10017 @10018 @10019 @10020 @10021 @10022 @10023 @10024 @10025 @10026 @10027 @10028 @10029 @10030 @10031 USING ~sodrtd/translations/autotra/%LANGUAGE%/game.tra~" INCLUDE ~.../inlined/my_mod/journal.tph~ // Replace SAY by WRITE_LONG COPY_EXISTING ~sodrtd/cre/c#rtdblc.cre~ ~override/c#rtdblc.cre~ SAY NAME1 ~Karlen~ SAY NAME2 ~Karlen~ WRITE_LONG SELECT_COMMON1 (eet_2 + 69456)
  4. I don't think RESOLVE_STR_REF supports the USING directive. However, you could wrap the WeiDU action in a WITH_TRA block. WITH_TRA ~modname/translations/%s/blabla.tra~ BEGIN OUTER_SET strref2 = RESOLVE_STR_REF(@107) END
  5. Usage is exactly like GET_RESPONSE_STRREFS except that you specify a second array parameter ("text") for accessing the response strref. Afaik WeiDU always returns the same strref for identical strings. For example if tra reference @1234 is used to add a new transition to a dialog then RESOLVE_STR_REF(@1234) should return the same strref that can be used to find the response later on. This contrived example adds a response trigger to selected transitions of Jaheira's BG2 dialog.
  6. Another point to consider is that many mods have already been updated to be compatible with patch 2.6. However, as a result it is possible that these mods are not fully compatible with patch 2.5 anymore. EET itself does only support a specific patch version anyway. You'd have to install older mod versions which were still developed for patch 2.5 to create a stable mod installation. But in that case you might miss new features or bugfixes. Btw, I don't see EE patch 2.7 coming in the foreseeable future.
  7. Following up on jastey's description of the GET_RESPONSE_STRREFS function above, this is a more powerful version that returns not only response strrefs but also the remaining response elements such as flags, journal entries, triggers, actions and the next dialog state. Definition of patch function GET_DLG_RESPONSES: Example code that prints information of a dialog state to the console (from SoD file BDEDWIN.DLG):
  8. Spellhold Studios Trials of the Luremaster for Baldur's Gate Trials of the Luremaster for Baldur's Gate is a port of the Icewind Dale expansion for the Baldur's Gate series. Version 3.0 overhauls monsters and brings them closer to their pen & paper descriptions, improves combat scripts, adds more starting points for the adventure and fixes several bugs. More details can be found in the Changelog section of the readme. You can grab the latest release from the download links below. Download: GitHub Forums: SHS, Beamdog Readme
  9. Improved Archer Kit This mod makes an attempt to rebalance the Archer kit. It adjusts overall power and adds several unique skills and abilities to the kits. Moreover, it offers similar kits for the fighter, thief and paladin classes. Version 4.0 overhauls all available kits, completely revises the "Create ammunition" ability to make them more unique for all kits and fixes several bugs. The full changelog can be found in the Readme. You can grab the latest release from the download link below. Links: Forums: Beamdog, SHS Download: GitHub Readme
  10. Achievements! This mod makes Steam Achievements available to everyone as journal entries and a special item that tracks your current progress. The mod supports all Enhanced Edition games patched to version 2.0 or higher, which includes BG:EE (with or without SoD), BG2:EE, EET, IWD:EE and PST:EE. Project Infinity is supported as well. You can find out more in the readme linked below. Download: GitHub Discussion: G3, Beamdog Readme
  11. There is always room for improvement.
  12. Improved Shamanic Dance This mod improves the main feature of the Shaman class - the Shamanic Dance. It allows you move at reduced speed while dancing to improve tactical options and provides additional features such as more useful spirits at higher levels, a new shamanic spell as well as several shaman-specific artifacts. Version 4.4 includes Russian translation by dim-chek. You can grab the latest release from the download link below. Links: Forums: Beamdog, SHS Downloads: GitHub Readme
  13. Achievements! Download from GitHub Readme Overview This is a small mod that I created out of a spontaneous idea. Just as the name suggests, this mod makes Steam Achievements available for everyone as regular journal entries in the game without the need to play it through the Steam client. It is not needed to purchase the game from Steam either. Journal entries will pop up whenever new achievements have been unlocked, along with a message in the log window that informs about the total number of unlocked achievements so far. In addition to the list of official achievements this mod also tracks a couple of unused achievements in SoD that were implemented in the game but apparently not registered in Steam. Unlocked achievements can also be inspected in the item description of an Achievements Trophy which is available in selected stores across the games. See the readme for more details. You can choose between two installation options which determine the detail level of the statistics presented by the Achievements Trophy. Screenshots: The mod supports all Enhanced Edition games patched to version 2.0 or higher, which includes: BG:EE (with or without SoD) BG2:EE EET IWD:EE (since patch 1.4.0) PST:EE
  14. Very insightful. In that case I'll have to be careful when using event-based triggers. The workaround of using GlobalTimerExpired() in place of !GlobalTimerNotExpired() should work well enough in my case. For PSTEE I had to come up with yet another solution involving the Delay() trigger, because apparently not even timer checks work correctly in that game when used in a global script.
  15. Yes, that works but can be solved more elegantly. I could instead replace !GlobalTimerNotExpired() by GlobalTimerExpired() to ensure that unset timers fail the check as well, which is functionally equivalent to using an extra variable. But then the script would be more vulnerable to outside influences, for instance, to other mods which install their own script blocks to the baldur.bcs and prevent the OnCreation() block from triggering. In that case the second block would never be triggered which basically disables the whole mod. Imo it's still the better option to work around the strange OnCreation() behavior since the probability of that scenario is quite low. The main reason for this topic is still to find out how a negated OnCreation() trigger can fail to evaluate at the same time as a non-negated OnCreation() trigger. It doesn't make sense to me.
  16. The second block runs immediately if the timer hasn't been set yet. Setting the timer in the same script round by another block doesn't work because changes to globals aren't registered until the next pass. I could change !GlobalTimerNotExpired() to GlobalTimerExpired(), but that isn't as robust either.
  17. The second block should not be triggered in the same script round as the first block because it wouldn't make sense. This is probably a corner case and can be solved in different ways, but the current implementation would be the most convenient option for me. I'm more interested why the OnCreation() trigger doesn't behave like other triggers.
  18. I have two script blocks for the BALDUR.BCS script. The first one should be triggered immediately whenever the game starts or a savegame is loaded to initialize nonpersistent data. The second block should be triggered in timed intervals to track changes. IF OnCreation() THEN RESPONSE #100 SetGlobalTimer("MY_TIMER","GLOBAL",FIVE_ROUNDS) // more actions... Continue() END IF !OnCreation() !ActuallyInCombat() !GlobalTimerNotExpired("MY_TIMER","GLOBAL") THEN RESPONSE #100 SetGlobalTimer("MY_TIMER","GLOBAL",FIVE_ROUNDS) // more actions... Continue() END With these blocks the OnCreation() block is triggered correctly whenever a game is loaded. However, it never fires the second block unless I remove the negated OnCreation() check. Is there something I have missed?
  19. Have you tried adding a SmallWait() between the two actions?
  20. According to the WeiDU documentation the syntax used by subtledoctor should work correctly. There is nothing that indicates that transition features have to be defined in a certain order or cannot be added multiple times. For instance, it is perfectly legal to add the UNSOLVED_JOURNAL entry or DO block before the reply string. However, it looks like WeiDU processes DO blocks in reversed order. In your case DO ~AddKit(THIS_KIT)~ DO ~ApplySpellRes("the_spl")~ results in ApplySpellRes("the_spl") AddKit(THIS_KIT) That's probably the reason why your original code example didn't work. Btw, it's even legal to add multiple REPLY entries without causing a compile error. However, only the last instance is used in this case.
  21. Did you try CLEAR_IDS_MAP after updating spell.ids? It is possible that ADD_SPELL works on a cached ids map otherwise.
  22. There is a mod compatibility list for EET which lists most mods that are compatible with EET: https://k4thos.github.io/EET-Compatibility-List/EET-Compatibility-List.html From the listed mods Saradas Magic, D's Odd Quest, Trials of Luremaster and Rupert Dye Merchant are mentioned in the list as being compatible. Trials of the Luremaster provides a readme which also lists all supported games and known compatibility issues. I don't know about the other mods. But if they don't explicitly mention EET in their readme then you could open the .tp2 file included in the mod packages and look for a mention of GAME_IS with "eet" listed somewhere in the associated game string.
  23. You can probably write a custom patch function that does the job for you. 2DA files are simple text files after all.
  24. Even the 64-bit version is still called OpenAL32.dll for compatibility reasons.
  • Create New...