The critter thread

[DayDreamer]

 

I'm sure everyone is probably well aware of this, but just in case, the errors below are appearing in my log over and over with the 2.0.1 beta:

[01/28/2014 - 06:37:28PM] warning: Function Critter.KickOffOnStart.OnUpdate in stack frame 0 in stack 2082297 differs from the in-game resource files - using version from save
[01/28/2014 - 06:37:28PM] warning: Function Firefly..OnStart in stack frame 1 in stack 2082297 differs from the in-game resource files - using version from save

That's the FireFly infinite loop fix in 2.0.1. You're stuck in an infinite loop waiting for 3D in an old save. Since the loop should end on loading, the fireflies are somehow placed into a non-loading environment.

 

I've tried to fix that in the future by testing for a loadable environment first (getparentcell) before calling that code.

 

Save that savefile, because I'm going to want you to test my stuff against it! In fact, save any places you've had trouble in the past. Should I make a test .bsa with a null .esp for easier testing?

[DayDreamer]

These papyrus errors appeared in my log with the 2.0.1 beta:

[01/29/2014 - 12:13:28PM] error: Cannot call GetValue() on a None object, aborting function call
stack:
    [ (000E1493)].critterSpawn01.IsActiveTime() - "CritterSpawn.psc" Line 198
    [ (000E1493)].critterSpawn01.shouldSpawn() - "CritterSpawn.psc" Line 187
    [ (000E1493)].critterSpawn01.OnCellAttach() - "CritterSpawn.psc" Line 79
[01/29/2014 - 12:13:28PM] warning: Assigning None to a non-object variable named "::temp26"
stack:
    [ (000E1493)].critterSpawn01.IsActiveTime() - "CritterSpawn.psc" Line 198
    [ (000E1493)].critterSpawn01.shouldSpawn() - "CritterSpawn.psc" Line 187
    [ (000E1493)].critterSpawn01.OnCellAttach() - "CritterSpawn.psc" Line 79

This is not on a new game, so I can't rule out "baked in" data, but I have never seen these particular errors before, which leads me to believe they might be a new issue with 2.0.1. I'm not going make a tracker issue on this (unless someone thinks I should), because like I said there were on an old save.

Actually, STEVE40 already had a fix for that, I've included it. There's a Hearthfires bug. Bethesda didn't set the GameHour property. So we should test for None first.... And set the property in UHFP, of course.

[BlackPete]

Save that savefile, because I'm going to want you to test my stuff against it! In fact, save any places you've had trouble in the past. Should I make a test .bsa with a null .esp for easier testing?

Okay. I have some backups of that save file and can test it when you think you have it sorted out. This stuff is far beyond my comprehension, so if testing would help to get rid of it for good, that would be great.

[Arthmoor]

Actually, STEVE40 already had a fix for that, I've included it. There's a Hearthfires bug. Bethesda didn't set the GameHour property. So we should test for None first.... And set the property in UHFP, of course.

Those GameHour properties have already all been fixed via the UHFP.

[DayDreamer]

Okay. I have some backups of that save file and can test it when you think you have it sorted out. This stuff is far beyond my comprehension, so if testing would help to get rid of it for good, that would be great.

Here is a bsa+bsl+esp (nothing in esp). Just copy them into your Data folder and select the crittertest plugin in your loader. Make sure you don't have any *critter*.pex or firefly.pex in the Scripts.

 

For Arthmoor, there's a separate Source only archive. Logging is off.

 

This allows a vanilla 1.8 USKP 1.2.5 savefile to walk in and out and in and out and in and out (as fast as I could go) from Honeyside onto the back porch with no papyrus errors.

 

With logging turned on, I counted all the old and new critters and made sure they cleaned up!

 

The OnCellAttach() and OnCellDetach() and OnTranslationFailed() and OnUpdate() event conflicts happen as expected, but so far my interlocks keep them sorted. Also, in addition to the existing detach timeout of 10.0 seconds, I used attach timeout of 3.14159 and translation failed timeout of 2.71828 -- going in and coming right back out will usually override the 10 seconds with 3, and on cleaning up the translates slightly less.

 

There may still be problems with birds. But I don't have any ready tests for them.

[old code deleted]

[DayDreamer]

A brief explanation of the interlocks.

 

bKilled is a local variable in Critter. Vanilla sets it in 2 places that call DisableAndDelete. STEVE40 sets it in DisableAndDelete itself, to cover the many other places that call DisableAndDelete.

 

