Standard Open Doors Have Collision In-Game

[ManehattanProject]

I'm having a strange somewhat inconsistent issue. I've set up utility doors throughout this particular facility. I've already configured massive amounts of them and they work fine. But in one of my cells, the UtlDoorBg01 will show the open animation, but an invisible wall will prevent a player from passing through the door. In the next cell, attached by teleporter door (which works fine), the NVDLC03UtlDoor01 variant does the same thing.

 

The only difference from my variant and the NVDLC03UtlDoor01 is that I changed the color of the light emitters on the "joints" in the door. However, I use the exact same doors in other places (purple, blue and green versions) and I have no trouble walking through the doorway.

 

When fired upon with a .44 magnum, the sound that plays is a bullet striking a glass or metal surface (It's the same one that happens if you fire at a NVDLC03 ForceField.)

 

I've checked the collision using F4 in the GECK, but there's no hidden collision item there. The door shows the normal "pink" of a door collision.

 

I've also had this problem with standard utility doors, but it only started to happen after I began to NavMesh some levels. However, neither of these levels are currently NavMeshed.

 

There's also the fact that sometimes it'll be the UtlDoorBg01 that works and the UtlDoor01 doesn't or vice verse. It's extremely inconsistent, but it's always one of the two and it's only in these two levels.

 

I have absolutely no idea why this is happening. Can someone throw out some suggestions?

[rickerhk]

We've actually experienced the same issue with vault doors in Project Brazil. Same symptoms you described. We haven't identified the cause(s), but I've noticed it may be more likely to happen if you make changes to a cell, then continue testing with the same save game.

[RoyBatterian]

If you modified the doors,maybe check the collision in nifskope against the original.

 

Are your doors also persistent?

[ManehattanProject]

If you modified the doors,maybe check the collision in nifskope against the original.

 

Are your doors also persistent?

 

Before I get to your questions, let me bring up something I discovered.

 

An “already set to open” UtlDoor01RED was REVERSED. When moused over, no open dialogue showed up unless you were mousing over the frame (As if it was already open). You could walk through it both OPEN and CLOSED.

 

It’s like the animation is playing (complete with sound), but the collision isn’t changing.

 

The UltDoorBg01 hasn't been changed. It's still the same basic one that's always been in-game. I made no changes to that model.

 

When I compared the GoENVDLC03UtlDoor01 variants (Purple & Red for this example), there was no difference between the two. Purple works fine. So does the NVDLC03X13UtlDoor01 (the base for all the lit doors). Both of these were in the same cell where the UltDoorBg01 still has collision when open.

 

When I get to the next cell, where I use the UtlDoor01RED does the open but collision thing.

 

When comparing GoEUltDoor01RED (or any other one) with NVDLC03X13UltDoor01, everything is the same in Nifskope until I reach the 179 line. In the Red/Purple ones, it shows "NiTriStrips TXT NVDLC03X13UtlDoor01:13 [116]." But the actual NVDLC03X13UtlDoor01.nif shows line 179 to be "NiNode TXT IKTrainMain [4]" There are several other differences progressively from there. For example, in the variant, NiNode TXT IKTrainMain [4] is on line 185.

 

What I don't get is why there's a change. The only thing I ever did to these was change the Emissive Colors. I did nothing else to the models. But even if I did, it doesn't explain why UltDoorBg01 isn't working.

 

As for permanent/temporary reference, in GoERFS4Security (where the problem first popped up and where the UltDoorBg01 isn't working), the UtlDoorBg01s (there's 2) are both temporary. Only the ones that are teleporters to other cells are shown as permanent and those work fine.

 

GoERFS4Manufactory uses at least a dozen GoENVDLC03UltDoor01RED (all but the open one not allowing a player to pass) and all are temporary save for the teleporter to the next cell.

 

In both levels, there are a few UtlDoorBg01 showing a permanent, but I believe those are the static ones (which is odd that they're showing as permanent. I may need to check the base static door to see if they're checked). Those are used for inaccessible areas for visual variety.

 

This is likely way too much information, but hopefully you can figure out what the hell I'm doing wrong here. I'm pulling my hair out when I go to playtest the level (which I do after every change).

[RoyBatterian]

You might want to make sure "auto sanitize" is unchecked in nifskope, that's the only reason I can see the IK being screwed up after editing the emissive colors.

 

Doors you can use probably should be set to persistent, they are in the base game and that's possibly why there is an issue as the open state might be getting confused. This is just conjecture though, however I have done that in mods now.

 

Perhaps TrickyVein would know something about this, I am still pretty much a beginner with nifs.

 

This does sound similar to collision problems people have with F3 assets ported into NV though...

[ManehattanProject]

I checked through some various cells and found that internal-only doors aren't set to persistent, but I checked the box anyway. No change. (For example, the 4 UtlDoor01 units in OVCentralSwers01 and the VaultDoors in NVDLC03ThinkTank leading to the Tank's personal quarters, all of these are not set as persistent).

 

I recreated the RED door variant .nif from the base NVDLC03X13UtlDoor01.nif with the Auto-Sanitize off. No change.

I changed the model being used by the GECK entry from the RED variant to the WHITE variant and the doors worked fine.

 

