i thought this might be a model-related issue, but nobody in the custom-content forum answered, so i thought i’d give it a shot here.
i’m trying to puzzle out how to make doors block [or not block] line-of-sight. i’ve started with a standard bioware door that, i believed, shouldn’t block line-of-sight. it’s the portcullis bridge door in the crypt tileset.
i thought line-of-sight was controlled by the door’s BlockSight entry in doortypes.2da , but that doesn’t seem to be the case. i was surprised to find out that my test door actually does block line of sight. this door is created from template nw_door_ttr_06.utd and further to the model tdc_udoor_07.mdl . it appears as TILE110DOOR0 in the .set file, which is a tileset-specific door whose index is 32. however, the entry for door 32 in doortypes.2da already has BlockSight set to 0…
I helped you once, so I’ll try another wild guess. Here goes.
What happens when you set a door with 1 there to 0? I assume this parameter only governs whether the door prevents area visibility of what’s beyond it. 0 is used by transparent area transition doors. LineOfSightVector probably ignores this file.
Even more peculiar, some doors, like nw_door_grate don’t have entries in doortypes.2da. This generic (read: tileset-agnostic) door does not block LOS. But it doesn’t appear in any 2da files, so the information how it works has to be in: every tileset data (doubtful), its template (but where) or its model (same).
You may try do a little experiment: switch models of blocking and non-blocking doors. This should tell if the information you seek is encoded in the model.
BTW, it doesn’t matter if the door has holes (grates, windows, etc) - if the door is set to block then the engine will render blackness beyond it until you somehow reveal the area there.
good call. apparently this actually has nothing to do w/LOS. it looks like it governs whether the area beyond the door is rendered or black.
since both nw_door_grate and nw_door_grate2 are generic doors, nwn gets its info from genericdoors.2da. the game first looks at the Appearance field in the door instance (you can also see it in the blueprint) ; if this field is non-zero, the game uses it as a reference into doortypes.2da. however, if it’s zero, the game then checks the GenericType field and instead uses that as an index into genericdoors.2da. in the case of nw_door_grate, this is a generic door of type 2, Porticullis, whose model is T_Door03. so i looked at T_Door03, which is a lot different to tdc_udoor_07 – but still have no clue as to why one doesn’t block LOS and the other does…
i’ll give that a shot. i’ll re-post when i get some more info.
as a control, i started w/a standard portcullis [generic door 2] in the crypt tileset on tile tcd01_a16_02 behind which i put an orc. i was able to shoot through the portcullis and hit the orc.
i then tried about two dozen different combinations of overriding TDC_UDoor_07.mdl w/T_Door03.mdl [made sure to change internal refs to correspond], TDC_UDoor_07.dwk w/T_Door03, entries for TILE110 and TILE110DOORx in tdc01.set, changed the entry in doortypes.2da to use the generic model, and even used nw-door_gate.utd directly in a couple of tests, but in all cases, i was unable to shoot an orc behind the portcullis ; the character runs up to the first portcullis and stops. in cases where i overrode the .set to use generic doors, the bridge did appear w/o doors and i was able to place generic portcullises, but even then – using exactly the same template, model, and walkmesh – the creature object was inaccessible.
strangely, i was able to ‘bash’ the far portcullis, shooting through the near one – just couldn’t attack the creature object. now i’m wondering if this is really a question of LOS, or if there’s something specific to creature objects interacting w/LOS that’s at play here…
there’s a lot in the bridge model and walkmesh i don’t understand [modeling stuff], so maybe it has something to do w/that.
Dang it, I missed this one - unlike doortypes.2da it doesn’t use ResRefs. I fixed my post.
Anyway, can you share screenshots from your tests? It would really make it easier to get the whole picture. Since these tileset-specific doors are placed via map paint tool, they probably have different behavior than the “normal” doors.
Speaking of normal doors, I tested this:
And the result is that BlockSight is everything for these doors. Nothing else was changed than this column in genericdoors.2da. I gave 1 to T_DOOR3 (portcullis) and 0 to T_DOOR1 (wooden “strong”). So, the one that should block LOS doesn’t and the other does.
Here are the results (with screenshots). I leave this here since this is also a useful resource.
I have a 2-room area with single door connecting them. SKELETOR is on the other side and checks PC with LineOfSightObject in its HB.
No-LOS portcullis blocks view of the other side and LOSO returns false
okay, i’ve got this one sorted. i admit to feeling a bit sheepish ; all that mucking about w/models and 2da’s and all, and the ‘problem’ was elsewhere… [one of those things where you end up asking yourself, ‘so why was i spending so much time on this again ?’]
it turns out it’s a feature of the LOS configuration on this particular tile, or tiles like it.
if you have both doors active and closed on the bridge, LOS for attacks is blocked. this is the case for all models and all door types i tested, whether generic or not.
if you place only one portcullis on the bridge [possible using generic doors], or you place both but one is open, behaviour is exactly as w/a portcullis in any other doorway – i.e., you get LOS and you can shoot through the portcullis.
so it seems this is a characteristic of the game engine itself. giving bioware the benefit of the doubt, i’m sure this must be a feature rather than a design oversight…
not sure whether or not the same rules hold for other configs w/2 doors, but i’ll assume so until i get a chance to test it.
@nwnshacker, thank you for all your help in this, my mad, misguided adventure.
[one of those things where you end up asking yourself, ‘so why was i spending so much time on this again ?’]