@Acifer
Yeah, there are a couple of bugs in the latest NI release which were introduced when I added alpha channel BAM palette support to the BAM converter.
I agree with Ulb to use an earlier NI version to work around the problem if your BAM files don't use alpha channel palette (which is only supported by more recent EE patch versions anyway).
@swit
These strrefs are calculated differently by the engine. They are determined by the formula "0xF00000 + ENGINEST.2DA row number". Afaik this strref mode is only used by the UI.
In your case: strref 15729574 = 0xF003A6. Row number is 0x3A6 = 934 (dec), which refers to the ENGINEST.2DA entry STRREF_GUI_MIXED_CRIPPLING_STRIKE.
@argent77@Ulb
One of the most powerful features in the latest NI release is the bam resizing / bam recentering tool. I am so glad you made that possible. Especially since the "Bammer" tool beamdog announced some time ago never seems to be released.
So it's absolutely fine for me using that "extra" step with the shadow palette. The lack of the powerful features of the bam-tool is the reason why I can't use "older" versions of NI.
I exported some NWN Animations some time ago using 3ds Max. The problem is that it takes a lot of work (and time) to check the animations ingame. Quite often the rendered animations seem to be too large and the circles of some bam sequences are out of place when the creatures finally appear in the game.
So with NI's newest release, it is so much easier to adjust the size and the center of the bam without the need of re-rendering the whole stuff in 3ds Max with a different adjustment of the camera.
I can see in scripts, it is commonly used, for example - !CheckStatGT(NearestEnemyOf(Myself),0,HELD). And it is not in STATE.ids.
For example, is Cleric Hold Person one of spell which will cause creature (if successful) to get stat HELD?
And more important, does any of STATE.ids cover that, or it have to be especially covered by using CheckStatGT(NearestEnemyOf(Myself),0,HELD) ?
I would suspect 0x00000008 STATE_STUNNED, but not so sure about it because it maybe only cover exactly Stun. I would more suspect, let say 0x00000020 STATE_HELPLESS ?
I can see in scripts, it is commonly used, for example - !CheckStatGT(NearestEnemyOf(Myself),0,HELD). And it is not in STATE.ids.
Because it's not a STATE, but a STAT. You can find it in STATS.ids along with other disabling stats (e.g. WEB).
Yes, that is clear, maybe I did write my post in little stupid way.
I did some testing and yes, Wizard or Cleric Hold person will put you in HELD stat, just as Ghast (if I recall right) melee attack.
0x00000020 STATE_HELPLESS cover that, tested. I did not test anything other like Web. I don't know exactly what else also provoke to go into HELPLESS state. As I recall, if you are under Web, you can't do anything just if you are Held. Don't know does ENTAGLE comes under HELPLESS, because if I recall right, under ENTAGLE you can still cast spells (which would mean you are not 100% helpless).
But I have to test it more, I did not play for long time and my memory is fading and I can be wrong about this, all play I do is when testing for short times, after working with scripts.
I will make test to clear 100% which spells exactly put creature in HELPLESS state, using every spell I suspect.
I have to report something else, maybe this is a bug. Anyway, if this is normal or anyone is aware of this, please let me know.
When you use HitBy([ANYONE],CRUSHING), it will return true if spells like Lower Resistance, Ruby Ray, Spell Strike (and I did not try every possible, that was enough to conclude something is wrong) are cast on creature.
I did try to use [PC] instead of [ANYONE], but nothing changes.
The symbolic name "CRUSHING" is misleading. It actually resolves into the IDS value 0 (from DAMAGES.IDS), which is generally used by the engine as a wildcard for anything.
Edit: I haven't test this, but you can probably check for "crushing" damage specifically by excluding every other damage type:
IF
HitBy([PC],CRUSHING)
!HitBy([PC],COLD)
!HitBy([PC],ACID)
!HitBy([PC],COLD)
!HitBy([PC],ELECTRICITY)
!HitBy([PC],FIRE)
!HitBy([PC],PIERCING)
!HitBy([PC],POISON)
!HitBy([PC],MAGIC)
!HitBy([PC],MISSILE)
!HitBy([PC],SLASHING)
!HitBy([PC],MAGICFIRE)
!HitBy([PC],MAGICCOLD)
!HitBy([PC],STUNNING)
THEN
...
The symbolic name "CRUSHING" is misleading. It actually resolves into the IDS value 0 (from DAMAGES.IDS), which is generally used by the engine as a wildcard for anything.
Edit: I haven't test this, but you can probably check for "crushing" damage specifically by excluding every other damage type:
IF
HitBy([PC],CRUSHING)
!HitBy([PC],COLD)
!HitBy([PC],ACID)
!HitBy([PC],COLD)
!HitBy([PC],ELECTRICITY)
!HitBy([PC],FIRE)
!HitBy([PC],PIERCING)
!HitBy([PC],POISON)
!HitBy([PC],MAGIC)
!HitBy([PC],MISSILE)
!HitBy([PC],SLASHING)
!HitBy([PC],MAGICFIRE)
!HitBy([PC],MAGICCOLD)
!HitBy([PC],STUNNING)
THEN
...
Another thing. AttackedBy, which than uses ASTYLES, do not seem to work its full purpose at all.
Yeah, this is a known issue (see action 0x0002 – "The style parameter is non functional - this trigger is triggered by any attack style."). It'll hopefully be fixed soon....
Ok, now seriously, I do not know who is responsible for fixing this, but if there is idea for fixing this soon, it would be worth and very important for me to know.
Because it would spare me to make tons of blocks to get what I want.. and now imagine after I finish that, this issue get fixed.. than I would have again to re-work that part (because using AttackedBy - MELEE or RANGED would work better and more precise for my idea, compared to solutions I now have).
So, if there is any real intention for fixing this in some next period of time, I would postpone work of that parts of scripts in mod, and work on other parts.
Ok, now seriously, I do not know who is responsible for fixing this, but if there is idea for fixing this soon, it would be worth and very important for me to know.
Because it would spare me to make tons of blocks to get what I want.. and now imagine after I finish that, this issue get fixed.. than I would have again to re-work that part (because using AttackedBy - MELEE or RANGED would work better and more precise for my idea, compared to solutions I now have).
So, if there is any real intention for fixing this in some next period of time, I would postpone work of that parts of scripts in mod, and work on other parts.
I think that it is one of the things that can only be fixed by Beamdog.
If that's the case, do your blocks because this fix will probably never come.
If, in other hand, it is something to be fixed by amateurs non-paid modders, probably it will be fixed really soon, so postponing may be a good idea.
I do not want to be one around who is whining, but the strong fact is, if this could be fixed, it would really really help. Not only me, but everyone who is working on scripts AI.
Yes, I can postpone that part of scripts, because I have much work on other parts of scripts anyway.
It would be really pity to complete these blocks with resources I have at this moment, because it would still be inferior to some degree, and even some blocks would have risk to return true (when they do not need to), although my opinion is that chance is very small. But when doing extreme encounters with AI which will go beyond any you seen so far.. it would be really pity not to tune it perfectly. Just simply line like AttackedBy, MELEE and RANGED (working) would spare me of all complications and combinations.
If I had knoweledge how to fix it, I would gladly take my time, but I do not have it.
Maybe this posts will catch someone attention. Lets see also what Argent77 have to say about such possibility
Anyway, I thank everyone so far for help and kind approach on forum.
What would happen if you added 0x1000 CRUSHING and changed the old crushing value to 0x0000 OTHER in damages.ids and dmgtypes.ids? do items like weapons and spells need to be updated to reflect the new changes?
What would happen if you added 0x1000 CRUSHING and changed the old crushing value to 0x0000 OTHER in damages.ids and dmgtypes.ids? do items like weapons and spells need to be updated to reflect the new changes?
Damage types are hardcoded. The entries in those IDS files are just for reference convenience.
And if hardcoded meaning that there is no way to fix it now.. well.. not something good to hear.
It would be much better, just as you suggested using logic, to give CRUSHING real value, and use someting else for "everything". That should make things correct from the start.
Luckily, all other works well, so you can tune your creatures how to respond when HIT BY ACID for example.
Now I will go back to post I already write. I see fixing of AttackedBy (DEFAULT, RANGED, MELEE) even more important than fixing CRUSHING.
Using LastAttacker, from my exipirence, is not perfect and I do not use it for various reasons.
Going back to my last post... if that can be fixed only by some unpaid amateur modder. Anyone interested?
I would even suggest to make organised donations for someone, of course trusted, if interested, to fix that. If there is enough interested people like me, maybe we can really start some change. I would gladly participate.
And some more:
Poison(25) and Regeneration(98) use their special field as a "Frequency Multiplier", with a default(0) value of '1'.
Parameter2 = 4, Frequency = 'Parameter1' * 'Special'
Shouldn't that be 'Parameter3' * 'Special'?
Moreover, is all of that limited to EE games?
And some more:
Poison(25) and Regeneration(98) use their special field as a "Frequency Multiplier", with a default(0) value of '1'.
Parameter2 = 4, Frequency = 'Parameter1' * 'Special'
Shouldn't that be 'Parameter3' * 'Special'?
Moreover, is all of that limited to EE games?
The 'Parameter3' field, when used, is damage value, not frequency.
These mechanics have since changed (v2.3 -> v2.5) however.
The 'Parameter3' field is still damage value, when appropriate.
The 'Special' field now controls which portrait Icon is displayed (poison has it's default, the others default to nothing). This works regardless of 'Parameter2' type.
The 'Parameter4' field (only available in EFF) is now used as the frequency multiplier, with a default(0) value of '1'.
@NiziNizi A mod cannot fix the AttackedBy function so it works correctly. However,@Bubb and @OlvynChuru are hard at work hacking the EE game(s) exe, ala ToBex; go talk to them on the EEex thread and see if they can help with this.
@NiziNizi A mod cannot fix the AttackedBy function so it works correctly. However,@Bubb and @OlvynChuru are hard at work hacking the EE game(s) exe, ala ToBex; go talk to them on the EEex thread and see if they can help with this.
Near Infinity is a great tool. Correct any bugs in the game if you know about programming. I mainly use it to change the colors of the armors the female characters wear especially elves, like pink, red, orange. I convert the appearance of ankheg plate into a leather armor for example. Or I add an armor class bonus to a circlet or the crown of the archdruid or thief hoods.
I'm using NI version 2.1-20180615 to work on a save game from the Android BG2EE 2.5.16.6. I can open the save game (BALDUR.SAV) and edit anything EXCEPT the WORLDMAP.wmp file. That one causes the program to pause for a while, then abort. If I keep hitting the View/Edit button, eventually the program will stop responding.
And some more:
Poison(25) and Regeneration(98) use their special field as a "Frequency Multiplier", with a default(0) value of '1'.
Parameter2 = 4, Frequency = 'Parameter1' * 'Special'
Shouldn't that be 'Parameter3' * 'Special'?
Moreover, is all of that limited to EE games?
The 'Parameter3' field, when used, is damage value, not frequency.
These mechanics have since changed (v2.3 -> v2.5) however.
The 'Parameter3' field is still damage value, when appropriate.
The 'Special' field now controls which portrait Icon is displayed (poison has it's default, the others default to nothing). This works regardless of 'Parameter2' type.
The 'Parameter4' field (only available in EFF) is now used as the frequency multiplier, with a default(0) value of '1'.
This is all limited to EE games.
May I ask you to clearly state the relationship between param#2, param#3 (only available in EFFs), and param#4 (only available in EFFs)?
If parameter2 = 0: ignore 'parameter3' and 'parameter4'. 'parameter1' just needs to be non-zero.
If parameter2 = 1: for best results, leave 'parameter3' and 'parameter4' at zero, 'parameter1' between 1 and 101.
- If the 'Parameter4' field is non-zero, damage is always dealt.
- If 'Parameter1' is less than 256:
Damage is dealt while Current HP > 100 / 'Parameter1'.
- Otherwise damage is dealt between certain thresholds:
[000 / ('Parameter1' / 65536)] < Current HP < [050 / ('Parameter1' / 65536)]
[100 / ('Parameter1' / 65536)] < Current HP < [150 / ('Parameter1' / 65536)]
[200 / ('Parameter1' / 65536)] < Current HP < [250 / ('Parameter1' / 65536)]
[300 / ('Parameter1' / 65536)] < Current HP < [350 / ('Parameter1' / 65536)]
[400 / ('Parameter1' / 65536)] < Current HP < [450 / ('Parameter1' / 65536)]
etc... up to characters maximum hit points.
I have no idea why.
If parameter2 = 2: deals 'parameter1' damage every 'parameter4' second(s).
If parameter2 = 3: deals one damage every ('parameter1' * 'parameter4') second(s).
If parameter2 = 4: deals 'parameter3' damage every ('parameter1' * 'parameter4') second(s). (This is the only one that must be in external EFF files.)
If parameter4 = 0: it's value is treated as '1'. This is the default value for SPL/ITM effects.
Only for op25 (poison), when the effect is NOT attached through op177, 'parameter4' will be replaced when using opcode 329 (slow poison) - not necessarily "slow" though, as it can increase or decrease the frequency.
Hope that helps.
If parameter2 = 4: deals 'parameter3' damage every ('parameter1' * 'parameter4') second(s). (This is the only one that must be in external EFF files.)
Does it mean that if param#2 = 2 (or = 3), then param#4 is automatically set to 1 when these opcodes are not used in external EFFs (for instance, have a look at MISC75.itm – it deals 1 poison damage per second, right)?
If parameter2 = 0: ignore 'parameter3' and 'parameter4'. 'parameter1' just needs to be non-zero.
If parameter2 = 1: for best results, leave 'parameter3' and 'parameter4' at zero, 'parameter1' between 1 and 101.
- If the 'Parameter4' field is non-zero, damage is always dealt.
- If 'Parameter1' is less than 256:
Damage is dealt while Current HP > 100 / 'Parameter1'.
- Otherwise damage is dealt between certain thresholds:
[000 / ('Parameter1' / 65536)] < Current HP < [050 / ('Parameter1' / 65536)]
[100 / ('Parameter1' / 65536)] < Current HP < [150 / ('Parameter1' / 65536)]
[200 / ('Parameter1' / 65536)] < Current HP < [250 / ('Parameter1' / 65536)]
[300 / ('Parameter1' / 65536)] < Current HP < [350 / ('Parameter1' / 65536)]
[400 / ('Parameter1' / 65536)] < Current HP < [450 / ('Parameter1' / 65536)]
etc... up to characters maximum hit points.
I have no idea why.
So, when param#2 = 0 or 1 (and if this is the case, consider both param#3 and #4 set to zero), the damage dealt is: 1 damage per 'parameter1' seconds? Or the damage dealt is always 1 per second regardless of param#1?
Does it mean that if param#2 = 2 (or = 3), then param#4 is automatically set to 1 when these opcodes are not used in external EFFs (for instance, have a look at MISC75.itm – it deals 1 poison damage per second, right)?
Parameter4 is effectively ignored outside of V2 effects (EFF/CRE), so it deals 1 / second.
The parameter doesn't actually get set to 1, the game just treats a value of 0 as 1.
So, when param#2 = 0 or 1 (and if this is the case, consider both param#3 and #4 set to zero), the damage dealt is: 1 damage per 'parameter1' seconds? Or the damage dealt is always 1 per second regardless of param#1?
The damage is always 1 / second for these two, provided their (simple or complex) conditions for damage are true. Likewise, op329 cannot affect them.
- Otherwise damage is dealt between certain thresholds:
[000 / ('Parameter1' / 65536)] < Current HP < [050 / ('Parameter1' / 65536)]
[100 / ('Parameter1' / 65536)] < Current HP < [150 / ('Parameter1' / 65536)]
[200 / ('Parameter1' / 65536)] < Current HP < [250 / ('Parameter1' / 65536)]
[300 / ('Parameter1' / 65536)] < Current HP < [350 / ('Parameter1' / 65536)]
[400 / ('Parameter1' / 65536)] < Current HP < [450 / ('Parameter1' / 65536)]
etc... up to characters maximum hit points.
I have no idea why.
Unless I'm missing something, most values between 255 and 65536 will end up in the first category. Is that correct? I think it would be clearer if you added an example (how it works and why one'd want to use it).
To sum up, the opcodes that behave like that are: #25 (Poison) and #98 (Regeneration). #78 (Disease) and #272 (Use EFF file on condition) seem to be slightly different. In particular:
op#78 – when param#2 = 1, the damage dealt is 'Parameter1' per rounds (instead of per seconds)
op#272 – param#2 = 1 is unknown
Is that correct? Are there any other significant differences?
Comments
Yeah, there are a couple of bugs in the latest NI release which were introduced when I added alpha channel BAM palette support to the BAM converter.
I agree with Ulb to use an earlier NI version to work around the problem if your BAM files don't use alpha channel palette (which is only supported by more recent EE patch versions anyway).
@swit
These strrefs are calculated differently by the engine. They are determined by the formula "0xF00000 + ENGINEST.2DA row number". Afaik this strref mode is only used by the UI.
In your case: strref 15729574 = 0xF003A6. Row number is 0x3A6 = 934 (dec), which refers to the ENGINEST.2DA entry STRREF_GUI_MIXED_CRIPPLING_STRIKE.
One of the most powerful features in the latest NI release is the bam resizing / bam recentering tool. I am so glad you made that possible. Especially since the "Bammer" tool beamdog announced some time ago never seems to be released.
So it's absolutely fine for me using that "extra" step with the shadow palette. The lack of the powerful features of the bam-tool is the reason why I can't use "older" versions of NI.
I exported some NWN Animations some time ago using 3ds Max. The problem is that it takes a lot of work (and time) to check the animations ingame. Quite often the rendered animations seem to be too large and the circles of some bam sequences are out of place when the creatures finally appear in the game.
So with NI's newest release, it is so much easier to adjust the size and the center of the bam without the need of re-rendering the whole stuff in 3ds Max with a different adjustment of the camera.
One more question about disabling/states.
I can see in scripts, it is commonly used, for example - !CheckStatGT(NearestEnemyOf(Myself),0,HELD). And it is not in STATE.ids.
For example, is Cleric Hold Person one of spell which will cause creature (if successful) to get stat HELD?
And more important, does any of STATE.ids cover that, or it have to be especially covered by using CheckStatGT(NearestEnemyOf(Myself),0,HELD) ?
I would suspect 0x00000008 STATE_STUNNED, but not so sure about it because it maybe only cover exactly Stun. I would more suspect, let say 0x00000020 STATE_HELPLESS ?
Download for compiled version
I was disappointed with how poorly it handled palette generation.
Because it's not a STATE, but a STAT. You can find it in STATS.ids along with other disabling stats (e.g. WEB).
Yes, that is clear, maybe I did write my post in little stupid way.
I did some testing and yes, Wizard or Cleric Hold person will put you in HELD stat, just as Ghast (if I recall right) melee attack.
0x00000020 STATE_HELPLESS cover that, tested. I did not test anything other like Web. I don't know exactly what else also provoke to go into HELPLESS state. As I recall, if you are under Web, you can't do anything just if you are Held. Don't know does ENTAGLE comes under HELPLESS, because if I recall right, under ENTAGLE you can still cast spells (which would mean you are not 100% helpless).
But I have to test it more, I did not play for long time and my memory is fading and I can be wrong about this, all play I do is when testing for short times, after working with scripts.
I will make test to clear 100% which spells exactly put creature in HELPLESS state, using every spell I suspect.
When you use HitBy([ANYONE],CRUSHING), it will return true if spells like Lower Resistance, Ruby Ray, Spell Strike (and I did not try every possible, that was enough to conclude something is wrong) are cast on creature.
I did try to use [PC] instead of [ANYONE], but nothing changes.
Everything else works fine.
I used for example..
OR(8)
HitBy([PC],COLD)
HitBy([PC],ACID)
HitBy([PC],FIRE)
HitBy([PC],ELECTRICITY)
HitBy([PC],MAGIC)
HitBy([PC],SLASHING)
HitBy([PC],PIERCING)
HitBy([PC],MISSILE)
..with no problems like this, just CRUSHING react to spells which do not have anything with crushing at all...
Edit: I haven't test this, but you can probably check for "crushing" damage specifically by excluding every other damage type:
IF HitBy([PC],CRUSHING) !HitBy([PC],COLD) !HitBy([PC],ACID) !HitBy([PC],COLD) !HitBy([PC],ELECTRICITY) !HitBy([PC],FIRE) !HitBy([PC],PIERCING) !HitBy([PC],POISON) !HitBy([PC],MAGIC) !HitBy([PC],MISSILE) !HitBy([PC],SLASHING) !HitBy([PC],MAGICFIRE) !HitBy([PC],MAGICCOLD) !HitBy([PC],STUNNING) THEN ...Tested, but result is same unfortunately.
Again, if someone is aware of this, let me know.
Using DEFAULT will return true for anything (which kill my purpose to separate melee and ranged attacks, etc.).
MELEE and RANGED never return true.
If I'm missing something to make it work, let me know.
Yeah, this is a known issue (see action 0x0002 – "The style parameter is non functional - this trigger is triggered by any attack style."). It'll hopefully be fixed soon....
Because it would spare me to make tons of blocks to get what I want.. and now imagine after I finish that, this issue get fixed.. than I would have again to re-work that part (because using AttackedBy - MELEE or RANGED would work better and more precise for my idea, compared to solutions I now have).
So, if there is any real intention for fixing this in some next period of time, I would postpone work of that parts of scripts in mod, and work on other parts.
I think that it is one of the things that can only be fixed by Beamdog.
If that's the case, do your blocks because this fix will probably never come.
If, in other hand, it is something to be fixed by amateurs non-paid modders, probably it will be fixed really soon, so postponing may be a good idea.
I do not want to be one around who is whining, but the strong fact is, if this could be fixed, it would really really help. Not only me, but everyone who is working on scripts AI.
Yes, I can postpone that part of scripts, because I have much work on other parts of scripts anyway.
It would be really pity to complete these blocks with resources I have at this moment, because it would still be inferior to some degree, and even some blocks would have risk to return true (when they do not need to), although my opinion is that chance is very small. But when doing extreme encounters with AI which will go beyond any you seen so far.. it would be really pity not to tune it perfectly. Just simply line like AttackedBy, MELEE and RANGED (working) would spare me of all complications and combinations.
If I had knoweledge how to fix it, I would gladly take my time, but I do not have it.
Maybe this posts will catch someone attention. Lets see also what Argent77 have to say about such possibility
Anyway, I thank everyone so far for help and kind approach on forum.
It would be much better, just as you suggested using logic, to give CRUSHING real value, and use someting else for "everything". That should make things correct from the start.
Luckily, all other works well, so you can tune your creatures how to respond when HIT BY ACID for example.
Now I will go back to post I already write. I see fixing of AttackedBy (DEFAULT, RANGED, MELEE) even more important than fixing CRUSHING.
Using LastAttacker, from my exipirence, is not perfect and I do not use it for various reasons.
Going back to my last post... if that can be fixed only by some unpaid amateur modder. Anyone interested?
I would even suggest to make organised donations for someone, of course trusted, if interested, to fix that. If there is enough interested people like me, maybe we can really start some change. I would gladly participate.
Shouldn't that be 'Parameter3' * 'Special'?
Moreover, is all of that limited to EE games?
These mechanics have since changed (v2.3 -> v2.5) however.
The 'Parameter3' field is still damage value, when appropriate.
The 'Special' field now controls which portrait Icon is displayed (poison has it's default, the others default to nothing). This works regardless of 'Parameter2' type.
The 'Parameter4' field (only available in EFF) is now used as the frequency multiplier, with a default(0) value of '1'.
This is all limited to EE games.
Will do. Thank you.
May I ask you to clearly state the relationship between param#2, param#3 (only available in EFFs), and param#4 (only available in EFFs)?
- If parameter2 = 0: ignore 'parameter3' and 'parameter4'. 'parameter1' just needs to be non-zero.
- If parameter2 = 1: for best results, leave 'parameter3' and 'parameter4' at zero, 'parameter1' between 1 and 101.
- If the 'Parameter4' field is non-zero, damage is always dealt.
- If parameter2 = 2: deals 'parameter1' damage every 'parameter4' second(s).
- If parameter2 = 3: deals one damage every ('parameter1' * 'parameter4') second(s).
- If parameter2 = 4: deals 'parameter3' damage every ('parameter1' * 'parameter4') second(s). (This is the only one that must be in external EFF files.)
- If parameter4 = 0: it's value is treated as '1'. This is the default value for SPL/ITM effects.
Only for op25 (poison), when the effect is NOT attached through op177, 'parameter4' will be replaced when using opcode 329 (slow poison) - not necessarily "slow" though, as it can increase or decrease the frequency.- If 'Parameter1' is less than 256:
- Damage is dealt while Current HP > 100 / 'Parameter1'.
- Otherwise damage is dealt between certain thresholds:- [000 / ('Parameter1' / 65536)] < Current HP < [050 / ('Parameter1' / 65536)]
- [100 / ('Parameter1' / 65536)] < Current HP < [150 / ('Parameter1' / 65536)]
- [200 / ('Parameter1' / 65536)] < Current HP < [250 / ('Parameter1' / 65536)]
- [300 / ('Parameter1' / 65536)] < Current HP < [350 / ('Parameter1' / 65536)]
- [400 / ('Parameter1' / 65536)] < Current HP < [450 / ('Parameter1' / 65536)]
- etc... up to characters maximum hit points.
I have no idea why.Hope that helps.
Does it mean that if param#2 = 2 (or = 3), then param#4 is automatically set to 1 when these opcodes are not used in external EFFs (for instance, have a look at MISC75.itm – it deals 1 poison damage per second, right)?
So, when param#2 = 0 or 1 (and if this is the case, consider both param#3 and #4 set to zero), the damage dealt is: 1 damage per 'parameter1' seconds? Or the damage dealt is always 1 per second regardless of param#1?
The parameter doesn't actually get set to 1, the game just treats a value of 0 as 1. The damage is always 1 / second for these two, provided their (simple or complex) conditions for damage are true. Likewise, op329 cannot affect them.
Unless I'm missing something, most values between 255 and 65536 will end up in the first category. Is that correct? I think it would be clearer if you added an example (how it works and why one'd want to use it).
To sum up, the opcodes that behave like that are: #25 (Poison) and #98 (Regeneration). #78 (Disease) and #272 (Use EFF file on condition) seem to be slightly different. In particular:
- op#78 – when param#2 = 1, the damage dealt is 'Parameter1' per rounds (instead of per seconds)
- op#272 – param#2 = 1 is unknown
Is that correct? Are there any other significant differences?