grayman

Source rev 4667 has the fix.

I haven't begun looking at it, so it won't be in 1.05, which freezes this weekend.

What was the reason for fading them in? After 14 months of playing and working with TDM, it continues to bother me that the menu items aren't immediately available and I have to wriggle the cursor around to make them appear faster. When I'm starting TDM umpteen times a day, it gets annoying.

Does that mean the spiked board resets itself and the player gets hit again if he stands still? Sounds like what you want is a one-time event. I sure wouldn't hang around after getting smacked.

Most Excellent, Robert. Just so you know, larger items like this are typically dirtied-up for TDM. This one looks like it just came off a store shelf. But it's definitely something I'd like to see (or use) in a map. Thanks!

I've found and fixed this problem in SVN. However, the problem causes the following missions to crash at the start with 1.04: Special Delivery The Thieves Storm Trapped

We haven't done many cutscenes, so this problem might pre-date the weapon-switch changes I made in 1.04. The 1.04 changes were thoroughly tested (by me and others), with all problems addressed, so either something's gone missing, or cutscene transitions are messing up the weapons somehow. Please file as many bugtracker issues as it takes to cover the problems mentioned, and assign them to me.

Many moons ago I reported that sometimes dmap doesn't create a *.cm file if one already exists. I suppose we'll fix that when the D3 engine source becomes available. However, I just noticed one effect that can have. I had a metal floor in a test map, and was searching around to see how far something was being tossed by an AI. It was small, and tough to see, so I decided to change the floor to ice, thinking I should be able to see anything on a white background. But after dmapping, my new ice floor sounded like metal, and I wasn't sliding around on it. My first thought was something got messed up with the 'slick' attribute, and I checked everything that I'd put in place to support it. All was well. Then I remembered the *.cm problem, and noted that my *.cm file was from before my recent dmap with the ice change. So I deleted the *.cm file, re-dmapped, and now I had my slick ice floor with a crunchy snow footstep. So, here's evidence of a very good reason to always delete your *.cm file when changing textures, and especially make sure the *.cm that goes out with your map is properly refreshed.

In 1.04 (and earlier), AI don't close doors when their alert level is 'Investigating' or higher. This covers combat. And just today I added not closing doors when running, for whatever reason. I'm not sure how "door's in the way" matters, because from what I've seen in testing, AI will try to open the door to clear the condition. Perhaps I need to chart out what the code is trying to do. Since we have such varied ideas on this topic, I'll need more people to chime in before deciding what to do.

