Changes in the game-engine with the Skyrim update v1.6 may cause CTD or Papyrus errors/warnings in some mods.

This is caused by Papyrus functions being run on refs that don't have 3D loaded. Before v1.6, one could perform these functions no problem.. wouldn't even return a warning or error; but now one needs to place an is3DLoaded() check before running certain functions (or take some other measure to ensure the 3D is loaded before the function is run). Errors may also occur with other functions if certain things haven't been filled or created, whereas before they worked uneventfully.

EXAMPLES:

PlayIdle()
- error: (formID of ref): has no AI process, so no idle can be played..

unEquipAll()
- instant CTD

(doing a check on an array that hasn't been created yet)
- error: Cannot cast from None to Form[]
(that error occurs by doing a check to see if the array=none; which then triggers the following errors because the array isn't created in the script if it doesn't exist already)
- error: Cannot create an array into a non-array variable
- error: Cannot access an element of a None array
(that error occurs for each iteration of the array; eg- myArray[10] will return 10 of these errors)


Who knows how many other functions are affected by these fundamental changes, which noone seems to have taken the time to conspicuously notify us of. If modding is so important to the business model, this over-reliance on the free labor of the community to identify and solve problems is getting a little out of hand.

As far as I know, Papyrus has always thrown errors when trying to perform operations like TranslateTo on objects that don't have their 3d loaded yet. If those other behaviors are new, though, that is unfortunate...

sorry.... ...that just is so funny to me because there are a LOT of things like this, not just a lack of information/updating us mushrooms.
There is defiantly some kind of love hate issue with Bethesda and moders. I believe them when they say they love us moders, but is seems like in the same way some guys love their girlfriends.

Following is a list off the top of my head of things they could do to help nurture moding, but I am sure there is a combination of good reasons that they do not do so. (legal, proprietary, wanting to make their own versions of some things before moders do, priorities, just plain cannot understand moders needs because they are professional DEV not moders, upper management restrictions, mistake or issues they do not want to have to admit to or document, $, programing limitations, moders can get annoying sometimes on some issues so the enthusiasm may not always be there, they know some things so well that they forget we do not... etcetera).

If there is no good reason not to however they would show us their love a lot more by doing so rather than just telling us they love us...


The list (off the top of my head):

1, Allow their tech staff more freedom to post, 90% of the question we ask here could easily be answered by their staff in a few seconds.
2, Make a save game cleaner (to remove scripts and other errors).
3, More information about reducing script lag. about 4 INI tweaks did a LOT for me (went from 1 second to 1/2) , so I know there must be MORE that can be done on their end.
4, Put on the wiki what the Condition's, games settings and more importantly animation variables do. The SKSE team could be wasting weeks of their time on functions that these variables can already do.

err... my lunch time is over, I will com back and add to this list, feel free to add to it yourself...

not only that, but really REALLY simple stuff like:

since the vanilla game has x number of whatever (be it races, armor slots, etc) and knowing full well rule of one applies to any FormID, would it really hurt to consider that there may be something in the future that adds onto the system (be it mods or DLC)

examples:

on armor perks: WornApparelHasKeywordCount ArmorMaterialLeather == 4
which means, this perk will only work if the number of returned keywords is exactly 4. no more, no less. using >= instead of == would not only allow for future-proofing the system, but it still works perfectly fine with the vanilla armors. sure, anyone can go and fix this, but it means that every perk-based mod must also include this fix or else it will undo the previous mod's fix. DLC is not immune either, because since those are esm's all esp based mods made before the hypothetical DLC would inadvertantly undo these perk records.


on races: dialogue -"oh you're a " - would it really kill to have a none of the above option? doesn't dawnguard add an additional race? so now they have to go back and change this quest, when all it takes is 2 min of "what if" to realize that it may be possible to add more races in the future, and adding an unknown to the equation would have future-proofed it.

there are so many other aspects related to race that are designed with absolutely no regard to future expansion (vampire/werewolf transformation, formlist-locked headparts, etc) and the fact that you cannot "extend" an existing race using a new form entry, which would have probably solved more than half of these issues (the copy from morph race is not even close)


but of all things the worst oversight is papyrus script-embedding into save games with absolutely no regard to uninstallation/garbage collection. to make matters even worse, they push the steam workshop as a modding distribution, when in reality the "set it and forget it" mentality of that design makes this issue even worse than it already is (it is virtually impossible to properly uninstall scripted mods from SW without severely risking damaging your save game permanently)

I dunno about that. This one has been coming up for ages, long before Patch 1.6:

[07/11/2012 - 01:28:53PM] error: Object reference has no 3Dstack:    [ (0001E68C)].Sound.Play() - "" Line ?    [ (000EBAA9)].fxDustDropRandomSCRIPT.OnLoad() - "" Line ?

It isn't causing crashes even now with 1.6 but it's sure annoying as hell that it contaminates the log with this at regular intervals. The messages pretty clearly tells me that the 3D needs to be loaded for this to work.

Everyone: I didn't mean to make this thread out to be a rant, but to educate people about strange crashing or behavior since the new update, AND to post other functions/procedures that cause the same thing (since 1.6). BUT it kinda seems to be rant-fest up in here, so I might as well join in... ("if everyone is jumping off a bridge.." then there's probably a good reason for it!)


