I'd like to request removing the 255 stats.ids restriction when it comes splprot.2da NI auto descriptions for opcodes 318, 324, 326. EEex expands number of usable stats.ids entries to 65737.
When it comes to EEex it would be also nice if NI treated it the same way as it does ToBex which means full support for the following opcodes changes:
Change in opcode #42:
Special: Force the slot modification?
If Special parameter is non-zero, the slot modification ignores access to particular spell level requirement.
Change in opcode #62:
Special: Force the slot modification?
If Special parameter is non-zero, the slot modification ignores access to particular spell level requirement.
Change in opcode #218:
Spell specified in resource key is fired when all layers are lost.
Change in opcode #280:
Parameter #1: Surge Roll
Special: Show hardcoded graphical effects?
'Surge Roll' field allows to force particular wild surge roll to occur if it is set to non-zero.
If Special parameter is non-zero, all hardcoded wild surge graphical effects are suppressed.
Change in opcode #319:
Power: Mode
Parameter #1: IDS Entry / Value
Parameter #2: IDS File / Stat Type
Known values for 'Mode' are:
0 item restricted if condition holds ('Not usable by' mode), parameters use IDS targets
1 item restricted if condition fails ('Usable by' mode), parameters use IDS targets
2 like 1 but parameters use splprot.2da
3 like 0 but parameters use splprot.2da
If 'Mode' is set to 2 or 3, then the creature type specified by the 'Stat Type' field will be affected by this opcode. See opcode #324 for more information.
Change in opcode #324:
Special: Strref
Hardcoded enginest.2da strref can be optionally overridden by strref specified in Special field.
New opcode #400: Set Temporary AI Script
Parameter #1: Irrelevant
Parameter #2: Type
Description:
Works exactly like Opcode #82 except:
1) A null resref can null a script slot
2) The original script is restored when the duration runs out or the effect otherwise ends.
New opcode #401: Set Extended Stat
Parameter #1: Statistic Modifier
Parameter #2: Type
Special: Stat
Description:
Applies the modifier value specified by the 'Statistic Modifier' field in the style specified by the 'Type' field.
Known values for 'Type' are:
0 Cumulative Modifier -> Stat = Stat+ 'Statistic Modifier' value
1 Flat Value Modifier -> Stat= 'Statistic Modifier' value
2 Percentage Modifier -> Stat = (Stat* 'Statistic Modifier' value) / 100
Values for 'Stat' are taken from stats.ids (EEex expands number of usable stats.ids entries to 65737).
New opcode #402: Invoke Lua
Parameter #1: Lua Value 1
Parameter #2: Lua Value 2
Special: Lua Value 3
Description:
The targeted creature(s) calls a Lua function specified by the resource key. Maximum function name length is 8, and function names must be completely upper-case.
Object that invoked the effect and values passed by the opcode can be used in the called Lua function. Example:
function MY_FUNCT(effectData, creatureData)
EEex_LuaObject = EEex_ReadDword(creatureData + 0x34)
local param1 = EEex_ReadDword(effectData + 0x18)
local param2 = EEex_ReadDword(effectData + 0x1C)
local special = EEex_ReadDword(effectData + 0x44)
C:Eval('DisplayStringHead(EEex_LuaObject,1)')
Infinity_DisplayString("MY_FUNCT invoked; param1 = " .. param1 .. "; param2 = " .. param2 .. "; special = " .. special)
end
New opcode #403: Screen Effects
Parameter #1: Lua Value 1
Parameter #2: Lua Value 2
Special: Lua Value 3
Description:
Whenever an effect is being added to the target creature a Lua function specified by the resource key is called. Maximum function name length is 8, and function names must be completely upper-case.
The Lua function's signature can be seen in the following example:
function B3BLOCKD(originatingEffectData, effectData, creatureData)
local effectID = EEex_ReadDword(effectData + 0xC)
if effectID == 12 then
local param1 = EEex_ReadDword(originatingEffectData + 0x18)
local param2 = EEex_ReadDword(originatingEffectData + 0x1C)
local special = EEex_ReadDword(originatingEffectData + 0x44)
local timesBlocked = EEex_ReadDword(effectData + 0x44) + 1 --get value stored in opcode 403 'special' field, add 1
EEex_WriteDword(effectData + 0x18, timesBlocked) --update opcode 403 'special' field value
Infinity_DisplayString("B3BLOCKD blocked effectID 12 " .. timesBlocked .. " time(s); param1 = " .. param1 .. "; param2 = " .. param2 .. "; special = " .. special)
return true
end
end
A return value of true blocks the effect from applying. Note: the immunity function "sees" effects after they have passed their probability roll, but before any saving throws have been made against said effect / other immunity mechanisms have taken place. The originating effect is passed via the immunity function's first Lua param.
New opcode #404: Override Button
Parameter #1: Type to override
Parameter #2: Override with type
Description:
Alter a specified actionbar button on the target creature.
Known values for both parameters match what is defined by EEex_ACTIONBAR_TYPE in M__EEex.lua:
2 BARD_SONG
3 CAST_SPELL
4 FIND_TRAPS
5 TALK
7 GUARD
8 ATTACK
10 SPECIAL_ABILITIES
11 STEALTH
12 THIEVING
13 TURN_UNDEAD
14 USE_ITEM
15 STOP
21 QUICK_ITEM_1
22 QUICK_ITEM_2
23 QUICK_ITEM_3
24 QUICK_SPELL_1
25 QUICK_SPELL_2
26 QUICK_SPELL_3
27 QUICK_WEAPON_1
28 QUICK_WEAPON_2
29 QUICK_WEAPON_3
30 QUICK_WEAPON_4
100 NONE
EEex can be detected for example using "EEex.db" file located in the main game directory.
edit: descriptions updated using Bubb's notes from below post.
edit2: added opcode #319 changes
edit3: added example Lua function for opcode #402
edit4: added opcode #42 and #62 changes
edit5: added opcodes #403 and #404
@swit: Everything looks good except for two things:
Opcode #324:
- Only change is to the Special parameter. Hardcoded enginest.2da strref is overridden by Special if non-zero.
New Opcode #400 (Set Temporary AI Script): Works exactly like Opcode #82 except -
1) A null resref can null a script slot
2) The original script is restored when the duration runs out or the effect otherwise ends. (Param1 is not used)
Though, that being said, I'm sure @argent77 doesn't want to meticulously follow every change I make; if there is a standard way I could add the definitions to Near Infinity myself, I'd happily do so and ever-so-often do a pull request.
@subtledoctor: Near Infinity simply checks for the existence of ./TobEx_ini/TobExCore.ini to see if it should enable TobEx specific Opcode entries... which are checked on a per-instance basis. EEex info wouldn't bleed into non-EEex installs if implemented correctly
It seems that BIT24 (Can target invisible) located at offset 0x0018 of a SPL's header is not a ToBEx-only feature (i.e., it works fine on EE games...)
Does the same hold for Toggle Backstab (I'm talking about BIT25 located at offset 0x0026 of an ITM's extended header)? If so, what is it for? Can I enable it to make a weapon eligible for backstab/sneak attack?
I recently had a problem when trying to view a .gam file with NI. It seems every time I try to open the .gam file from the save of a certain BG2 run of mine NI hangs pretty badly. I am not sure why this would be other than that this is a very OLD run. In fact, if I recall correctly, I had created it before the public release of BG2:EE. I will attach the save in question in case you want to look at it.
Not really a new label, but an oddity regarding EFF files opcode field.
Effects in Spells/Items have only 2 bytes for their opcodes, while EFF files have 4 bytes.
While they still only use the first 2 for which effect to apply, the entire 4 byte section is still read for other mechanics.
For one, when comparing to values listing in EFFTEXT.2DA. As such, when applying an effect through an EFF file, you can suppress the default feedback message from EFFTEXT.2da by setting any BIT in the 3rd or 4th BYTE, or you could add up to 65536 custom entries for each opcode to EFFTEXT.2da using those upper bytes.
Oddly, EFFTEXT.2DA does not allow hexadecimal numbers, and requires signed values, so all values above 2147483647 must be their 4-byte negative equivalents.
Immunity, reflection, and removal by opcode effects also read the whole 4 bytes, and will not block/reflect/remove their specified effect in an EFF file if any bits of the opcode's upper two bytes are set.
I'm not sure if changing/splitting the opcode field in EFF files would be appropriate without a legitimate use for this (or even possible, I know EFF aren't open to much change).
Just a word of caution: the engine has many hardcoded checks that directly compare against the full dword id. Most, if not all of these checks would break if you altered the extra id bytes, and that would have varying consequences.
Opcodes that have different ids but share the same code branch wouldn't be able to tell which opcode is running, and would act like the arbitrary default in that scenario.
As kjeron has already found, any mechanics that specifically check against the id will fail.
Certain opcodes are treated as special by the engine, and have certain exceptions / special rules applied. These would all break down, etc.
@Bubb That's kinda what I was looking for though, it's just too many side-effects.
It's the only way I've found to get op25 (poison) past Stone Skins since the v2.5 update, though oddly doing the same does not allow physical damage from op12 (damage) to get past Stone Skins. It also gets op25 past Mirror Image, but of course the flag does that in a much safer manner.
Worth documenting stuff found by Bubb regarding opcode 319 (true without EEex):
the 'Power' of the effect changes how it evaluates. Power = 1 means allow item use if condition holds, Power != 1 means allow item use if condition fails.)
Updated my previous post adding full range of changes done by EEex to opcode 319 - I will keep that list updated.
Are recent builds slower? With ~27,000 files in my override folder, NI takes a solid 3-4 minutes to start up. (Quite annoying when I want to clone a file by exporting it into /override, then I need to quit and restart NI to edit it.)
I feel like my former build (which I think was of late 2017/early 2018 vintage) didn't have that delay.
@subtledoctor Can't you do "Game/Refresh Tree"? Might take just as long, of course.
--
I have a question and I'm sure the answer is somewhere on my side. If I look at a modded game, NI often does not display mod added text strings but displays them as "No such index" instead. This is also true for the BG1 ressources in EET, for example. If I export e.g. AMNIS4.dlg file as weidu-d file, it looks like this:
BEGIN ~AMNIS4~
//////////////////////////////////////////////////
// WARNING: this file contains non-trivial WEIGHTs
//////////////////////////////////////////////////
IF ~~ THEN BEGIN 0 // from:
SAY #200763 /* ~No such index~ */
IF ~~ THEN EXIT
END
IF WEIGHT #7 /* Triggers after states #: 9 8 7 6 5 4 3 even though they appear after this state */
~ GlobalLT("Chapter","GLOBAL",8)
StateCheck(Myself,STATE_CHARMED)
~ THEN BEGIN 1 // from:
SAY #205753 /* ~No such index~ */
IF ~~ THEN UNSOLVED_JOURNAL #226840 /* ~No such index~ */ EXIT
IF ~ GlobalGT("CHAPTER","GLOBAL",2)
~ THEN EXIT
END
IF ~~ THEN BEGIN 2 // from:
SAY #208910 /* ~No such index~ */
IF ~~ THEN EXIT
END
I guess I forgot to tick something somwhere or what can I do so all ressources are shown properly?
NI opens definitely quicker than 500 seconds on my potato-notebook.
Out of curiosity, does it vary with the amount of files in your \override folder? How much does it take if there are, say, ~27,000 files (as is the case with @subtledoctor )?
I'm trying to figure out the duration of the paralyze effect of the Implosion spell. NI says the duration is 6. Is this seconds or is it something else?
For me it definitely varies by the amount of files. I've done a few different cross-mod testing installs lately, and it's something like:
- vanilla: a few seconds
- ~5,000 files: 15-20 seconds
- ~12,000 files: a minute or so
- ~30,000 files: several minutes
Like, I have to go do something else while I wait for NI to open. I've never had to do that before.
About the slowness: Couldn't it be related to an antivirus aggressive real-time scanning?
I.e. a ton of small files multiplied by a extra delay in accessing them each time (AV getting in the way with the RT scanning) and you get a big slowdowns.
Just make sure that your AV has excluded from RT scanning all the BG folders that has tons of files (override, data, probably all mods folders, etc.)
EDIT: Just to add an extra reference, my NI says it scanned 61169 files (at the bottom) and launches and loads in less that 30 secs.
Comments
When it comes to EEex it would be also nice if NI treated it the same way as it does ToBex which means full support for the following opcodes changes:
EEex can be detected for example using "EEex.db" file located in the main game directory.
edit: descriptions updated using Bubb's notes from below post.
edit2: added opcode #319 changes
edit3: added example Lua function for opcode #402
edit4: added opcode #42 and #62 changes
edit5: added opcodes #403 and #404
Opcode #324:
- Only change is to the Special parameter. Hardcoded enginest.2da strref is overridden by Special if non-zero.
New Opcode #400 (Set Temporary AI Script): Works exactly like Opcode #82 except -
1) A null resref can null a script slot
2) The original script is restored when the duration runs out or the effect otherwise ends. (Param1 is not used)
Though, that being said, I'm sure @argent77 doesn't want to meticulously follow every change I make; if there is a standard way I could add the definitions to Near Infinity myself, I'd happily do so and ever-so-often do a pull request.
Does the same hold for Toggle Backstab (I'm talking about BIT25 located at offset 0x0026 of an ITM's extended header)? If so, what is it for? Can I enable it to make a weapon eligible for backstab/sneak attack?
What's the meaning of IWD style check (it's BIT30 located at offset 0x002C)?
Effects in Spells/Items have only 2 bytes for their opcodes, while EFF files have 4 bytes.
While they still only use the first 2 for which effect to apply, the entire 4 byte section is still read for other mechanics.
For one, when comparing to values listing in EFFTEXT.2DA. As such, when applying an effect through an EFF file, you can suppress the default feedback message from EFFTEXT.2da by setting any BIT in the 3rd or 4th BYTE, or you could add up to 65536 custom entries for each opcode to EFFTEXT.2da using those upper bytes. Oddly, EFFTEXT.2DA does not allow hexadecimal numbers, and requires signed values, so all values above 2147483647 must be their 4-byte negative equivalents.
Immunity, reflection, and removal by opcode effects also read the whole 4 bytes, and will not block/reflect/remove their specified effect in an EFF file if any bits of the opcode's upper two bytes are set.
I'm not sure if changing/splitting the opcode field in EFF files would be appropriate without a legitimate use for this (or even possible, I know EFF aren't open to much change).
@Bubb - just in case it helps your work in EEex.
Opcodes that have different ids but share the same code branch wouldn't be able to tell which opcode is running, and would act like the arbitrary default in that scenario.
As kjeron has already found, any mechanics that specifically check against the id will fail.
Certain opcodes are treated as special by the engine, and have certain exceptions / special rules applied. These would all break down, etc.
It's the only way I've found to get op25 (poison) past Stone Skins since the v2.5 update, though oddly doing the same does not allow physical damage from op12 (damage) to get past Stone Skins. It also gets op25 past Mirror Image, but of course the flag does that in a much safer manner.
Updated my previous post adding full range of changes done by EEex to opcode 319 - I will keep that list updated.
Should be =>
Apparently I implemented my args in reverse order from what the engine defines. Oops.
Maybe an example could help clarify this:
Like this:
Replace <directory> by the folder where you downloaded NearInfinity.jar and be sure that Java.exe is in the system PATH, but it probably should be.
It might print something to the console that would let you diagnose what's going on...
@subtledoctor Can't you do "Game/Refresh Tree"? Might take just as long, of course.
--
I have a question and I'm sure the answer is somewhere on my side. If I look at a modded game, NI often does not display mod added text strings but displays them as "No such index" instead. This is also true for the BG1 ressources in EET, for example. If I export e.g. AMNIS4.dlg file as weidu-d file, it looks like this:
I guess I forgot to tick something somwhere or what can I do so all ressources are shown properly?
Out of curiosity, does it vary with the amount of files in your \override folder? How much does it take if there are, say, ~27,000 files (as is the case with @subtledoctor )?
Me too, but I'm still on the Mid 2012 model
Anyway, it's likely an OS thing.....
I.e. a ton of small files multiplied by a extra delay in accessing them each time (AV getting in the way with the RT scanning) and you get a big slowdowns.
Just make sure that your AV has excluded from RT scanning all the BG folders that has tons of files (override, data, probably all mods folders, etc.)
EDIT: Just to add an extra reference, my NI says it scanned 61169 files (at the bottom) and launches and loads in less that 30 secs.