Jump to content

Concordance of new features


Ascension64

Recommended Posts

c.) they change the RGB of the entire creature to a set value

The palette color lock is coded into the effect.

 

If someone wants to come along and change the colouring of an overlay or introduce a new one, how could (s)he do so? I've looked for RGB hints in the overlay.2da, and found none.

 

b.) they do not play on creatures out of sight from the party (very important IMO)

I don't draw anything when not seen, i think :mad:

 

It would be nice to see this in BGII. If I want any .bam to never play on invisible non-allied creatures, how could I achieve that in GemRB?

 

I don't pause any overlay (be it hardcoded or 0x215) because of timestop. I don't think i should, i didn't even notice this quirk.

 

I don't understand this. Is this opcode 215?

 

e.) they set some sort of stat while they are active

The stat setting is in the opcode.

This means we would still be setting a stat in a seperate effect in the extended header?

 

>How would you remove the "apply spell repeatedly" from single .spl or .itm source?

>a.) there is no "dispel by resource" opcode,

Oh, but there IS (0x0fe). Hmm, Asc should write it, but it exists in IWD/GemRB.

You can remove an effect coming from a specific source. ASR is not different from other opcodes.

 

The IESDP lists 0x0fe as "Spell Effect: Remove Map Marker" in BGII. I don't think we'd be overwriting this opcode. What solution does GemRB use that is possible to implement in ToBEX?

 

-Galactygon

 

Changing body color in overlays: It is basically a whole body coloration.

GemRB supports the whole body color stuff as in IWD.

The coloration in sanctuary can be turned off by the 'enhanced opcodes' feature. (If you find this weird, read the comments in the code). GemRB doesn't support the hardcoded overlays more than necessary (i view them as a dead end). It is better to use opcode 215 (not hex number as i mistakenly wrote).

 

Hmm, as i wrote earlier, I don't think i ever draw anything on invisibles. (Unless they already attacked, because once an invisible thing attacked, it is partially invisible!). Allies are also partially invisible.

 

I wrote effect removal exists in IWD, then you talk about 0xfe in BG2 O_o. Obviously, BG2 needs this effect, to be cool. If you can think only in enhancing existing opcodes, then it is tougher.

I think removing effects by source is a very handy effect. The other route (removing by school/secondary type) is a bit clunky, because you cannot restrict your removal to selected spells.

Maybe this could be an option of dispel effects. (It has an empty resource field, and its param2 can support other options).

Link to comment
Changing body color in overlays: It is basically a whole body coloration.

GemRB supports the whole body color stuff as in IWD.

The coloration in sanctuary can be turned off by the 'enhanced opcodes' feature. (If you find this weird, read the comments in the code). GemRB doesn't support the hardcoded overlays more than necessary (i view them as a dead end). It is better to use opcode 215 (not hex number as i mistakenly wrote).

 

Hmm, as i wrote earlier, I don't think i ever draw anything on invisibles. (Unless they already attacked, because once an invisible thing attacked, it is partially invisible!). Allies are also partially invisible.

Opcode 215 still draws over invisible creatures, does not set the .cre's colour overlays, and freezes during timestop. Maybe we could solve this in .vvc files. Asc64 did thorough research on the .vvc format; Bit 11 at 0x0018 is a flag for "Ignore time stop". Some of the unused bits can be used for "disable on non-allied invisible" and "set RGB of .cre", with unused offsets 0x001c, or 0x0024 being used as pallettes.

 

That still leaves us with opcode 141 (lighting effects) playing on invisible creatures. Maybe that could be hardcoded to not play on the invisible.

 

What do you think?

 

I wrote effect removal exists in IWD, then you talk about 0xfe in BG2 O_o. Obviously, BG2 needs this effect, to be cool. If you can think only in enhancing existing opcodes, then it is tougher.

I think removing effects by source is a very handy effect. The other route (removing by school/secondary type) is a bit clunky, because you cannot restrict your removal to selected spells.

