Jump to content

Random notes


Taimon

Recommended Posts

You are not trying to lure me into researching Bit 6, are you? ;)

Didn't find anything in BG/BG2/PST/IWD/IWD2 but IWD2 is hard to read and I might have missed something. But I'd say it's unused.

 

Some info for script object matching:

You can check for multiclass with the class ids starting at 202.

The order is Mage, Fighter, Cleric, Thief, Bard, Paladin, Druid, Ranger.

So CLASS_ANY_MAGE (202) will match a simple MAGE, as well as a FIGHTER_MAGE_THIEF.

(Already documented, should have check earlier.)

And there is an additional allegiance EA_GOODOREVIL/EA_NOTNEUTRAL (198). It matches anything with an allegiance < EA_NOTGOOD and > EA_NOTEVIL.

 

I also came across a bug concerning the actions 51-59:

They use the wrong coordinates when trying to scroll to the target. (for scroll speed > INSTANT)

Fixed it locally, but these actions seem to be useless, because the reference point is the upper left corner.

So ClickLButtonObject("minsc", SLOW) will slowly scroll until Minsc is in the upper left corner and then click him.

 

And there seems to be something wrong with tiled objects (in areas). The open/closed searchmap squares are not copied into the internal structure. Has anyone ever used these tiled objects with success? Maybe I'm just reading it wrong.

Link to comment

No, sorry. I didn't mean to imply that there's some use for it, just that it was a generic "door located" (followed by door secret and secret door detected) bit when they specced it out.

 

I don't think tiled objects have ever been used.

Link to comment
I also came across a bug concerning the actions 51-59:

They use the wrong coordinates when trying to scroll to the target. (for scroll speed > INSTANT)

Fixed it locally, but these actions seem to be useless, because the reference point is the upper left corner.

So ClickLButtonObject("minsc", SLOW) will slowly scroll until Minsc is in the upper left corner and then click him.

 

Sounds like there might be more to the parameter's then somehow? From the sound of it it seems to be defaulting to 0,0 as the corner. Just a wild guess, I've been out of the loop for awhile.

Link to comment
Sounds like there might be more to the parameter's then somehow? From the sound of it it seems to be defaulting to 0,0 as the corner. Just a wild guess, I've been out of the loop for awhile.

Internally, actions 51-58 all use 59 to move the viewpoint. The bug is that 59 calls GetCursorPos() (Windows API) which returns screen coordinates but they are treated like if they were area coordinates.

Just before GetCursorPos(), the current viewpoint (in area coordinates) is retrieved, but not used.

For me, that call to GetCursorPos() looks really out of place. The position of the cursor is usually retrieved from the area or the chitin object, so it's not necessary (and wrong) to do it this way.

I'm not sure, what exactly that action is supposed to do.

(/Edit: Maybe it should scroll the specified point to the cursor location. I guess that's how I'll implement it.)

 

Buggy actions part 2:

Action 88 (Leader) has a typo that prevents it from working correctly. It's not directly in the action, but in a subroutine that sends all selected party member the follow action. (This action takes additional coordinates at int2 and int3, but the routine sets int2 twice. I assume the developer simply mistyped the second int2.)

The action is supposed to be called by the party leader. (He, or rather the first of the selected party members, does not get the follow action.) Int1 selects whether the actions are appended to the action queue (1) or inserted at the beginning (0).

Link to comment

Taimon, you talk about this part ? :

.text:0040E4ED mov [ebp+var_60], edx

.text:0040E4F0 mov eax, [ebp+var_60]

.text:0040E4F3 mov ecx, [ebp+arg_10]

.text:0040E4F6 mov [eax+42h], ecx <---- useless instruction

.text:0040E4F9 mov edx, [ebp+var_60]

.text:0040E4FC mov eax, [ebp+arg_14]

.text:0040E4FF mov [edx+42h], eax <---- overwrites previous value

.text:0040E502 mov ecx, [ebp+var_60]

Link to comment

Some info for the CHU file format:

  • Window+0x1a (flags):
  • Bit0 means don't shade the underlying window. (Easy to test with the confirmation dialog in GUILOAD, when you try to delete a game.)
  • Bit1 skips the allocation/loading of the window ingame. Can't think of any use for that.
     
    Button:
  • Bit6 in the flags (0x17) disables multi-line text. Only one line will be displayed.
  • And you can specify an offset for the anchor (bit4): (0x19 | 0x1b << 8) is the x coordinate and (0x1d | 0x1f << 8) the y coordinate. Internally, these two words are unsigned and copied into dwords, so you can't specify negative offsets. In my opinion only useful if you want to place the text at an exact position. (You would set the anchor, top and left bits and then specify the offset in the described bytes.)
     
    Slider:
  • The unknown words starting at 0x2c specify the slider rectangle. Order is top, bottom, left, right.

Link to comment

Nice finds!

The disable modal shadow flag is used heavily in guicg.