I recreated the RED door variant .nif from the base GoENVDLC03UtlDoor01WHITE.nif (the one that works mentioned above and with auto-sanitize off. No change.

 

I created a new door using the RED .nif with a different name "GoENVDLC03UtlDoor01Red02" and replaced all doors. No change, but in that test, the UtlDoorBg01 did work (both a GoEUtlDoorBg01 and the UtlDoorBg01. There's no difference save the name).

 

I placed all utility doors in the GoERFS4Security section. (Purple, Green, White, Red, Red02, UtlDoor01 (vanilla version), Blue & NVDLC03X13UtlDoor01). All doors work save for the two red ones. I also placed the GoEUltDoorBg01 and UltDoorBg01 in there. Both of those worked as well. That particular time, I opened a Red02 door that was already set in the wall (where it's supposed to be first) and could not pass through it.

 

I used the "GetOpenState" in console and the animations are showing correctly. (1 for open and 3 for closed).

 

That's the extent of my QA so far. I'm still going through variations. I'm also always running from the same "QA" save for consistent results. I'm always running through the previous cell and not just CoCing into S4Security (I noticed that seems to skew the results).

 

 

EDIT:

 

I've spent the last eight hours trying to troubleshoot and nail down this issue, using every possible thing I could think of. Sometimes the issue seems to start upon entering S3Labs. Sometimes it's S4Security. Sometimes it's S4Manufactory. I don't know what to do. The only scripts I have running are scripts to do basic "OnPlayRunForward" animations.

 

Here's my QA log if you want to see what I've tried: https://docs.google.com/document/d/1NbfmoCOtWp3iH5EOFQnY3EH-UVThbN7bJi2L15Dcb_A/edit?usp=sharing

 

I've checked the collision a dozen times. But the one consistency is that the door animation will play correctly with the correct sound, but if the mouse is still centered on the doorway, you'll get an activator option to close it the door. That's when you can't walk through it.

 

For some reason, opening the door is not disabling the collision and it's happening to both the vanilla basic UltDoorBg01 and only the RED variant of NVDLC03UltDoor01. At one point, I could get it to only happen to the UltDoorBg01, but once that happens, it will happen for ANY cell that uses that door type. (Even if the RED door stopped working, the other colors would remain working).

 

What could prevent a door from playing its animation but not drop its collision? Is there a way to force it?

Edited March 6, 2016 by ManehattanProject

[ManehattanProject]

I finally nailed down when the issue started happening. Thank God we do tons of iteration. I did a lot of NavMesh work to some separate levels...where I started noticing a similar problem, only it seemed to resolve itself after I adjusted some cover.

 

However, I just used FNVEdit's "compare" between V519 and 520 (520 is where the issue starts happening) and the information makes no sense when looking at the NavMesh data.

 

http://i.imgur.com/0Ra1kXY.png

 

It's matching up cells that have nothing to do with one another (or I'm totally reading this wrong). There are cells mentioned in here which I haven't NavMeshed yet.

 

Could this be the culprit?

Edited March 7, 2016 by ManehattanProject

[ManehattanProject]

I'm going to post this for anyone else who comes across this issue.

 

I finally nailed down what was causing my issue. One of my levels had an unfinished NavMesh. It was the level directly before the location with the problems. As soon as I removed it, the issue resolved itself. I remembered afterwards that I had a similar problem after NavMeshing another level. I suspect it has something to do with the cover system, but that's just a theory.

 

Thankfully, I had iterations and using the Compare filter in FNVEdit helped clue me in after going through each version of the mod to find what had been changed.

[Nimboss]

At first reading your initial first lines posting it sounded like an issue I once had, but the later info seems not likely.

 

When adding a door to a building in one of my mods I could not reach it in game, at all?! The reason was not the door but the general asset building in the game, it had no cut in the collision mesh where the door was placed, found out that by opening the building in NIFskope.

I think you already past that level of checking why things not work, but for someone new with issues like I had it could be a helper, if they can read more than a few posts in search of answers that is.

 

You have two among all the best posting in this thread so I would wait to see if they can come up with something for you. Also to have (700 already? checked in snap shots) of the development process give you a fair chance to go back to a safe version before the nastiness was introduced (the tools we use is not 100% bullet proof). Are you some kind of professional in RL? Because I seldom see someone taking the need of backups when modding to the heart like you seems to do. :smile:

 

The last post of you is disturbing, if things changed at places you not yet made any changes to you have a tool (G.E.C.K.?) that screwed up your save. In that case IMHO it's best to go one version back before this was introduced.

 

EDIT: Ah took me to long time to type this, blame it on to not be native in English, so you got first, glad you found the issue.

[ManehattanProject]

Oh yes. Roy especially has been of tremendous help with insane levels of patience for dozens of my random questions in the past. I'm always grateful for the insight of the best. Without their help, this would have never happened. At all.

 

I've always been huge on iteration. My real skill set is an author and I started doing that years and years ago because saves can be unpredictable. Occasionally I'll want something that I wrote previously and I want to have that always available. Our build numbers are also somewhat misleading. When we make a massive change or cleanup, we'll usually up it to the next tier (400, 500, etc.). I also do have some professional experience as did our former Technical Director, who set us up early on with the idea of iteration as a key component of design. I also formerly did both hardware/software tech support and have some experience building network infrastructure from the ground up. Those kinds of systems demand an extremely thorough iteration system.

 

And then there's the whole OCD thing. :D

 

I've learned this doubly so in GECK which is bloody unpredictable (especially when NavMeshing - thank God for autosaves).

 

Thankfully, it was iteration that saved us. I ended up loading each one until I found the one that didn't have the problem and compared it to the one immediately afterwards. I didn't want to restart from there because an ENORMOUS amount of work had been done already, stuff I really didn't want to duplicate, so instead I searched for the culprit and found it. :)

 

Thank you though! I'm just happy the nightmare is over (even if it took 12 hours of QA :P)