Maybe this could be an option of dispel effects. (It has an empty resource field, and its param2 can support other options).

 

I'll share my idea for opcode 58 (Cure: Dispellable Effects (Dispel Magic)):

Parameter #1: Level

Parameter #2: Type

Description:

Dispels magic from the targeted creature(s) (excepting magical weapons eg. Spirtual Hammer). Depending on the value of the 'Type' field, the 'Level' field can be used to set the level of the effect.

 

Known values for 'Type' are:

0 Always dispel

1 Use Caster Level

2 Use 'Level' field

3 Always dispel effects that use resource as a source

4 Use Caster Level to dispel effects that use resource as a source

5 Use 'Level' field to dispel effects that use resource as a source

 

-Galactygon

Link to comment
Animations: i'm not really keen on this idea. It would be difficult to implement and little to gain from.

We should at least keep the "do not draw on invisible creatures" flag. Or if that's not possible, introduce new parameters for opcodes 215 and 141.

 

#141 (0x08D) Graphics: Lighting Effects [141]

Parameter #1: Target

Parameter #2: Type

Description:

Shows the lighting effect (a .bam file) specified by the 'Type' value. These effects are usually used for spell hits based on the spell school.

If Target is non-zero then the effect will be played in the original target point (ignores spell target).

 

Known values for 'Type' are:

(...)

 

Values for 'Target' are:

0 - Play on target, specified by targettype.

1 - Play on point the spell was cast.

2 - Play on target, specified by targettype. Does not draw on non-allied invisible creatures.

3 - Play on point the spell was cast. Does not draw on non-allied invisible creatures.

#215 (0x0D7) Graphics: Play 3D Effect [215]

Parameter #1: irrelevant (or we can specify the RGB overlay of the creature which overrides opcode 8 if both are active)

Parameter #2: Effect State

Description:

Plays the BAM/VVC specified by the resource key, in the style specified by the 'Effect State' value.

 

Known values for 'Effect State' are:

0 Play on target (not attached).

1 Play on target (attached).

2 Play on point.

3 Play on target (not attached). Does not play if the target is out of sight and invisible.

4 Play on target (attached). Does not play if the target is out of sight and invisible.

5 Play on point. Does not play if the target is out of sight and invisible.

 

It's a cosmetic thing, it really bugs me to see invisible creatures run around with fireshields.

 

Dispel: fine, easy to do.

Nice.

 

We'd still like to know what opcode 110 (was Retreat From, not TurnUndead) does in detail, we haven't heard much about it.

 

-Galactygon

Link to comment
As i wrote: i don't intend to draw anything if a creature is totally invisible.

When it becomes partially visible (attacks, and could be attacked back), the overlays appear.

So this means:

a.) opcode 215 never draws on invisible hostile creatures,

b.) the new overlay opcode also doesn't draw on invisible creatures.

Am I right?

 

We'd still like to know what opcode 110 (was Retreat From, not TurnUndead) does in detail, we haven't heard much about it.

Could you answer this please, Avenger?

 

-Galactygon

Link to comment

When an opponent is invisible (no visual feedback), i don't draw anything.

When it is visible (attacked, so it is targetable), i draw it half transparent (slight pulsing), and all overlays.

 

At least, this is the plan.

There is no plan to skip the drawing phase based on a creature flag+vvc flag. Unless this is in the original engine.

 

There is no new overlay opcode, just de-hardcoded original overlay affecting opcodes plus opcode 215 in BG2.

 

opcode 110 doesn't do anything in the original engines (except in PST), where it moves the affected creature away from opponents (for this, we look for the nearest enemy and call the pathfinder to find the farthest available point (in a given distance) from that one.

 

Turn is similar (imo), it moves the affected undead from the cleric (source). IIRC, even RetreatFrom has such an option. But as i wrote earlier, this seems to be a bit mixed up in our effect list.

Link to comment

