58 replies to this topic

[Galactygon]

AMOUNTOFDAMAGESUFFERED (maxhp - currenthp) (doesn't go over 255) IIRC DamageTaken() only works for Myself

You can now to NextTriggerObject() and then DamageTaken(), but I did discuss the limitations of DamageTaken() earlier in that the last amount of damage sticks. My question here is why you need an absolute value for damage? Wouldn't it be more consistent to use HPPercentLT()?

This could be useful for spells that cure a fixed number of hitpoints - HPPercentLT can mean a deficiency of 5, 10, 20, etc. number of hitpoints. So you'd have to check the maxhp alongside to get a rough estimate - no wait, you can't check max hitpoints. If you can do this with extra triggers that's just better.

MOVEMENTRATE (default is 9, set by opcodes 126, 176, haste, and slow opcodes)

Now the movement rate is not affected by haste and slow, but is affected by 126, 176. I did throw in MovementRate[LT/GT]() trigger, but given that haste and slow does nothing to it, is it still useful?

I don't know; we'll have to see. I was thinking about running away scripts to check if the pursuers are faster, and haste does matter.

Rather than using up 20 stats, I've just made triggers instead. See http://www.shsforums...post__p__510530

Yeah, that's much better than using a whole bunch of stats.

The rest all look really good, thanks.

-Galactygon

[Ascension64]

This could be useful for spells that cure a fixed number of hitpoints - HPPercentLT can mean a deficiency of 5, 10, 20, etc. number of hitpoints. So you'd have to check the maxhp alongside to get a rough estimate - no wait, you can't check max hitpoints. If you can do this with extra triggers that's just better.

OK, I'll do a HurtAmount[LT/GT].

0x4117 HurtAmount(O:Object*,I:Amount*)
0x4118 HurtAmountGT(O:Object*,I:Amount*)
0x4119 HurtAmountLT(O:Object*,I:Amount*)
Compares the absolute number of hit points short of maximum hit points on the targett creature specified by Object to Amount.

MOVEMENTRATE
I don't know; we'll have to see. I was thinking about running away scripts to check if the pursuers are faster, and haste does matter.

You could take STATE_HASTE, STATE_SLOW into account. However, there will be a fuzz factor you will have to work out for how much this accounts to a difference in movement rate.

So, for example, if two movement rates of 9, one with haste will definitely catch the other, whereas the chaser with a slow will definitely not catch the other. However, if one rate is 7 and the other 9, will a hasted 7 catch the 9?

Edited by Ascension64, 13 March 2011 - 01:25 AM.

[Galactygon]

0x4117 HurtAmount(O:Object*,I:Amount*)
0x4118 HurtAmountGT(O:Object*,I:Amount*)
0x4119 HurtAmountLT(O:Object*,I:Amount*)
Compares the absolute number of hit points short of maximum hit points on the targett creature specified by Object to Amount.

Nice, thanks.

MOVEMENTRATE
I don't know; we'll have to see. I was thinking about running away scripts to check if the pursuers are faster, and haste does matter.

You could take STATE_HASTE, STATE_SLOW into account. However, there will be a fuzz factor you will have to work out for how much this accounts to a difference in movement rate.

So, for example, if two movement rates of 9, one with haste will definitely catch the other, whereas the chaser with a slow will definitely not catch the other. However, if one rate is 7 and the other 9, will a hasted 7 catch the 9?

Hasted 7 will catch the 9, but hasted 3 won't, and neither will a slowed 17. The fuzz factor can be neglected, because from experience the .cre has to stand still for a few AI frame rates in order to swing and do damage. If the pursued is fast enough, then there is no way the pursuer can ever hit.

Now that I think about it, checking movementrate can be used to check entangle and such (if modded spell has entangle-like effects but doesn't use the entangle overlay), so it's still going to have some use.

-Galactygon

Edited by Galactygon, 13 March 2011 - 01:38 AM.

[Ascension64]

Nice, thanks.

I think one of the biggest limitations of triggers is that it is very hard to compare something between two objects. Is this achievable at all by any means? For example, can something as simple as "is my HP% greater than your HP%" be implemented using vanilla ToB?

Hasted 7 will catch the 9, but hasted 3 won't, and neither will a slowed 17. The fuzz factor can be neglected, because from experience the .cre has to stand still for a few AI frame rates in order to swing and do damage. If the pursued is fast enough, then there is no way the pursuer can ever hit.

Now that I think about it, checking movementrate can be used to check entangle and such (if modded spell has entangle-like effects but doesn't use the entangle overlay), so it's still going to have some use.

That is true. With your "can i catch you?" idea, how would you have proposed to compare one movement rate to another? Is there a way to say movement rate A > movement rate B?

Opcode 216: there is already a LEVELDRAIN stat for this. Does it work, or is there an engine bug?

Completely unused.

Edited by Ascension64, 13 March 2011 - 02:53 AM.

[Galactygon]

Nice, thanks.

I think one of the biggest limitations of triggers is that it is very hard to compare something between two objects. Is this achievable at all by any means? For example, can something as simple as "is my HP% greater than your HP%" be implemented using vanilla ToB?

Since there is no way to save data in variables and later reuse them, I have to make do with a bunch of OR() blocks. Here's my (untested) theory:

IF
  OR(2)
    CheckStatGT(Myself,2,MOVEMENTRATE)
    CheckStatLT(NearestEnemyOf(Myself),2,MOVEMENTRATE)
  OR(2)
    CheckStatGT(Myself,3,MOVEMENTRATE)
    CheckStatLT(NearestEnemyOf(Myself),3,MOVEMENTRATE)
  OR(2)
    CheckStatGT(Myself,4,MOVEMENTRATE)
    CheckStatLT(NearestEnemyOf(Myself),4,MOVEMENTRATE)
  OR(2)
    CheckStatGT(Myself,5,MOVEMENTRATE)
    CheckStatLT(NearestEnemyOf(Myself),5,MOVEMENTRATE)
...

IF
  OR(2)
    CheckStatGT(Myself,2,MOVEMENTRATE)
    CheckStatLT(SecondNearestEnemyOf(Myself),2,MOVEMENTRATE)
  OR(2)
    CheckStatGT(Myself,3,MOVEMENTRATE)
    CheckStatLT(SecondNearestEnemyOf(Myself),3,MOVEMENTRATE)
  OR(2)
    CheckStatGT(Myself,4,MOVEMENTRATE)
    CheckStatLT(SecondNearestEnemyOf(Myself),4,MOVEMENTRATE)
  OR(2)
    CheckStatGT(Myself,5,MOVEMENTRATE)
    CheckStatLT(SecondNearestEnemyOf(Myself),5,MOVEMENTRATE)
...

// This gets really messy when you have to account for disabled enemies that otherwise have a MOVEMENTRATE > 0

-Galactygon

[Ascension64]

Hmm, would a Compare() trigger be useful?

It could be something like

Compare(O:Object*,I:Compare*Compare,I:CompareSub)

Since triggers can only accept one Object, compare would always be in reference to the object with the active script (but you can use NextTriggerObject()). Compare*Compare would be a type specified by COMPARE.IDS, which may then specify a CompareSub.

For example,
Compare(NearestEnemyOf(Myself),STAT,MAXHITPOINTS)
would fetch the active object's maxHP and check against NearestEnemyOf(Myself)'s maxHP.

Another example outside stats could be
Compare(NearestEnemyOf(Myself),RAND,5)
would see check my random number out of 5 against the other's random number out of 5.

We can have variations on this.



Another idea is to allow variable substitution.
In this case, I would need to overload whatever triggers are required to accept a S:Variable* argument (this won't work if both string arguments are already used, such as in Global, etc.).
If such an argument is detected, then the relevant I:* argument is set.


Both need lots of work, but can certainly open up a lot of possibilities.

[the bigg]

Compare(NearestEnemyOf(Myself),STAT,MAXHITPOINTS)

I would appreciate if compare.ids used STATS instead of STAT (I.E. using the name of the IDS file where MAXHITPOINTS will be looked up).

this won't work if both string arguments are already used, such as in Global, etc.

Er, Global() use a single string in BCS format, or am I missing something?

[Ascension64]

Er, Global() use a single string in BCS format, or am I missing something?

Global("Me", "GLOBAL", 1) = 2 strings.
However, the script parser lumps the two into a "GLOBALMe", leaving the second string member alone. I am not exactly the exact conditions for this. Will need to investigate.

GlobalTimerExpired("TimeMe", "GLOBAL") = 2 strings.
This stays as two strings in BCS.

Edited by Ascension64, 13 March 2011 - 05:27 PM.

[the bigg]

Var name + scope is always compiled to "scopename" when doing BAF->BCS, so perhaps some mechanism is splitting them up during script evaluation. This is even more fun for tool writers in the lesser engines, where sometimes a colon is added between scope and name, and different users wish for different treatment of said colon in both BAF -> BCS and BCS -> BAF.

Edited by the bigg, 13 March 2011 - 05:50 PM.

[Ascension64]

Here is an issue. The internal script parser (used for dialogues) only recognises the following parameter constructions for triggers:

(statement) id
(O) 4
() 5
(I) 6
7 error
8 error
(O, I) 9
A error
(S) B
(S, I) C
(S, S, I) --> (S2+S1, I) D (e.g. Global)
(I, I) E
(S, O) F
10 error
11 error
(S, S) 12
(O, I, I) 13
14 error
15 error
(S, O, I) 16

I don't think this is an issue with BCS files.
The question is whether this applies to AICompile.exe as well, to whatever DLTCEP uses, and then there is NI + WeiDU compatibility.

Edit: The same statement types are used for actions too, with the following list:

FFFFFFFFFF not recognised
00 invalid
01 (P)
02 (P,I)
03 (O,I,O)
04 (O)
05 ()
06 (I)
07 (O,P)
08 (O,O)
09 (O,I)
0A (O,A) -> for ActionOverride()
0B (S)
0C (S,I)
0D (S,S,I)
0E (I,I)
0F (S,O)
10 (S,P)
11 (S,P,I)
12 (S,S)
13 (O,I,I)
14 (S,I,I)
15 (S,I,I,I)
16 (S,O,I)
17 (S,O,I,I)
18 (S,O,I,I,I)
19 (S,S,P,I)
1A (S,S,P)
1B (S,O,P)
1C (S,S,O)
1D (S,S,S,O)
1E (S,S,S)

Edited by Ascension64, 13 March 2011 - 07:36 PM.

[Galactygon]

Another idea is to allow variable substitution.
In this case, I would need to overload whatever triggers are required to accept a S:Variable* argument (this won't work if both string arguments are already used, such as in Global, etc.).
If such an argument is detected, then the relevant I:* argument is set.


Both need lots of work, but can certainly open up a lot of possibilities.

While I certainly like this idea, I'll back down from this discussion, as I'm not into large-scale scripting - so my scripting related requests are small-scale.

You'd have to ask modders like DavidW or Wisp to see which parts of the scripting system really need improvement.

-Galactygon

[Galactygon]

I'll suggest you take a look at some of the IWD2 triggers and actions to see if there are any overlaps, so that we won't have to deal with cross-compatibility later (assuming GemRB carries them over to BGII). For example, there is:

0x40DB HPLost(O:Object*,I:Hit Points*)
0x40DC HPLostGT(O:Object*,I:Hit Points*)
0x40DD HPLostLT(O:Object*,I:Hit Points*)

-Galactygon

[Ascension64]

I'll suggest you take a look at some of the IWD2 triggers and actions to see if there are any overlaps, so that we won't have to deal with cross-compatibility later (assuming GemRB carries them over to BGII). For example, there is:

0x40DB HPLost(O:Object*,I:Hit Points*)
0x40DC HPLostGT(O:Object*,I:Hit Points*)
0x40DD HPLostLT(O:Object*,I:Hit Points*)

-Galactygon

I can change the syntax to match. However 0x40DB conflicts with InWatchersKeep() so the opcodes will differ. I think there are a number of BG2/IWD2 issues with triggers in a similar manner. However, it is relatively easy for both TobEx and GemRB to change the opcodes on-the-fly. This will obviously render BCS scripts incompatible, but so long as BAF scripts are used, this shouldn't invalidate mods using different versions of TobEx where opcodes aren't the same.

[Lamach Head]

Apologizes for being total noob, can anyone help me to make FIREDAMAGEBONUS/MAGICDAMAGEBONUS/etc working as a permanent class ability for a kit?

Let's say I want to make my own customized kit, which has +1% fire damage per level.

I understand I go to DLTCEP -> choose a SPCLXXX.SPL -> go to "extended effects" -> add effect -> set "Effect opcode" to "Unknown(318)" -> set "Parameter 1" to "1" (1% increase at level 1) -> set "parameter 2" to 391 (fire damage bonus) -> set timing to "9-Permanent after death" -> done -> copy paste the whole extended effect for level 2 and change "parameter 1" to "2" (2% increase), and so on up to level 50.

Am I right?
What means "-New stats are not permanent, they require an ongoing effect opcode 318 in order to keep their values" in the TobEx_ini.txt?

Edited by Lamach Head, 22 June 2011 - 04:16 AM.

[Andrea C.]

Hi Asc64,

I think my request belongs in here, since it's about stats, but I apologize in advance if it doesn't. The answer might as well be hidden in the tech talk that preceeds this post, but being no modder I can't quite make it out Is it possible to mod the .exe so that all six stats (STR, DEX, CON, INT, WIS, CHA) behave exactly as per their P&P description on the AD&D Player's Handbook? INT and WIS were quite possibly the most overlooked stats, as god-like figures above 18 should be granting a plethora of bonuses and spell immunities that are totally absent from the game. Many creatures and villains might be entitled to some of those, and in ToB it's not unlikely for PCs to get there with one or two stats. I'm quite positive there are other things that were overlooked, though I can't remember them as of now... Anyway, do you think this could be done? If yes, would you consider doing it?

[Andrea C.]

I... should take your silence as a no?

[Galactygon]

Take a look at A64's profile, he was last active on Jun 21 2011. I'm pretty sure he hasn't had the time to read your post. Anyway, this was already requested:

For WIS, INT, etc. modifiers a better idea would be to build tables of .effs or .spls that are applied whenever the character has a certain value for a certain stat, and then stripped/reapplied when the stat changes. These .effs/.spls could carry a whole slew of effects, including a concentration stat modifier. This will satisfy many modmakers, who might be looking for something like, bards/sorcerers gaining additional spell slots based on high charisma. And it's less work for you too, since you don't have to bother on implementing every single stat dependant request.

This table would look like this:

         1        2        3        4        5     ...     25
EFFECT1  MODEFF11 MODEFF21 ...      ...      ...   ...     ...
EFFECT2  MODEFF12 MODEFF22 ...      ...      ...   ...     ...
EFFECT3  MODEFF13 MODEFF23 ...      ...      ...   ...     ...
...

So a character with 2 WIS will carry effects MODEFF21.eff, MODEFF22.eff, and MODEFF23.eff, which could be anything.

-Galactygon

[Andrea C.]

Hi Galactycon,

thanks for pointing that out. I didn't know it had already been requested. Also, my bad for not checking Asc64's profile

[Ascension64]

Apologizes for being total noob, can anyone help me to make FIREDAMAGEBONUS/MAGICDAMAGEBONUS/etc working as a permanent class ability for a kit?

Let's say I want to make my own customized kit, which has +1% fire damage per level.

I understand I go to DLTCEP -> choose a SPCLXXX.SPL -> go to "extended effects" -> add effect -> set "Effect opcode" to "Unknown(318)" -> set "Parameter 1" to "1" (1% increase at level 1) -> set "parameter 2" to 391 (fire damage bonus) -> set timing to "9-Permanent after death" -> done -> copy paste the whole extended effect for level 2 and change "parameter 1" to "2" (2% increase), and so on up to level 50.

Am I right?

That sounds right. Then you need to reference that SPCLXXX.SPL in your relevant AB*.2DA file so that the kit gets that ability at level up. If you are ever unsure, the great thing about modding is just to try it and see what happens. The worst thing that happens is you crash for the game, or nothing happens. The best way to test would be to exaggerate the difference to say 50% or 100% so you can see an obvious damage difference. 1% may round to 0 for a lot of damage amounts.

What means "-New stats are not permanent, they require an ongoing effect opcode 318 in order to keep their values" in the TobEx_ini.txt?

It means that the effect needs to be stored in the creature (technical aspect) if you want to see the effect. As soon as you rid of the effect, the stat returns to 0. Think of it like a button on a spring. You have to keep your finger on the button to depress it, otherwise it will stay up. Your finger is the effect, the state of the button (up/down) is the value of the stat.

I think my request belongs in here, since it's about stats, but I apologize in advance if it doesn't. The answer might as well be hidden in the tech talk that preceeds this post, but being no modder I can't quite make it out Is it possible to mod the .exe so that all six stats (STR, DEX, CON, INT, WIS, CHA) behave exactly as per their P&P description on the AD&D Player's Handbook? INT and WIS were quite possibly the most overlooked stats, as god-like figures above 18 should be granting a plethora of bonuses and spell immunities that are totally absent from the game. Many creatures and villains might be entitled to some of those, and in ToB it's not unlikely for PCs to get there with one or two stats. I'm quite positive there are other things that were overlooked, though I can't remember them as of now... Anyway, do you think this could be done? If yes, would you consider doing it?

I have been busy. Yes, as Galacyton put it, it has been proposed and it is on the to-do list.