Jump to content

agris

Members
  • Posts

    122
  • Joined

  • Last visited

Everything posted by agris

  1. For what it's worth, when I replayed BG1 with SCS earlier this year, this is the only part that seemed wrong to me. That Aerial Servant completely changes the encounter in a way that screams "modder content". I play my IE games for tough, tactical fights and tight resources. I would recommend either bumping his level down so that he can't summon it, or give him more bespoke AI that precludes the summoning of the Aerial Spirit entirely. This, and the ogre mages outside of Candlekeep. Those two optional encounters felt off to me. I liked the tougher kobolds.
  2. agreed, some modularity would be much appreciated
  3. This is a good mod, but I think it would benefit from more items on the "do not randomize" list for BG1. This is mostly due to story / gameplay reasons: Gauntlets of Weapon Expertise on Meilum Balduran Logbook (desk in top level of Balduran's ship) Butterknife of Balduran (desk in top level of Balduran's ship) Short Sword of Backstabbing (Slythe) Curious if anyone else has played through BG1 somewhat recently with this and felt that some items were randomized that shouldn't be.
  4. I would call the flame blade assigned proficiency an error given the spell description text. non-EE IWD is also using v1 of the ITM file type, and some summons have proficiencies assigned (Shillelagh, Spiritual Hammer - clubs, hammers) while others use the miscellaneous category/proficiency, likely to avoid penalizing the caster who does not have proficiency. Interestingly, Flaming Blade does this (likely to avoid the situation you just highlighted) as does Moonblade. So my original bug report was wrong, but it did highlight that some of the weapon summoning spells are not being faithful to TotSC.
  5. Check out the BG1:TotSC version of those spells, where applicable. Shillelagh, Flame Blade, Spiritual Hammer all create items with proficiencies - but it's BG1's style of proficiency. The 'Category' field in NI. Your example cuts both ways, for example in BG1, a divine caster is fairly likely to have blunt proficiency. It makes sense that Shillelagh would be a summon then, as it utilizes a proficiency the caster is likely to have. Similar logic for Flame Blade, where a druid with large sword proficiency (functionally scimitars) would be likely to cast it due to - from the description - "This blade-like ray is wielded as if it were a scimitar". The BBoD is an interesting example, in that it acknowledges the poor utility of a spell summoning a weapon for which the caster's class likely has no proficiency (short of multi/dual). To me, it seems like a bug that BG1:EE didn't adopt this, and may have been a mistake by the original developers when they implemented BG2-style proficiencies to the revised .itm format for BG2. Did you check OG BG2, or BG2:EE for those summoned items' proficiencies? edit: actually, in TotSC, flame blade is incorrectly set to small sword proficiency. The point stands those, these summoned items are assigned proficiencies that I believe were intentionally in-sync with the casting class(es). edit2: to your point about Phantom Blade, the description indicates that the spell would confer proficiency "The caster wields the phantom blade as if proficient with it, at their normal THAC0." which addresses the point you're trying to make. I think the intention was for some summoned weapons to use the player's proficiency (i.e. make sure you can use it or be penalized) while others purposefully eschewed an assigned proficiency to avoid the penalties.
  6. When playing with Divine IWD spells, the Moonblade spell does not create a blade with any defined proficiency. I checked IWD: EE and this is consistent, but I believe it is an error. Other weapon summoning spells, when the weapon is a clearly defined type (hammer, club) use the correct proficiency. The summoned Moonblade is clearly a long sword/large sword.
  7. If using cdtweaks’ option to alter the proficiency system and stratagems, does it make sense to install that specific tweaks component after stratagems?
  8. Balls, I thought it was 10000 gp in BG2. That SoD price should be the standard, but I understand that’s a different conversation than this. I was shocked at how cheap it was in BG1:EE and saw the fandom wiki page for it list the price as 10k. I mistakenly assumed that was the non-enhanced BG2 price.
  9. For cdtweaks v16, component 1080 adds bags of holding using the bag04.itm packaged with the mod. It's base price is set incorrectly at 500 gp. Setting aside concerns of balance, bags of holding in BG2 are priced at 10,000 gp each. I think it's reasonable for cdtweaks to use 10,000 gp as the base price of the added bags of holding rather than 500. This is in reference to a BG1:EE install.
  10. I absolutely loved the lack of direction that Thalantyr gives. It made me pop open my gem bag and actually read the descriptions of the gems I had, and wouldn't you know it, some mentioned scrying! I expect that these descriptions were modified by The Calling, but even if not, it's an excellent touch. Not everything needs to be spoonfed to the player. Now if only I could find Melicamp in the Nashkel mines...
  11. In Firewine: 1. Speak to Carsa, end the dialogue such that she's random walking around the gully without invoking Kazah's name 2. Force attack Carsa, kill her, get an invalid sttref floater: "carsa_say_strref_8" Guessing the error is in /tactical_bg1/carsa.tpa, but I don't know weidu syntax well enough to know precisely where COPY_EXISTING "%tutu_var%carsa.dlg" override GET_OFFSET_ARRAY say_arr 0xc 4 0x8 4 0 0 0x10 PHP_EACH say_arr AS say_ind=>say_off BEGIN READ_LONG say_off strref SET $carsa_say_strref("%say_ind%")=strref GET_STRREF strref string SPRINT $carsa_say("%say_ind%") "%string%" END GET_OFFSET_ARRAY resp_arr 0x14 4 0x10 4 0 0 0x20 PHP_EACH resp_arr AS resp_ind=>resp_off BEGIN READ_LONG (0x4+resp_off) strref SET $carsa_response_strref("%resp_ind%")=strref GET_STRREF strref string SPRINT $carsa_response("%resp_ind%") "%string%" END win10 x64 stratagems 34.3 weidu 249.0 WeiDU.log
  12. I like how CHARNAME can petition the temple next to Beregost for their black pearl. Yet, when you return later with another one and offer to give it to the temple, it is not removed from inventory. This occurred when the party member who actually held the pearl - the one ostensibly given to the temple - is not actually inside the temple. They were outside the temple. The pearl was also in a gem bag. I don't know if the NPC's location / gem bag are relevant, but those were the specific conditions. Also cdtweak's "require identification for gems / pots" results in the black pearl that the temple hands you being unidentified - which doesn't make much sense.
  13. I swear in the non-enhanced versions the log printed the actual value of HP healed, similar to the Player Takes Damage (<#>) string printed when you trigger a trap. I've forced 'Extra Feedback' on in Baldur.lua and it doesn't do it, nor does the overkill option of 'Extra Combat Info'. Is there a UI mod that shows these values?
  14. Thank you. Excuse my ignorance, but to point 1, would something like this work? { on E action " count = 0 Infinity_PlaySound('GAM_09') worldScreen:TakeAllFromContainer() count = 1 " if count > 0 then if #loot.containerItems == 0 then Infinity_PopMenu('WORLD_CONTAINER') end count = 0 end } The counter is tracking if we've pressed E or not, so newly opened but empty containers don't close automatically. To point 2, is there an action bar equivalent of Infinity_PopMenu? like Infinity_PopMenu('ACTION_BAR') that could be invoked together with the closing of the world container? edit: whew, that code view is a finicky beast!
  15. Another oddity of Nostalgia Pack helmets being borked by Lava's unique icons. On BG:EE, Nostalgia Pack Component 50 "Restore BG1 Icon Icons and Appearances" created or unbiffed helm11.itm. Lava's component 170 modifies it to change the icon and the paperdoll appearance, but the new appearance isn't valid. This is the helm after Lava's modification of the ITM's appearance field to "h6". The nostalgiapack version used h5, which renders correctly.
  16. I'm playing BG:EE right now with the excellent Classic BG UI mod, and it includes some handy hotkeys. One of them is "loot entire container" when pressing E. It's great, reminds me of some of the great time-saving sfall tweaks for Fallout 1/2. It's defined as such in ui.menu { enabled "containerBigMode == 0" on E action " Infinity_PlaySound('GAM_09') worldScreen:TakeAllFromContainer() " } Setting aside bigmode, I would like to add onto the end of the on E action macro a line that (1) checks if the container is empty, and (2) if so, closes the container. Something like if getContainerEmpty = 1 then closeContainerWindow else end Except both those function calls are fake. I made them up! This is where I'm running into my first issue: it seems like there is no good documentation of the functions available for the EE UIs. It's all contained in the black hole that is the Beamdog forums, which don't let you search per-forum and, strangely, are not searchable by google using the classic "TERM site:https://forums.beamdog.com/categories/ui-modding" method. I've looked through ui.menu and I see a lot of container functions, like getContainerItemProperty([index, 'property']) but I can't find these getContainerX functions documented. So: what's the "easy" function to check if a container is empty, and what type of function am I looking at to close the loot window? And will the "on E action" macro accept those functions?
  17. on BG:EE, if component 170 "Unique Icons [Lava] -> Only replace icons that aren't already unique: v16" is installed after ~NOSTALGIAPACK/NOSTALGIAPACK.TP2~ #0 #60 // Restore BG1 Flaming Fist appearance: RC4, Flaming Fist NPCs' helms are green. Flaming Fist mercenaries are equipped with HELM09.itm, which has a conspicuous color code for the helm set to green. Running a --change-log on HELM09.itm shows that nostalgiapack unbiffed and modified it, followed only by cdtweaks 170. The version that nostalgiapack generated does not have the green code. weidu.log, change-log output, and both versions of the itm file attached. _helm09 bug.7z
  18. @jmerry that sounds like an issue you should submit on weidu's github.
  19. Thanks, I’m aware of tresset’s mod. It doesn’t address the functionality that I’ve suggested.
  20. The newest BG/IWD EEs massively shorten the range of bard song. I propose a tweak that lets the user choose between: original bard song range (whole map) some balance between new and old behavior user-configurable (integer input) The component would smartly scan bard songs and modify their range, such that (for example) IWDification’s optional change to true class / skald / jester songs can be detected and patched, vanilla and mod-added (rr) bard song HLAs, etc. component would work on BGs and IWDs.
  21. BGEE 2.6.6.0 steam release, weidu v249, win10 environment outside of C:\ and Program Files. When trying to install component 50 of randomiser, (Mode 2: No items lost, following 50% chance to not randomize) I consistently get errors on the component trying to place items on creatures stating: ERROR: cannot convert rcp_prof_103 or %rcp_prof_103% to an integer sometimes the number if 105 rather than 103. Just a guess - since this is during the modification of .CREs with random items, maybe randomiser is checking and modifying cre proficiencies to ensure it is proficient with the weapon that randomiser is placing on it. Maybe randomiser is not handling cdtweak's change of weapon proficiencies? It's the only thing that I can think of: since I'm installing randomiser after cdtweak's component 2161 (Alter Weapon Proficiency System: BG-style weapon proficiencies, with weapon styles [the bigg] v16), randomiser is choking on the proficiencies as redefined by that component. But that's assuming this rcp_prof function is doing what I think it is, I really have no idea. I've attached a set of debugging files, hopefully they will help ID the issue. In the meantime, I'll rework my install to try randomiser prior to cdtweaks. edit: looks like I was being too specific in my search terms, I found another user with this issue (https://www.gibberlings3.net/forums/topic/31667-errors-during-linux-install-cannot-convert-rcp_prof_/). It is due to changing the proficiency system. debugging files.7z WeiDU.log
  22. Can anyone comment on the April 2021 version of BGGOEET? I'm curious what, if any, graphical problems remain with it.
  23. For anyone else dealing with this, prior to Cam releasing an update, I've attached the fixed. tpa. Drop it in /lib/ rest_spawns.tpa
  24. If I understand you correctly, 1) this fix you provided works around the .ARE being modified, but doesn't actually let cdtweaks impact the encounter rate? i.e. the component doesn't fall down, but for this one map it has no impact (which is fine). 2) from your most recent reply, it sounds like you *thought* the rest encounter element and "a couple others" were missing, but that was because you expected to find them at certain offsets and randomizer, by virtue of doing what it does, required the re-calculation of those offsets and thus the fields aren't where you (or cdtweaks) expects them.
×
×
  • Create New...