Marty and I are working it on... we've noticed some patterns here, but it's too early to write a specific function for it. Our latest discussion and cross examination through multiple files seems to point to have to do with the order of entities at the same abstraction level.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The key here (so to speak) is whether the values in this field constitute "information", and in particular if the NWN clients, server or tools use the values in any way.
This is something that Bioware could answer, even if they don't tell us what that use is.
Failing that, the experiment would be to modify said code fields and see if it impacts performance in any way.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is this so, Eyrdan?
I know that it is consistent with that, but is it required. By that, I mean, the codes could be "coincidentally" the same as the ID, rather than *defining* the ID.
A way to check? Edit the codes and move them around and see what impact it has on the various factions.
Did you do your experiment of a deleted faction, by the way?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It appears to me that the code stays the same no matter what is changed, though I may not be looking in the right places.
Can anyone confirm or deny this?
Perhaps it is just used internally as a sanity check or something. If that's the case I guess I'll just have to build a table of entry codes. But that also means that a generic plist2itp function may not be possible unless the specific type of itp is passed...
I'll fool around changing them and see what all breaks. It sure would be nice if it's mostly useless.
Has anyone asked bioware what the heck it is?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
looks like the entry code on creature's equipment tells where the item is equipped:
list Equip_ItemList
BEGIN ITEM 0
# Code for entry 37: 0x2
resref EquippedRes "nw_aarcl008"
BEGIN ITEM 1
# Code for entry 38: 0x10
resref EquippedRes "nw_wswgs001"
END list Equip_ItemList
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here are the entry codes I've extracted from my module.
root entry always appears to be 0xffffffff
Creatures:
Skill List: Always 0x0
Feat List: Always 0x1
Class List: Always 0x2
Memorized sublist of class list: Always 0x3
SpecAbilityList: always 0x04
Equip List: depends on where equipped, more to come
ItemList: increases by 1 for each item, starting at 0x0
GIT:
Area Properties: 0x64
Creature List: 0x4
(other creature entry codes seem to match UTC)
(except ItemList and Equip_ItemList: where the item is defined within the list)
Door List: 0x8
Waypoint List: 0x5
Placeable List: 0x9
itemlist sublist of placeable (inventory): 0x0, rest match UTI
list List: 0x0 (wtf? appears to be items on the ground)
triggerlist: 0x01
triggerlist geometry sublist: 0x03
Items:
PropertiesList: always 0x0
creaturepalcus.itp: All 0x0 (except root of course)
doorpalcus.itp: as above
encounterpalcus.itp: as above
itempalcus.itp: as above
placeablepalcus.itp: as above
aoundpalcus.itp: as above
storepalcus.itp: as above
triggerpalcus.itp: as above
waypointpalcus.itp: as above
module.ifo:
mod_area_list: 0x6
mod_hak_list: 0x8
module.jrl:
not sure. seems to increase by 1 starting at 0x0 for both the Categories list and the EntryList sublist
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
so clearly from the above a generic plist2itp function may not be feasable. I guess I can compare the list varname to a list of codes, which is what I suppose I will do for now, but doing that seems to lend some inflexibility to it...
any other place it could be implemented? perhaps storing the codes in the nwn_object, hence allowing the user to change them if he really really wanted to?
mebbe I'll hack up some code to generate the above from every nwn resource on my disk... That should be a good reference, as I'm sure I've missed some things.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, I've extracted all the itp entry codes from the official campaign and sorted and compressed them into something useful. Repute.fac and *.dlg are junk, but perhaps something can be learned from the rest of it.
Has anybody figured out what the "code" means in the first array of values in the ITP file format? (This is the first array just after the header).
I never could figure out what in the world this could be.
Marty and I are working it on... we've noticed some patterns here, but it's too early to write a specific function for it. Our latest discussion and cross examination through multiple files seems to point to have to do with the order of entities at the same abstraction level.
The key here (so to speak) is whether the values in this field constitute "information", and in particular if the NWN clients, server or tools use the values in any way.
This is something that Bioware could answer, even if they don't tell us what that use is.
Failing that, the experiment would be to modify said code fields and see if it impacts performance in any way.
Well I've seen in the Repute.fac file that this information IS necessary (used to determine the ID of each faction).
Is this so, Eyrdan?
I know that it is consistent with that, but is it required. By that, I mean, the codes could be "coincidentally" the same as the ID, rather than *defining* the ID.
A way to check? Edit the codes and move them around and see what impact it has on the various factions.
Did you do your experiment of a deleted faction, by the way?
I haven't tried experimenting yet, been too busy with the move... also now that I got myself the linux client I started playing it a bit again. :)
It appears to me that the code stays the same no matter what is changed, though I may not be looking in the right places.
Can anyone confirm or deny this?
Perhaps it is just used internally as a sanity check or something. If that's the case I guess I'll just have to build a table of entry codes. But that also means that a generic plist2itp function may not be possible unless the specific type of itp is passed...
I'll fool around changing them and see what all breaks. It sure would be nice if it's mostly useless.
Has anyone asked bioware what the heck it is?
looks like the entry code on creature's equipment tells where the item is equipped:
list Equip_ItemList
BEGIN ITEM 0
# Code for entry 37: 0x2
resref EquippedRes "nw_aarcl008"
BEGIN ITEM 1
# Code for entry 38: 0x10
resref EquippedRes "nw_wswgs001"
END list Equip_ItemList
Here are the entry codes I've extracted from my module.
root entry always appears to be 0xffffffff
Creatures:
Skill List: Always 0x0
Feat List: Always 0x1
Class List: Always 0x2
Memorized sublist of class list: Always 0x3
SpecAbilityList: always 0x04
Equip List: depends on where equipped, more to come
ItemList: increases by 1 for each item, starting at 0x0
Dialog: Seems to depend on linkage
Area:
Tilelist: always 0x1
GIC:
placeablelist: always 0x9
waypointlist: 0x5
creaturelist: 0x4
encounterlist: 0x0
doorlist: 0x8
GIT:
Area Properties: 0x64
Creature List: 0x4
(other creature entry codes seem to match UTC)
(except ItemList and Equip_ItemList: where the item is defined within the list)
Door List: 0x8
Waypoint List: 0x5
Placeable List: 0x9
itemlist sublist of placeable (inventory): 0x0, rest match UTI
list List: 0x0 (wtf? appears to be items on the ground)
triggerlist: 0x01
triggerlist geometry sublist: 0x03
Items:
PropertiesList: always 0x0
creaturepalcus.itp: All 0x0 (except root of course)
doorpalcus.itp: as above
encounterpalcus.itp: as above
itempalcus.itp: as above
placeablepalcus.itp: as above
aoundpalcus.itp: as above
storepalcus.itp: as above
triggerpalcus.itp: as above
waypointpalcus.itp: as above
module.ifo:
mod_area_list: 0x6
mod_hak_list: 0x8
module.jrl:
not sure. seems to increase by 1 starting at 0x0 for both the Categories list and the EntryList sublist
so clearly from the above a generic plist2itp function may not be feasable. I guess I can compare the list varname to a list of codes, which is what I suppose I will do for now, but doing that seems to lend some inflexibility to it...
any other place it could be implemented? perhaps storing the codes in the nwn_object, hence allowing the user to change them if he really really wanted to?
mebbe I'll hack up some code to generate the above from every nwn resource on my disk... That should be a good reference, as I'm sure I've missed some things.
Ok, I've extracted all the itp entry codes from the official campaign and sorted and compressed them into something useful. Repute.fac and *.dlg are junk, but perhaps something can be learned from the rest of it.
http://leaf.ultrasoul.com/itp-codes.txt
This information has been added to OKDocs. Along with plenty of Issues to puzzle over. :)
Thanks, nice work.