I've turned it into an interlock. Now, it is _only_ set in DisableAndDelete. There can be multiple simultaneous calls to DisableAndDelete, but only the first is allowed.

 

PlayerRef is a new property. It speeds up the original Game.GetPlayer by 1,000 times.

 

Since I'm adding it, and therefore old critters will be None, I'm using it as a flag indicating everything should stop and call DisableAndDelete.

 

This is also a shortcut. STEVE40 does a lot of redundant tests. They could be streamlined quite a bit. But instead, I've added the PlayerRef test before each of his tests. Since it gets cleared by both OnCellAttach and OnCellDetach, it's a quick and dirty first test for disabling and deleting.

[Arthmoor]

Uber quick non-scientific results - I was able to take two different freshly minted chars on a round trip around Lake Ilinalta. Loads of critters spawn there. Not a single error in the logs.

 

Loaded up one of my old saves, got a boatload of spam, but then checked and discovered they were for refs already in the save from before. The good news is, they SEEM to have become invalid after the test which suggests they will go away even though they spam errors saying they can't be deleted.

 

So that could be encouraging - reduction in already existing bloat. I'm going to go ahead and package these with an updated beta to get this in front of more eyes.

[BlackPete]

Here is a bsa+bsl+esp (nothing in esp). Just copy them into your Data folder and select the crittertest plugin in your loader. Make sure you don't have any *critter*.pex or firefly.pex in the Scripts.

I tried those out in my game and am still getting the same errors. I'm also getting some other stuff about various critters "killing themselves" (not sure what that's about). I also tested with the latest USKP 2.0.1 beta version that Arthmoor just now updated and still have the same thing on this existing game save. See the attached log below for more info:

CrittersTestLog.zip

[DayDreamer]

I tried those out in my game and am still getting the same errors. I'm also getting some other stuff about various critters "killing themselves" (not sure what that's about). I also tested with the latest USKP 2.0.1 beta version that Arthmoor just now updated and still have the same thing on this existing game save. See the attached log below for more info:

As I mentioned, the Source-only version for Arthmoor had the debugging turned off -- I left the debugging on in the bsa version.

[01/29/2014 - 11:37:54PM] warning: Function Critter.KickOffOnStart.OnUpdate in stack frame 0 in stack 2082297 differs from the in-game resource files - using version from save
[01/29/2014 - 11:37:54PM] warning: Function Firefly..OnStart in stack frame 1 in stack 2082297 differs from the in-game resource files - using version from save
[01/29/2014 - 11:37:54PM] warning: Function Critter.KickOffOnStart.OnUpdate in stack frame 0 in stack 2082277 differs from the in-game resource files - using version from save
[01/29/2014 - 11:37:54PM] warning: Function Firefly..OnStart in stack frame 1 in stack 2082277 differs from the in-game resource files - using version from save
[01/29/2014 - 11:37:54PM] warning: Function Critter.KickOffOnStart.OnUpdate in stack frame 0 in stack 2083153 differs from the in-game resource files - using version from save
[01/29/2014 - 11:37:54PM] warning: Function Firefly..OnStart in stack frame 1 in stack 2083153 differs from the in-game resource files - using version from save
[01/29/2014 - 11:37:54PM] warning: Function Critter.KickOffOnStart.OnUpdate in stack frame 0 in stack 2083143 differs from the in-game resource files - using version from save
[01/29/2014 - 11:37:54PM] warning: Function Firefly..OnStart in stack frame 1 in stack 2083143 differs from the in-game resource files - using version from save
[01/29/2014 - 11:37:54PM] warning: Function Critter.KickOffOnStart.OnUpdate in stack frame 0 in stack 2083138 differs from the in-game resource files - using version from save
[01/29/2014 - 11:37:54PM] warning: Function Firefly..OnStart in stack frame 1 in stack 2083138 differs from the in-game resource files - using version from save
[01/29/2014 - 11:37:54PM] warning: Function Critter.KickOffOnStart.OnUpdate in stack frame 0 in stack 2082288 differs from the in-game resource files - using version from save
[01/29/2014 - 11:37:54PM] warning: Function Firefly..OnStart in stack frame 1 in stack 2082288 differs from the in-game resource files - using version from save
[01/29/2014 - 11:37:54PM] warning: Function Critter.KickOffOnStart.OnUpdate in stack frame 0 in stack 2082284 differs from the in-game resource files - using version from save
[01/29/2014 - 11:37:54PM] warning: Function Firefly..OnStart in stack frame 1 in stack 2082284 differs from the in-game resource files - using version from save
[01/29/2014 - 11:37:54PM] warning: Function Critter.KickOffOnStart.OnUpdate in stack frame 0 in stack 2083148 differs from the in-game resource files - using version from save
[01/29/2014 - 11:37:54PM] warning: Function Firefly..OnStart in stack frame 1 in stack 2083148 differs from the in-game resource files - using version from save

