grayman

Sitting direction: 1. Set the "angle" spawnarg on the path_sit. 2. If "angle" is undefined, use whichever direction you're facing when the path_sit is processed. Some mappers put a path_turn in front of the path_sit. Arrival direction: Arrival direction should be irrelevant. The problem is that pathfinding says if the AI is at A and the sitting path_corner is at B, and there's no path from A to B, then the AI will not walk to B. He'll just continue along the string of path nodes.

No, newly-spawned entities aren't frozen by default. Their drop-to-floor spawnarg says whether they should find the floor or stay put when spawned. Moveable entities typically drop. Is the flinder hitting something on its way down? That would stop its movement.

Not w/o Springheel's permission to use his assets ahead of the official release. Ping him directly about it.

Slide_distance should be irrelevant, since it's part of the animation (which will be skipped). It's the AI's inability to get to the path_corner where he should sit/sleep that's the problem.

What's your opinion about disallowing an AI sitting down or sleeping if he's not in the correct place where he's supposed to do this? This happens when the AI is unable to move to the path_corner where the animation plays. A distance check can be done to determine "closeness", and an AI who fails will log his situation to the console, so mappers can see their AI is having a problem. And can correct it. A failure will cause the AI to continue on with his patrol beyond the sitting/sleeping animations. Thanks.

Done.

Biker gave me a new Discord link. I updated the OP.

Biker asked that I post this: “Evening, as some of you may know I have been working on a large city based mission for TDM. I am very close to rolling out the first beta so have set up a Discord server to do the beta testing on. For anyone that has previous beta testing exp and would like to help, head on over to - https://discord.gg/fP32yEn" I've seen this map, and it looks really good. Help Biker get this long-awaited puppy out the door! Thanks!

No idea at all. A quick glance through the player camera code indicates that the screen is simply taken over by the camera's viewport. No GUI involved. My suggestion is invalid if the camera doesn't use a GUI to paint the screen. Looks like this is a dead end. I can't think of another way to do it.

IIRC, If your cam view is an overlay, as part of the request to create the overlay, you can give the overlay a layer number. Perhaps you can look at the def of the message overlay to see if you can give it a higher layer number than the cam view?

The fault is in the "2" map, and is not a general "the player will move...". What happens in the "1" map: 1. The player falls into the trigger, and gets teleported to a spot just below mover1. 2. The player falling into the trigger also calls the script routine "cs_cam1". 3. This routine runs AFTER the player has been teleported. 4. The player is bound to the mover, and stays with the mover until it's finished its movement. 5. When the player's view is restored, he's at the end of the mover's path, so when he's unbound from the mover, he drops down to the floor in the 'end' area. What happens in the "2" map: 1. The player falls into the trigger, and DOES NOT teleport, because the teleport entity doesn't exist. 2. The player falling into the trigger also calls the script routine "cs_cam1". 3. The player is bound to the mover, and stays with the mover until it's finished its movement. Since the player never teleported, he ends up a large offset from the mover, at (4623.88 2948.38 204.64), which is in the void. 5. When the player's view is restored, he's unbound from the mover, and since he's in the void, he begins to fall forever.

Thanks for playing! 5 missions underway atm.

Is there evidence of this behavior?

It appears in several places: on the piece of paper that the drunk drops at mission start in a note on the engineer's desk in a note in Ales' fireplace (You don't read the readables? )

Clock

No video I know of. Create a nodraw moss patch to cover the walking surface of the rock. Give the patch lots of triangles: Select the patch and switch to vertex mode. Select the individual vertices and pull them down to a couple units above the rock surface below. See if you and the AI can walk across the patch.

Perhaps gift-wrapping the walking surface of the rock with a single moss patch snugged to fit?

Are there any existing examples of working drawbridges, where AI are blocked when the bridge is up, and can walk across when the bridge is down? Thanks. Edit: FIgured it out.

The areas mentioned in the warnings aren't created until dmap runs, so DR knows nothing about them. Look for these situations: 1. You're missing one or more location separators between the basement and the ground floor. Check visportals where the basement is on one side and the ground floor is on the other. Add separators where needed. 2. You have all the separators in place, but one or more of them aren't touching their visportals. Adjust them so they are. dmap posts warnings about separators not touching portals. 3. The separators are fine, but you're missing one or more visportals at the separators. Again, dmap posts warnings.

Creepy!

Got it. Testing. Thanks!

Nope. Add a path_wait after the path_sleep.

Fair enough. For whatever unknown reason, whoever created it decided not to have it show up in the Targets folder. Here's a picture of one I used in Somewhere Above the City, showing spawnargs. This one, when triggered every frame or so, resets the "target" spawnarg in VaultCamera4 so that it points to the entity target_null_7, which is moving around. This lets the camera resync its view in real time.

And you don't want to use the existing "target_setkeyval"? Keep in mind that some spawnargs are read and initialized only at spawn time, and changing them later will have no effect.