ZAZ missing script when generating dyndolod?

[Very Tired Anna]

I got this error log and i don't know what this mean. Like, is there a script missing in ZAZAnimationPack.esm mod?
Error: File not found scripts\zazontriggerenterbindingstmg.pex ZaZAnimationPack.esm zbfdefaultActivateGetTiedUp [ACTI:260680D6]

[traison]

Easy to verify, no? Inspect the ACTI record in xEdit. Does it contain a reference to that pex file? Then query your mod manager for whether that file exists or not. Also check if ZaZ contains a BSA archive, and whether or not it has that missing script in it; extract it if it does.

Edited March 16 by traison

[Grey Cloud]

I'm fairly certain that I get the same message. I am totally certain that I ignore it. 

Just had a look  - no sign of the file in the Zaz scripts older. Can't look in XEdit at the mo as I'm defragging the drive it's on.

 

Why would DynDOLOD be interested in a script file?

[traison]

42 minutes ago, Grey Cloud said:

Why would DynDOLOD be interested in a script file?

 

It might be doing a generic health-check on the plugin. There's a load-door in one of the CC content plugins that's linked wrong that certainly isn't going to be in any way relevant to DynDOLOD either, but you can't progress unless you fix the door. I guess the idea is to try to reduce the number of complaints in their communication channels. Like how installers tend to checksum check downloaded files, even though TCP/IP already has packet integrity verification - it cuts out the "it no work" message from that one person that has broken or unstable RAM. DynDOLOD doesn't run for more than a few weeks before it demands to be updated too, even if you're offline. The exe has been made to invalidate itself based on your computer clock - again an attempt to reduce messages from people that don't update. I bytecode patched that date check out, I don't like updating things that already work.

[Grey Cloud]

The ACTI record references the script file. The script file is referenced by the ZAZ Test Zone. Nothing else.

[traison]

32 minutes ago, Grey Cloud said:

The ACTI record references the script file. The script file is referenced by the ZAZ Test Zone. Nothing else.

 

In that case I would just remove the script reference from the ACTI object rather than go on a witch hunt to try to find this script somewhere. Still, silly that DynDOLOD even cares.

[wren888]

On 3/16/2026 at 11:24 AM, traison said:

 

In that case I would just remove the script reference from the ACTI object rather than go on a witch hunt to try to find this script somewhere. Still, silly that DynDOLOD even cares.

