Sorry everyone to bother you AGAIN with another tiledoor issue… yup…my luck another one cropped up and I have done all I can on my own (hours) of trying to fix this using the info from my last tileset issue I had. The door is suppose to look like this below:
The steps I took:
I opened up the toolset. I recorded the tileset the issue was found in - the CTP Cave Ruins tileset
I highlighted the tileset area where the door was to see what more I could get from this. It is the tile:
tccro_009_02
I clicked and opened the door to look at it. Its tag is: Cave Door. It is the Mine Door (you will see this in the pics below). Door reference is: nw_door_ttr23
I went to my doortypes 2da. I looked for the “tccr” tiles. Found 10 of them. One fit this perfectly
It was the TDM_Udoor_02 with refrence nw_door_ttr23
went to hak which keeps my mdl parts - found it …took it out thinking it was overriding my door like the last door issue.
I Then one-by-one took out every TDM_Udoor_01 to 10 in the “tccr” tilset set…still had that dam door
I then went through all 12 haks looking for that TDM_Udoor_02 with that reference above…nope nothing
I looked through all my doortype 2da for other TDM_UDoor_02 (with same resref of nw_door_ttr23) and found the following ones:
CaveDoor12MD on tileset TDM01
CaveDoor1RC on tileset ttccro (which is the actual tileset)
CaveDoor1MD on tileset TDT01
CaveDoor1MD on tileset TT201
Extract the .SET file for this tileset, find a relevant tile to the tccro_009_02 check [TILEXDOOR0] entry. The row Type=X refers to doortypes.2da. Now you either change the Type=X to refer to the right door model in doortypes.2da or you change doortypes.2da so that the “TDM_Udoor_02 with refrence nw_door_ttr23” is at this line.
However, as these are afaik both vanilla doors this is not making much sense. I recommend to compare yours doortypes.2da to vanilla/EE doortypes.2da whether you have all the vanilla doors at same lines. If you do not, then it would be wise to fix this as it is most likely the culprit behind your issues with doors.
If you do then I would re-download CTP tilesets, these tilesets are known by their high quality and almost no errors, so it is odd there would be such an issue in there, most likely you have some outdated version.
I will do all you say…but I am wondering why it changed ONLY AFTER updating from CEP 2.4 to the CEP 2.67…
So frustrating…spent hours on this…To be honest…I don’t even know how to play around in the “.SET” file
I’ll try some of the things you mention on there that I can do…i.e. compare the vanilla to my current. Might just put the vanilla in the override and see if that changes anything
I think I will take your advice about re-download this specific CTP tileset and just find the door model and place it in my hak…see if that works…I will do that this weekend and let you know what the result is. Thanks for all your help.
Hi Mmat…I’m confused…I always thought that the number to the left had no bearing on a 2da. Isn’t it the door (TDM…) tied to the tileset “frame” per se …the CaveDoor…)? I wish a person could just choose doors like other doors in the toolset…this would make it easier. So not sure if you mean that I have to adjust my 2da line to fix this…is that correct? Hmm…when I did the 2da updates I must have shifted my lines by one. So is that it? So strange as I thought those lines in the first column meant nothing other than to list rows.
The reference of the game is always the position of the line in the 2da. The counting starts at 0 with the first line below the headings (actually line 4).
In an ideal world, the numbering in the first column is identical with the position of the line in the file, giving the mod-builder a hint this way. But if one mess things up by skipping / duplicating line-numbers in column 1, the game will still work since it ignores the actual contents of column 1. It’s a nightmare to ammend files with a messed up linenumbering. (what shaddooow says is right!)
I confess i didn’t check the line numbering of the 2 doortypes.2da files, but I’ve no reason to think, that there is a fault.
In your case, 2 lines are affected, where the second directly follows the first (533+534. In your 2da, these two lines point to a different model. In the original file from CTD, they point to the same (round) model.
The problem is your line 534, it points to the wrong model
I have been looking at these youtube videos on how to just shift a dam line by one on my notepad++ and I just can’t figure it out. How the hades does one just delete one line so it renumbers? I.e…delete for example line 391 so line 391 is now line 390 and the numbering continues in sequence.
Edit: I found that if I start at that line…391 on my 2da and just turn it into line 390 and resequence the numbering on my notepad++…it would fix this dam issue. how does one do that?
Yes, as Mmat explained, game does this if there is an error in numbering order. Ie. it doesn’t matter that the written number is 23 when it is 24th row from start - game will automatically renumber it and treat it as there was number 24.
So in fact, the written numbers doesn’t matter, but the real row number does. But that only happens with faulty 2DAs that have errors in the number sequence in them (there are few exceptions to exceptions, but you don’t have to worry about that, it is likely you never run into those cases and even if you do - you won’t screw up anything by renumbering lines with number out of order - most 2DA tools will do this automatically when saved anyway)
