Just a quick note on the DNAM and TNAM fields on messages: DNAM appears to be a message/messagebox flag, and TNAM appears to control the message display time, which is one major improvement over Oblivion's message system.
E: Looking at the other messages I may be wrong about DNAM, unless messages triggered by a messagebox are always messageboxes.

What is the difference between 'copy as override' and 'deep copy as override'?

edit: minor request if you get a chance -- for DIAL topics, it would be handy to have an option to 'copy with children' in both new/override forms.

If you copy a DIAL record as override it only copies that DIAL record, if you use "deep copy" as override then it also copies all the INFO records underneath.

To get a copy of a DIAL and all INFO records under it as new records you can do the following currently:

• Use "Deep Copy as Overrride into..."
  
• Go to the override copy of the DIAL record (you can just CTRL+Click on the "Record Header \ FormID" field of the override copy in the detail view)
  
• Select that record in the navigation treeview
  
• Press F2 (opens the change FormID dialog)
  
• Backspace (clears the FormID)
  
• Enter (shows the dialog again with a newly generated unique FormID)
  
• Enter (confirms the change)
  
• Repeat for the INFO records (Cursor Down, F2, Backspace, Enter, Enter, repeat)

I'll see if I can automate that for a future version.

There I go again asking for things that (mostly) already exist, and with two separate questions that I didn't realize were interrelated .

I'll see if I can implement a proper "Deep Copy as New Record into..." function. But it's not quite as trivial as you might expect. Suppose the records you are copying contain references to each other, e.g. you copy a CELL and one REFR has another REFR as Enable Parent, you would want not only all copied records to have new FormIDs but also all internal references to be updated to these new FormIDs instead of going back to the original records. Same in TES4 when you copy DIAL/INFO records where the INFO records where linked together via the PNAM subrecord (and thanks the deity of the day for doing away with that in FO3).

If you follow the instructions above then you should already be getting dialogs that tell you about such cross references and offer to update them, but doing that on the fly during the copy is not so trivial...

Yeah, i was running into a similar issues trying to update stuff from one version of a mod to another, the CTDAs in INFOs were referencing the same global in each file, but since it was two .esps it saw them as two globals so it was trying to make me have one master the other... I ended up copying things backwards to get around it. If it's hard to make the 'deep copy as new' work then don't bother, not that important really.

For comparing / moving data between 2 versions of the same mod:

• when starting FO3Edit, only load ONE of the 2 versions
  
• select the file in the navigation treeview
  
• context menu -> Compare to
  
• select the 2nd file in the file open dialog (it needs to be in the data folder for this to work currently)
  
• the 2nd file now gets loaded with the same load order index as the first file

Doing that FO3Edit would have recognized the records in the 2 modules as being overrides of each other which would have simplified copying stuff around a lot.

Should be fixed in the next release. Not ETA for it yet.

I definitely need to get around to writing up that manual/readme wiki .

I still have no idea how to read this program once I have a file open.

I don't know what your question is.

Tiny suggestion:

When you press F2 over the Target field for a CTDA, F3Edit freezes up for a long time while it tries to load every single reference into the dropbox. In cases like this it might be wise to disable F2 or show a confirmation box or something .

"doctor it hurts when i bend my arm this way!"


"... then dont bend your arm that way!"



but yeah, having not messed around with this, idont know the exact problem, but i have an idea of what your talking about and it would get annoying real fast. "dammit thats NOT what i meant to be hovering over .... " 10 mins later " ... finally i can click off" =x

Also figured out what the Unknown field in the SCHR part of SCPT records and result scripts is for. Seems to be set to 256 for any script tied to an MGEF and 0 otherwise (which may mean the field is a flags field since 256 = 1 bit).

Define "long time"? For me it takes at most about 3 seconds to load all 800000 FormIDs if I edit a totally unrestricted FormID field.


In TES4, the format was:

  wbSCHR := wbStruct(SCHR, 'Basic Script Data', [	wbByteArray('Unknown', 4),	wbInteger('RefCount', itU32),	wbInteger('CompiledSize', itU32),	wbInteger('VariableCount', itU32),	wbInteger('Type', itU32, wbEnum([	  'Object',	  'Quest'	], [	  $100, 'Magic Effect'	]))  ]);