controlundead2 (iwd2) was used, so that turning could also be possible in pst (no clash with retreatfrom), if it was ever needed. The control undead effects are only present in the dales.

Param2 is set to 4, which means the turning action is dictated by the caster's capabilities (turn undead level, alignment). The other values hardcode some possible results (see IWDOpcodes.cpp:1838).

Link to comment
There is no new overlay opcode, just de-hardcoded original overlay affecting opcodes plus opcode 215 in BG2.

And that's the sanctuary opcode? You mentioned a few posts back we could introduce a new overlay opcode if we wanted to.

 

So overlays listed in the overlay.2da are handled to disappear on invisible creatures, but nothing else disappears (ie opcodes 141, 215).

 

Speaking of opcode 141 (lighting effects), I've noticed they are externalized in shtable.2da. The entries seem to be .bam files, but there are no .vvc files or RGB values attatched. How does it work?

 

opcode 110 doesn't do anything in the original engines (except in PST), where it moves the affected creature away from opponents (for this, we look for the nearest enemy and call the pathfinder to find the farthest available point (in a given distance) from that one.

 

Turn is similar (imo), it moves the affected undead from the cleric (source). IIRC, even RetreatFrom has such an option. But as i wrote earlier, this seems to be a bit mixed up in our effect list.

 

So ToBEX would be implementing the PS:T opcode, with the difference that there is no "run", just "walk". So the parameters wouldn't mean anything. It would act like a repulsion effect, and override scripting actions?

#110 (0x06E) Run Away

Parameter #1: Irrelevant

Parameter #2: Type

Description:

Leave both parameters at zero for this effect to work.

 

Known values for 'Type' are:

7 Weak

8 Walk

 

Other values for 'Type' act as 'Run Away'

 

I've looked at the turn.spl, which replicates the turn undead modal state, and only found one opcode (110). How does the turn.spl control undead, check for the caster's alignmnent, level, the turned undead's level with this single opcode? Or is this still a work-in-progress that causes undead to run away?

 

-Galactygon

Link to comment

That is all internal to the opcode.

 

There is one missing bit though. Available reading suggests that the turning is hd-limited (2d6 (+2d4 for high turning level differences)), but we don't do that yet, since nobody confirmed these values yet. If not before, we'll need it once we start implementing iwd2 feats (improved turning).

Link to comment
That is all internal to the opcode.

 

So turn undead is hardcoded?

 

There is one missing bit though. Available reading suggests that the turning is hd-limited (2d6 (+2d4 for high turning level differences)), but we don't do that yet, since nobody confirmed these values yet. If not before, we'll need it once we start implementing iwd2 feats (improved turning).

 

I'm missing something here. How exactly do you control what HD you turn based on what level?

 

-Galactygon

Link to comment
That is all internal to the opcode.

 

So turn undead is hardcoded?

 

There is one missing bit though. Available reading suggests that the turning is hd-limited (2d6 (+2d4 for high turning level differences)), but we don't do that yet, since nobody confirmed these values yet. If not before, we'll need it once we start implementing iwd2 feats (improved turning).

 

I'm missing something here. How exactly do you control what HD you turn based on what level?

 

-Galactygon

This depends on what reverse engineering brings up.

Why don't we talk about stuff that we already know?

 

For example: what about fixing the FillSlot action.

It is totally buggy in the original engine. I know of 2 crashers.

1. if your parameter is a non existing slot, it will still happily dereference the item

2. if you have two of the same types, the inventory will get mixed up by referencing the same item twice.

At this point, a reload or quit game will cause a crash because of messed up pointers.

 

Contrary to IESDP, FillSlot doesn't destroy the item, if there is only one candidate in the inventory.

It messes up only if there are more than one.

So, the obvious fix is: exit the loop after a successful swap.

Link to comment
This depends on what reverse engineering brings up.

Why don't we talk about stuff that we already know?

I don't know what you know; it would be great help if you put something on the table.

 

For example: what about fixing the FillSlot action.

It is totally buggy in the original engine. I know of 2 crashers.

