Taimon Posted November 8, 2010 Author Share Posted November 8, 2010 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
devSin Posted November 8, 2010 Share Posted November 8, 2010 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
Kung Fu Man Posted November 12, 2010 Share Posted November 12, 2010 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
Taimon Posted November 12, 2010 Author Share Posted November 12, 2010 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
Avenger Posted November 13, 2010 Share Posted November 13, 2010 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
Taimon Posted November 16, 2010 Author Share Posted November 16, 2010 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
Avenger Posted November 17, 2010 Share Posted November 17, 2010 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
Taimon Posted November 24, 2010 Author Share Posted November 24, 2010 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?) Link to comment
Avenger Posted November 24, 2010 Share Posted November 24, 2010 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 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 Posted November 25, 2010 Share Posted November 25, 2010 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
Avenger Posted November 25, 2010 Share Posted November 25, 2010 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
Taimon Posted November 25, 2010 Author Share Posted November 25, 2010 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
lynx Posted November 25, 2010 Share Posted November 25, 2010 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
Taimon Posted November 25, 2010 Author Share Posted November 25, 2010 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
Recommended Posts
Archived
This topic is now archived and is closed to further replies.