Jump to content

Recommended Posts

Posted

v1.3.6 is up.

  • Added init prompt: yes = write tags to header, no = suggest tags only, abort = terminate script
  • Destructible: Fixed error when the DEST element doesn't exist in the master record
Posted (edited)

 

[2] Graphics:  \ [04] Better Dynamic Snow.esp \ [1] GRUP Top "STAT" \ [753] Barrel02Static_HeavySN [STAT:0010EAF1] \ [3] Model
[2] Graphics:  \ [00] Skyrim.esm \ [31] GRUP Top "STAT" \ [43] Barrel02Static_HeavySN [STAT:0010EAF1] \ [3] Model
00075046 has the change to a Model subrecord. 02009669 has changes to flags, but not Cell flags so it is properly ignored.

 

I don't know what you're telling me. Result vs. Expected Result?

 

 

 

if (sig = 'STAT') then begin
  Validate(ElementByName(e, 'DNAM - Directional Material\Material'), ElementByName(m, 'DNAM - Directional Material\Material'), tag, true);
end;
If I add that it doesn't seem to work. Am I doing that right?

 

ElementBySignature for signatures. ElementByName for names. ElementByPath for paths. Validate() doesn't work with flags, by the way.

 

 

EDIT4: I suggest the following for Skyrim. Not sure if Fallout or TES4 has the same subrecords.

Effect Shaders are already handled in the CheckGraphics() function. I added NAM8 and NAM9 to v1.3.7 for Skyrim only.

 

 

I was going to make the same request, to have the bash tag script append the bash tags to the existing plugin header description text rather than overwriting the existing text that describes the plugin.

I don't want to go through the pain of string comparisons, regular expressions, and blah. Nobody uses descriptions anyway. Modders barely use the author field.

 

 

There are a lot of records in some plugins that shouldn't be included in the bashed patch, and to make sure this happens the tags for these records shouldn't be used. For example, if Project Beauty is used then the face and other changes to NPCs that some mods make (e.g., armor mods) should not be used. If the NPC-related bash tags are eliminated Wrye Bash will then take care of ensuring that the Project Beauty faces are used. I do such reviews for the bash tag inputs I provide to LOOT, by the way.

I'll leave any discussion about how Wrye Bash handles tags to the developers. Edited by fireundubh
Posted (edited)

I don't know what you're telling me. Result vs. Expected Result?

Yes. Result vs Expected result.

 

ElementBySignature for signatures. ElementByName for names. ElementByPath for paths. Validate() doesn't work with flags, by the way.

Thanks.

 

Effect Shaders are already handled in the CheckGraphics() function. I added NAM8 and NAM9 to v1.3.7 for Skyrim only.

I'll have to see how you did that so I can make future suggestions. I didn't see where to do that.

 

EDIT: Did you remove EDID for Skryim? I don't check for that. I honestly don't check for that in any game mode I am pretty sure.

Edited by Sharlikran
Posted (edited)

Yes. Result vs Expected result.

What's the result? What's the expected result?

 

 

I'll have to see how you did that so I can make future suggestions. I didn't see where to do that.

if IsSkyrim(game) then begin
	Validate(ElementBySignature(e, 'NAM8'), ElementBySignature(m, 'NAM8'), tag, debug);
	Validate(ElementBySignature(e, 'NAM9'), ElementBySignature(m, 'NAM9'), tag, debug);
end;

The Validate() function is a PITA. I'm going to rewrite it so that you have to type only:

Validate(e, m, 'NAM8', tag, debug);

There's really no reason for it to be the way it is right now. And if I can figure out a way to determine whether a Flags element is a Flags element, I'll make Validate() handle those, too, but DefType/DefTypeString returns Integer and that type covers too much ground.

 

 

EDIT: Did you remove EDID for Skryim? I don't check for that. I honestly don't check for that in any game mode I am pretty sure.