These 16 lines appear repeatedly. These are 8 fireflies. My guess is you hand removed the usual Loading and "VM is thawing..." lines, so these are appearing on each savegame load. As I stated before, these are stuck in an infinite loop trying to load 3D. Once you go to where they are, hopefully loading 3D will kill the loop. But you'll have to figure out where they are....

[01/29/2014 - 11:16:50PM] [critterFish < (FF0013BB)>]CheckFor3D() [critterFish < (FF0013BB)>] 3D failed, counter = 0/8.
[01/29/2014 - 11:16:51PM] [critterFish < (FF001B4A)>]CheckFor3D() [critterFish < (FF001B4A)>] 3D failed, counter = 0/8.
[01/29/2014 - 11:16:51PM] Critter [critterFish < (FF0013BB)>] just killed itself.
[01/29/2014 - 11:16:51PM] [critterFish < (FF002607)>]CheckFor3D() [critterFish < (FF002607)>] 3D failed, counter = 0/8.
[01/29/2014 - 11:16:51PM] Critter [critterFish < (FF001B4A)>] just killed itself.
[01/29/2014 - 11:16:51PM] Critter [critterFish < (FF002607)>] just killed itself.

This is good news! Here an infinite loop has been replaced by a counted loop, and they've cleaned themselves up!

[01/29/2014 - 11:17:27PM] [Firefly < (FF000855)>]OnCellAttach() had failed to kill self OnCellDetach
[01/29/2014 - 11:17:32PM] Critter [Firefly < (FF000855)>] just killed itself.

Here is a pair illustrating bloat that's been sitting in the savefile since before USKP 1.3.3 -- now it's gone! Note that 855 is a fairly low number, so it's been in there for a long time....

[DayDreamer]

Uber quick non-scientific results - I was able to take two different freshly minted chars on a round trip around Lake Ilinalta. Loads of critters spawn there. Not a single error in the logs.

 

Loaded up one of my old saves, got a boatload of spam, but then checked and discovered they were for refs already in the save from before. The good news is, they SEEM to have become invalid after the test which suggests they will go away even though they spam errors saying they can't be deleted.

 

So that could be encouraging - reduction in already existing bloat. I'm going to go ahead and package these with an updated beta to get this in front of more eyes.

Woke up this morning, and realized I have a bug in the interlock code (without even looking, the sleeping brain is a wonder). Fixing it should allow even more bloat to remove in the future.

 

Need to see your critter log spam from old games. That would be something else I didn't catch properly. Or a debug line I missed.

[Screwball]

As far as critter log spam (errors) is concerned the updated beta is looking good. Just been to multiple locations (which have been giving me serious grief over the past couple of days) and my logs have remained clean. Earlier saves (which already produced spam) still produce it, but I've not continued from those saves for long enough to know if they eventually disappear.

Definitely a step in the right direction, even if the changes are [NR].

 

One thing which does need addressing at some point, though, is that the critters (Lunar Moths, for example) are no longer moving realistically. They move alright, but slowly, as if they are just "floating" around, and they're not playing their animations properly (wings don't flap). Can anyone else confirm this?

[DayDreamer]

As far as critter log spam (errors) is concerned the updated beta is looking good. Just been to multiple locations (which have been giving me serious grief over the past couple of days) and my logs have remained clean.

Thank goodness!

 

Earlier saves (which already produced spam) still produce it, but I've not continued from those saves for long enough to know if they eventually disappear.

Need those logs. And the (long specified) timeout for cleanup is 10 seconds, so please continue the saves for at least that long. I've been going inside and counting to 25 during testing.

 

Definitely a step in the right direction, even if the changes are [NR].

Everything I've done should be retroactive. I've put a lot of effort into making it retroactive. But that 3d loaded infinite loop (already fixed in the previous beta) may be [NR].

 

One thing which does need addressing at some point, though, is that the critters (Lunar Moths, for example) are no longer moving realistically. They move alright, but slowly, as if they are just "floating" around, and they're not playing their animations properly (wings don't flap). Can anyone else confirm this?

