• There is NO official Otland's Discord server and NO official Otland's server list. The Otland's Staff does not manage any Discord server or server list. Moderators or administrator of any Discord server or server lists have NO connection to the Otland's Staff. Do not get scammed!

TFS 1.3 - Buggy Doors

Alkenyx

Member
Joined
Jun 6, 2014
Messages
97
Solutions
1
Reaction score
16
Location
Germany
Hello everyone.

Server: TFS 1.3
Client: 10.98
Remere: 3.2 and 3.7

Am I the only one who places a normal door (ID 6252) in an stone wall for example that's locked in game?
Bild_2021-07-29_175908.pngBild_2021-07-29_175443.pngBild_2021-07-29_175826.png
I guess I must do smth wrong.. And don't tell me to use RAWs..
 
Solution
E
I'll fix RME walls.xml later today to fix this issue according to latest tfs
Last edited:
Battled with something similar myself recently and ended up here:


Or maybe you just need to update your doors to latest tfs, they changes it to revscript.
I went for this x64 Version: [10.98] Nightly packages of The Forgotten Server (official / master) (https://otland.net/threads/10-98-nightly-packages-of-the-forgotten-server-official-master.270332/)

But it looks like, that nekiro is working on the items.h right now.
 
Use 6253 instead if you want the door to be unlocked. Most (all?) normal doors have a locked version - you can check that by going to tfs/data/global.lua - not sure if you both or me are missing something here but this is how it is supposed to be.

The only real issue is that items.xml will pass locked door name for both and because of that you can't make any difference in RME when mapping.

1627640894463.png

Lua:
lockedDoors = {
1209, 1212, 1231, 1234, 1249, 1252, 3535, 3544, 4913, 4916, 5098, 5107, 5116, 5125, 5134, 5137, 5140,
5143, 5278, 5281, 5732, 5735, 6192, 6195, 6249, *6252, 6891, 6900, 7033, 7042, 8541, 8544, 9165, 9168,
9267, 9270, 10268, 10271, 10468, 10477, 10775, 10784, 12092, 12099, 12188, 12197, 19840, 19849, 19980,
19989, 20273, 20282
}

You can also check the name for it under items.xml

XML:
<item id="6252" article="a" name="closed door" editorsuffix=" (Locked)">
<attribute key="type" value="door" />
<attribute key="blockprojectile" value="1" />
<attribute key="description" value="It is locked." />
</item>
<item id="6253" article="a" name="closed door">
<attribute key="type" value="door" />
<attribute key="blockprojectile" value="1" />
</item>
 
Last edited:
I won't start RAWing Doors.. This would be a huge backstep for RME.
But if RME has no bug here, it's an TFS 1.3 bug. Gonna check this out.
 
I won't start RAWing Doors.. This would be a huge backstep for RME.
But if RME has no bug here, it's an TFS 1.3 bug. Gonna check this out.

Nvm - actually I think I understand what you mean now.

RME defaults to the first normal door when using the door paint which is the closed one. Now with this TFS change the first door is the locked one.



Thats a change made there - it might be just a case of swapping the doors under locked for those under closed section in global.lua
 
Last edited:
I'll fix RME walls.xml later today to fix this issue according to latest tfs

If we are to maintain compatibility with old maps or even the RL/TFS map - this won't help as every instance of closed door turned to locked after PR#3000 and vice versa.

This change will just help new placed doors.
 
I'll fix RME walls.xml later today to fix this issue according to latest tfs
Good news to me. Could you please check out the missing walls connection since rme 3.2 too?
I know RAWing is a lot of fun to many of the ppl here but using autowalls is why I like RME.
 
Back
Top