Verteiron and Arthmoor: Yea.. the translateTo and various other functions have always returned errors or warnings, I knew about those for a while. My issue is that the above functions used to work perfectly well (and without warning/error) BEFORE v1.6 - so something was fundamentally changed in the game-engine. This almost certainly is the case because the unEquipAll() function in the Actor script is completely empty... presumably because it's hardcoded. All the above errors don't even MENTION 3D loading... one of em I had to fool around with the script just to narrow down the cause first (unEquipAll), then had to experiment to fix all of them. Thankfully it only took about 30 minutes total, but it coulda been nightmarish!

The unEquipAll() is actually what's causing my Vanilla Mannequin Script Fix to cause CTD post v1.6 (though I already uploaded the fix/new version for it, posted on the Nex)... and it doesn't warn you, no error, just straight out CTD (because my onCellAttach calls that function eventually... and it isn't even CLOSE to being at the beginning of that event!). As a side note, I dunno if you guys have noticed but there are a ton of NEW functions and events added in the v1.6 update (such as the onEnable event, as shown in the new mannequinActivatorScript)... can't wait to see what drama THAT causes.


spookyfx: I agree with most or all of what you said... and much of it are semi-valid reasons. Without trying to turn this thread into a full-blown rant-at-MaBeth thread, I can only summarize in that they shouldn't be so far removed from modders... they claim that modding is essential to the game series, and HAVE gone to great extents to cater to us; but it seems more and more like weak patronization instead of genuine catering. They give us just enough to get by, and even that has several problems which we are left out in the cold to fend for ourselves with.

As far as I know, there isn't ANY participation in these forums from actual employees, which I assume is due to non-disclosure agreements. Could they not at least hire ONE ombudsman?? Maybe there ARE employees, but they can't divulge their identities... but if that were the case, I'd think we'd have more warnings and faster solutions instead of making our own.

I REALLY wasn't gunna pick your response apart, but now I can't resist (so just skip this whole super-paragraph if adverse)... "legal, proprietary" - I doubt that's the case, these are bugs, not hacked out options (like NIF exporting); "wanting to make their own versions of some things before moders do, priorities" - then they shouldn't plan to release the SDK/CK when the game is released (which, as we all know didn't even happen); "just plain cannot understand moders needs because they are professional DEV not moders" - I don't buy that because I'm sure some of them WERE modders, and just because they get paid for it doesn't mean they're professional or better (not for nothin); "upper management restrictions, mistake or issues they do not want to have to admit to or document" - maybe the best argument but in my opinion holds no water; $ - really? Skyrim has sold for over 1/2 billion amerikan dollars so far AHEM (do the math; though I concede not ALL that goes to Ma Beth); "programing limitations" - which they know about but choose not to document in publicly or include in a change-log; "moders can get annoying sometimes on some issues so the enthusiasm may not always be there" - I assume most of us wouldn't get annoying if this relationship wasn't to one-sided (like being sent to boarding school for 13 years because of parental "love" heheh); "they know some things so well that they forget we do not" - another good reason which may be 'the number one answer' (Family Fued style)


Amethyst: heheh.. sounds like you're more frustrated than I am when it comes to this kind of stuff

sorry, just had to let off some steam. pun intended. definitely frustrated after long hours and endless nights trying to pvssyfoot around domino-effect issues caused by very simple oversights and macguyver'ing some kind of wacky mickey mouse rig to get around them.

dont get me wrong. i'm sincerely grateful we even get to mod the game at all, and beth's support thus far has been far beyond most of the other major studios. but good god is it frustrating when you can see extremely simple solutions that could have prevented a hornets nest of complications. and i'm not just spitting out "modder's self-entitlement" here, this goes for any potential DLC's and just efficient systems design in general. speaking from a strictly development point of view, game designs should account for expandability, even if that game never even offers modding at all (just even for the sake of patching and expansion compatibility with itself). i understand that when you have a game that has a dev team consisting of lots of people it becomes hard to "proof-read" your game/systems design as a whole, and that none of this could even be caught at the QA level unless someone was hired specifically to look for it, it's still frustrating none-the-less.

just my steamy 2cents, and not finger-pointing over at beth

Full agreement on the frustrations brought on by apparent oversights on the part of gamesas when it comes to extensibility. Even in their own scripts, you can see their developers working around the limitations imposed by the engine and exposed scripting functions. Check out the code the Spriggan use to call animals to their defense... FindClosestActorFromRef's limitation bit them there. There's no way to do simple, apparently straightforward things like find out what the player is aiming at. There are oversights like a lack of a MovableStatic property type.

And the bugs... lord, the bugs. I know somewhere I saw a gamesas dev assure us this really is the same software they developed the game with. My hat is off, and my heart aches for them

Here's another priceless gem I just discovered... and it wasn't the case pre1.6...

Actors with enableAI(false) will sometimes turn to 'ghosts' within 10sec of onCellLoad (and/or possibly attach, I haven't tested it far enough yet). Their collision disappears and Player may no long interact with them; leaving the area then returning allows the collision to return, but may disappear again. I dunno yet if this is caused by some other function I'm calling in my onCellAttach, but I know if the AI is true then it nevers ghosts-out.

Why should anyone care? AI-false mannequins that don't use the clumsy collision-box system have to be finagled in order to properly work. Also, any actor that has AI disabled for whatever reason is potentially affected.

[EDIT: also, doing a moveto on an actor whose 3D isn't loaded yet will potentially send it up in the air. I haven't tested this that much either, but I know putting the is3DLoaded before the moveto (in an onCellAttach) prevents the floating actor. And neither the moveto nor the enableAI(false) returned any errors or warnings in the Papyrus log.]

In reference to your edit, I've found the same thing happens even when 3d is loaded sometimes. An early script I was messing with to simulate banishing NPCs for a set time worked by disabling their AI and translating them, very quickly, to z = -10000, then back to their original point (didn't use Disable because if they were talking while being banished, the dialog would continue). About once every 5 times, the actor would suddenly fly into the air after being translated back, often high enough to kill them on the landing. And this was months ago...

[07/12/2012 - 09:20:08AM] Cannot open store for class "ARTH_OCS_JorrvaskrTriggerScript", missing file?[07/12/2012 - 09:20:08AM] error: Unable to bind script ARTH_OCS_JorrvaskrTriggerScript to  (02018C6E) because their base types do not match

Something else that can potentially lead to CTDs. Forgetting to make sure a new script actually makes it into your final product.