Jump to content

haama

Members
  • Content Count

    2
  • Joined

  • Last visited

  1. Thanks for the info on the file header, I'll try it out. Maybe component is a better word? (It's loaded too for anyone heavy into the .net world.) I'm trying to split up the Cobl Main.esm into many smaller, independent ems that can be developed on their own and then merged back together for release. I thankfully did a lot of the heavy lifting the last time I worked on Cobl (so, like, 10 years ago or so...) by denoting the module that the record belongs to (second part of the name, such as cobAls for the Alchemy Sorters and cobGrind for the grinder) and removing unnecessary "dependencies". I want to make sure I've isolated records so they are practically modules and only reference other records in the same module. I've already found a few records that I need to change, some common modules like cobGen(eneral functional activators), and some dependency cycles (the options menu quest references many modules which in turn reference options buttons/misc items). Cobl has over 50 different modules and hundreds (thousands?) of records, so if I want to check everything, I'll need a list of references made by each record. As of now, because we already have the modules denoted, I think I can get away with finding all of the references made by all of the records in a module, sort them by editorID, log them, look through them. But there's "grab all references" function like there is a "grab all referenced by" function. Looks like I can handle this with some recursion, thank you for the tip looks like there are no gotchas such as sub-records treated records and becoming infinite loops, so it should be easy, Any shortcuts would be appreciated. (And I have a start for the actual merge process - just need to use "Merge overrides into Master" as a starter and modify to copy all records into master "Renumber FormID of Matching EDID" is useful too.)
  2. Hellos there. I'm trying to create a few xEdit scripts to help modularize Cobl.esm, break it into separate esps for developers to work on (mostly) independently and then merge it all together for releases, and have a couple questions (at least two for now). Is there a magic trick to getting the file header, or is it really not implemented? I would like to add some information in the description like Module namespace (cobAls, cobGrind, etc.), Dependency/Required Modules. I saw something about injected info in this thread, would that be the preferred method? I can always have a co-file csv and parse it, but I've learned over the years that the closer you place info to the original code the less likely it'll be lost and the more likely it'll actually be updated. I'm writing a script to gather the dependent modules (not mods, again trying to break apart a single mod), make sure I'm not missing anything. I've got scripts and magic effects so far, so I can use what I've learned to take on pretty much anything, but... Any hints on writing a recursive function that will work with all record types? I can use ElementCount and ElementByIndex to walk down and through the sub-records (so far at least) but then I need a solid way to tell if that element is a record. From the interface, CanContainFormIDs() would work if it returned False correctly, but if I can't trust that can I just use LinksTo() and skip if it returns nil/-1? Another route I've considered is grabbing all the ReferencedBy entries and building a dependency graph, check it for (module/namespace) cycles. I know of a few general "check on the other quest/container statuses" maintenance quests that are cyclic and will need to be in a last stage module after everything else has come together. Anyway, any suggestions for Delphi graph libraries? I found GraphViz and SimpleGraph but they have not been updated in over 7 years.

Support us on Patreon!

Patreon
×
×
  • Create New...