I'm starting to map creature (CRE) file structure using IESDP and, of course, NI. I've observed that NI doesn't display some data, namely, offsets: - 0x0077 - 0x0078 - 0x0079 - 0x007a - 0x007b - 0x007c Listed as 'Unknown' on IESDP. It doesn't show either all Memorized Spells blocks which leaves a hole between Spell Memorization Info and Items blocks. Is this intended?
The 7 bytes of data starting at offset 0x76 are defined as Unknown in NI. IESDP lists them as "Unknown proficiency", but I haven't seen these bytes used yet. Bytes starting at offset 0x7d are reassigned by the EEs with new functionality.
Can you attach a file that produces this "hole" in the Spell Memorization or Item blocks?
Ah, I see you've put a 7 bytes at this offset, instead of 7 x 1 byte. Since it's not used it doesn't make much of a difference.
As for the file, I was using the first one as a template (25SPELL.CRE). See the gap between offset 4a0 (Memorization Info 16) and 5e8 (Helmet). The other offsets are fine, it's just that the Memorized Spell blocks are not displayed.
As for the file, I was using the first one as a template (25SPELL.CRE). See the gap between offset 4a0 (Memorization Info 16) and 5e8 (Helmet). The other offsets are fine, it's just that the Memorized Spell blocks are not displayed.
That "hole" is a bit misleading. Data in the range 0x4b0...0x5e8 is used for "Memorized Spell" structures which can be found within the "Memorized info" structures for convenience. NI just does a bit of internal reordering in this case.
A "real" hole caused by unassigned or undefined data would be realized by one or more "Unused bytes?" structures, probably appended to the end of the file. I have improved the hole detection routine not too long ago however, so it should only happen for corrupted files in more recent NI releases.
Some more label requests: Opcode 301: Critical Hit Bonus, Opcode 341: Critical Hit Effect, Opcode 361: Critical Miss Effect, & Opcode 362: Critical Miss Bonus
Special Field(SPL/ITM/EFF): 0 : Any Weapon 1 : Melee Weapon Only 2 : Ranged Weapon Only Parameter3(EFF): 0 : Any Weapon 28 : Fists Only
Opcode 178: THAC0 vs. Type bonus, Opcode 179: Damage vs. Type bonus
Some more details on the Special Field for the Critical [Hit/Miss|Bonus/Effects] opcodes. This is matched to the ability type, so if you created a weapon using a Magical(3) ability in a weapon-slot instead of item-slot, a Value of 3 would work for it.
A value of 4 does not work for Launchers, though this wasn't very surprising, since you cannot attack with a Launcher unless it also has a Ranged ability or ammo.
Higher values(5+) also work, provided you create weapons using that number for its ability type. They appear to otherwise function identical to "Melee" or "Magical" abilities, if there is even a difference between those two other than consistency.
Weapons like Throwing Axes with multiple ability types can have separate Critical [Hit/Miss|Bonus/Effects] for their Melee and Ranged attacks. Maybe they could migrate this behavior over to Opcode 1(Modify Attacks per Round).
Weapons like Throwing Axes with multiple ability types can have separate Critical [Hit/Miss|Bonus/Effects] for their Melee and Ranged attacks. Maybe they could migrate this behavior over to Opcode 1(Modify Attacks per Round).
You can always make a feature request and hope for the best.
Hello, I haven't found how to add projectiles to the list of projectiles in NearInfinity, what am I missing ?
It seems that projectiles were non moddable previous to EE, I haven't found a good source of information on how to make new ones. ( it also seems that area of effect targets are tied directly to the projectiles ?)
Use the WeiDU function ADD_PROJECTILE. With it you only have to provide the PRO file. The function takes care of everything else.
Projectiles were always moddable since original BG2, but several aspects were still hardcoded until recently. You can find out more about the PRO format in IESDP. The format description is not up-to-date with the EE patch v2.0 version though.
More Labels: PRO file: offset: 0xc, bit (6) - Do not disable Saving. (as Duration-based AoE's do by default).
Notes: - Active projectiles are not saved to the Area, they are gone upon reloading. Only inactive projectiles(traps) are saved. - The trap flag (Trigger on Condition) also does this, but only while the trap is inactive, once its been triggered, if it can trigger multiple times, saving will be disabled until it has run its course unless this bit is also set.
Bit 9, Currently labeled "Made Save", appears to be functioning as a "Fail for Half", similar to Bit 8's "Save for Half". It's completely redundant though, since if your going to save for nothing or fail for half you may as well just halve the damage your dealing to begin with.
Made save is used internally. There is indeed no point in using it in an editor
Reverse-save effects might have some use for if it were for nondamaging effects but for opcode 12 it is redundant. An example ADnD spell that could use such an eff is the 6th level Phaerimm "Heal Self" spell:
This healing spell is usable only by the phaerimm. When it is cast, a saving throw vs. spell is required. If the throw fails, the casting phaerimm is healed of only 4d8 points of damage (to the limit of damage previously taken). Blindness, poison, weakness, or nausea, however caused, are banished from the phaerimm's body. If the throw succeeds, all damage is healed, including the restoration of full use to broken limbs and damaged organs. All afflictions (including rot grub and other parasitic infestations, diseases such as mummy rot, and even lycanthropy) are ended. In addition, the phaerimm temporarily gains 1 point of Strength, with the applicable bonuses (a phaerimm possessing 18 Strength attains 19 Strength, regardless of any percentile normally possessed). This augmentation lasts for 1 turn, plus 1 round per level. The healing effects of the spell cannot be dispelled, although new damage can be taken.
Made save is used internally. There is indeed no point in using it in an editor
I don't remember the specifics off hand, but I have actually been using it to deal normal damage at half of an odd-valued dice number, with and without a savingthrow sometimes along with bit 8, depending on the effect. So I can just deal half(5d6) instead of 3d6 or 2d6 or 1d13+2. It has been working as I expected , but would this cause any interference with its internal use>?
@lefreut Does the Debug Console show any error messages (open via Tools -> Show Debug Console)?
The PNG conversion routine is VERY memory-demanding. Chances are NI doesn't have enough memory to complete the operation. You can increase the amount of available memory by installing the 64-bit version of the Java Runtime. If you're still running the 32-bit JRE and don't want to upgrade you can try your luck with the "Hide NI DOS" tool found in this post.
@subtledoctor NI uses standard Java functions to load and store preferences. They are all stored using the key "org.infinity.*". The actual storage method is platform-specific. On Mac OS X it should be somewhere under "~/Library/Preferences".
Currently this information is not stored by the respective BAM or MOS decoders. But I can probably add a small "Properties" message box which shows some basic properties of the current BAM or MOS resource, including referenced PVRZ files (either as full filenames or only the pvrz page indices).
Comments
Now to figure out what happens to .d files after a mod is installed...Found them.I've observed that NI doesn't display some data, namely, offsets:
- 0x0077
- 0x0078
- 0x0079
- 0x007a
- 0x007b
- 0x007c
Listed as 'Unknown' on IESDP.
It doesn't show either all Memorized Spells blocks which leaves a hole between Spell Memorization Info and Items blocks.
Is this intended?
Can you attach a file that produces this "hole" in the Spell Memorization or Item blocks?
As for the file, I was using the first one as a template (25SPELL.CRE). See the gap between offset 4a0 (Memorization Info 16) and 5e8 (Helmet).
The other offsets are fine, it's just that the Memorized Spell blocks are not displayed.
A "real" hole caused by unassigned or undefined data would be realized by one or more "Unused bytes?" structures, probably appended to the end of the file. I have improved the hole detection routine not too long ago however, so it should only happen for corrupted files in more recent NI releases.
Opcode 301: Critical Hit Bonus, Opcode 341: Critical Hit Effect, Opcode 361: Critical Miss Effect, & Opcode 362: Critical Miss Bonus Opcode 178: THAC0 vs. Type bonus, Opcode 179: Damage vs. Type bonus
Field name and type for Parameter 3 can't be updated dynamically for technical reasons.
Btw, "28 : Fist only" matches the value from ITEMCAT.IDS. Does that mean you can limit the effect to specific weapon types besides fists?
A value of 4 does not work for Launchers, though this wasn't very surprising, since you cannot attack with a Launcher unless it also has a Ranged ability or ammo.
Higher values(5+) also work, provided you create weapons using that number for its ability type. They appear to otherwise function identical to "Melee" or "Magical" abilities, if there is even a difference between those two other than consistency.
Weapons like Throwing Axes with multiple ability types can have separate Critical [Hit/Miss|Bonus/Effects] for their Melee and Ranged attacks. Maybe they could migrate this behavior over to Opcode 1(Modify Attacks per Round).
Update: NearInfinity v2.0-20160812
Changes:It seems that projectiles were non moddable previous to EE, I haven't found a good source of information on how to make new ones. ( it also seems that area of effect targets are tied directly to the projectiles ?)
Thanks.
Projectiles were always moddable since original BG2, but several aspects were still hardcoded until recently. You can find out more about the PRO format in IESDP. The format description is not up-to-date with the EE patch v2.0 version though.
PRO file:
offset: 0xc, bit (6)
- Do not disable Saving. (as Duration-based AoE's do by default).
Notes:
- Active projectiles are not saved to the Area, they are gone upon reloading. Only inactive projectiles(traps) are saved.
- The trap flag (Trigger on Condition) also does this, but only while the trap is inactive, once its been triggered, if it can trigger multiple times, saving will be disabled until it has run its course unless this bit is also set.
sometimes along with bit 8, depending on the effect.So I can just deal half(5d6) instead of 3d6 or 2d6 or 1d13+2.
It has been working as I expected , but would this cause any interference with its internal use>?
The PNG conversion routine is VERY memory-demanding. Chances are NI doesn't have enough memory to complete the operation. You can increase the amount of available memory by installing the 64-bit version of the Java Runtime. If you're still running the 32-bit JRE and don't want to upgrade you can try your luck with the "Hide NI DOS" tool found in this post.
A quick Google search showed up this page which contains some macOS-specific troubleshooting hints:
https://eclecticlight.co/2016/10/25/preference-settings-where-to-find-them-in-macos-sierra/
Does NI's debug console show anything after starting NI?
Update: NearInfinity v2.0-20161118
Changes:Update: NearInfinity v2.0-20170106
Changes: