[Courtesy of Kjeron] As far as EE games are concerned:
op18,p2=6 is missing.
Also op18, Special field is missing.
What about renaming op44,p2=3 to Bull's strength (since we have op15,p2=3 – Cat's Grace)?
Moreover, for both op15 and op44, when p2=3 and the effect is applied in SPL/ITM (V1 effects), 'Parameter1 – Value' should turn into 'Unused'...
I suggest renaming op265 and op309 to "Modify global/local variable" so as to distinguish them from op187, which can only SET variables.
V2 effects, Dispel/Resistance attribute is missing:
BIT2
BIT31
Moreover, for both V1 and V2 effects, what about turning the Dispel/Resistance attribute into a bit field? IMHO, it'd be more appropriate...
op61: parameter2a – Location should be flagged as unused.
op363: should be renamed to "Modal state check". Parameter1 and 2 are unused, only the Special field is used.
op336, Parameter2 / op335, Special values should range from '0|None' to '26|Z'.
op18,p2=6 is missing.
Also op18, Special field is missing.
Will be added.
What about renaming op44,p2=3 to Bull's strength (since we have op15,p2=3 – Cat's Grace)?
That's a good argument. Will be fixed.
Moreover, for both op15 and op44, when p2=3 and the effect is applied in SPL/ITM (V1 effects), 'Parameter1 – Value' should turn into 'Unused'...
Will be fixed.
I suggest renaming op265 and op309 to "Modify global/local variable" so as to distinguish them from op187, which can only SET variables.
I agree. Will be fixed.
V2 effects, Dispel/Resistance attribute is missing:
BIT2
BIT31
Moreover, for both V1 and V2 effects, what about turning the Dispel/Resistance attribute into a bit field? IMHO, it'd be more appropriate...
I thought about turning it into a bitfield several times over the last couple of years. I decided against it since it didn't really improve usability back when only the first two bits were used. With two more flags available I'll think about it again.
op61: parameter2a – Location should be flagged as unused.
Will be fixed.
op363: should be renamed to "Modal state check". Parameter1 and 2 are unused, only the Special field is used.
This is the overly technical name from IESDP. I prefer to use more descriptive names for NI. The current name 'Movement rate check' may not be 100% accurate, but should suffice. I could change it to 'Movement state check' or 'Movement check' though.
op336, Parameter2 / op335, Special values should range from '0|None' to '26|Z'.
op336: Will be fixed. op335: Doesn't 'Special' refer to the Type/Eye Group value of op336?
You might want to rename op219 to "Attack & Saving Throw roll penalty"...
Yes, saves appear to be affected as well. Will be fixed.
op243, Parameter2 is unused...
This is a strange opcode with incompatible parameter types between different game engine revisions. In both variants param2 is unused though; will be fixed.
op3, Parameter2=2: there's no Blood Rage option (see also IWDEE v2.6 SPPR422 – Blood Rage: it's now using 'p2=1'...)
Will be fixed.
op248, Parameter2=4 (BIT2) is missing... I suggest naming it 'Fist only?'...
A new feature in 2.6 that went unnoticed by most so far is that the projectile ray functionality has been fixed and enhanced. The concept is the same. You set the amount of rays in the projectile explosion at 0x202 (word), set the distance the rays travel as the explosion radius (word at 0x206), and the angle between multiple rays at 0x224 (word). Something which is new in 2.6 is that you can rotate the entire set of rays by some angle specified at 0x226 (word) in a clockwise (iirc) direction. See .pro file format description here: https://gibberlings3.github.io/iesdp/file_formats/ie_formats/pro_v1.htm
What made the ray functionality less than useful in previous patches was that the rays fired off at a fixed angle. As of 2.6 this is no longer the case. The rays originate either from the origin of the projectile (usually where the caster is standing) if the cone bit is enabled or if the cone bit is disabled, then the rays originate from the explosion point of the parent projectile. The orientation of the first ray is a vector pointing from the origin of the projectile to the destination if the cone bit is enabled. If the cone bit is disabled, then the first ray continues in the same direction as the vector between the origin of the parent projectile (usually the caster) and the explosion point. Subsequent rays are generated in an alternating expanding pattern going from left to right. So an odd number of rays is needed to get them to launch symmetrically unless you rotate the entire ray package by some amount of degrees specified in 0x226 (word).
What is especially cool about this feature is that you can nest different ray projectiles into one another using polar coordinates for launch/destination points. Combine it with several different subspells/child spells and you can pretty much have any shaped area of effect.
Where are these rays used in 2.6?
Lightning Bolt projectile (LIGHTB.pro/IDPRO40.pro) appears to be a traveling projectile that doesn't harm any in its path and then transforms into a "bouncy" projectile that damages all in the same path. The cone bit is disabled and only one ray is launched as the child projectile LIGHTGRN.pro/IDPRO206.pro which uses the same animation as the parent projectile LIGHTB.pro/IDPRO40.pro. The explosion radius is a very large number but that's internally converted into a duration (ticks) as defined by distance/projectile speed of LIGHTGRN.pro/IDPRO206.pro which causes the projectile to travel a certain distance including bouncing around as measured from the destination point.
Spiritual Wrath (IDPRO312.pro) in IWD:EE uses multiple rays (SWRATH.pro) and the cone bit is enabled. So the 4 rays are launched from the caster with the intial ray direction pointing to which the spell is cast. Subsequent rays are generated 90 degrees off of the initial ray.
You can drain charges for a specific item if the resource field is used
#324 (0x144) Protection: Immunity to Resource and Message
The name of the correct resource is displayed instead of the name of the resource the effect instance is located in. It now works as intended in 2.6.
New smart feature: It will attempt to identify the name of the parent spell if this effect is located in a child spell with no name. It does in the following manner: if the effect is used within a spell that has no name but there is a spell in the game who's resname is one character shorter with a valid name, then it will display that name. This feature is used in Sunfire (SPWI523D.spl) to check for thief evasion.
This feature will also attempt to look for an identical resname.itm and display that (identified/unidentified) if the .spl the effect is in doesn't have a name.
I am not sure if this is a bug or just my own ineptitude, but whenever I use NI to append an Extended Header to the bottom of a file, be it by copy/paste or by the add button, I get some erroneous "unused bytes?" that appear at the bottom of the file. A real pain, especially since these bytes cannot be deleted in any way I know of using NI (other than restoring a backup). I will give you a Beamdog style repro case to help you solve the problem:
1. Open a spell file (say, spin102.spl) and go to the edit tab.
2. Select any field so that it is highlighted (the "Signature" field will do).
3. Click the "Add" button and select "Spell Ability" to add a spell ability.
4. Save the changes to the resource.
5. Refresh the Tree and view the resource you just edited.
Observed: Erroneous "Unused Bytes?" appear at the bottom of the file, as seen in the attached screenshot. If the spell is cast in game, the game crashes.
Expected: There should be no erroneous data added to the file which can cause a crash in the game.
@Tresset
It's failing to update the "Effects Offset" field when you add an ability header after/below the final one on a spell/item. It doesn't occur when removing ability headers or when adding ability headers before/above the final ability header (or if there are currently 0 ability headers). It was reported back in December on SHS.
Until fixed, add new abilities above/before the existing abilities (by having one of the ability headers selected when pressing "Add...").
@Tresset
It's failing to update the "Effects Offset" field when you add an ability header after/below the final one on a spell/item. It doesn't occur when removing ability headers or when adding ability headers before/above the final ability header (or if there are currently 0 ability headers). It was reported back in December on SHS.
Until fixed, add new abilities above/before the existing abilities (by having one of the ability headers selected when pressing "Add...").
This issue is very tricky to fix. I added a workaround for another issue back in May 2020 to ensure that effects offset always points behind the abilities offset, but it seems to have raised just another issue under different circumstances.
@argent77, are you interested in merging @Bubb's Near Infinity branch with main one? Here are the commits: https://github.com/Bubb13/NearInfinity/commits/EEex
I've been using this altered NI version extensively without problems. If there are no merge conflicts I think it's worth it (not sure why Bubb has not sent you pull request yet though)
New features and bugfixes sounds exciting but without EEex support I'm forced to stay on the old one.
I would be happy to include @Bubb's EEex additions. NI already contains TobEx-specific stuff, so EEex support would be welcome. His fork is slightly dated though. I'd rather wait until his fork is up to date with the more recent changes.
@argent77: I'm absolutely terrible at Git, but I've added some newer EEex definitions and somehow managed to update my fork to match yours, (totally mangled my commit history though). Is anything else needed from me for a merge?
@argent77: I'm absolutely terrible at Git, but I've added some newer EEex definitions and somehow managed to update my fork to match yours, (totally mangled my commit history though). Is anything else needed from me for a merge?
From what I've seen it looks fine. Feel free to create a pull request whenever you're ready.
V1/V2 Effects, Savetype – BIT24 – Bypass mirror image: This bit is only relevant for opcode #12 and opcode #25 (All other opcodes bypass Mirror Image by default, setting/unsetting this bit is harmless).
V1/V2 Effects, Savetype – BIT25 – Ignore difficulty: This bit is specific to opcode #12 only.
[SPL Extended Header]: `Bonus to hit`, `Dice size`, `# dice thrown`, `Damage bonus`, `Damage type`, `# charges`, `When drained` should be flagged as "Irrelevant/Unused".
[SPL Header]: `Identified name` and `Identified description` should be flagged as "Irrelevant/Unused".
I would like to ask you to investigate the possibility to provide self-contained/ static build of NI. I have no other application which requires Java so it would be great to get rid of it.
op15/44 and p2=3: to be precise Parameter1 is unused only in SPL/ITM Effects.
Once applied to a creature, `Parameter1` will store the exact DEX/STR increase granted (so it can be edited through NI, and shouldn't be labeled as "Unused").
When you apply these effects in an External EFF file, `Parameter1` in the EFF will determine the exact STR/DEX increase (so it must be set manually, and shouldn't be labeled as "Unused").
[SPL Extended Header]: `Bonus to hit`, `Dice size`, `# dice thrown`, `Damage bonus`, `Damage type`, `# charges`, `When drained` should be flagged as "Irrelevant/Unused".
[SPL Header]: `Identified name` and `Identified description` should be flagged as "Irrelevant/Unused".
I would like to ask you to investigate the possibility to provide self-contained/ static build of NI. I have no other application which requires Java so it would be great to get rid of it.
The .jar file is the "executable" for a Java application. There may be ways to wrap it in a native Windows executable by third party tools, but I'd be wary about these methods since they could introduce malicious code or compatibility issues.
If you're concerned that the Java Runtime installer installs something that might compromise your system then I'd suggest to use OpenJDK instead. It provides simple zip archives without the need to "install" anything.
op15/44 and p2=3: to be precise Parameter1 is unused only in SPL/ITM Effects.
Once applied to a creature, `Parameter1` will store the exact DEX/STR increase granted (so it can be edited through NI, and shouldn't be labeled as "Unused").
When you apply these effects in an External EFF file, `Parameter1` in the EFF will determine the exact STR/DEX increase (so it must be set manually, and shouldn't be labeled as "Unused").
[SPL Extended Header]: `Bonus to hit`, `Dice size`, `# dice thrown`, `Damage bonus`, `Damage type`, `# charges`, `When drained` should be flagged as "Irrelevant/Unused".
[SPL Header]: `Identified name` and `Identified description` should be flagged as "Irrelevant/Unused".
I would like to ask you to investigate the possibility to provide self-contained/ static build of NI. I have no other application which requires Java so it would be great to get rid of it.
The .jar file is the "executable" for a Java application. There may be ways to wrap it in a native Windows executable by third party tools, but I'd be wary about these methods since they could introduce malicious code or compatibility issues.
If you're concerned that the Java Runtime installer installs something that might compromise your system then I'd suggest to use OpenJDK instead. It provides simple zip archives without the need to "install" anything.
Let me clarify:
Take a look at jpackage, a new standard tool in Java 14 for packaging self-contained Java applications. Example usage is:
I'm not asking to deprecate .jar builds, I'm only asking to provide additional build using this official tool so players would only have to download NearInfinity.exe and that's it.
I'm not asking to deprecate .jar builds, I'm only asking to provide additional build using this official tool so players would only have to download NearInfinity.exe and that's it.
From what I can see `jpackage` creates some kind of installation package for the NearInfinity.jar which has to be installed before NI can be used. The installer itself contains a Java Runtime image that is installed along with NI which adds another 50 MB to the installer file size and requires about 130 MB additional disk space after installation. Moreover, the binary location is fixed to the installation folder.
I don't really see an advantage except that you don't have to install Java separately. The price for this convenience is a considerably higher installation size, the requirement to run a setup whenever you want to install a new NI version (and possibly the inability to install different versions side by side) and the inability to move or copy the NI binary from its installation folder to some other location (like a game folder).
The tool is called 'jlink' and it apparently can create a bundled custom JVM which will be placed alongside the application. Then, you can move the whole NI directory where you want. Running NI would be double-click on .bat file for windows.
The tool is called 'jlink' and it apparently can create a bundled custom JVM which will be placed alongside the application. Then, you can move the whole NI directory where you want. Running NI would be double-click on .bat file for windows.
Can you give it a last try?
That link describes basically the same just with the addition of `jlink` for optimizing the size of the attached Java Runtime image.
There are wrappers which create Windows executables that can be run directly (e.g. Launch4j), but they are either not maintained anymore or not fully trustworthy. Moreover, these wrappers are likely a good candidate for false alarms from antivirus tools since they contain another executable inside similar to UPX packed executables.
In either case you're always installing a Java Runtime with the application you want to run which eats up a lot of disk space if you want to keep several NI versions around. I don't see a real benefit over installing Java once separately and run JAR files (or only this specific JAR file) afterwards.
The AdoptOpenJDK project can be used to download a pure Java Runtime package with requires much less disk space than the JDK. I'd recommend to use the Java 8 JRE which is the same version NI is build with. It reserves about 95 MB on disk.
This new PRO field at 0x226. However, @Galactygon it seems this field is always 0...? I'm failing to understand if the field at 0x226 is functional or not...
Whenever the number of rays in a projectile explosion exceeds zero (word at 0x202) then the word at 0x224 (called "cone width") becomes the field "angle between rays" expressed in degrees. That's already known. If there's only one ray then it doesn't matter what the field is set to. If there are multiple rays and the field is set to 0 then those rays spawn and travel on top of each other which means the effects are applied multiple times on creatures in the area of effect of those rays.
The new field (word at 0x226) can be known as "rotate rays CCW CW" which rotates the entire ray group spawned by the explosion. None of the official projectiles use this offset but it's a low-hanging fruit to enable this functionality for modders who can now create complex projectiles.
#324 (0x144) Protection: Immunity to Resource and Message
The name of the correct resource is displayed instead of the name of the resource the effect instance is located in. It now works as intended in 2.6.
New smart feature: It will attempt to identify the name of the parent spell if this effect is located in a child spell with no name. It does in the following manner: if the effect is used within a spell that has no name but there is a spell in the game whose resname is one character shorter with a valid name, then it will display that name. This feature is used in Sunfire (SPWI523D.spl) to check for thief evasion.
This feature will also attempt to look for an identical resname.itm and display that (identified/unidentified) if the .spl the effect is in doesn't have a name.
That's great!
What about adding the possibility to display a custom string if the `Special` field is non-zero? That would be great too...
Comments
It appears to be a permissions issue, Im still trying to sort out.
Similar to @Luke93 I'm unable to add specific file folder access, and I'm not receiving the prompt when the program is opened or installed.
Perhaps older versions aren't prompting correctly? I would try removing old versions of java - https://osxdaily.com/2017/06/16/uninstall-java-mac/ - and then installing the updated version from the link above. Not being able to manually add entries are normal I think since I can only delete entries.
I got Java from the official site, guess I'll try getting it from your URL or via Brew...
[Courtesy of Kjeron] As far as EE games are concerned:
Also op18, Special field is missing.
Moreover, for both op15 and op44, when p2=3 and the effect is applied in SPL/ITM (V1 effects), 'Parameter1 – Value' should turn into 'Unused'...
- BIT2
- BIT31
Moreover, for both V1 and V2 effects, what about turning the Dispel/Resistance attribute into a bit field? IMHO, it'd be more appropriate...For further details (and in case I missed something), please check the IESDP.
Will be added.
That's a good argument. Will be fixed.
Will be fixed.
I agree. Will be fixed.
I thought about turning it into a bitfield several times over the last couple of years. I decided against it since it didn't really improve usability back when only the first two bits were used. With two more flags available I'll think about it again.
Will be fixed.
This is the overly technical name from IESDP. I prefer to use more descriptive names for NI. The current name 'Movement rate check' may not be 100% accurate, but should suffice. I could change it to 'Movement state check' or 'Movement check' though.
op336: Will be fixed. op335: Doesn't 'Special' refer to the Type/Eye Group value of op336?
Will be added.
Yes, saves appear to be affected as well. Will be fixed.
This is a strange opcode with incompatible parameter types between different game engine revisions. In both variants param2 is unused though; will be fixed.
Will be fixed.
Will be fixed.
https://gibberlings3.github.io/iesdp/file_formats/ie_formats/pro_v1.htm
What made the ray functionality less than useful in previous patches was that the rays fired off at a fixed angle. As of 2.6 this is no longer the case. The rays originate either from the origin of the projectile (usually where the caster is standing) if the cone bit is enabled or if the cone bit is disabled, then the rays originate from the explosion point of the parent projectile. The orientation of the first ray is a vector pointing from the origin of the projectile to the destination if the cone bit is enabled. If the cone bit is disabled, then the first ray continues in the same direction as the vector between the origin of the parent projectile (usually the caster) and the explosion point. Subsequent rays are generated in an alternating expanding pattern going from left to right. So an odd number of rays is needed to get them to launch symmetrically unless you rotate the entire ray package by some amount of degrees specified in 0x226 (word).
What is especially cool about this feature is that you can nest different ray projectiles into one another using polar coordinates for launch/destination points. Combine it with several different subspells/child spells and you can pretty much have any shaped area of effect.
Where are these rays used in 2.6?
Lightning Bolt projectile (LIGHTB.pro/IDPRO40.pro) appears to be a traveling projectile that doesn't harm any in its path and then transforms into a "bouncy" projectile that damages all in the same path. The cone bit is disabled and only one ray is launched as the child projectile LIGHTGRN.pro/IDPRO206.pro which uses the same animation as the parent projectile LIGHTB.pro/IDPRO40.pro. The explosion radius is a very large number but that's internally converted into a duration (ticks) as defined by distance/projectile speed of LIGHTGRN.pro/IDPRO206.pro which causes the projectile to travel a certain distance including bouncing around as measured from the destination point.
Spiritual Wrath (IDPRO312.pro) in IWD:EE uses multiple rays (SWRATH.pro) and the cone bit is enabled. So the 4 rays are launched from the caster with the intial ray direction pointing to which the spell is cast. Subsequent rays are generated 90 degrees off of the initial ray.
You can drain charges for a specific item if the resource field is used
#324 (0x144) Protection: Immunity to Resource and Message
The name of the correct resource is displayed instead of the name of the resource the effect instance is located in. It now works as intended in 2.6.
New smart feature: It will attempt to identify the name of the parent spell if this effect is located in a child spell with no name. It does in the following manner: if the effect is used within a spell that has no name but there is a spell in the game who's resname is one character shorter with a valid name, then it will display that name. This feature is used in Sunfire (SPWI523D.spl) to check for thief evasion.
This feature will also attempt to look for an identical resname.itm and display that (identified/unidentified) if the .spl the effect is in doesn't have a name.
1. Open a spell file (say, spin102.spl) and go to the edit tab.
2. Select any field so that it is highlighted (the "Signature" field will do).
3. Click the "Add" button and select "Spell Ability" to add a spell ability.
4. Save the changes to the resource.
5. Refresh the Tree and view the resource you just edited.
Observed: Erroneous "Unused Bytes?" appear at the bottom of the file, as seen in the attached screenshot. If the spell is cast in game, the game crashes.
Expected: There should be no erroneous data added to the file which can cause a crash in the game.
Screenshot of issue:
It's failing to update the "Effects Offset" field when you add an ability header after/below the final one on a spell/item. It doesn't occur when removing ability headers or when adding ability headers before/above the final ability header (or if there are currently 0 ability headers). It was reported back in December on SHS.
Until fixed, add new abilities above/before the existing abilities (by having one of the ability headers selected when pressing "Add...").
I've been using this altered NI version extensively without problems. If there are no merge conflicts I think it's worth it (not sure why Bubb has not sent you pull request yet though)
New features and bugfixes sounds exciting but without EEex support I'm forced to stay on the old one.
From what I've seen it looks fine. Feel free to create a pull request whenever you're ready.
Changelog:
@argent77, IWD2 is missing item and spells usability labels. Correct ones are listed on iesdp: https://gibberlings3.github.io/iesdp/file_formats/ie_formats/itm_v2.0.htm#Kit_Usability
Yes, kit usability in IWD2 items is incorrect. Will be fixed in the next release.
I would like to ask you to investigate the possibility to provide self-contained/ static build of NI. I have no other application which requires Java so it would be great to get rid of it.
The .jar file is the "executable" for a Java application. There may be ways to wrap it in a native Windows executable by third party tools, but I'd be wary about these methods since they could introduce malicious code or compatibility issues.
If you're concerned that the Java Runtime installer installs something that might compromise your system then I'd suggest to use OpenJDK instead. It provides simple zip archives without the need to "install" anything.
Thanks, will be fixed in the next release.
Let me clarify:
Take a look at jpackage, a new standard tool in Java 14 for packaging self-contained Java applications. Example usage is: I'm not asking to deprecate .jar builds, I'm only asking to provide additional build using this official tool so players would only have to download NearInfinity.exe and that's it.
From what I can see `jpackage` creates some kind of installation package for the NearInfinity.jar which has to be installed before NI can be used. The installer itself contains a Java Runtime image that is installed along with NI which adds another 50 MB to the installer file size and requires about 130 MB additional disk space after installation. Moreover, the binary location is fixed to the installation folder.
I don't really see an advantage except that you don't have to install Java separately. The price for this convenience is a considerably higher installation size, the requirement to run a setup whenever you want to install a new NI version (and possibly the inability to install different versions side by side) and the inability to move or copy the NI binary from its installation folder to some other location (like a game folder).
I dug deeper and I found this: https://walczak.it/blog/distributing-javafx-desktop-applications-without-requiring-jvm-using-jlink-and-jpackage
The tool is called 'jlink' and it apparently can create a bundled custom JVM which will be placed alongside the application. Then, you can move the whole NI directory where you want. Running NI would be double-click on .bat file for windows.
Can you give it a last try?
That link describes basically the same just with the addition of `jlink` for optimizing the size of the attached Java Runtime image.
There are wrappers which create Windows executables that can be run directly (e.g. Launch4j), but they are either not maintained anymore or not fully trustworthy. Moreover, these wrappers are likely a good candidate for false alarms from antivirus tools since they contain another executable inside similar to UPX packed executables.
In either case you're always installing a Java Runtime with the application you want to run which eats up a lot of disk space if you want to keep several NI versions around. I don't see a real benefit over installing Java once separately and run JAR files (or only this specific JAR file) afterwards.
The AdoptOpenJDK project can be used to download a pure Java Runtime package with requires much less disk space than the JDK. I'd recommend to use the Java 8 JRE which is the same version NI is build with. It reserves about 95 MB on disk.
You might want to add the following to your to-do list:
The new field (word at 0x226) can be known as "rotate rays CCW CW" which rotates the entire ray group spawned by the explosion. None of the official projectiles use this offset but it's a low-hanging fruit to enable this functionality for modders who can now create complex projectiles.
That's great!
What about adding the possibility to display a custom string if the `Special` field is non-zero? That would be great too...