Bash Tagging Best Practices?

[fireundubh]

I'm updating the BASH tags autodetection script that comes with xEdit.
 
The following tags are implemented:

• Actors.AIData
• Actors.AIPackages
• Actors.CombatStyle
• Actors.DeathItem
• C.Climate
• C.Light
• C.Music
• C.Names
• C.Owner
• C.Water
• Delev
• Eyes
• Factions
• Graphics
• Hair
• Invent
• Names
• NPC.Class
• NPC.Race
• R.Description
• R.Relations
• Relev
• Scripts
• Sound
• SpellStats
• Stats

22 more to go!
 
So, now, I get results like this when I run the script:

Applying script...
-------------------------------------------------------------------------------
YUP - Base Game + All DLC.esm:
Added tags to header: 
{{BASH:Actors.AIData,Actors.AIPackages,Actors.DeathItem,C.Climate,C.Light,C.Owner,C.Water,Delev,Factions,Graphics,Hair,Invent,Names,Relev,Scripts,SpellStats,Stats}}
-------------------------------------------------------------------------------
[Apply Script done]  Processed Records: 9089, Elapsed Time: 00:12

I intend to implement support for all tags, but I'd like to know if there are any bash tagging best practices (e.g., what to watch out for, what doesn't matter.)
 
Let me know in this thread.

Edited January 10, 2015 by fireundubh

[EssArrBee]

I'm curious about you list. It says the tag and the record type it looks for or does it go into the sub-record type as well and you just didn't list those?

[fireundubh]

I'm curious about you list. It says the tag and the record type it looks for or does it go into the sub-record type as well and you just didn't list those?

Those tags are generated for those records.

[EssArrBee]

Those tags are generated for those records.

Okay, so the only problem I can really foresee is that some mods would end up getting tags it didn't need.

 

In your example, YUP gets Actor.CombatStyle and SpellStats which I believe are not needed. This can cause an issue if an earlier loading mod changed something and used that same tag, but the bahsed patcher algorithm may take the later loading mod's subrecord because it was tagged.

[fireundubh]

Okay, so the only problem I can really foresee is that some mods would end up getting tags it didn't need.

 

In your example, YUP gets Actor.CombatStyle and SpellStats which I believe are not needed. This can cause an issue if an earlier loading mod changed something and used that same tag, but the bahsed patcher algorithm may take the later loading mod's subrecord because it was tagged.

How do you know when they're needed? I'm just going off zilav's (?) logic in the original script, which is:

 

If the value of an element in the overriding record is different from the value of the same element in the overridden master record, suggest a bash tag.

Edited January 10, 2015 by fireundubh

[EssArrBee]

Ahh, well then zilav is probably making a script that can be used to give an outline of all possible tags, but not really a specific list.

 

It looks like it is more for mod authors to use as a utility for their mods, and after the list is generated they can leave out whatever they know isn't needed.

[fireundubh]

Again though, how do you know whether a tag is needed? 

 

By the way, nothing loads earlier than YUP except ESMs.

 

I'm pretty sure tags exist purely to tell Wrye Bash that "there are differences in this file." How Wrye Bash handles those differences is another story, and LOOT handles load order.

Edited January 10, 2015 by fireundubh

[EssArrBee]

Yeah, YUP was an example, but the example still holds for mods that load late.

 

You tell by looking at sub-record types instead of record types. Look at NPC.Class. It isn't looking at the NPC_ record as a whole to see if it's made a change from it's master, it's looking to see if the CNAM sub-record has been changed.

 

Some tags do purely tell Wrye Bash that there are changes to a record, but most are doing it within the record and only telling the patcher that there is only a part of a record that is different. 

[fireundubh]

You tell by looking at sub-record types instead of record types. Look at NPC.Class. It isn't looking at the NPC_ record as a whole to see if it's made a change from it's master, it's looking to see if the CNAM sub-record has been changed.

That's what the script does.

 

Example:

 

uses mteFunctions; // matortheeternal's library

var
  tag: string;

function CheckActorsAIData(e, m: IInterface): integer;
var
  // a = overriding element, am = its master
  a, am: IInterface;
begin
  // define tag
  tag := 'Actors.AIData';

  // if tag is already in header, exit
  if TagExists(tag) then
    exit;

  // select elements in overriding record and its master
  a := ElementBySignature(e, 'AIDT');
  am := ElementBySignature(m, 'AIDT');

  // if the element exists in one record but not in the other, suggest tag and exit
  if Assigned(a) <> Assigned(am) then begin
    AddTag(tag);
    exit;
  end;

  // if the element doesn't exist at all, exit
  if not Assigned(a) then
    exit;

  // if the properties of the element are different, suggest tag and exit
  if (geev(a, 'Aggression') <> geev(am, 'Aggression'))
  or (geev(a, 'Confidence') <> geev(am, 'Confidence'))
  or (geev(a, 'Energy Level') <> geev(am, 'Energy Level'))
  or (geev(a, 'Responsibility') <> geev(am, 'Responsibility'))
  or (geev(a, 'Buys/Sells and Services') <> geev(am, 'Buys/Sells and Services'))
  or (geev(a, 'Teaches') <> geev(am, 'Teaches'))
  or (geev(a, 'Maximum training level') <> geev(am, 'Maximum training level')) then
    AddTag(tag);
end;

YUP gets Actor.CombatStyle because there are overriding CREA or NPC_ records whose ZNAM elements differ from their masters.

 

YUP also gets SpellStats because there are overriding SPEL records whose FULL or SPIT\Type elements differ from their masters.

 

I'm not sure why you thought I was implementing something different from the bash tags spec.

Edited January 10, 2015 by fireundubh

[EssArrBee]

Alright, then that is good. I thought it might just parse the record and see if any part was changed and then apply tags for that record type. going into the sub-records that make up every record is really what the bashed patch was created for. It will return a lot less false positives, probably a negligible amount.

 

I think we were crossed up because you just listed the record type in the OP, but bash tags start with a record and go into the sub-records that make them up.