A question about formlists

[rlavlfwo0911]

Suppose there is formlist A and add any form by using addformtoformlist function.
After this load mod that revise formlist A.
Then what happens?

Edited April 30, 2019 by rlavlfwo0911

[dubiousintent]

I am not an expert on formlists, but would expect much depends upon how you mean "revise".

 

To the best of my knowledge, the "Rule of One" still applies in this situation: whichever plugin last modifies a record "wins". Form lists can be nested. (See "Scripting Tutorial: Working with FormLists".)

 

However, note the GECKWiki points out for the addformtoformlist function: "Unlike ListAddForm, this function adds the new form at the 0th index, adding 1 to the indices of the other list entries." That strongly implies to me that the nested list (assuming it contains the matching "form") will be the result returned. Most searches stop upon encountering the first match, and do not perform exhaustive searches for all possible matches. (That is usually redundant and time consuming.)

 

I doubt it is possible to have more than one "base form" entry in a given formlist but have not tried to confirm that. However, "nesting" formlists conceivably could get tricky. See function "IsInList" and the "How to Keep Track of Your Records" tutorial.

 

If that does not answer your question, perhaps a bit more detail as to what you are attempting will clarify?

 

-Dubious-

[rlavlfwo0911]

I am not an expert on formlists, but would expect much depends upon how you mean "revise".

 

To the best of my knowledge, the "Rule of One" still applies in this situation: whichever plugin last modifies a record "wins". Form lists can be nested. (See "Scripting Tutorial: Working with FormLists".)

 

However, note the GECKWiki points out for the addformtoformlist function: "Unlike ListAddForm, this function adds the new form at the 0th index, adding 1 to the indices of the other list entries." That strongly implies to me that the nested list (assuming it contains the matching "form") will be the result returned. Most searches stop upon encountering the first match, and do not perform exhaustive searches for all possible matches. (That is usually redundant and time consuming.)

 

I doubt it is possible to have more than one "base form" entry in a given formlist but have not tried to confirm that. However, "nesting" formlists conceivably could get tricky. See function "IsInList" and the "How to Keep Track of Your Records" tutorial.

 

If that does not answer your question, perhaps a bit more detail as to what you are attempting will clarify?

 

-Dubious-

For lack of my English skill I think using example is easier to explain.

 

Form A

Formlist B

Mod C

start game without C -> script add A to B -> save game -> start game with C and load previous game -> C overwrites B -> is A still in B?

[dubiousintent]

I'm assuming "Mod C" is not your creation, but some other author's mod?

 

In that example, "Form A" is probably still present. (It is never a good idea to delete any existing form as that will fatally break anything (DLCs or other mods) that expect to find it).

 

If "Mod C" is done properly, "Form A" will still be present unless "Mod C" uses a function to delete ALL the contents of "Formlist B" or specifically removes/replaces "Form A". So much depends upon how "C overwrites B": "Rule of One".

 

To ensure your "Form A" is added to "Formlist B", your script needs to run each time the game starts in order to add "Form A" (e.g. as a "DoOnce" condition in a "Quest" script. It will/can then run after "Mod C" loads). Do not count upon the "save game" file to preserve additions to a "Formlist".)

 

-Dubious-

[rlavlfwo0911]

I'm assuming "Mod C" is not your creation, but some other author's mod?

 

In that example, "Form A" is probably still present. (It is never a good idea to delete any existing form as that will fatally break anything (DLCs or other mods) that expect to find it).

 

If "Mod C" is done properly, "Form A" will still be present unless "Mod C" uses a function to delete ALL the contents of "Formlist B" or specifically removes/replaces "Form A". So much depends upon how "C overwrites B": "Rule of One".

 

To ensure your "Form A" is added to "Formlist B", your script needs to run each time the game starts in order to add "Form A" (e.g. as a "DoOnce" condition in a "Quest" script. It will/can then run after "Mod C" loads). Do not count upon the "save game" file to preserve additions to a "Formlist".)

 

-Dubious-

I use millenia's script as a reference which stops quest after adding form to formlist.

 

scn scriptname

 

short idoonce

 

begin gamemode

if idoonce == 0

addformtoformlist form formlist

set idoonce to 1

stopquest questname

endif

end

 

So you mean this does not cause problem NORMALLY but can be problematic in rare case?

Edited May 1, 2019 by rlavlfwo0911

[dubiousintent]

That script is doing exactly what I recommended in the last paragraph of the previous reply. (There is no need to use separate quests for each such script in your mod. Just give each "initialization section" it's own unique conditional "DoOnce" check (e.g. iDoOnce-1, iDoOnce-2, etc.) in one quest for that purpose and stop the quest when all the initialization checks are done. However, it is not a good idea to just add it to an existing script provided by anyone else, as you have no control over whether or not that script gets replaced by some author at a later time by an update.)

 

Because the script runs after mods are loaded, "Form A" gets added to "Formlist B" AFTER "Mod C" makes it's changes, unless it uses the same "quest" technique. AFAIK, you have no way to control when your respective scripts run in relation to each other, except possibly by using a "timer" to delay yours. As each Editor-ID is unique, no other script should be doing anything to "Form A" except by design, and that is their problem to work out.

 

However, when both mods use the "quest script" to load their changes, the modified formlist is in the same game session and both sets of changes will be present in it. So only if both attempt to modify "Form A" is there a possibility of a "conflict".

 

-Dubious-

[rlavlfwo0911]

That script is doing exactly what I recommended in the last paragraph of the previous reply. (There is no need to use separate quests for each such script in your mod. Just give each "initialization section" it's own unique conditional "DoOnce" check (e.g. iDoOnce-1, iDoOnce-2, etc.) in one quest for that purpose and stop the quest when all the initialization checks are done. However, it is not a good idea to just add it to an existing script provided by anyone else, as you have no control over whether or not that script gets replaced by some author at a later time by an update.)

 

Because the script runs after mods are loaded, "Form A" gets added to "Formlist B" AFTER "Mod C" makes it's changes, unless it uses the same "quest" technique. AFAIK, you have no way to control when your respective scripts run in relation to each other, except possibly by using a "timer" to delay yours. As each Editor-ID is unique, no other script should be doing anything to "Form A" except by design, and that is their problem to work out.

 

However, when both mods use the "quest script" to load their changes, the modified formlist is in the same game session and both sets of changes will be present in it. So only if both attempt to modify "Form A" is there a possibility of a "conflict".

 

-Dubious-

Thanks for your help. :)