In 1.04, AI always close doors, whether they find them open or closed. I thought this was useful for performance, but there might be cases where this behavior isn't desirable. A little while back, Tels and I were discussing how to give more control of this to mappers. We concluded that a door could have a spawnarg defining its need to stay closed, which could be expressed as a probability between 0.0 and 1.0. And an AI could have a spawnarg defining how often it closes doors, which also could be expressed as a probability between 0.0 and 1.0. If an AI's setting is "0.0", he never closes doors, and it wouldn't matter what the door setting is--the AI would not close it. This is useful for zombies, who don't know doors from ... well ... whatever. (They still use the door-opening animation, but that's a different problem.) If an AI's setting is something other than "0.0", and the door's setting is "1.0", the AI will close the door regardless of his own setting. For any other combinations, the probability of closing the door would most simply be the average of the door and AI settings. Since AI on a door queue will defer to the last AI in line, this behavior only pertains to the last AI through the door. This would allow mappers to make specific settings for AI and doors as needed. Any comments or other situations you can think of? Thanks.

That should work. Put him on the waitfortrigger and teleport him when you need him. Surround the teleport destination with a trigger_once_entityname and have that target the AI. It will recognize the incoming AI and trigger its target, the AI itself, and he should start his patrol.

I'm afraid I can't join this beta at this time. Sorry.

Cutscenes occur when you let a camera take over the view. So, yes, you need a set, which can either be part of the map the player will see, or a separate area the player won't see. In SATC, the finale cutscene takes place on a set the player cannot get to. Its 2 actors stood silent throughout all the gameplay until the first camera on the set activated, beginning the cutscene. Any actors or movers you want to be seen by the camera need to be marked 'cinematic'. Otherwise they won't appear in the view, or think. When a camera isn't playing, these entities will think and be available for gameplay if the player can get to them. To save FPS, you could make your actors dormant. So, the sequence is ... 1 - Keep your actors in blue rooms and dormant until needed. 2 - Teleport them into the "wings" of your set when it's time to begin the cutscene. Since the player needs to be on the set to hear sounds, his nearness will wake up the incoming actors. The player can either be teleported into place or the set could be somewhere he entered on his own, triggering the cinematic. 3 - Start your first camera. 4 - Have the actors walk onto the set and into the camera's view. 5 - Play out the scene, including a conversation if it's needed. 6 - Move the actors back into the wings and remove them if they're no longer needed. 7 - Teleport the player where you need him to be, or leave him on the set if appropriate. 8 - Transfer control from the final camera back to the player.

Can you be more specific? What O/S?

Is this the Conversation wiki, or Part 3 of the Cutscene Wiki, which describes how to create a conversation?

This is included in 1.04.

Thanks, BD! WRT Windows, I assumed "for System Builders" meant companies building systems. An individual can get it at this price?

The only AI aversion to water is that the rats will not stand around in it. Because of their size, they can quickly drown.

I'm glad to hear the AI are behaving better. Hopefully the number of places where they become confused or repetitive will be reduced in future releases.

Are you using the conversation editor, or doing this by hand? "talk" should be "Talk". The commands are case-sensitive, is my guess.

I created an area with two angled crates where the only path past the crates was between them. dmap correctly carved up the floor into AAS rectangles, placing a few small ones between the crates. So the AI walked between the crates correctly. I then placed an angled wall farther along the path and cut a door-sized opening in it. dmap again placed a few small AAS rectangles inside the wall opening and the guard had no problem walking through the opening and the crates. However, I noticed that the small rectangles inside the opening were inside a larger rectangle that included the angled wall. That's the first time I've noticed AAS areas inside other AAS areas. I don't know if this is legal or not, but the guard had no problems. When I added a door to the angled opening, the guard bumped through the opening when the door opened away from him, but got stuck on the way back, when the door opened toward him. So there are issues with angled architecture and how AAS is laid out. Maptesting by the mapper should expose any of these issues, though, so we'll probably never see finished maps with these problems.

I haven't tried that, but I'll bet it doesn't let the AI path correctly between the crates. I'll try a test case tomorrow where the only way from path_corner A to path_corner B is between the crates. I'll bet that even if there's a way around the crates, if the crates are on a direct line between A and B it'll probably fail. I could easily be wrong; perhaps other conditions are present at dmap time that don't exist in the test map I'm using.

While debugging #720 today, I noticed that my AI can't walk through a door oriented along the SW/NE axis (i.e. rotated 45 degrees). He opens the door, then circles at the door opening, repeatedly bumping into the door jamb. At first I thought this had to do with the AI's bounding box never changing its orientation, and not fitting through the angled opening. But when I turned on debug drawing, I saw that the angled wall into which my door was set hadn't factored into how the AAS areas were calculated. The angled wall, the door, and the floors on either side of the door were all part of the same rectangular AAS area. So pathfinding found a nice straight path to the far side of the door, but unfortunately it went through the door jamb. That ain't gonna work. (Pathfinding rule: you can walk in a straight line from any point inside an AAS area to any other point inside the same AAS area, barring any dynamic obstacles.) So my question for mappers is: have you used doors in your maps that aren't oriented NS or EW? And did you have to do anything special to let your AI use them? Thanks.

Awesome. I'll look at that next. Thanks.

I suppose the werebeast not attacking the guard is a variation of #2383. As long as I know the werebeast isn't supposed to be anybody's friend, I'll take a look at this issue for 1.05. Thanks.