Looks like I'm one release behind (The macOS version is on 2.1-20180531, the latest release is 2.1-20180615). I guess I missed it when @argent77 released it. I'll get an update out.
@argent77 Would it be very hard and time consuming to adapt NI for high resolution displays? Everything is just too small, and even I tried many things like external manifest files for java.exe and javaw.exe, nothing worked...
@argent77 Would it be very hard and time consuming to adapt NI for high resolution displays? Everything is just too small, and even I tried many things like external manifest files for java.exe and javaw.exe, nothing worked...
I've looked into the very same issue several times in the past. Unfortunately the GUI toolkit used by NI doesn't support DPI-aware scaling. However, I tried to work around it with some bits of hackery. You can use menu Options > "Change Global Font Size" to adapt text size to your needs. In many cases this will also affect surrounding UI elements.
Afaik Java 9 introduced some kind of DPI-awareness, so you could try out the latest Java Runtime (JRE). I don't know if it's already available as a standalone user package though. You might have to download and install the Java Development Kit (JDK) instead (link), which also provides the necessary binaries.
Both TRUECLASS and MAGESCHOOL_GENERALIST are defined with the same numeric id (0x4000). NI picks one or the other depending on row order of these entries in KIT.IDS. It shouldn't make a difference for the games, since they use the numeric values directly.
Another label, as a recent thread just reminded me:
Opcode 109 (Paralyze):
Special Field:
Zero: Normal
Non-zero: False Petrify
In addition to the normal paralyze effect, it maintains a detectable STATE_STONE_DEATH and the stone overlay, but does not directly kill, award exp, or chunk when attacked. Only functions like this against non-party members.
Against party members, it functions as normal, unless you save and reload while the effect is active, upon reloading, the stone overlay will be applied and the character will be dropped to 0 hit points, but not killed, and no STATE_STONE_DEATH. Suspect this alternate behavior is to avoid kicking the character from the party.
Another label, as a recent thread just reminded me:
Opcode 109 (Paralyze):
Special Field:
Zero: Normal
Non-zero: False Petrify
In addition to the normal paralyze effect, it maintains a detectable STATE_STONE_DEATH and the stone overlay, but does not directly kill, award exp, or chunk when attacked. Only functions like this against non-party members.
Against party members, it functions as normal, unless you save and reload while the effect is active, upon reloading, the stone overlay will be applied and the character will be dropped to 0 hit points, but not killed, and no STATE_STONE_DEATH. Suspect this alternate behavior is to avoid kicking the character from the party.
Another label:
Opcode 24 (Panic):
Parameter2:
Zero: Normal
Non-zero: Bypass opcode 101 (Immunity to effect). (Used by Turn Undead against Paladin's)
Looks like I'm one release behind (The macOS version is on 2.1-20180531, the latest release is 2.1-20180615). I guess I missed it when @argent77 released it. I'll get an update out.
No rush! My current mac versions are on a 2016 build. I just don't remember where to find them...
EDIT - duh, it's on the first post of this thread. Cheers mates
@subtledoctor - Updated to the latest nearinfinity.jar file.
I'm wondering why IESDP and NI insist that CREv1 stores kit as long value (dword) at 0x244 offset rather than short value at 0x246 (leaving the first 2 bytes as unused). From what I understand the first 2 bytes are always 0 since there are other places that reference kits that only use short values (IDS targeting in PRO files). Current implementation results in confusion what numbers are actually associated with kits (example: editing values as numbers by hand in NI). NI clearly displays the kit numbers in preview window as short values (unless I missed something)
I'm wondering why IESDP and NI insist that CREv1 stores kit as long value (dword) at 0x244 offset rather than short value at 0x246 (leaving the first 2 bytes as unused). From what I understand the first 2 bytes are always 0 since there are other places that reference kits that only use short values (IDS targeting in PRO files). Current implementation results in confusion what numbers are actually associated with kits (example: editing values as numbers by hand in NI). NI clearly displays the kit numbers in preview window as short values (unless I missed something)
Two kits: Barbarian, Wildmage.
Kit values are 4 bytes, even if the rest only utilize the first 2.
It's confusing because the CRE file stores kit ID half-backwards:
In KITIDS, TrueClass is: 0x00004000, Barbarian is: 0x40000000
In a CRE, Trueclass is: 0x40000000, Barbarian is: 0x00004000
Every other KIT field follows KITIDS format.
The IDS targeting in PRO files is the limited exception, and cannot target those kits. It also cannot target half of the creature STATEs for the same reason.
[PRO] I have a question about BIT4 (Face target, offset 0x002a): what does it refer? Does it mean that my SPL will land on the target only if I'm facing it directly?
@argent77 I've discovered something quite obvious in NI that IDK if it is a bug or I am misunderstanding something: the saving throw.
#1 Open any effect in any spell
#2 Go to saving throw
#3 Check the numbers presented by NI
Expected behavior: the numbers be the same that one would have to input in Weidu to determine a saving (generic example savingthrow = 4 for Death)
Observed behavior: the number have their own logic (Spells = 0, Death = 2) that doesn't reflect the info that needs to be input in Weidu (unlike DLTCEP).
Probably I'm misunderstanding what those numbers means but they are kind of misleading as in a rule of thumb the values displayed by NI = what needs to go to Weidu (NI saved my life with Opcode 324 countless times lol).
[PRO] I have a question about BIT4 (Face target, offset 0x002a): what does it refer? Does it mean that my SPL will land on the target only if I'm facing it directly?
It's needed to orient the explosion animation VVC in the direction of casting, for spell such as Wall of Moonlight. It's a visual only flag.
Expected behavior: the numbers be the same that one would have to input in Weidu to determine a saving (generic example savingthrow = 4 for Death)
Observed behavior: the number have their own logic (Spells = 0, Death = 2) that doesn't reflect the info that needs to be input in Weidu (unlike DLTCEP).
Those are bits.
BIT0 = Spells
BIT1 = Breath
BIT2 = Death
BIT3 = Wand
BIT4 = Poly
Each of them is a separate flag, and can be combined, along with the others:
BIT10: Ignore primary target
BIT11: Ignore secondary target
BIT24: Bypass Mirror Image
BIT25: Ignore Difficulty
Weidu predefines those variables (BIT0, BIT1, BIT2, ...) to their integer value for use.
BIT0 = 1
BIT1 = 2
BIT2 = 4
BIT3 = 8
BIT4 = 16
...
Comments
Guess it's up to @AstroBryGuy .........
The promised feedback: Using the previous version of NI made the palette thing work like a charm.
Thank you!
Afaik Java 9 introduced some kind of DPI-awareness, so you could try out the latest Java Runtime (JRE). I don't know if it's already available as a standalone user package though. You might have to download and install the Java Development Kit (JDK) instead (link), which also provides the necessary binaries.
Let's say I have a BAM that is 100x100 px and I want to reduce it to 64 x 64. How do I do it?
Thanks!
And don't forget to tick Adjust center position.
You can keep Nearest neighbor setting. For such a small bam, it does not really matter.
Opcode 109 (Paralyze):
Special Field:
Opcode 24 (Panic):
Parameter2:
@subtledoctor - Updated to the latest nearinfinity.jar file.
https://github.com/AstroBryGuy/NearInfinity-OSX/releases/tag/v2.1-20180615
Let's say I want to know all items that provide Free Action while equipped. Possible?
Thanks.
or
Extended Search (Crrl-Alt-X) : Items > Item ability > Set options > Effects opcodes > Set options > equipped effect
Only applies to opcode 12 AFAIK.
Kit values are 4 bytes, even if the rest only utilize the first 2.
It's confusing because the CRE file stores kit ID half-backwards:
In KITIDS, TrueClass is: 0x00004000, Barbarian is: 0x40000000
In a CRE, Trueclass is: 0x40000000, Barbarian is: 0x00004000
Every other KIT field follows KITIDS format.
The IDS targeting in PRO files is the limited exception, and cannot target those kits. It also cannot target half of the creature STATEs for the same reason.
#1 Open any effect in any spell
#2 Go to saving throw
#3 Check the numbers presented by NI
Expected behavior: the numbers be the same that one would have to input in Weidu to determine a saving (generic example savingthrow = 4 for Death)
Observed behavior: the number have their own logic (Spells = 0, Death = 2) that doesn't reflect the info that needs to be input in Weidu (unlike DLTCEP).
Probably I'm misunderstanding what those numbers means but they are kind of misleading as in a rule of thumb the values displayed by NI = what needs to go to Weidu (NI saved my life with Opcode 324 countless times lol).
Well, I think it worth a report/feedback.
Cheers!
BIT0 = Spells
BIT1 = Breath
BIT2 = Death
BIT3 = Wand
BIT4 = Poly
Each of them is a separate flag, and can be combined, along with the others:
BIT10: Ignore primary target
BIT11: Ignore secondary target
BIT24: Bypass Mirror Image
BIT25: Ignore Difficulty
Weidu predefines those variables (BIT0, BIT1, BIT2, ...) to their integer value for use.
BIT0 = 1
BIT1 = 2
BIT2 = 4
BIT3 = 8
BIT4 = 16
...
BIT0 = 1 is equivalent to 2^0 = 1
BIT1 = 2 is equivalent to 2^1 = 2
BIT2 = 4 is equivalent to 2^2 = 4
And so forth......
Thanks @kjeron and @Luke93