1. if your parameter is a non existing slot, it will still happily dereference the item

2. if you have two of the same types, the inventory will get mixed up by referencing the same item twice.

At this point, a reload or quit game will cause a crash because of messed up pointers.

 

Contrary to IESDP, FillSlot doesn't destroy the item, if there is only one candidate in the inventory.

It messes up only if there are more than one.

So, the obvious fix is: exit the loop after a successful swap.

 

We are talking of opcode 143, right? Something this specific has a high chance of making it into ToBEX.

 

Please share some more. :mad:

 

-Galactygon

Link to comment

I talked about the fillslot <b>Action</b>

 

It is probably good to add new options to opcode 143 (0x8f).

But, it should keep the original functionality of overwriting an item.

That is an important functionality for polymorph items.

 

If you have ideas how to improve createitem opcodes, we can talk about those too.

 

Btw, i implemented all of the Apply/Restrict item types/resref opcodes.

Link to comment
It is probably good to add new options to opcode 143 (0x8f).

But, it should keep the original functionality of overwriting an item.

That is an important functionality for polymorph items.

 

Sure.

 

Btw, i implemented all of the Apply/Restrict item types/resref opcodes.

IIRC, that's in Taimon's hacks.

 

Here are my rough ideas on item opcodes, they took some time to think out, and require some polishing.

 

#143 (0x08F) Item: Create Item in Slot [143]

Parameter #1: Slot and Type (first bit is slot, second is type)

Parameter #2: Primary Charge Count

Parameter #3: Secondary Charge Count

Parameter #4: Tertiary Charge Count

Description:

Creates the item specified by the resource key in the slot specified by the 'Slot' field, on the targeted creature(s).

 

Durations attatched to this opcode will be stored on the .itm rather than the .cre

 

Values for 'Type' are:

0 - Default - Create item in slot, overwriting any possible items.

1 - Overwrite item in slot, but only if .itm resource in the 2nd resource key matches with what's in the slot. If that returns false, do not create the item, and fire an effect speficified in the 3rd resource key. If the 2nd resource key is blank, this effect will only fire if the slot is filled with any item. If the 3rd resource key is blank, the effect will not fire another effect.

2 - The reverse of type 1 - Overwrite the item in the slot, but only if the .itm resource does not match. If the .itm in the existing slot matches with the 2nd resource, fire a different affect specified in the 3rd resource key. If the 2nd resource key is blank, this effect will only fire if the slot is empty. If the 3rd resource key is blank, the effect will not fire another effect.

3 - Create item in slot - bumping any items in slot to inventory or the ground.

4 - Bump item in slot to inventory, but only if itemresreff matches with the 2nd resource key. If that returns false, do not create the item, and fire an effect specified in the 2nd resource key. If the 2nd resource key is blank, this effect will only fire if the slot is filled with any item. If the 3rd resource key is blank, the effect will not fire another effect.

5 - The same as 4, but in reverse - if the 2nd resource key matches the .itm in the slot, do nothing and fire a different effect specified in the 3rd resource key. If the 2nd resource key is blank, this effect will only fire if the slot is empty. If the 3rd resource key is blank, the effect will not fire another effect.

 

Known values for 'Slot' (from slots.ids) are:

(...)

This still leaves us with a problem of item charge count (with secondary and tertiary charges). Since item slot types and the opcode types never go over 255, I effectively puts them as bits.

 

I like the idea of firing other .effs in the process, if the effect returns false. You can attatch a chain of these effects, effectively looking for the right slot to overwrite in the order the modder specifies.

 

#180 (0x0B4) Item: Can't Use Item [180]

Parameter #1: String Reference

Parameter #2: Type

Description:

The targeted creatures(s) cannot use the item specified by the resource key. The strref specified by the 'String Reference' field is displayed when an attempt to use the item is made.

 

Known values for type:

0 - Default - Do not bump the item into the inventory if the character has it equipped.

