Athelbras

Yep, I am aware of how Utility.Wait() functions. I use it in various ways and it works correctly on the PC. However, it potentially misbehaves on the Xbox One, as per my initial post.

My own mod. In a pair of scripts with simple invocations. Feedback from Xbox One players.

It appears that the Utility.Wait() function works as expected on the PC, but potentially causes issues on the Xbox One. The behavior seems to vary from player to player. Xbox One: - A message box containing multiple choices that immediately follows a Wait might not be displayed, with a non-zero button click value being returned from its Show(). Or the message box might be displayed and work as expected. - The Wait may cause the script to "crash" with no execution of the remainder of the script. So this is just an FYI for those who are 'porting an FO4 PC mod to the Xbox One with scripted Waits.

Other areas that manifest the problem, and which I used for testing, are Vault 3 and the REPCONN Facility at the REPCONN Test Site.

Summarized Update: The results of further investigation tentatively indicates that the presence of various interior cell illuminations, and the lighting / alpha of an object, was merely coincidental. The root cause is now conjectured to be the use and/or misuse of Room Markers, and the effect they have upon objects as the objects transition into and out of those bounded areas. Detailed Update: Looks like cell "lighting" was merely a coincidence with regard to areas of object visibility and invisibility ... The Helios One entry way (HELIOSOnePlan interior), plus initial sections of its two adjacent corridors, are within the bounds of a Room Marker (highlighted via a blue-boxed zone in the GECK's rendering window). While within the bounds of that room marker, objects remain visible. When objects are moved beyond the bounds of that room marker (to be outside of the blue box), they become invisible. Extending the boundaries of that Room Marker enables objects to remain visible in places where they previously vanished - and they continue to remain visible as long as they are within the confines of that extended Room Marker. Similarly, removal of the Room Marker enables objects to be visible everywhere, but it is likely that there are other things dependent on its presence. In general, there is potentially an adverse effect if objects transition across Room Marker boundaries, whether into another such Room Marker or into/out-of an unmarked area. - * - The implication is that various interior cell locations would need to be suitably revised in order to resolve this vanishing object issue overall; i.e. changes which appear to be far beyond the scope of my own mod. It is unclear as to why some objects (including "vanilla" objects) are affected and others are not. [ Thanks are extended to Roy for assistance in gaining this insight ]

I am willing to provide a simple test case .esp, with appropriate saved game(s), for anyone who might be interested in pursuing the issue.

The invisibility issue strikes again ... I was hoping to use the Mother Ship model in one of my "Whirly" variations, but it too exhibits the problem. Nothing restores it to visibility, other than leaving the area of invisibility, which can be quite extensive. Hopefully, at some future date, a knowledgeable modeler with insights into model Lighting and Alpha Properties will investigate and discover which specific settings a model must have, and not have, to remain visible at all times, everywhere.

An update ... The issue does not appear to arise from, or be affected by, rescaling objects from 1:1 via scripting. And it occurs for some vanilla models, but not for others. Unfortunately, I do not have the knowledge to understand individual model Lighting / Alpha properties, much less tinker with them. However, I was able to [knock on wood] get my original Whirly and Rocket Whirly to work correctly without resorting to NVSE, but various workarounds were required. The one continuing casualty is Jokerine's model for Playground UFO (aka UFOHang.nif from the original download) - absolutely nothing fixes the disappearances, not even NVSE's Update3D. And it is not the result of reworking the vanilla model (ufofort01.nif) - that exhibits the same problem.

The UFO variant of my mod has an NiAlphaProperty record containing a flag field set to 4844 with a Threshold of 90. The other of the two is 4845 with 0. So should those be changed?

Yes, there are multiple instances of NiAlphaProperty. The mod is called Whirly. Resources are packaged in a BSA file, with the model located at \meshes\whirly\whirly.nif. Note that collision data has been removed from that particular variant of the model, but similar troubles exist for the original as well; that one might only exhibit the corner problem or perhaps at the lights as well. Whirly can be readily found in Goodsprings Saloon - just activate the Vertibird. At which point nothing else need be done other than travel around to places for testing.

Hiya Roy! I was not aware of Update3d - likely because I avoid using NVSE (or similar libraries) in order to not impose them on players when not really required by my mods. So I used Console commands, instead of scripting, to test as you suggested ... Yep! Upon entering a new cell and issuing Update3D the model no longer disappears at the places it did before - which were readily identifiable light sources. It can be issued immediately upon a cell transition, regardless of current visibility, and it works as desired at those locations. However ... it then causes the model to disappear in areas where it did *not* do so before. For example: after entering Helios One, go through the door on right and follow that corridor until you reach a corner with a Basket Ball and Cinder Block on the ground, plus a door on the left. The model now vanishes in that corner area. Issuing Update3d again at that point, whether the model is visible or not, has no effect. The disappearance happens regardless of whether an Update3d was issued upon originally entering the cell or is instead executed only when reaching that corner. However, by forcing a redisplay of the model via SetScale (as in set the model's scaling to something smaller and then back to the desired size) the model becomes visible. Note that the SetScale trick was something I was aware of but found to work inconsistently - and it does not in fact work for the light sources that the Update3d fixes. The next thing I tried was this: upon entering a new cell, immediately issue Update3d, followed by a SetScale for smaller resizing, then SetScale back to normal size. Now *that* sequence seemingly fixes all visibility issues within Helios One!!! Of course these test results are just preliminary, and need to be rigorously verified using updated scripting. But in the meantime there is indication of a viable solution (even though it may require NVSE). Thanks Roy! Your help with this is greatly appreciated. Much Regard, Athelbras

I have instances where an object (Misc Item) will vanish in variously-sized areas within an internal cell. When the object is moved outside of that area (which can be small to rather large) it becomes visible again. In addition, while seemingly invisible, if the camera view is rotated around the object it potentially becomes visible while viewed from a particular angle. The object is actually present and fully functional, with no disruption in audio or script processing, as it enters / remains inside / exits the zone of disappearance. In various places the invisibility seems to be localized around a specific light source, such as a lantern or ceiling light - but that is not always the case. This occurs for vanilla models as well as specialized mod-specific models. It happens regardless of use of an object from PlaceAtMe, or use of a Permanent / Temporary defined object for a Cell or World Space. Efforts to force redisplay via Disable/Enable pairs, temporary size alteration via SetScale, having a scripted light appear just above the object in hopes of having a positive effect, etcetera, are only infrequently effective as workarounds. Note: the above also holds true for a "Light" object with a specified model. My conjecture is that there is a rendering engine bug that causes this issue, depending on the specific focused lighting and/or ambient lighting at a given location within a cell. Is this known to be so? If yes, is there any way to counter that problem; some sort of workaround? I have tried many things, across countless experiments, but none are 100% successful in all cases. Good examples of test locations are: the Power Plant at Helios One (the entry way and heading along the corridor to the right), the Repcon Facility building at the Repcon Test Site (go left from the entry way), and Vault 3 (the corridors just beyond the entry chamber). Insights? Advice? Ideas? The problem is crippling one of my mods ... Athelbras

Well ... by golly ... I do believe I got it working, mostly, both for interiors and exteriors. But don't actually know *why* it works. This morning I began experimenting to see if I could resolve a secondary issue: as Whirly moves around, supposedly flying in the air, he pushes aside ground clutter that is in his way. Which of course is not visually appropriate since he is elevated above that stuff. So what I tried is this: I changed his skeleton's BSBound values to only encompass the model itself; i.e. to no longer extend down to the ground (although extending to ground level seems to be what's typical, e.g. Eyebots). With that change he still pushes ground clutter around ... but now he properly attacks enemies both indoors and out. Well, mostly: every once in a while he gets confused as before. But that confusion seems to be infrequent, and - very tentatively - can seemingly be cleared by moving him away from his target if/when he is clearly too close, then issuing a ResetAI, followed by a StopCombat. My current thinking though is that with a revised model / animations that are reworked to the desired size, without the need for down-scaling, it might solve the problem reliably, and without the need for special case handling as I described above. I'll report back here later after completing significantly more testing of things as they are right now, for those who might be interested in the results. But in the meantime ... many thanks to those of you who have participated in this discussion thus far. Regards, Athelbras

To close-out this topic ... MindBoggles very kindly provided instructions that enabled me to elevate the model to travel at a higher level above the ground; required editing animation files. Many Thanks!!!

At this point I am thinking it is simply the game getting confused as a result of either (1) the scaling-down of the model, or (2) because it is not happy with something about the model / animations. But don't really know. I did try various scaling factors (the desired 0.03 up through 0.5), wherever interior ceiling height allowed that - no improvements discerned. I also tried a multitude of min/max weapon range values, and none of them had noticeable effect indoors, although any combination worked fine outdoors. For much of my testing I used 100 / 300 since that pairing seemed reasonably appropriate for interiors; but again, I tried a great many lesser and greater values as well. Also tried the Fixed Range flag setting that ignores Combat Style modifiers, but with no success. Also set the Reach values to 100 in the creature record and ranged weapon record, which also matched the Min Range that I was using. That was done just in case the rifle was being used as a melee weapon. Didn't help. The current single package is the absolute minimal "Follow", with no invalid flag settings. I also tried a variety of the vanilla default packages, created variations, and tested Wander and Travel - all of which I have used copiously and successfully in the past for other companion mods. Given the observed characteristics of the central problem, I think packages are unlikely to play a role in the issue. Eventually, thinking that the game was perhaps getting confused when using a scaled-down model in smaller interior areas (even though it maneuvers around quite easily and freely), I tried a couple places that are quite expansive: McCarran Concourse and McCarran Terminal Building. I guess they are large enough to have characteristics similar to exterior cells ... because they actually worked most of the time, with only a rare exception. A medium-sized chamber (McCarran Supply Shack) would only work if I started the fight at maximum range, otherwise my creature (Whirly) always did the embed-nose-in-enemy-target routine. Although, interestingly enough, if the guy tried to run away and gained some distance between himself and Whirly, Whirly would suddenly become unconfused and gun him down. Note that altering min/max range values of the weapon while in that room had only marginal affect (no matter how small or how large the settings). Areas that have never worked include: Nipton Town Hall, Vault 3, and the various NCR CF buildings. And of interest is the fact that everything works correctly if some other unscaled model (and its animations) is used instead (with all settings, gear, AI, Combat Style, etc. staying exactly the same). Also, just FYI, a scaled-down Securitron and Deathclaw (two of my other follower mods) do not have these issues, although their down-scaling is much less significant. Very perplexing ... Athelbras

I have tried multiple different interior cells. Fails in all cases. Perceptions is 10 - all attributes are set to 10, and all skills to 100. Combat Style is set in the follow package (the only package), is set when the critter is initialized via scripting, and is the same as what is specified in the creature record. I have varied the CS from one that I tailored myself, to also trying existing alternatives (eyebot, sentry turret, etc.) - none of them make a difference: they all work in exterior cells, but never interior. Also, in all cases I confirmed that the appropriate weapon (the only one in its inventory) is equip'ed, that the creature is in combat, and it has acquired an appropriate combat target. Am kind of wondering now if it is attempting to invoke an unknown (to me a least) animation file (that is not used in exterior cells), and when failing to find it is getting confused. <shrug> But who knows. I am about to disappear for the day in just a couple of minutes (back later this evening), but could provide a rather small - very simplified - test case package with a couple saved games that exhibit the issue, with the player & critter positioned ready to start a fight, and make it available later this evening or tomorrow morning ... if you'd like to see for yourself. Regards, Athelbras

I have a Creature follower that works just fine in exterior cells for combat and movement. It is defined to use only ranged combat (no melee whatsoever), and across a variety of test cases it behaves as expected outdoors. But in any interior cell, once the critter acquires a target, it heads straight to that target and tries to reach the center of that target's model (possibly simply in an effort to get to that entity's x/y coordinate position) and continues doing that until it switches targets, the current target moves quickly away (at which point the critter follows to re-embed itself), or the current target dies (in which case it chases down a new target and does the same thing). At no time does it shoot. It happens regardless of circumstances. ResetAI has no affect, neither do changes in packages, combat style, weaponry, etc. The only obvious difference is interior versus exterior cell. I have several existing follower mods, including two "creatures", and have never encountered this issue before. Any thoughts on what the cause might be? Or suggestions on how to further troubleshoot it? I've spent a great many hours on this with no success, and have run out of ideas. It uses a new skeleton and model file (a vertibird), with accompanying animations. Could the problem perhaps have something to do with any of those things? [my knowledge of models and animations is almost nil] Oh, and if I simply switch to something else, such as an EyeBot, with all the various things otherwise being same (gear, combat style, packages, etc.) it then works fine, both for interior and exterior cells. Thoughts and suggestions will be greatly appreciated. Regards, Athelbras

I have .nif files for an NPC, both model and skeleton. Would like to adjust things so that the NPC has a different relative height from the ground. For example, take ED-E and lower it, or more specifically take my model and raise it so that it walks/flies higher above ground level than it does now. I have already spent many hours trying to figure things out myself - and failed miserably. So I would very much appreciate someone providing explicit details for each basic step to do that in Blender (i.e. walk me through the process), or else identify the specific data structures / data fields to be altered when using NifSkope. I have no prior knowledge of Blender (although I have installed it and tinkered a bit with no success). I have examined and altered various minor things via NifSkope in the past, so have (very) rudimentary knowledge of that tool. Alternatively, please point me at a beginner-level tutorial that specifically teaches how to do that exact alteration. Many Thanks, Athelbras

An alternative for New Vegas is to use FOMM v0.13.21. Its .bsa file browsing and packing appear to work correctly, especially for .wav, .ogg, and .lip assets. I've used it extensively for well over a year now and have not had any issues. But note that newer versions of FOMM can *not* be trusted for packing sound files.

@Jokerine: hooray!!! @mindboggles: thanks for the insights! I did not encounter that issue myself since Buddy Bot has Essential disabled. And, FYI, I invoke a Kill upon self-destruct specifically to prevent normal destruction, which then facilitates better control via scripting: the Kill causes him to shutdown and collapse, and the explosions rip him apart with various visual effects as he collapses.

The actual Eye-Bot death explosion may be iffy in the sense that perhaps it occurs only upon a "critical" death situation; not normal damage death. Just a conjecture.

Perhaps someone will offer a more "correct" solution that simply ensures the Eye-Bot explodes appropriately the normal way ... What I do for my Buddy Bot companion is as follows: MBFBuddyBotREF.PlaceAtMe MBFPulseExplosion MBFBuddyBotREF.PlaceAtMe FlashBangExplosion MBFBuddyBotREF.Kill Which yields spectacularly satisfying results when he self-destructs; and can similarly be used in the OnDeath block without the Kill command. MBFPulseExplosion is just a tailored variant of GrenadePulseExplosion. Regards, Athelbras

Fixed as of NMM 0.61.1. Athelbras

It appears that I have discovered an installer script bug in NMM 0.61.0 that did not exist in the 0.5x series. So this is a heads-up posting to alert other modders. My testing indicates that the fileDependency function no longer correctly detects a file's true state (Missing, Inactive, Active). The result is always determined to be Missing. Which means that install scripts that are designed to examine the DATA folder and then automatically choose from a set of options, will potentially fail to work correctly. This issue occurs (1) when used within a <visible> block that controls presentation of an <installStep>, as well as (2) when used within an installStep's pattern <dependencies> block. The case in point is our main EVE download which automatically chooses between All DLC, No GRA, and No DLC depending on which DLC .esm files are actually present and enabled/activated. That installer now always fails by choosing No DLC, when before with NMM 0.5x it would always work correctly for all options. The same problem exists for non-DLC files (.esm and .esp), even those already installed and activated using NMM 0.61.0. I posted an official bug report. Here is a link: http://forums.nexusmods.com/index.php?/tracker/issue-47365-fnv-script-processing-bug-in-nmm-06x/ Feel free to discuss, especially if able to refute my perception of there being a bug. Regards, Athelbras

What I do is make a duplicated item for my mod that refers to an edited version of the original mesh. The edit simply sets the Mass entry to 0 in the bhkRigidBody record. That causes the otherwise moveable object to no longer be moveable. For example, an original moveable wooden barrel thus became an immobile "water barrel" with a visible water overlay on its top, with drinking activation. Did that in my Goodsprings Tented Campsite mod. Might work for Turrets; might not.