I thought so, too. That's probably the DoPathStartStuff() fTakeOff -> TakeOff?

UPDATE: yep, a copy & paste bug in my code, comparing to vanilla it should read (note the 1.0):

Function DoPathStartStuff()
	; Transition to the flight state
;!	SetAnimationVariableFloat("fTakeOff", 1.0);
	SetAnimationVariableFloat("TakeOff", 1.0); [USKP 2.0.1]
endFunction

[DayDreamer]

There's a lot of terribly inefficient code. Sclero proposed 1 change in #7, but there are others. I've already moved some constant expressions out of loops. How much code cleanup do we want to do?

[Screwball]

Just to be clear - I'm talking about the updated Beta posted by Arthmoor, not the mod you posted a few posts up.

 

The savegames I'm using are the ones I uploaded here - the second of which (Save 17) should produce errors the instant it is loaded. I have the original logs, if you want them, and I can take one of those saves and continue playing for a while, if that would help.

 

[NR] - 2.0.1 Beta update or your extra mod? (which I've not d/loaded).

 

fTakeOff > TakeOff. I'm sure I saw the "cannot find variable named Takeoff" error, (Takeoff, not fTakeOff or TakeOff) but for some reason it's not in any of my kept logs. I've had so much trouble with the general critter spam that I've had to cheat like hell to get past them (COC between locations so no chance of encountering critters), which involved me not bothering with the logs, temporarily. If I see it again I'll log it.

[Screwball]

There's a lot of terribly inefficient code. Sclero proposed 1 change in #7, but there are others. I've already moved some constant expressions out of loops. How much code cleanup do we want to do?

 

 Enough to get rid of any errors and prevent savegame bloat, if possible. Anything beyond that is, I would suggest, overkill at present given the volume of outstanding issues. Not to be dismissed totally, of course, but kept for when there's time to look at it carefully. If it doesn't really impact on gameplay then temporarily put it to one side - can't go rewriting the whole game...

[VaultDuke]

Efficient code is good on the long run since it takes pressure from the papyrus engine. And if efficient also means streamlined and easier to maintain and fix then i think go for it. If in the current state it just means extra work and potential new errors for a few ps faster code, then take it easy.

[DayDreamer]

The savegames I'm using are the ones I uploaded here - the second of which (Save 17) should produce errors the instant it is loaded.

Thanks, you didn't mention those savefiles on this topic, so I didn't know about them.

As to Save 17, you have 3 fireflies locked into infinite loops. I'm going to explain, for the record.

Vanilla:

	while(!landingMarker.Is3DLoaded() && is3DLoaded())
		wait(0.1)
	endWhile

If the invisible landing marker hadn't loaded, but the visible critter had loaded, it waits.

Vanilla had an escape. If the visible critter isn't loaded, it continues, not stuck in the loop.

Certainly, there could be a bug. The visible critter takes longer to load than the invisible marker, so it's not a very good test. After continuing, later Translates might not work. (Documentation says they will, but I'm not sure.)

USKP 1.3.3 and 2.0.0:

	while !landingMarker.Is3DLoaded()	; BUGFIX BY STEVE40
		wait(0.1)
	endWhile

The "fix" was terrible! And it was done in many places! It became an infinite loop. You will never be free of it. You might as well quit that game, unless there is some way of clearing individual stacks.

The proper fix is to return a boolean after the loop fails, so that the critter can clean up:

Bool Function PlaceLandingMarker(ObjectReference arTarget, string asTargetNode)
; ; 	Debug.TraceConditional("Critter " + self + " placing landing marker " + landingMarker, bCritterDebug)
	if !CheckFor3D( landingMarker ) || !CheckFor3D( arTarget )
		DisableAndDelete()
		return true
	endIf

Note this also checks the target, assuming everything has to be loaded to work properly.

 

EDIT: I forgot to mention that STEVE40 had fixed his infinite loop in later versions, but that never got into USKP. So I give him credit for the fix, because he did provide a proper fix later.

 

UPDATE: I forgot to mention that save 15 had no problems. It cleaned up nicely.

[Arthmoor]

My logs won't be of much value since I was conducting the test with what's in the current beta. So it was just your typical complains about not being native objects bound to blah blah blah. They were relatively low FF IDs, which I could verify were in the save by loading in another location and using prid to grab hold of them. So they're stuck on old copies of the script. For all I know these things are part of why I occasionally get stack dumps just wandering around. This new code shows some promise toward finally ending that.

 