A pity, we already hardcoded all modal shadow stuff in gemrb guiscripts.

 

All sliders (they are used only in guiopt) use the same four values.

 

I have yet to find any button control that uses the custom anchor point. It is a really obscure placement of values. Apparently hacked in later. The only really useful part of that info is to restrict the cycle/frame fields to a byte value.

Link to comment
Yeah, it's mostly useless, but good to know you implemented it immediatly. :)

 

By the way, I went through the attack action code, lately. If GemRB needs some specific info, let me know. (You guys know about rndbase bitmaps, right?)

 

I don't even know what you mean by rndbase. (or mdbase :laugh:

Bitmaps vs. attack, doesn't ring any bells.

 

And we need to refactor our attack code in 0.6.3 (it was one of the planned changes by Fuzzie), so i guess she would be happy to hear about it.

Link to comment
Guest Asc64_away

Haha, I came across the rndbase bmp stuff too. I'll let Taimon do the explaining since I have no access to modding/reversing stuff for some time, but the bitmap controls when the character swings, when is idle, when attack is calculated, etc. Each rndbase corresponds to the # of attacks.

Link to comment
Haha, I came across the rndbase bmp stuff too. I'll let Taimon do the explaining since I have no access to modding/reversing stuff for some time, but the bitmap controls when the character swings, when is idle, when attack is calculated, etc. Each rndbase corresponds to the # of attacks.

This is totally new for me :)

Link to comment

Well, I'm certainly not good at explaining things, but here goes:

 

The rndbase bitmaps describe the basic attack round. There are 5, each corresponds to the number of attacks (-5 if it's greater 5) the attacker has.

They are indexed by attack initiative and a timer/counter (named it attack_rnd_timer) that increments each ai update.

Initiative is calculated like this:

((item_ability.speed - cre.stats.phys_speed) [>= 0] + rand_mod(k, -cre.stats.luck) - (k/2)) [0,10]

I think I already describe what rand_mod does (biased random number in range [0,k-1]) and k is hardcoded to 6.

 

Rndbase values range from 0 to 15 (4bpp) and here is what I think each value means:

 

0: play ready sequence, if not already playing ready or attack or shoot, action is interruptable

1-5: noop, not used as far as I can tell, action is not interruptable

6: non-projectile only, play attack sequence, do attack sound, set last attacker, action is interruptable

7: play attack/shoot sequence if attack_enable (see 10-14) is set, action is not interruptable

8: action is not interruptable, (this does reset something that 7 set, but let's ignore it for now)

9: real attack happens here, nearly all of the code is protected by an attack_enable flag, action is not interruptable

10-14: do setup for 9, set/reset attack_enable and whether it's an offhand attack, play attack/shoot sequence, do attack sound if non-projectile, action is not interruptable

15: play ready sequence (if not playing ready or attack or shoot), reset timer, action is interruptable

 

low-level pseudo-code for 10-14:

if (num_attacks <= 5):
if num_attacks >= (value - 9):
	attack_enable = 1
	if (num_attacks == (value - 9)) and (num_attacks != 1):
		offhand_attack = 1
else:
	attack_enable = 0
	offhand_attack = 0
else:
if (num_attacks - 5) > (value - 9):
	attack_enable = 1
	if (num_attacks - 6) == (value - 9) and (num_attacks - 5) != 2:
		offhand_attack = 1
else if (num_attacks - 5) == (value - 9):
	attack_enable = rand(1)
	offhand_attack = 0
else:
	attack_enable = 0
	offhand_attack = 0

(Disclaimer: I might be wrong. :))

 

pseudo code for the real attack (9):

set last attacker, force visible, remove sanctuary
if not projectile:
play attack sequence, do attack roll
if (attack succeeded):
	send hitby trigger, check protection from melee weapons
	if (target not immune):
		do damage roll, add damage effect to item ability,
		send melee effects (from cre.stats), dispatch item ability effects
else:
play shoot sequence, do attack roll and check prot. melee weapons
if (attack succeeded) and (target not immune):
	do damage roll, add damage and other effects to projectile
	(item ability, launcher, ranged effects from cre.stats)
else:
	clear projectile effects
do attack sound, start projectile

handle item charges/stackamount, do autopause if weapon became unusable
send attackedby trigger and interrupt dialogue if attacker.allegiance <= GOODCUTOFF

Link to comment

Nice, this should help a lot. I've just committed the cleaned initiative calculation. We also take speed bonuses from weapon style in there, so I guess the original used them as bonuses to the physical speed stat. And a wtf at that -k/2.

Link to comment
We also take speed bonuses from weapon style in there, so I guess the original used them as bonuses to the physical speed stat.

Yep, they are applied when updating the stats.

 

And a wtf at that -k/2.

Only to have [-(k/2), (k/2) -1] range instead of [0, k-1], i. e. to have a chance to increase or decrease initiative.

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...