For EFSH, "almost anything" is in the documentation, so I just went with what was easiest for me to validate. Removed EDID for v1.3.7.

Edited by fireundubh
Posted (edited)

For EFSH, "almost anything" is in the documentation, so I just went with what was easiest for me to validate. Removed EDID for v1.3.7.

Yeah I didn't put that there and I can see how it wouldn't be that helpful.

 

For Skyrim:

	if (sig = 'STAT') then begin
        Validate(ElementByName(e, 'Model'), ElementByName(m, 'Model'), tag, true);
        Validate(ElementByName(e, 'Material'), ElementByName(m, 'Material'), tag, true);
        Validate(ElementByPath(e, 'DNAM - Direction Material\Material'), ElementByPath(m, 'DNAM - Direction Material\Material'), tag, true);
        Validate(ElementByPath(e, 'DNAM\Direction Material\Material'), ElementByPath(m, 'DNAM\Direction Material\Material'), tag, true);
        Validate(ElementByPath(e, 'DNAM\Material'), ElementByPath(m, 'DNAM\Material'), tag, true);
    end;
Which one is correct? I am applying this to Better Dynamic Snow.esp and I would think I would see like over 100 records in the messages pane with that but I don't.

 

EDIT: I only want to check for Material not Max Angle.

    wbStruct(DNAM, 'Direction Material', [
      wbFloat('Max Angle (30-120)'),
      wbFormIDCk('Material', [MATO, NULL])
    ], cpNormal, True),

What's the result? What's the expected result?

Result: Screen Shot

[2] Graphics:  \ [04] Better Dynamic Snow.esp \ [1] GRUP Top "STAT" \ [753] Barrel02Static_HeavySN [STAT:0010EAF1] \ [3] Model
[2] Graphics:  \ [00] Skyrim.esm \ [31] GRUP Top "STAT" \ [43] Barrel02Static_HeavySN [STAT:0010EAF1] \ [3] Model
Expected Result: Screen Shot

[2] Graphics:  \ [04] Better Dynamic Snow.esp \ [1] GRUP Top "STAT" \ [753] FarmInnDestroyed01Snow [STAT:00075046] \ [3] Model
[2] Graphics:  \ [00] Skyrim.esm \ [31] GRUP Top "STAT" \ [43] FarmInnDestroyed01Snow [STAT:00075046] \ [3] Model
And I expect it to pick up the DNAM \ Material also. Edited by Sharlikran
Posted

For Skyrim:

	if (sig = 'STAT') then begin
        Validate(ElementByName(e, 'Model'), ElementByName(m, 'Model'), tag, true);
        Validate(ElementByName(e, 'Material'), ElementByName(m, 'Material'), tag, true);
        Validate(ElementByPath(e, 'DNAM - Direction Material\Material'), ElementByPath(m, 'DNAM - Direction Material\Material'), tag, true);
        Validate(ElementByPath(e, 'DNAM\Direction Material\Material'), ElementByPath(m, 'DNAM\Direction Material\Material'), tag, true);
        Validate(ElementByPath(e, 'DNAM\Material'), ElementByPath(m, 'DNAM\Material'), tag, true);
    end;
Which one is correct? I am applying this to Better Dynamic Snow.esp and I would think I would see like over 100 records in the messages pane with that but I don't.

 

EDIT: I only want to check for Material not Max Angle.

 

 

So, first of all, you want to use an existing or new function if you need more than one validator. Validate() is also recursive up to 5 levels, so 'Model' would look at MODL, MODT, MODS, etc.

 

If you need one validator:

if (sig = 'STAT') then
	Validate(ElementByPath(e, 'DNAM\Material'), ElementByPath(m, 'DNAM\Material'), tag, false);

If you need two or more validators:

if (sig = 'STAT') then begin
	Validate(ElementByName(e, 'Model'), ElementByName(m, 'Model'), tag, false);
	Validate(ElementByPath(e, 'DNAM\Material'), ElementByPath(m, 'DNAM\Material'), tag, false);