As far as making it more efficient, cleaning it up, I say go for it and whatever is done by the time we're ready to go live (probably next week) will do.

[Screwball]

I did mention it - in the issue (14686) where you reminded me you couldn't download the first upload. Might be an idea to "follow" tracdown issues you reply to

 

I already reverted to a savegame prior to #17 where the issue didn't exist, though as noted above I had to cheat like hell to prevent it happening again.

[Screwball]

 @Arthmoor - there are several re-raised issues which relate to existing ones marked "fixed" but which are still happening. Would be good if they could be re-looked at prior to the full public release.

[Arthmoor]

You'd need to point them out since closed issues don't generally get followed.

 

As far as ones saying they've been fixed, I'd wager a good portion of them are NR and can't be fixed since they're locked in 3D loops and such.

[Screwball]

They're new issues - tracdown numbers - which relate to existing/fixed issues (because of the "old issues aren't followed" issue)

 

http://www.afkmods.com/index.php?/tracdown/issue/14681-duncgfxbirdfleescript-object-reference-has-no-3d/

http://www.afkmods.com/index.php?/tracdown/issue/14683-pf-carryfirewood-000d97fa-cannot-call-changecarrystate-on-a-none-object/

http://www.afkmods.com/index.php?/tracdown/issue/14690-defaultdisablehavokonload-unable-to-call-various-functions-no-native-object-bound-to-the-script-object/

http://www.afkmods.com/index.php?/tracdown/issue/14691-draugrfxscript-unable-to-call-getsex-no-native-object-bound-to-the-script-object/

http://www.afkmods.com/index.php?/tracdown/issue/14692-qf-we31-000753ca-ff000ca8-has-no-3d-and-cannot-be-equipped/

 

Plus some new ones and some variants on older ones. Anything posted (as a new issue, by me and possibly BlackPete) since the 28th

 

Bear in mind that this is a brand new game started after the release (and installation) of 2.0.1 beta, so [NR] issues shouldn't apply.

[DayDreamer]

They're new issues - tracdown numbers - which relate to existing/fixed issues (because of the "old issues aren't followed" issue)

Thanks, but these aren't critters. Could somebody please move the past 3 messages into the USKP thread?

[BlackPete]

Some more critter errors (in spoiler below) with the most recent release (01/29/14) of the USKP 2.0.1 beta.

Note: this was on an existing game, so probably more "baked in data".