The ZazOnTriggerEnterBindingsTMG script is also referenced by the Activator zbfdefaultActivateGetTiedUp, which is the one at the bottom. I deleted the script reference there as well as the one in Cell\ . . . \Test Zone. (it's REFR:020680d7 there). When I run DynDOLOD, I'm still getting the error message. I looked for the script in order versions of ZaZ, both SE and LE. I didn't find it in any of them. When I delete the script from those to places, I don't need to do anything else special, do I? Any further idea about what the problem is?

[traison]

54 minutes ago, wren888 said:

I deleted the script reference there as well as the one in Cell\ . . . \Test Zone. (it's REFR:020680d7 there). When I run DynDOLOD, I'm still getting the error message.

 

I feel like you missed something. It seems quite unlikely to me that DynDOLOD would complain about something that shouldn't exist anymore - that would imply some kind of memory that it references between executions.

 

56 minutes ago, wren888 said:

I don't need to do anything else special, do I? Any further idea about what the problem is?

 

Since I don't use ZaZ myself, I can't tell without seeing your setup. TeamViewer or RustDesk. Make sure you understand what these mean until you agree to anything; at the very least read the warning at the top of the RustDesk website. PM me if this sounds reasonable.

[PippinTom]

I've searched for that file some time ago for quite some time. No luck.

I don't think that file exist anywhere on the web (shit:  how weird that sounds... first thing in the history that got actually removed from the internet?!)

 

I didn't delete test zone nor ACTI reference from .esm - it seems harmless. But on the other hand I've never had any problems because of that with DYNDOLOD - OP must be using it wrong, if it screams about ZAZ - unless it's just a log entry that does not break execution, in which case I wouldn't care about it - if that was important to DYNDOLOD it would halt execution instead of just reporting it (amongst lots of other meaningless tiny fuckups in various mods).

[traison]

1 hour ago, PippinTom said:

first thing in the history that got actually removed from the internet?!

 

Hehe, plenty of things disappear every day. It's the very reason why I do not delete anything that I download, and why I sometimes download things just in case I need it in 10 years.

 

1 hour ago, PippinTom said:

I've searched for that file some time ago for quite some time. No luck.

 

I suppose there is another approach to this problem which is just to create a pex file with the name DynDOLOD is expecting to find. I very much doubt DynDOLOD would actually check the contents of the file. The base game might flip out if it tries to execute it so perhaps removeit again after DynDOLOD has done its thing.

 

The real fix is still going to be to either provide the script or remove the script reference, but no one is going to sue you for using a workaround every now and then.

[PippinTom]

2 minutes ago, traison said:

Hehe, plenty of things disappear every day. It's the very reason why I do not delete anything that I download, and why I sometimes download things just in case I need it in 10 years.

 

I know, doing exactly same thing. I was obviously joking but anyway - it's rather rare that thing I need disappear, so whenever it happens it's a surprise/disappointment of sort.

 

4 minutes ago, traison said:

The real fix is still going to be to either provide the script or remove the script reference, but no one is going to sue you for using a workaround every now and then.

 

For me the question is - what for fix something that does not break anything? Just for sport? Achieving zero-warning-logs-award (no matter if it's papyrus, dyndolod or something else) and nothing else (functionally noticeable) sounds tempting until it gets old, what happened in my case, some time ago.

[traison]

3 minutes ago, PippinTom said:

[why] fix something that does not break anything?

 

I assumed DynDOLOD was using the INFO/WARNING/ERROR labels correctly: Error means it terminated; failed to do what it was designed to do.

 

4 minutes ago, PippinTom said:

Just for sport?

 

Learning, perhaps.

[PippinTom]

11 minutes ago, traison said:

Learning, perhaps.

 

If there is not functional change as a result - then where is the learning part in faking .pex? I don't buy it, but in general I agree that learning is fun, but only when it occurs.

[traison]

10 minutes ago, PippinTom said:

...where is the learning part in faking .pex?

 

The discovery of a workaround. I have a feeling if the OP had thought of this, they wouldn't have made this thread.

 

It's similar to when I discovered that in order to compile a script you don't actually need the scripts it depends on. Just having a script that contains function stubs with matching signatures to what the compiler is expecting is enough. A workaround like this allows you to speed up certain workloads.

[PippinTom]

19 minutes ago, traison said:

It's similar to when I discovered that in order to compile a script you don't actually need the scripts it depends on. Just having a script that contains function stubs with matching signatures to what the compiler is expecting is enough. A workaround like this allows you to speed up certain workloads.

 

But that's actually useful, and I would learn from that highlighted part. For me easier is to comment out calls to scripts and/or functions I know for sure will never be used by me anyway. and that way remove dependency that is just deadweight for mod I'm trying to compile for my personal taste/needs.

 

BTW: Regarding OP's issue - to me it's still unclear if DYNDOLOD halted execution or just mentioned ZAZ missing script as warning in its log. And that is something that OP could learn here - that providing essential details when filling issue description is vital to getting actuall help and not get flooded by off-topics. ; )

[belegost]

3 hours ago, traison said:

I do not delete anything that I download, and why I sometimes download things just in case I need it in 10 years.

Any chance you have a floppy somewhere with a shareware version of Wolfenstein 3D dated to May 1992?

Edited May 9 by belegost

[traison]

1 hour ago, belegost said:

Any chance you have a floppy somewhere with a shareware version of Wolfenstein 3D dated to May 1992?

 

I have a zip of the Wolfenstein 3D floppy with WOLF3D.EXE dated 1995-07-09 14:12, CRC 17B59350.

 

Edit: That's the EXE date, not the zip. The zip was made much later. Original floppy is in storage somewhere.

 

Edit again: Also to clarify, I do not remember if this is the entire game or shareware.

Edited May 9 by traison

[belegost]

14 hours ago, traison said:

I have a zip of the Wolfenstein 3D floppy with WOLF3D.EXE dated 1995-07-09 14:12, CRC 17B59350.

I was joking when I made my original comment, but that is actually fucking impressive. I bet if I dug up my ancient 386 out of a cellar it would run. Is that date a normal date or a retarded, freedom unit date?

[traison]

4 hours ago, belegost said:

Is that date a normal date or a retarded, freedom unit date?

 

YYYY-MM-DD, not freedom I'd say.