But that didn't work anymore in FO3 and I fixed it like this:

  wbSCHRReq := wbStruct(SCHR, 'Basic Script Data', [	wbByteArray('Unknown', 4),	wbInteger('RefCount', itU32),	wbInteger('CompiledSize', itU32),	wbInteger('VariableCount', itU32),	wbInteger('Unknown', itU16),	wbInteger('Type', itU16, wbEnum([	  'Object',	  'Quest'	], [	  $100, 'Magic Effect'	]))  ], cpNormal, True);

which, as you noticed, is wrong and in the next version it will be corrected to:

  wbSCHRReq := wbStruct(SCHR, 'Basic Script Data', [	wbByteArray('Unknown', 4),	wbInteger('RefCount', itU32),	wbInteger('CompiledSize', itU32),	wbInteger('VariableCount', itU32),	wbInteger('Type', itU16, wbEnum([	  'Object',	  'Quest'	], [	  $100, 'Magic Effect'	])),	wbUnknown  ], cpNormal, True);

That "Unknown" at the end seems to consistently contain 01 00, everywhere. So I'm not quite sure what it represents. It might be something like an "enabled" flag, or it might be a version number, no idea.

1-5 minutes. My computer is pretty beastly too so that's not the problem.


Oh, I see. And yes, if you set that to 00 00 the script won't run (found that out because FOMM used to set it to 00 00 on script compile in an older version).

Actually some of the scripts set this to '1', so we may have another flag in there.

Also, I've just noticed that all the scripts in fallout3.esm appear to be Quest. Not sure if this has been discussed before, but I find that interesting. I seem to remember the majority of scripts in Oblivion being Object.

As I said above, the information FO3Edit currently shows you is wrong. This is what it should be:

  wbSCHRReq := wbStruct(SCHR, 'Basic Script Data', [	wbByteArray('Unknown', 4),	wbInteger('RefCount', itU32),	wbInteger('CompiledSize', itU32),	wbInteger('VariableCount', itU32),	wbInteger('Type', itU16, wbEnum([	  'Object',	  'Quest'	], [	  $100, 'Magic Effect'	])),	wbInteger('Flags', itU16, wbFlags([	  'Enabled'	]))  ], cpNormal, True);

And this is what the 2.0.10 uses:

  wbSCHRReq := wbStruct(SCHR, 'Basic Script Data', [	wbByteArray('Unknown', 4),	wbInteger('RefCount', itU32),	wbInteger('CompiledSize', itU32),	wbInteger('VariableCount', itU32),	wbInteger('Unknown', itU16),	wbInteger('Type', itU16, wbEnum([	  'Object',	  'Quest'	], [	  $100, 'Magic Effect'	]))  ], cpNormal, True);

So what you see as "Type" is actually the Enabled flag and what you see as Unknown is acutally the type.

Yes, if you look at them in FOMM it will show the correct type.

I apologise in advance for the fact that this is a "random" post - I haven't read the entire thread up to this point. I just wanted to let you know, in case you didn't already, that the "Unknown: 5" General flag seems to be a "Power Armor" flag, and the "Unknown: 6" General flag seems to be an "Unplayable" flag.

Cipscis

Minor minor snafu -- FO3Edit restricts the form dropbox for IsSpellTarget to SPELs only, whereas the function can take any kind of MagicItem (such as ALCHs and ENCHs). Yeah, obviously not the biggest deal in the world, but would be nice to have fixed when you get around to it .

edit: actually it won't let me enter it manually, so I would like to see it fixed, for now I'll use FOMM.

edit2: turns out I can hack it by entering the form ID in hex format before I assign the function.

Well, I could only use the records that exist on Fallout3.esm as an "example" of what is allowed and what not. And in Fallout3.esm IsSpellTarget has never ever been called with anything but SPELs.
But if you say ALCHs and ENCHs are valid too I'm going to add them. Anything else?

It seems the only other valid type in Oblivion was ingredient so no, just looks like those 3.

Just a quick note that I'm now working on an update for FO3Edit which will have all fields properly decoded (no Unknown anymore).

There is one small issue with FO3Edit 2.0.10, it calculates the record count in the file header incorrectly, so you might get a warning from GECK about that when loading mods edited with FO3Edit. This warning does not affect the functionality of any mod edited with FO3Edit. The game engine doesn't care and GECK offers to correct that value on load. The next version of FO3Edit will calculate the record count correctly again.

Yeah, I got the warning... figured it was FOMM though hehe. Good to know ou're on the job... there's SO much info in the GECK. And I finally realize why image spaces were so gonzo... they're animated . So many things we were trying to guess seem so obvious now that we know what they are .