View Single Post
Old 08-29-2007, 07:03 PM   #245
stoffe
Mostly dormant
 
stoffe's Avatar
 
Status: Administrator
Join Date: Apr 2002
Posts: 5,834
Helpful! 10 year veteran! Notable contributor 
Quote:
Originally Posted by Kristy Kistic
From what I gather, if the parent of the branch you want to add is an entry the Path var would be EntryList\<entry#>\RepliesList

What is the Path var syntax if the parent is a reply?
What is the Path var syntax if the branch you want to add is in the StartingList?
The RepliesList field under each Entry struct in the EntryList contains an index link to a struct in the ReplyList for each Reply that comes below that Entry.

The EntriesList field under each Reply struct in the ReplyList contains an index link to a struct in the EntryList for each Entry that comes below that Reply.

So, to add a new Reply node below an existing Entry in the DLG file, you find the list index of the parent Entry (#) within the EntryList and set the parent like EntryList\#\RepliesList for your new node.

To add a new Entry node below an existing Reply in the DLG file you find the list index of the parent Reply (#) within the ReplyList and set the parent like ReplyList\#\EntriesList for your new node.

Consequently, since the patcher needs to know the index of the parent node in the ReplyList or EntryList this means the patching will fail if the user has a heavily modified version of the DLG file in their install destination (override or ERF/RIM file) since those indexes may no longer exist, or they may have been renumbered if a DLG editor that doesn't preserve the indexing order of the nodes was used to modify it.

In other words this isn't as safe to do as for example TLK or 2DA patching since it assumes a certain structure of the source file but has no way of verifying if this actually is the case, but in the instances that it does work it should save the user some trouble having to merge things manually.


Quote:
Originally Posted by Kristy Kistic
One last thing. I noticed you pretty much hard coded the entry and reply indexes into the changes.ini file.
If you mean the Value of the Index fields those aren't really hardcoded, since the values assigned when the fields are created will be overwritten further down, during the convoluted modifying of the fields that have been added before.

For example, if you look at these modifiers (relevant parts highlighted):
Code:
[gff_kreia_Index_0]
FieldType=DWORD
Label=Index
Value=738
2DAMEMORY8=!FieldPath


[gff_kreia_ReplyList_738_0]
FieldType=Struct
Path=ReplyList
Label=
TypeId=ListIndex
AddField0=gff_kreia_Listener_3
AddField1=gff_kreia_AnimList_3
AddField2=gff_kreia_Text_3
AddField3=gff_kreia_VO_ResRef_3
AddField4=gff_kreia_Script_3
AddField5=gff_kreia_Delay_3
AddField6=gff_kreia_Comment_3
AddField7=gff_kreia_Sound_3
AddField8=gff_kreia_Quest_3
AddField9=gff_kreia_PlotIndex_3
AddField10=gff_kreia_PlotXPPercentage_3
AddField11=gff_kreia_WaitFlags_3
AddField12=gff_kreia_CameraAngle_3
AddField13=gff_kreia_FadeType_3
AddField14=gff_kreia_EntriesList_0
AddField15=gff_kreia_SoundExists_3
AddField16=gff_kreia_ActionParam1_3
AddField17=gff_kreia_ActionParam1b_3
AddField18=gff_kreia_ActionParam2_3
AddField19=gff_kreia_ActionParam2b_3
AddField20=gff_kreia_ActionParam3_3
AddField21=gff_kreia_ActionParam3b_3
AddField22=gff_kreia_ActionParam4_3
AddField23=gff_kreia_ActionParam4b_3
AddField24=gff_kreia_ActionParam5_3
AddField25=gff_kreia_ActionParam5b_3
AddField26=gff_kreia_ActionParamStrA_3
AddField27=gff_kreia_ActionParamStrB_3
AddField28=gff_kreia_AlienRaceNode_3
AddField29=gff_kreia_CamVidEffect_3
AddField30=gff_kreia_Changed_3
AddField31=gff_kreia_Emotion_3
AddField32=gff_kreia_FacialAnim_3
AddField33=gff_kreia_NodeID_3
AddField34=gff_kreia_NodeUnskippable_3
AddField35=gff_kreia_PostProcNode_3
AddField36=gff_kreia_RecordNoOverri_3
AddField37=gff_kreia_RecordVO_3
AddField38=gff_kreia_Script2_3
AddField39=gff_kreia_VOTextChanged_3
AddField40=gff_kreia_CameraID_3
AddField41=gff_kreia_RecordNoVOOverri_3
2DAMEMORY7=ListIndex


[kreia.dlg]
AddField0=gff_kreia_RepliesList_3_0
AddField1=gff_kreia_EntryList_627_0
AddField2=gff_kreia_EntryList_628_0
AddField3=gff_kreia_EntryList_629_0
AddField4=gff_kreia_ReplyList_738_0
AddField5=gff_kreia_ReplyList_739_0
AddField6=gff_kreia_ReplyList_740_0
2DAMEMORY2=2DAMEMORY1
2DAMEMORY4=2DAMEMORY3
2DAMEMORY6=2DAMEMORY5
2DAMEMORY8=2DAMEMORY7
2DAMEMORY10=2DAMEMORY9
2DAMEMORY12=2DAMEMORY11
In the first one, the line 2DAMEMORY8=!FieldPath stores the full field path to the new Reply-link node that was just added in the 2DAMEMORY8 token (needed since you don't know beforehand what list index it will end up as).

In the second one, the line 2DAMEMORY7=ListIndex stores the list index the new struct that is inserted ends up as in the ReplyList in the 2DAMEMORY7 token.

In the third one, the line 2DAMEMORY8=2DAMEMORY7 links these two stored pieces of info together. It assigns the value in the 2DAMEMORY7 token (the list index) to the field at the path stored in the 2DAMEMORY8 token.

For example, say that the RepliesList link to your new Reply node that is added to entry 587 in the EntryList gets added as EntryList\587\RepliesList\4\Index. And that your new reply node struct added to the ReplyList (which the previous link should point to) gets added at list index 600 in the Reply List.

Then the third highlighted modifier above would read, when parsed by the patcher:
Assign the value 600 to the field EntryList\587\RepliesList\4\Index

Thus the initial value that was assigned when the Index field was created above (738) would be overwritten by the actual value (600) soon afterwards, and it's no longer hardcoded but dynamic.

Very convoluted and primitive, but at least it works (in the cases I've tested) until someone can figure out a better way of doing it.

(Wish I had used XML instead of INI as format for the patcher config file back when I first made it. Would have made it a lot easier to structure this sort of thing logically in the configuration. )


mt

Last edited by stoffe; 08-29-2007 at 11:08 PM.
stoffe is offline   you may: quote & reply,