Fallout 4 Optimization and Performance Systems Explained

[Mycenia]

Thank you! The issue with this mod is that all but 4 of those cells are widely spread apart, so they end up covering a huge chunk of the commonwealth when you're generating a 3x3 for each of them. I will do as you say with the 4 that are adjacent though and just pick one and let it handle them, that will cut down on some of the potential conflicts. The rest I'll patch with the larger mods and CR in xedit with the little stuff. This is mostly just for me and wanting to learn in general. Good stuff to know if I ever do decided to make something worth releasing in the future.

[SMB92]

Cool. Nothing really wrong with what you were doing, but I'd say you're probably covering the same 3x3 grid over and over on a number of those cells. Ain't nobody got time for that XD

 

I did the whole of Cambridge once. I think 11 or 13 grids squared. Consumed all 32GB of my Ram, all 11GB of my Gpu and a further 30GB+ of page file (the latter seems to matter more to the CK, at least in my experience). I was only trying to cover a number of spread out cells for Beantown, however I found the performance in Cambridge was better across the board, better average frametimes etc etc. Bethesda has missed a bunch of stuff, no doubt. However, our CK generator is not without its flaws, it will fail to include or link physics to some objects and in some cases produce really bad previs (but this is mostly just Umbra/calculation being imperfect) among other odd things from time to time, and may differ per generation.

[hereami]

 

The auto-disable system compares the Version Control Info 1 field (a record timestamp) of the REFR records listed in the XCRI sub-record of the CELL to the PCMB timestamp. If the REFR has a later timestamp, or has no timestamp (all 0s in old xEdit, or None in xEdit 4.0), it disables previs/precombineds for that cell. So if you are building precombiends with one plugin and trying to merge it into another, you'll have issues, since xEdit zeros that field out when you copy (as override, or as new record) into another plugin. This is apparently related to some issues people were having in Oblivion days when it did copy that field.

 

Hi. That was a good hint about timestamp, thanks. I tried to restore vanilla precombines that were never used and a DLC touched few records of them, so nothing worked untill i restored the timestamps in my overriding REFRs to original vanilla values (don't know, if Cell timestamp was important in this case, i simply restored it as well). Interesting, Precomb timestamp in Cell record is important too, game doesn't seem to load Precomb untill it's set, there's no "default" logic, even if files exist.

 

What was "Oblivion days issue"? Main question, if there can be any fatal consequences after duplicating the timestamp in overriding records? I don't get any crashes because of that. Maybe those days are long gone then? (Was always a mistery for me, why XEdit zeroes/locks those fields, while it's such a wonderful low-level editor)

 

Also, how to obtain two-byte timestamp FROM a PreComb/PreVis file?

 

Thanks.

Edited January 20, 2019 by hereami

[VIitS]

 

 

What was "Oblivion days issue"? Main question, if there can be any fatal consequences after duplicating the timestamp in overriding records? I don't get any crashes because of that. Maybe those days are long gone then? (Was always a mistery for me, why XEdit zeroes/locks those fields, while it's such a wonderful low-level editor)

 

Also, how to obtain two-byte timestamp FROM a PreComb/PreVis file?

 

Thanks.

 

 

The Oblivion issue was apparently related to something when you enabled Version Control in the CS (Construction Set). Not sure what the problem was, probably things not overwriting properly. Apparently using that was actually somewhat important in Oblivion modding to get things working properly, this is all third hand*, over a month ago. It was probably locked because it: A) wasn't decoded, so we had no idea what values were acceptable and B) was never used for anything except doing work that required it to be accurate in the CS up until Fallout 4 and the precombined/previs system. And the fact that it was used there was discovered (AFAICT) by me, shortly before I made that post. The other locked subrecords in the header are things that would cause all kinds of problems if you directly edited them (with a possible exception of VC Info 2), so VC Info 1 was just left locked for the time being.

 

I don't think there is any timestamp embedded in the actual .uvd or .nif files. From my testing, all that matters is that the PCMB and VISI fields have the same or later date as any REFR that is part of a precombined mesh. You can get the VC Info 1 data as a hex value (to more easily compare) by selecting the VC Info 1 subrecord -> Ctrl+C, and paste it in a text doc or something. The first two hex pairs are what matter, the last two are probably related to the User/Index values. And I don't think the VC Info 1 for the Cell itself matters, pretty sure I tested that when I found the connection between REFR VC Info 1 and PCMB/VISI.

 

Also, if you don't want to have to deal with making sure that both plugins have the same masters, I fixed the script to remove that requirement:

 

 

{
  Copy Version Control Info inside Record Header between plugins.
  Apply script to destination records, then select the source plugin.
  Both plugins must have the same masters list, records are matched by FormIDs.
}
unit CopyVCInfo;
var
  fromPlugin: IInterface;
//==================================================================================
// list of masters of a plugin
function MastersList(aFile: IInterface): string;
var
  masters: IInterface;
  i: integer;
begin
  masters := ElementByName(ElementByIndex(aFile, 0), 'Master Files');
  for i := 0 to Pred(ElementCount(masters)) do
    Result := Result + GetElementEditValues(ElementByIndex(masters, i), 'MAST') + #13#10;
end;
 
//==================================================================================
function Process(e: IInterface): integer;
var
  frm: TForm;
  clb: TCheckListBox;
  i: integer;
  r: IInterface;
