Thanks for the replies. This came about when trying to bring an item from iwd2 into bg2ee. Currently, in NI in iwd2 you can use modifier type Increment (0) or Set (1), whereas in NI with bg2ee opened, there's no modifier type option.
So if I set the value to say 20 - this will increment resistance by 20. Perhaps the iwd2 engine added a feature to both increment and set?
I think it may be a good idea to make splprot.2da description labels less confusing:
0x103: match entries x or y - description is fine, to block/apply spell either x or y must return true (or both) 0x104: Not match entries x or y - I'd suggest using "and" instead of "or" in this case. To block/apply spell both x and y must return false
I think it may be a good idea to make splprot.2da description labels less confusing:
0x103: match entries x or y - description is fine, to block/apply spell either x or y must return true (or both) 0x104: Not match entries x or y - I'd suggest using "and" instead of "or" in this case. To block/apply spell both x and y must return false
Speaking of splprot.2da, do you know the correct value for AREATYPE != specified value ?
AREATYPE is defined as a bitfield, so it's required to check for matching bits. This splprot.2da entry should return true only if none of the areatype flags specified by parameter1 of the opcode are set:
NOTAREA 0x106 -1 9
A detailed description of available pseudo-stats can be found here.
Btw, AREATYPE does only work correctly in patch 2.5 or higher.
Speaking of splprot.2da, do you know the correct value for AREATYPE != specified value ?
AREATYPE is defined as a bitfield, so it's required to check for matching bits. This splprot.2da entry should return true only if none of the areatype flags specified by parameter1 of the opcode are set:
NOTAREA 0x106 -1 9
So, it's basically like ALIGNMENT bit_uneq specified value, right?
NOTALIGNMN 0x110 -1 9
Still, I don't understand how to set up parameter2 of opcode 318/324 (for the record, I'm interested in AREATYPE != FOREST.....) For example, why ALIGNMENT bit_uneq specified value is 118 (decimal)?
Param2 of opcode 318/324/326 refers to the row number of splprot.2da entries. So if you add a new definition to splprot.2da, you will also have to determine the row number of the new entry.
An issue with the script reader: These compile correctly: Spell("",WIZARD_SPOOK)
Spell([ANYONE],WIZARD_SPOOK)
SpellPoint([0.0],WIZARD_GREASE)But when reopening the file, NI incorrectly decompiles them as such: SpellRES("",[ANYONE])
SpellRES("",[ANYONE])
SpellPointRES("",[0.0])And will re-compile these actions instead of the original. It only appears to be an issue with actions that have a RES variant, switching an empty/zero target/object for an empty RES field.
The first variant is indistinguishable from the second, since both will produce the same bytecode. However, they should be properly detected as non-RES variants by the decompiler.
Param2 of opcode 318/324/326 refers to the row number of splprot.2da entries. So if you add a new definition to splprot.2da, you will also have to determine the row number of the new entry.
Got it, thanks.
However, what are the possibilities here? Is it possible to add the condition "No ongoing combat" ?
Also, if the references function could search the various .menu files as well, I think it would be helpful to modders.
MENU files are not parsed by NI, so adding this file type to the reference searcher might lead to occasional false positives, and the results list wouldn't show exact position of a match. I'll add it to my todo list though.
Is the "Find References" function for .PVRZ working in the current build, and taking files in override into account?
When looking at some PVRZ images that have corresponding v2 MOS files, find references has yet to find any of those MOS files.
It works for me, even with files in the override folder. Make sure "Options -> Ignore Overrides" isn't enabled.
That's so strange. If you look at BOX5B.MOS, in my (modded w/ Lef's UI mod), it points to MOS4290.pvrz. If I run a reference search on MOS4290.pvrz, it doesn't find BOX5B.
I've tested the same file with lefreut's UI and it worked correctly in both ways. Does the debug console (Tools > Show Debug Console) show something unusual after the reference search?
I've tested the same file with lefreut's UI and it worked correctly in both ways. Does the debug console (Tools > Show Debug Console) show something unusual after the reference search?
Ding ding ding! It didn't find any references for MOS4291, but it did find find references for MOS4009. Both searches generated these errors related to invalid bams. I wonder if this is related to my problem with some BAMs.
There might not be a problem with the lack of hits on 4291, I realized I replaced BOX5B.MOS with a .PNG, so if that was the only file that used 4291 then the lack of hits is correct. Did you get more than one hit for it?
Yeah, some of the BAM files appear to be corrupted on your side. It shouldn't influence the search process though. I did get only a single hit for MOS4291, so if you replaced the MOS by a PNG, then the lack of hits is correct.
Don't know if it has been already reported, but the latest BAM converter appears to have a palette regression. When loading BAM v1 files, the shadow index is always moved to the last index (#255). Does not appear with v2-1-2018.05.31.
Feature request: when I go to an area file and select a container trap detection difficulty and then use the find > selected attribute feature, I can search for e.g. all values >0 and then sort the results. The problem is that these appear to be an alphabetical sort on a numerical field, e.g. the list will be sorted 1, 10, 100, 15, 19, 20, 30, 40, etc. Perhaps it's because the field itself is actually populated with 'Trap detection difficulty=1' but it would be nice to get a true ascending/descending sort.
@argent77: I think I just stumbled a cross a bug -
Near Infinity, built from the latest master branch, is producing this error when attempting to "Find => references to this entry". It looks like attempting to find references to a string from anywhere in NI will throw this exception.
Exception in thread "AWT-EventQueue-0" java.lang.IllegalArgumentException: 'query' must not be null at org.infinity.search.ReferenceHitFrame.(Unknown Source) at org.infinity.search.AbstractReferenceSearcher.(Unknown Source) at org.infinity.search.AbstractReferenceSearcher.(Unknown Source) at org.infinity.search.StringReferenceSearcher.(Unknown Source) at org.infinity.gui.StringEditor$Listeners.itemStateChanged(Unknown Source) at java.desktop/javax.swing.AbstractButton.fireItemStateChanged(AbstractButton.java:1995) at org.infinity.gui.ButtonPopupMenu.menuItemSelected(Unknown Source) at org.infinity.gui.ButtonPopupMenu.access$200(Unknown Source) at org.infinity.gui.ButtonPopupMenu$PopupItemListener.mouseReleased(Unknown Source) at java.desktop/java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:298) at java.desktop/java.awt.Component.processMouseEvent(Component.java:6632) at java.desktop/javax.swing.JComponent.processMouseEvent(JComponent.java:3342) at java.desktop/java.awt.Component.processEvent(Component.java:6397) at java.desktop/java.awt.Container.processEvent(Container.java:2263) at java.desktop/java.awt.Component.dispatchEventImpl(Component.java:5008) at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2321) at java.desktop/java.awt.Component.dispatchEvent(Component.java:4840) at java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4918) at java.desktop/java.awt.LightweightDispatcher.processMouseEvent(Container.java:4547) at java.desktop/java.awt.LightweightDispatcher.dispatchEvent(Container.java:4488) at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2307) at java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2772) at java.desktop/java.awt.Component.dispatchEvent(Component.java:4840) at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:772) at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721) at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:95) at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:745) at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:743) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85) at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742) at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203) at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
I couldn't reproduce this error on my system. Does the error message occur reliably when you perform the search? Do you get any results?
Edit: I can provoke this error with a binary compiled from the latest development branch code. There are currently lots of changes being made internally, and more are in the works. I would strongly recommend to stick with the latest official release, unless you really need any of the new features.
Yes, the error occurs 100% of the time. And actually, the error occurs before I can even attempt the search, (the following window doesn't appear for me on the affected versions):
I tested a bunch of the recent commits, and it was this one that introduced the bug for me.
Edit: Ah, I just saw your edit. Yeah, I'll stick to the official release until things iron out And DUH, I accidently said master branch when I meant devel. Sorry for wasting your time argent -
Comments
So if I set the value to say 20 - this will increment resistance by 20. Perhaps the iwd2 engine added a feature to both increment and set?
0x103: match entries x or y - description is fine, to block/apply spell either x or y must return true (or both)
0x104: Not match entries x or y - I'd suggest using "and" instead of "or" in this case. To block/apply spell both x and y must return false
Speaking of splprot.2da, do you know the correct value for AREATYPE != specified value ?
AREATYPE is defined as a bitfield, so it's required to check for matching bits. This splprot.2da entry should return true only if none of the areatype flags specified by parameter1 of the opcode are set: A detailed description of available pseudo-stats can be found here.
Btw, AREATYPE does only work correctly in patch 2.5 or higher.
NOTALIGNMN 0x110 -1 9Still, I don't understand how to set up parameter2 of opcode 318/324 (for the record, I'm interested in AREATYPE != FOREST.....) For example, why ALIGNMENT bit_uneq specified value is 118 (decimal)?
These compile correctly:
Spell("",WIZARD_SPOOK) Spell([ANYONE],WIZARD_SPOOK) SpellPoint([0.0],WIZARD_GREASE)But when reopening the file, NI incorrectly decompiles them as such:SpellRES("",[ANYONE]) SpellRES("",[ANYONE]) SpellPointRES("",[0.0])And will re-compile these actions instead of the original.It only appears to be an issue with actions that have a RES variant, switching an empty/zero target/object for an empty RES field.
The first variant is indistinguishable from the second, since both will produce the same bytecode. However, they should be properly detected as non-RES variants by the decompiler.
However, what are the possibilities here? Is it possible to add the condition "No ongoing combat" ?
When looking at some PVRZ images that have corresponding v2 MOS files, find references has yet to find any of those MOS files.
Also, if the references function could search the various .menu files as well, I think it would be helpful to modders.
MENU files are not parsed by NI, so adding this file type to the reference searcher might lead to occasional false positives, and the results list wouldn't show exact position of a match. I'll add it to my todo list though.
There might not be a problem with the lack of hits on 4291, I realized I replaced BOX5B.MOS with a .PNG, so if that was the only file that used 4291 then the lack of hits is correct. Did you get more than one hit for it?
@Gwendolyne Can you give me a repro case? Does it help to make changes in the bam converter options?
Near Infinity, built from the latest master branch, is producing this error when attempting to "Find => references to this entry". It looks like attempting to find references to a string from anywhere in NI will throw this exception.
1. Open clean BG2EE with NI
2. Edit -> String table.
3. Strref: 14027.
4. Find... -> references to this entry
Nothing happens, and the exception is thrown. Here's a ss of the offending screen:
Edit: I can provoke this error with a binary compiled from the latest development branch code. There are currently lots of changes being made internally, and more are in the works. I would strongly recommend to stick with the latest official release, unless you really need any of the new features.
I tested a bunch of the recent commits, and it was this one that introduced the bug for me.
Edit: Ah, I just saw your edit. Yeah, I'll stick to the official release until things iron out