[01/30/2014 - 05:27:18PM] error: Cannot call getDistance() on a None object, aborting function call
stack:
[ (FF000F12)].critterMoth.OnCritterGoalReached() - "critterMoth.psc" Line ?
[ (FF000F12)].critterMoth.OnTranslationComplete() - "Critter.psc" Line 855
[01/30/2014 - 05:27:18PM] warning: Assigning None to a non-object variable named "::temp19"
stack:
[ (FF000F12)].critterMoth.OnCritterGoalReached() - "critterMoth.psc" Line ?
[ (FF000F12)].critterMoth.OnTranslationComplete() - "Critter.psc" Line 855
[01/30/2014 - 05:27:18PM] error: Cannot call getDistance() on a None object, aborting function call
stack:
[ (FF000EAE)].critterMoth.OnCritterGoalReached() - "critterMoth.psc" Line ?
[ (FF000EAE)].critterMoth.OnTranslationComplete() - "Critter.psc" Line 855
[01/30/2014 - 05:27:18PM] warning: Assigning None to a non-object variable named "::temp19"
stack:
[ (FF000EAE)].critterMoth.OnCritterGoalReached() - "critterMoth.psc" Line ?
[ (FF000EAE)].critterMoth.OnTranslationComplete() - "Critter.psc" Line 855
[01/30/2014 - 05:27:21PM] error: Cannot call getDistance() on a None object, aborting function call
stack:
[ (FF000E70)].critterMoth.OnUpdate() - "critterMoth.psc" Line 106
[01/30/2014 - 05:27:21PM] warning: Assigning None to a non-object variable named "::temp9"
stack:
[ (FF000E70)].critterMoth.OnUpdate() - "critterMoth.psc" Line 106
[01/30/2014 - 05:27:22PM] error: Cannot call getDistance() on a None object, aborting function call
stack:
[ (FF000DBB)].critterMoth.OnUpdate() - "critterMoth.psc" Line 106
[01/30/2014 - 05:27:22PM] warning: Assigning None to a non-object variable named "::temp9"
stack:
[ (FF000DBB)].critterMoth.OnUpdate() - "critterMoth.psc" Line 106
[01/30/2014 - 05:27:23PM] error: Cannot call getDistance() on a None object, aborting function call
stack:
[ (FF000AC4)].critterMoth.OnUpdate() - "critterMoth.psc" Line 106
[01/30/2014 - 05:27:23PM] warning: Assigning None to a non-object variable named "::temp9"
stack:
[ (FF000AC4)].critterMoth.OnUpdate() - "critterMoth.psc" Line 106
[01/30/2014 - 05:27:23PM] error: Cannot call getDistance() on a None object, aborting function call
stack:
[ (FF000CDD)].critterMoth.OnCritterGoalReached() - "critterMoth.psc" Line ?
[ (FF000CDD)].critterMoth.OnTranslationComplete() - "Critter.psc" Line 855
[01/30/2014 - 05:27:23PM] warning: Assigning None to a non-object variable named "::temp19"
stack:
[ (FF000CDD)].critterMoth.OnCritterGoalReached() - "critterMoth.psc" Line ?
[ (FF000CDD)].critterMoth.OnTranslationComplete() - "Critter.psc" Line 855
[01/30/2014 - 05:27:24PM] error: Cannot call getDistance() on a None object, aborting function call
stack:
[ (FF000EB1)].critterMoth.OnUpdate() - "critterMoth.psc" Line 106
[01/30/2014 - 05:27:24PM] warning: Assigning None to a non-object variable named "::temp9"
stack:
[ (FF000EB1)].critterMoth.OnUpdate() - "critterMoth.psc" Line 106
[01/30/2014 - 05:27:25PM] error: Cannot call getDistance() on a None object, aborting function call
stack:
[ (FF000EAE)].critterMoth.OnUpdate() - "critterMoth.psc" Line 106
[01/30/2014 - 05:27:25PM] warning: Assigning None to a non-object variable named "::temp9"
stack:
[ (FF000EAE)].critterMoth.OnUpdate() - "critterMoth.psc" Line 106
[01/30/2014 - 05:27:25PM] error: Cannot call getDistance() on a None object, aborting function call
stack:
[ (FF000F12)].critterMoth.OnUpdate() - "critterMoth.psc" Line 106
[01/30/2014 - 05:27:25PM] warning: Assigning None to a non-object variable named "::temp9"
stack:
[ (FF000F12)].critterMoth.OnUpdate() - "critterMoth.psc" Line 106
[01/30/2014 - 05:27:25PM] error: Cannot call getDistance() on a None object, aborting function call
stack:
[ (FF000F0F)].critterMoth.OnUpdate() - "critterMoth.psc" Line 106
[01/30/2014 - 05:27:25PM] warning: Assigning None to a non-object variable named "::temp9"
stack:
[ (FF000F0F)].critterMoth.OnUpdate() - "critterMoth.psc" Line 106
[01/30/2014 - 05:27:26PM] error: Cannot call getDistance() on a None object, aborting function call
stack:
[ (FF000E67)].critterMoth.OnCritterGoalReached() - "critterMoth.psc" Line ?
[ (FF000E67)].critterMoth.OnTranslationComplete() - "Critter.psc" Line 855
[01/30/2014 - 05:27:26PM] warning: Assigning None to a non-object variable named "::temp19"
stack:
[ (FF000E67)].critterMoth.OnCritterGoalReached() - "critterMoth.psc" Line ?
[ (FF000E67)].critterMoth.OnTranslationComplete() - "Critter.psc" Line 855
[01/30/2014 - 05:29:30PM] [critterMoth < (FF000E70)>]CheckFor3D() [critterMoth < (FF000E70)>] 3D failed, counter = 0/8.
[01/30/2014 - 05:29:30PM] [critterMoth < (FF000E6F)>]CheckFor3D() [critterMoth < (FF000E6F)>] 3D failed, counter = 0/8.

[DayDreamer]

Some more critter errors (in spoiler below) with the most recent release (01/29/14) of the USKP 2.0.1 beta.

Note: this was on an existing game, so probably more "baked in data".

 

Please post the savegame in weird stuff. That's an event, and the latter lines indicate it has the new CheckFor3D code. But the other line numbers don't come close, so it looks like odd incompatibility. Are you sure you don't have some old *.pex files hanging around?