agris

On 11/29/2023 at 8:14 AM, DavidW said:

That's fairly persuasive. And my original playtesting of that component is ancient, and probably in a period where BG1 creatures were using a narrower range of high-level spells. I'll consider a level adjustment.

Yes (I hope) though my thoughts of incorporating aspects of your component got triaged on time grounds, sorry. Possibly next version...

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.

On 3/11/2023 at 12:13 PM, Guest Mikey205 said:

Can you please make this modular? I would appreciate the option to transfer over SOD items + upgrades without the other components. This is literally the title of the mod, so other elements should be optional addons or separate mods.

agreed, some modularity would be much appreciated

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.

1 minute ago, jmerry said:

I don't have original BG1 or original BG2.

The "small sword" type is still there for Flame Blade. Druids can take that proficiency in oBG1 as well, because it's what daggers use. Clerics are out of luck, even though they're able to cast the spell. Types are still present for the other weapons too, although it usually doesn't matter for player characters. Only the gauntlets that boost unarmed attacks still care; weapons with the "hand to hand" type like many shapeshifted attacks get that bonus.

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.

33 minutes ago, jmerry said:

If they did use a proficiency, then characters without that proficiency would take non-proficiency penalties. Phantom Blade is already a spell nobody uses, but if your mage took -5 to hit because they're not proficient in long swords? Ouch.

You could cover that by granting proficiency while equipped ... but that introduces bugs to the system. It's very easy to turn temporary proficiencies into permanent ones through the level-up and dual-class systems.

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.

Nice QC, thanks.

edit: but also, sorta weird?

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.

If using cdtweaks’ option to alter the proficiency system and stratagems, does it make sense to install that specific tweaks component after stratagems?

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.

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.

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

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

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.

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?

37 minutes ago, lefreut said:

I tried something like this:

if #loot.containerItems == 0 then Infinity_PopMenu('WORLD_CONTAINER') end

But there are two issues:

1) The loot.containerItems variable is updated only after the action ends so you have to press 'E' a second time.

2) This will close the container menu but it will not reopen the action bar.

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!

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.

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?

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

@jmerry that sounds like an issue you should submit on weidu's github.

20 hours ago, jmerry said:

Actually, the current bard song range varies based on which song it is (at least in the BG series):

Vanilla bard song: The entire area, but only party members.

Blade song, skald song, HLA enhance bard song: all allies within a standard medium AoE.

Jester song: all enemies within a standard medium AoE.

And here's an existing tweak for bard song range: https://forums.beamdog.com/discussion/61898/tressets-choice-tweaks (Bigger Bard Song, some way down the post)

Thanks, I’m aware of tresset’s mod.

It doesn’t address the functionality that I’ve suggested.

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.

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

Can anyone comment on the April 2021 version of BGGOEET? I'm curious what, if any, graphical problems remain with it.

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

3 minutes ago, jmerry said:

... Ah. I think I see. Deleting and replacing items requires all the later offsets to be recalculated. The functions there must be recalculating the "rest encounters offset" to "after the items". Which is the end of the file. Oops.

This should be fixable on the cdtweaks end, by updating that sanity check I quoted above:

    READ_LONG rest_offr rest_off
	PATCH_IF (rest_off > 0) AND (rest_off < SOURCE_SIZE) BEGIN // in case area has no rest encounter section, skip attempted patching

 

42 minutes ago, jmerry said:

It's still missing the rest encounter element and a couple others, but it has the offsets for those at "size of file" instead of 0.

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.