end;

If you had a lot of DNAM elements to look at:

if (sig = 'STAT') then begin
	d := ElementBySignature(e, 'DNAM');
	dm := ElementBySignature(m, 'DNAM');

	Validate(ElementByName(e, 'Model'), ElementByName(m, 'Model'), tag, false);
	Validate(ElementByName(d, 'Max Angle (30-120)'), ElementByName(dm, 'Max Angle (30-120)'), tag, false);
	Validate(ElementByName(d, 'Material'), ElementByName(dm, 'Material'), tag, false);
end;

In a function, you'd change those bools to the debug variable, which is passed through that function.

 

You can suggest things without writing any code, FYI. I'd imagine your time would be better spent on Wrye Bash development. ;)

Posted (edited)

You can suggest things without writing any code, FYI. I'd imagine your time would be better spent on Wrye Bash development. ;)

Since I didn't make the documentation for Wrye Bash's patchers it's not complete and it defiantly does not cover the differences between all four versions. It mostly covers just Oblivion. As you mentioned for Effect Shaders the documentation says, Almost anything and that wasn't very helpful. It would take me longer to update the documentation for all four games then it would for me to update Wrye itself. Probably the only way to know what the patcher is doing is to read the Python code and compare it to xEdit's code. Since that isn't really ideal for you then I wanted to become more familiar with the script itself. I think I will take your advice for now and just make simple short requests. Then as time goes on I will track your changes until I can figure out the script.

 

I'll take a stab at some requests and see how I can format the information so it works the best for you. I think I will try listing the game first either FO3/FNV/TES4/TES5. I'll list multiple games when applicable. Second I will list the top group like STAT or EFSH. Then when the entire subrecord should be mitigated I will list just the Subrecord. When only specific parts of the subrecord should be mitigated I will list the subrecord followed by a slash and the attribute.

 

I don't know how I am going to handle Model. Wrye looks at the entire group of subrecords under the Model attribute which can be multiple subrecords. So I will add the prefix "attr:" when I have no idea what Wrye is actually doing. Normally when I specify an attribute the Bash Tag can't be applied to the entire Subrecord because Wrye will only be looking at the attribute I have indicated. Except in the case of Model as I mentioned previously. When a subrecord is indicated only the subrecord should be looked at. xEdit might group subrecords that belong together but Wrye will only be looking at the subrecord(s) indicated.

 

The only issue I have with using the Entire subrecord is that Wrye 'usually' ignores unused, unknown, and hidden data. So for example in WEAP the DNAM record has 5 unknown values. If those are included the Bash Tag will be inaccurate. Also for WEAP:DNAM in FO3 and FNV just wbFloat; is used a few times, so you can't always look for wbFloat("Unknown"); or wbFloat("Unused");. The naming for xEdit is as inconsistent as it is with Wrye.

 

As I go along let me know if there is another way that will work better for you.

 

Graphisc Patcher:

 

TES5; STAT: DNAM\Material, attr:Model

FO3/FNV/TES4; STAT: attr:Model

TES5; EFSH: ICON, ICO2, NAM7, NAM8, NAM9, DATA

TES4; EFSH: ICON, ICO2, DATA

FO3/FNV; EFSH: ICON, ICO2, NAM7, DATA

Edited by Sharlikran
Posted

@Sharlikran