begin
  // plugins selection window for the source plugin to copy from
  if not Assigned(fromPlugin) then begin
    frm := frmFileSelect;
    try
      frm.Caption := 'Select plugin to copy from';
      frm.Width := 420;
      clb := TCheckListBox(frm.FindComponent('CheckListBox1'));
      // add files except the current one
      for i := 0 to Pred(FileCount) do
        if not SameText(GetFileName(e), GetFileName(FileByIndex(i))) then begin
          clb.Items.AddObject(GetFileName(FileByIndex(i)), FileByIndex(i));
          Inc(i);
        end;
      // get the first checked file
      if frm.ShowModal = mrOk then
        for i := 0 to Pred(clb.Items.Count) do
          if clb.Checked[i] then begin
            fromPlugin := ObjectToElement(clb.Items.Objects[i]);          
            Break;
          end;
      // if nothing is checked then abort
      if not Assigned(fromPlugin) then begin
        Result := 1;
        Exit;
      end;
    finally
      frm.Free;
    end;
  end;
  // copy VC info
  r := RecordByFormID(fromPlugin, FixedFormID(e), False);
  if Assigned(r) then begin
    SetFormVCS1(e, GetFormVCS1(r));
    SetFormVCS2(e, GetFormVCS2(r));
  end;
end;

end.

 

 

 

I verified with Elminster that it doesn't matter, and zilav (the guy who made it) said it was put in at the request of the person who asked him to make it, and shouldn't be needed. My tests confirmed that it works fine without the masters matching. Might be related to that same "Version Control in the CK" thing.

 

*The reason for it being disabled is directly from Elminster, He Who Created The Most Wondrous of Tools. The problem that occurred when using Version Control in the CS when using Copy as Override in xEdit was reported to him, and not something he directly experienced. My guess is that it makes it so the CS left it with the copied timestamp, whereas an empty subrecord was auto-filled with the current date when you load and save it in the CS (or CK).

[hereami]

 

I fixed the script to remove that requirement:

Oh, afraid i made it good old dumb way with timestamps :) My bad, there's so much, i don't know about, never needed to run scripts.

 

Thank you for explanation!!

[VIitS]

Yeah, loading it in the CK will also fix the missing timestamps in the CK. But if your mod has a bunch of .esp masters, it is easier to work on the precombineds in a separate plugin, then copy it over in xEdit, and use the script to copy the VC info data over.

[Mycenia]

I was hoping for a bit of clarification on something. Do all texture mods that have material swaps that touch precombined objects, such as Langley's bricks or Illuminated Billboards, break them? I was something I was completely unaware of until I stumbled on a post earlier today. Most of the information I can find on it is focused more on mod authors and generating precombines with custom materials than a definitive answer from a user pov. Or I just missed it. I have the flu, my brain is just plain stupid right now.

[VIitS]

The only thing that breaks precombineds/previs is touching REFR records that are part of precombined/previs meshes, or direct edits to the CELL record to remove precombineds/previs.

 

Texture replacers (where the .dds files are replaced and the mesh itself isn't touched) work fine, even on precombineds. Material swaps (either by editing the .nif, or applying a MSWP in the record, will not break precombineds, but it will also not apply to precombined versions of that mesh.

 

I think that a material replacer (.bgsm/.bgem) that doesn't require an edit to the .nif or the record will also work, but I haven't tested it.

[calthrop]

I have a quick question: this post over on Bethnet asserts that "Most grass (but not all) is procedurally generated so isn’t part of a precombine."

 

I'm currently working on a mod that would replace some of the awful grass meshes but have no idea how to track down which ones should be left alone. I wasn't planning on changing many (or even most, just a handful), but I don't want to go through all that work only to later get reports that I've gone and broken precombines over half the map.

 

So...does anyone happen to know *if* grass is actually part of precombines, and if so, which ones? Or if they are and no one has actually tracked them down, is there any way for me to do so?

 

Thanks in advance! This thread is a life saver.

 

Edit: just to be clear, the meshes I'm considering working with are grass/driedgrassshapes02, forestgrassobj01->04, driedgrasscluster04->05, blastedforestgrassobj02, blastedforestrocksobj01->02, blastedforesttwigs01->02.

 

Another question occurs to me: if I change only the UVs of a mesh (say, landscape/forest/leafpile01->04) and leave the geometry, etc. untouched would that break precombines?

Edited January 23, 2019 by calthrop

[chucksteel]

I have a quick question: this post over on Bethnet asserts that "Most grass (but not all) is procedurally generated so isn’t part of a precombine."

 

I'm currently working on a mod that would replace some of the awful grass meshes but have no idea how to track down which ones should be left alone. I wasn't planning on changing many (or even most, just a handful), but I don't want to go through all that work only to later get reports that I've gone and broken precombines over half the map.

 

So...does anyone happen to know *if* grass is actually part of precombines, and if so, which ones? Or if they are and no one has actually tracked them down, is there any way for me to do so?

 

Thanks in advance! This thread is a life saver.

First, do yourself a favor and ignore that thread! It’s full of miss information by the misinformed.

 

The grass that is included in pre-combined meshes are attached to meshes like rocks and cliffs. The grass that is painted on the landscape is proceduraly generated.