grayman

And you're accounting for that brown stretch of dirt between the two stone walks being a patch, and not worldspawn? Hide that patch, and it exposes a deep well stretching the entire length of the street. In the version of the map I was checking, the large visportal that's behind you from where you took those shots is unsealed.

I wouldn't think so. I just tried it, and Level 0 and Level 1 are retained, but Level 2 disappears. After using the objectives editor, I see: mission_logic_success mission_logic_success_diff_0 mission_logic_success_diff_1 mission_logic_failure mission_logic_failure_diff_0 mission_logic_failure_diff_1 are retained, but whatever you do, mission_logic_success_diff_2 mission_logic_failure_diff_2 are not. Looks like a DR bug.

Check your messages. The problem in that area might not involve the visportal.

greebo said he merged it. Rev 4722.

If you're playing with TDM 1.04, there's a known crash loading these missions: Special Delivery The Thieves Awaiting the Storm Trapped 1.05 fixes the problem.

That should definitely not be happening with the latest 1.05 RC.

When you've exhausted every mapping check you can think of (or even before), I can offer two bits of help. 1 - I can run the *.map file through my visportal checker, and 2 - I can debug what happens when the AI comes up against that vp.

It's identifying itself as 1.5, both during installation and in the Help window.

Happy to participate. The flyaway func_static mirroring and missing shader fixes alone are worth the price of admission. I save often, so hopefully that won't be a problem. Thanks.

If you want to send me the area exhibiting the problem, I'll be happy to see what pathfinding is doing.

Is there a door nearby that is not visportaled?

My only suggestion is to beef up the monsterclip. For the AI movement improvements, I've been using a section outside the Inn at the start of anoott where the guards got stuck treadmilling against the stuff under the overhang. I've tested with that countless times, and every time I find myself thinking, "If only he'd put monsterclip around that stuff...".

What version of TDM were you using? Starting with 1.04, AI are more polite around open doors.

For 1.06, I'll be coalescing the ideas in this thread into a proposal for door-handling changes. Perhaps in response to that, someone will describe why TDM AI open/close doors the way they do.

Drop it down a deeeep dark hole, and they'll never see it again. No stims, no scripts, nothing but net.

Not that I know of. If this item is something he can frob from the other side of the bars, then you could wrap it in an atdm:target_set_frobable brush, initialize the brush to "start_frobable" "0", then trigger the brush at the point where the player is on the other side of the bars. Or you could set the frobbox_size on the item small enough that he can't frob it through the bars.

We would need to use a different texture than 'visportal' on the new audio-only portals, otherwise dmap will treat them as normal visportals and cut up the map anyway.

You use func_portals to turn visportals on and off based on their distance from the player. It's useful if you have a vp in the distance (i.e. a window) when there's no point in showing what's behind it because it's so far away. Mostly used in outside areas. Check the tower windows in the training map's arrow-shooting range.

Would anyone who was around when the door-opening/closing animations were designed care to talk about how the design decisions were made?

I have a test map I made when we were talking about this. It's a long hall (1536) with visportals every 256. At one end of the hall I have a looping speaker playing "gregorian01a" and I set the min/max distances to 1888 and 1968. (The spawnargs are 48 & 50.) Each vp has an info_locationseparator on it, each with "sound_loss" set to "100". Each vp has a func_portal on it. Cases: A - set "portal_dist" to "2560" on each func_portal This keeps each vp open as I walk down the hall. I get to the far end of the hall (away from the speaker) and I'm hearing full volume from the speaker, because my distance is less than the min distance (1536 < 1888). B - set "portal_dist" to "256" on each func_portal Now the visportals close behind me as I walk away from the speaker. When the third visportal shuts behind me, the sound cuts off. If I turn back toward the speaker and take a couple steps, visportal #3 opens and the sound comes back. Step back, vp closes, sound gone. So open visportals with info_locationseparators have no effect on what the player hears. But closed visportals with info_locationseparators do.

Closing the door involves reaching toward the door, and it's most natural if they face the door when they do that, so it's coded that way. There is no way the user can alter that. I don't recall what Thief AI do when they close doors.

All I can think of is to put multiple visportals inside the hole, with a single info_locationseparator touching all of them. Hopefully the code will register the separator with each visportal and apply its sound reduction to each. Since visportals are just a plane, I assume they can be as little as 0.125 apart.

Need details. What's the sound? Where's it located? How far from the visportal? Where are you when you're listening to the sound? Sound reduction changes the min and max radii for the sound. If you're inside the reduced min radius, you'll still hear the sound at max volume.

I still can't believe that stone masons in those days had very large curvy blocks, which you're using in your vaulted ceiling. See my suggestion above.

This looks good. If you can post a shot with an AI standing there, it'll be easier to gauge the proportions. My one comment is the ceiling material. It looks like a curved vaulted ceiling, so it probably wouldn't be made of large blocks. Smooth or rough plastering, cloth, paint, or other contiguous texture would look more realistic. Good work. Hope to see more.