Feel free to post your links to Wrye Flash (or whatever you can't host on the Nexus) on this thread or PM them to me, and we can add these as "mod pages" within our system, which will provide basic metadata about the mod(s), including download links (to your assets on DropBox or OneDrive or whatever). I know DropBox provide a public link (in Public folder only) that allows seamless download of the file directly, but some other services only provide a link to the web page and then another click to download the file ... not sure what OneDrive does.

Posted

There's really no reason for it to be the way it is right now. And if I can figure out a way to determine whether a Flags element is a Flags element, I'll

I added new functions for get a list of flags and enumerations values. Non flags and enum fields will return empty strings.

Uploaded new version of afkmods.

 

When Mator was working on his smasher script, I also added a function that xEdit uses to compare elements when "coloring" them and checking for conflicts. I think you can figure out how it works using demo script "Detect conflict between elements.pas". This function respects conflict pripority of elements, so if some values differ but marked to be ignored, it will properly return ITM. It should suit your script perfectly instead of just comparing strings.

Posted

I'll take a stab at some requests and see how I can format the information so it works the best for you. I think I will try listing the game first either FO3/FNV/TES4/TES5. I'll list multiple games when applicable. Second I will list the top group like STAT or EFSH. Then when the entire subrecord should be mitigated I will list just the Subrecord. When only specific parts of the subrecord should be mitigated I will list the subrecord followed by a slash and the attribute.

 

I don't know how I am going to handle Model. Wrye looks at the entire group of subrecords under the Model attribute which can be multiple subrecords. So I will add the prefix "attr:" when I have no idea what Wrye is actually doing. Normally when I specify an attribute the Bash Tag can't be applied to the entire Subrecord because Wrye will only be looking at the attribute I have indicated. Except in the case of Model as I mentioned previously. When a subrecord is indicated only the subrecord should be looked at. xEdit might group subrecords that belong together but Wrye will only be looking at the subrecord(s) indicated.

 

The only issue I have with using the Entire subrecord is that Wrye 'usually' ignores unused, unknown, and hidden data. So for example in WEAP the DNAM record has 5 unknown values. If those are included the Bash Tag will be inaccurate. Also for WEAP:DNAM in FO3 and FNV just wbFloat; is used a few times, so you can't always look for wbFloat("Unknown"); or wbFloat("Unused");. The naming for xEdit is as inconsistent as it is with Wrye.

 

I don't understand your use of the word "mitigated" above. If you want me to ignore an element, don't mention it. If you want me to process an element, list them like you have. If you want me to remove an element, just tell me you want it removed.

 

As for unused and unknown elements, I can instruct my validator to ignore elements that are named so. I don't think there are any "hidden data" elements though.

 

Good luck with Wrye Bash! I'd help since Python is pretty easy, but the Wrye Bash source code is a mess and who knows what the file names mean. I guess you need a Python IDE to figure out how everything fits together.

 

 

I added new functions for get a list of flags and enumerations values. Non flags and enum fields will return empty strings.

Uploaded new version of afkmods.

 

When Mator was working on his smasher script, I also added a function that xEdit uses to compare elements when "coloring" them and checking for conflicts. I think you can figure out how it works using demo script "Detect conflict between elements.pas". This function respects conflict pripority of elements, so if some values differ but marked to be ignored, it will properly return ITM. It should suit your script perfectly instead of just comparing strings.

 

Awesome! Thank you!

Posted

I don't understand your use of the word "mitigated" above.

It means to lessen the effects of the changes between mods. In other words to deal with or to process the changes between plugins and their respective Bash Tags.
Posted

...Good luck with Wrye Bash! I'd help since Python is pretty easy, but the Wrye Bash source code is a mess and who knows what the file names mean. I guess you need a Python IDE to figure out how everything fits together...

Trust me, using any IDE to see how that code works makes no difference. :O_o:  :wallbash:

Python is one of the languages I find the easiest to read but I get migraines everytime I try to decipher that stuff.

  • +1 1
Posted (edited)

Known issue:

 

v1.3.6 and below generate too many tags and some validators are broken.

 

v1.3.7 resolves these issues in large part by reducing the risk of programmer error, by using xEdit's conflict detection functions to determine what elements to compare, and by using a universal GetElement function that automatically determines whether to use ElementBySignature, ElementByName, or ElementByPath.

Edited by fireundubh

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.