Geep

Upcoming TDM 2.10 will have more features for debugging info_location problems, thanks to @stgatilov. These are summarized in my update to The Location Entities section of Location Settings. Also See More at the bottom has additional links.

I added that link to the wiki a while ago, and I see that you are correct, the page is now missing. I couldn't find an equivalent replacement thread to link to. Assuming your FM has had some beta testing, you could ask a beta tester to release it, or maybe @Dragofer or @nbohr1more can help. Long term, it would be good if TDM had a more formal and maintained way to know who to contact for FM release... there is an @admin contact, but is that the right way to go, given there are many types of admin (forum, db, wiki, FM release, source, art assets) ?

@Obsttorte, could you elaborate on your wall technique a bit more... what is this "wall with no thickness" of which you speak? Is that a patch or decal? Also, it sounds like you make each room with its own caulk shell, so that 2 abutting rooms have 2 caulk walls between. So you cut through each to make a doorway+visportal? To the more general discussion, @Frost_Salamander, my current project, based on and extending _Atti_'s castle-like architecture, typically has a single non-caulk worldspawn (so sealing) wall between abutting rooms. These walls are either 16 or 14 grid units thick... 14

Sometimes the project has changed, particularly if you're making a copy of a project. Then DR is looking one place for the .lin, but TDM is putting it in another place. So in DR, make sure you've selected the correct project under File > Game/Project Setting...

Thanks, will check it out. Sounds like a custom script.

@Obsttorte, I looked into a Score to Settle. Inspecting the map file, there are 2 conversations in it, only 1 of which is between an AI and a player. Nothing special in the conversation commands there; a few seated gestures PlayAnims interposed. You can see this conversation starting at minute 11 in AluminumHaste's video runthru (Google it). The head does turn, but because the character is seated, the upper body and so the head does not turn as much as standing AI. Unfortunately, my AI has to be standing. I'll play around with the idle_headturn idea tomorrow. Tweaked the various head

It's a video cutscene. So the single AI character is looking directly at the player, whose viewpoint is being screen-captured. I can move the player, but not in a fast, fluid way to compensate for AI gaze shifts. And the gaze shifts makes the AI seem "shifty", not the effect I want. If there's no TDM solution, I'll have to use choppy editing, not ideal.

@JackFarmer, if you look at that video closely, you will see the guards heads (and shoulders) are constantly rotating slowly from side to side. That's what I need to stop... or at least keep the eyes pointed in exactly one direction. The head movement is fine for casual chit-chat, less so for vital high-drama engagement.

I've been trying without success to get a standing AI to deliver a Conversation Talk with a steady gaze, without moving the head around. My experiments to overlap a Talk with a PlayAnim that points to an anim def with "no_random_headturning" haven't been fruitful. Tried the "Turn Towards" and "Look at" commands too. Head still shifting. Ideas?

FYI. I've added a new section to the Doors wiki article, "Initially Blocking a Door - Partially or Fully", that summarizes the recent discussion here about that.

@Petike the Taffer, a few thoughts... I dunno about the transparent room idea. Maybe you could achieve the same thing (I'm guessing a minor improvement in performance in some circumstance) with lots less effort by using a horizontal visportal at the interface between floors. A design with a spire or tower in the center of the courtyard, extending up to the skybox, could serve as an anchor for radial visportals to the courtyard walls. Festoon with worldspawn buttresses and arches as needed to make that work.

I've gotten myself confused about keys on AI and doors. Am I correct that all the following are true? If a key on an AI is pickpocketed, by default the AI can no longer go through a closed door needing that key Most gamers and game developers would recommend the opposite: letting the AI still go through the door That is achieved by adding spawnarg "can_unlock<num> <door name>" on the AI There is no difference between def_attached and bound keys in this regard There is no difference between def_attached and bound keys in ANY aspect of key use (not cou

Here's a hack solution I used recently. Create a movable (I guess a rock in your case) that gets pushed, but it can't really move because the other side of it runs into something immobile, like a world spawn chunk. Yet the player can pick the rock up and let the door open, or a script can remove the rock when no longer needed.

@kin, since no one responded otherwise, I think what you have here is a New Feature Request. You can add it to the bug tracker if you have an account (bugs.thedarkmod.com) or ask someone (including me) to do that for you. I have no opinion on whether it's technically feasible.

Sorry, false alarm. Problem (1) was due to an AI renaming I did a while ago breaking the script. I only noticed the effect of the breakage coincident with the 2.08 -> 2.09 upgrade. Likewise, I have a hypothesis of what caused problem (2) and have applied a fix to prevent recurrence.