The Harvest Moon Consortium

[Pstemarie]

Working on a new building for my module. I'm having a great deal of difficulty getting the tile to accept doors in the Toolset. I've painted the door "dummy" (trv01_b03_02_D01) like you're supposed to, checked and confimred the orientation, and linked it to the AuroraBase (trv01_b03_02). In the .set file, I've got the door node setup correclty (AFAIKT) and the XYZ locations matched to the dummy node on the model. However, nothing appears in the toolset when I paint a door.

I haven't loaded any animations yet - could this be the problem, or is there another cause?

[Michael DarkAngel]

Generic or specific door?

If its a generic door, nothing will show up in the toolset until you select a door.

If its a specific door, you may have an issue with the 2da line number you are using in the .set file, or a bad listing in your doortypes.2da.

[Pstemarie]

Generic or specific door?

If its a generic door, nothing will show up in the toolset until you select a door.

If its a specific door, you may have an issue with the 2da line number you are using in the .set file, or a bad listing in your doortypes.2da.

I think I need to clarify a bit . The issue has nothing to do with doortypes.2da or the 2da line number called out in the .set file.

Code: Select all

[TILE15DOOR0]

Type=0
X=-72.0
Y=-314.0
Z=0.00
Orientation=0.00

The issue is specifically a model issue - the tile will NOT accept any type of door, either generic or specific doors (doesn't matter what type I select). I believe that when I set up the door "dummy" I missed some tiny detail in the rollout in GMax that prevents it from working properly.

[Pstemarie]

I think I need to clarify a bit . The issue has nothing to do with doortypes.2da or the 2da line number called out in the .set file.

Code: Select all

[TILE15DOOR0]
 
Type=0
X=-72.0
Y=-314.0
Z=0.00
Orientation=0.00

The issue is specifically a model issue - the tile will NOT accept any type of door, either generic or specific doors (doesn't matter what type I select). I believe that when I set up the door "dummy" I missed some tiny detail in the rollout in GMax that prevents it from working properly.

Having just posted this I now see my error - decimals in the wrong place in the .set file That door node should read:

Code: Select all

[TILE15DOOR0]

Type=0
X=--0.72
Y=-3.14
Z=0.00
Orientation=0.00

Just goes to show that sometimes you need to look at things out of context to see your mistake :thumb:

[Michael DarkAngel]

I think I need to clarify a bit . The issue has nothing to do with doortypes.2da or the 2da line number called out in the .set file.

Code: Select all

[TILE15DOOR0]

Type=0
X=-72.0
Y=-314.0
Z=0.00
Orientation=0.00

The issue is specifically a model issue - the tile will NOT accept any type of door, either generic or specific doors (doesn't matter what type I select). I believe that when I set up the door "dummy" I missed some tiny detail in the rollout in GMax that prevents it from working properly.

Okay.

First, you don't really need the door dummies. They are only helpers for Velmar's TSC and have no bearing on the model in-game or in the toolset.

Second, divide your X, Y, Z values by 100 before placing them in the .set file.

Yours from above should be:

X=-0.72
Y=-3.14
Z=0.0

That should do the trick.

/me types too slow sometimes

[Pstemarie]

Okay.

First, you don't really need the door dummies. They are only helpers for Velmar's TSC and have no bearing on the model in-game or in the toolset.

I would tend to agree on the dummy nodes, but this blurb from the BioWare Tileset Construction Tutorial 1.4 makes me hesitate a bit:
Placement/Orientation of Nodes on Tile
Your model will also need a place to be spawned, which is handled by placing a dummy object on the tile where you want it to occur. Again, this requires two different systems based on whether the door is generic or unique.

For Generic Doors:
When you place a dummy on the tile and link it to the Aurabase, you have to name the dummy with the prefix of the tile name, and the addition of "_D01", "_D02" and so on for up to four nodes. The orientation is important!

For Unique Doors:
When you place a dummy on the tile and link it to the Aurabase, you have to name the dummy with the prefix of the tile name, and the addition of "_U", and then the last two numbers of the unique door's name! It will look like this, for example: "TTR01_A01_01_U02", which will use the door "TTR_UDoor_02".
(N.B. If you want multiple tiles to use the same unique door model, then you can use the same last two digits.)

Again, the orientation of the dummy is important.

[lord rosenkrantz]

Placement/Orientation of Nodes on Tile
Your model will also need a place to be spawned, which is handled by placing a dummy object on the tile where you want it to occur. Again, this requires two different systems based on whether the door is generic or unique.

For Generic Doors:
When you place a dummy on the tile and link it to the Aurabase, you have to name the dummy with the prefix of the tile name, and the addition of "_D01", "_D02" and so on for up to four nodes. The orientation is important!

For Unique Doors:
When you place a dummy on the tile and link it to the Aurabase, you have to name the dummy with the prefix of the tile name, and the addition of "_U", and then the last two numbers of the unique door's name! It will look like this, for example: "TTR01_A01_01_U02", which will use the door "TTR_UDoor_02".
(N.B. If you want multiple tiles to use the same unique door model, then you can use the same last two digits.)

Again, the orientation of the dummy is important.

I reckon the above info is outdated. In my experience, the .set file handles the door placement and no other elements are required. It might be that it was changed during the NWN history, or that adding a door dummy gives some obscure advantage or restriction.
But I am very skeptical of the naming conventions, I am positive they have no effect on the game.
Overall, I never experienced any issue nor any bug has been ever reported about the lack of door dummies in the models I released

It might be that OMB has more infos and/or a different opinion on the matter though, since he handled most CTP doors

[OldMansBeard]

I agree with LR.

The dummies have no effect in the toolset or in game. If they ever did, it was a control feature that disappeared a long long time ago and was replaced by the .set/2da system we all know and love.

As a system, it wouldn't work anyway with door numbers above 99 and we are up in the thousands these days.

I made CM3 preserve them (and even correct them) if it found them in tiles but it doesn't care if they are not there and I've never made any effort to check that they are present and correct in CTP tilesets.

OMB

[Bannor Bloodfist]

From my experience with these door dummies, actually having the dummies is only helpful during the design phase of a particular tile.

it gives a visual representation that helps you to visualize what that 'node' is for. Makes it very clear that it is a doorway, and shows you the rotation of that door etc.

The naming convention is not really followed in the way your post listed it.

I have only seldom seen the UDoor type entry, typically when you see a 'U' defined node, it is actually a 'use' node, to allow people to say...sit on a bench. But I can't be sure I have actually seen those defined in tiles, only on placeables.

[Bannor Bloodfist]

Door Visibility Nodes:

Are only valid (i.e actually do something) for tileset specific doors. In other words, if your tile has only D01, D02 dummy nodes, then the door visibility entry will do nothing-- it only works on U01, U02, etc. nodes.

I pulled my hair out for quite a while figuring this out. I started to assume the node function was broken. I then decided to open my set in BuildTil and noticed the door node was greyed out for my tile. I checked a Bio tile and its door node entry was not greyed out-- I then realized the Bio tile was using tile specific doors. I changed mine to U nodes and sure enough the entry was no longer greyed out and in-game the visbility node changed with the door opening/closing.

Just some info. to save future frustrations-- Bio doesn't document this clearly and I didn't find this info. anywhere else.

So, what Heed is saying is that when you create your tile, and place a door dummy, you may need to place two for each door position, OR ensure that you set the proper type for each door.

So, your tile is using a GENERIC door, then you would first create the door dummy (TTR01_A01_01_D0), and properly place it in the tile to grab the location information for use in adding to the .set file as explained earlier in this thread. AFTER you have done that, you need to duplicate that dummy nude and name it TTR01_A01_01_U1 for the visibility features to actually work in game.

Now, if you are wondering what effect this has in game, I can give a minor example.

If you ONLY have the TTR01_A01_01_D0, yet you have assigned a generic door to this position, when the door is closed, your mini-maps of the area will still display what is 'behind' the closed door. Yet, if you have a duplicated dummy named TTR01_A01_01_U0 and use that same generic door, then when the character first walks up to that closed door, the room behind the door will remain invisible.

With a Tileset specific door, you do NOT need the 'U' node at all, as the engine correctly translates the D node for visibility.