1 - Bump the item into the inventory if the character has it equipped, and display the strref on the character.

 

If the creature has the specified item equipped in the resource key at the moment the effect fires (the opcode returns true), an external .eff specified in resource key2 will be fired. If the opcode returns false, an external .eff specified in resource key3 will be fired.

#181 (0x0B5) Item: Can't Use Itemtype [181]

Parameter #1: String Reference

Parameter #2: Itemtype

Parameter #3: Opcode Type

Description:

The targeted creature(s) cannot use the item type specified by the 'Type' field. The strref specified by the 'String Reference' field is displayed when at attempt to use such an item is made.

 

Known values for Opcode type:

0 - Default - Do not bump the itemtype into the inventory if the character has it equipped.

1 - Bump the itemtype into the inventory if the character has it equipped, and display the strref on the character.

 

If the creature has the specified itemtype equipped at the moment the effect fires (the opcode returns true), an external .eff specified in the resource key will be fired. If the opcode returns false, an external .eff specified in resource key2 will be fired.

These are self-explanatory, I added this calling external .eff thingie.

 

#182 (0x0B6) Item: Apply Effect Item [182]

Parameter #1: Irrelevant

Parameter #2: Irrelevant

Description:

Applies the effect specified by the resource key to the targetted creature(s) when an item of a filename is specified in the second resource field is equipped. Effective only in external effects. If the item is unequipped, this effect is suppressed until the item is equipped again within the duration.

 

Known values for type:

0 - Default - Apply if the .cre has the item equipped

1 - Apply if the .cre has the item in its inventory

 

The effect works in reverse if the resource key 2 is filled; the .eff in resourcekey2 is applied when the effect returns false, and is suppressed when the effect returns true.

#183 (0x0B7) Item: Apply Effect Itemtype [183]

Parameter #1: Irrelevant

Parameter #2: Type

Description:

Applies the effect specified by the resource key to the targetted creature(s) when an item of a filename is specified in the second resource field is equipped. Effective only in external effects. If the item is unequipped, this effect is suppressed until the item is equipped again within the duration.

 

The effect works in reverse if the resource key 3 is filled; the .eff in resourcekey2 is applied when the effect returns false, and is suppressed when the effect returns true.

Are these fixed in GemRB?

 

#243 (0x0F3) Item: Drain Item Charges [243]

Parameter #1: Item Type

Parameter #2: Irrelevant

Parameter #3: Charge Slot - if not specified, all extended headers are drained

Parameter #4: Charge Number - if not specified, the opcode drains one charge

Description:

Items matching the 'Item Type' value on the targeted creature(s) will have their charges drained.

 

Known values for 'Item Type' are:

0 Magical items excluding weapons. If the itemtype does not exist on the character, fire an external .eff specified in the 2nd resource key. If the item exists, fire an external .eff specified in the 3rd resource key in addition to draining the item.

1 Magical items including weapons. If the itemtype does not exist on the character, fire an external .eff specified in the 2nd resource key. If the item exists, fire an external .eff specified in the 3rd resource key in addition to draining the item.

2 Itemtype specified in parameter2. If the itemtype does not exist on the character, fire an external .eff specified in the 2nd resource key. If the itemtype exists, fire an external .eff specified in the 3rd resource key in addition to draining the item.

3 Item in the slot specified in parameter2. If the slot on the character is not filled, fire an external .eff specified in the 2nd resource key. If the slot is filled, fire an external .eff specified in the 3rd resource key in addition to draining the item.

4 Item specified in the resource key. If the item does not exist on the character, fire an external .eff specified in the 2nd resource key. If the item exists, fire an external .eff specified in the 3rd resource key in addition to draining the item.

By setting 'Item Type' to 4, and parameters 3 and 4 to some values, it would be possible to make items that have a fixed number of charges, and each ability drains different amounts of charges from the item.

 

#248 (0x0F8) Item: Set Melee Effect [248], #249 (0x0F9) Item: Set Ranged Effect [249]

Parameter #1: Condition

Parameter #2: Maximum range

 

Known values for condition:

0 - Default - The effect hits the creature on a successful hit, and is not immune to the weapon. If this returns false (ie on a miss or if he is immune to the weapon), an external .eff in the second resource key is fired on the .cre

1 - The effect hits the creature on a successful hit, even if he is immune to the weapon. If this returns false (ie on a miss), an external .eff in the second resource key is fired on the .cre

2 - The effect hits the creature on a successful critical hit, and is not immune to the weapon. If this returns false (ie on a miss, or the critical hit does not happen, or if he is immune to the weapon), an external .eff in the second resource key is fired on the .cre

3 - The effect hits the creature on a successful critical hit, even if he is immune to the weapon. If this returns false (ie on a miss, or the critical hit does not happen, or if he is immune to the weapon), an external .eff in the second resource key is fired on the .cre

 

The maximum range indicates the farthest range the effect will apply. The default value of 0 means the effect is applied at any range.

 

#26 (0x01A) Item: Remove Curse [26]

Parameter #1: Type

Parameter #2: Irrelevant

Description:

Removes cursed items from the targeted creature(s)

 

Known values for type:

0 -Default - all cursed items are removed

1 - Cursed items of itemtype specified in parameter2 are removed

2 - Cursed items matching the resource key are removed

3 - Cursed items in the slot specified in parameter2 are removed.

 

If the effect returns true for some item, the effect fires an external .eff specified in resource key2 in addition to removing the curse from an item. If the effect does not return true for any item, an external .eff specified in resource key3 is fired.

 

#111 (0x06F) Item: Create Magical Weapon [111] and #122 (0x07A) Item: Create Inventory Item [122]

The item expiry should be stored externally. I would also make use of resource key2 in external effects that fires an .eff file when the item is consumed/dispelled/expires and remove the hardcoded "play sound effect" EFF_M02.

 

#123 (0x07B) Item: Remove Inventory Item [123]

Parameter #1: Type

Parameter #2: Irrelevant

Description:

Removes the item specified by the resource key from the targeted creature(s). This effect should be used to remove inventory items (use effect 112 for equipped items).

 

Values for 'Type' are:

0 - Removes the first instance (one slot is one instance != num of charges) of the item specified in the resource key. The effect returns true if at least one instance is found.

1 - Removes number of instances specified in param2 of the item specified in the resource key. The effect returns true if the number of instances are found specified by param2.

2 - Removes all instances of the item specified in the resource key. The effect returns true if at least one instance is found.

 

If the effect returns true (an item is removed), an external .eff specified in resource key2 is fired. If the effect returns false, an external .eff specified in resource key3 is fired.

 

Although this doesn't have to do with "create item", I smuggled this last one in.

#120 (0x078) Protection: from Melee Weapons [120]

Parameter #1: Enchantment

Parameter #2: Type

Parameter #3: Itemtype

Parameter #4: Num of HitPoints absorbed

Description:

Gives the targeted creature(s) immunity to melee weapons as specified by the 'Type' field. The 'Enchantment' field is used if 'Type' is set to 0. If parameter3 is set to non-zero (only possible in external effects), the effect only protects against the itemtype specified. If parameter4 is set to a non-zero value, the effect works like a decrementing item immunity opcode, protecting from damage equal to the value of parameter4.

 

Known values for 'Type' are:

0 Enchantment

1 Magical

2 Non-Magical

3 Silver

4 Non-Silver

5 Silver / Non-Magical

6 Two-Handed

7 Non Two-Handed

8 Cursed

9 Non-Cursed

10 Cold-Iron

11 Non Cold-Iron

12 Item specified in the resourcekey

13 Item using damagetype in the extended header specified by parameter 1

14 Item using sectype in the extended header specified by parameter 1

15 Item using school in the extended header specified by parameter 1

 

 

-Galactygon

Link to comment

Archived

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

×
×
  • Create New...