grayman

And this is what 2.07 looks like. This is what I'd like to return to.

This just started today with my update of SVN to 15737/8388 followed by a rebuild. Some textures (not limited to the door texture shown) are painted black in-game. (Working fine prior to the latest update.) For textures on frobable items, normal highlighting appears when the item is frobbed. For textures on non-frobable items, the texture remains black regardless of distance from the object. Backing away to turn off highlighting paints the texture normally. Anyone else seeing this?

I uncommented the two lines and there was no change. I see no blurring using the original font.

I updated SVN and the two problems noted above went away. Apparently my update from a week ago caught some WIP that wasn't finished, causing the problems. All is well now, thanks! ----------------------------------- On a separate note, what was the reason for changing the console font? How do I change it back?

Problem disappears with your cfg file. Let me diff yours and mine to see what's different.

Updated to latest drivers, and the problem persists. Have you tried using my Darkmod.cfg file?

It looks like it's the heat haze, and not smoke particles, that's showing the problem. Okay on 2.07 hotfix. Black on SVN Hardware is NVIDIA GeForce GTX960. CHecking for latest drivers ...

AA was off. When I set it to 4x, there's no change. Here's my Darkmod.cfg, if it helps:

I looked at WS4_Warrens and none of the dozens of lamps there exhibit the problem. So I made a test map and attached it to this issue. All the lamps in the test map exhibit the problem.

Along the same lines, I noticed that debugging info is painted differently depending on distance from the player. For example, turn on these lines in Darkmod.cfg: seta tdm_ai_showalert "1" seta tdm_ai_showname "1" and you get debug info that looks like this in the game: If you back up a bit, that info is displayed differently: This is more difficult to read, so it's a problem.

The monster_clip brush isn't accidentally a func_static? I know your wall paneling models have built-in m/c. Does the grate have built-in m/c? If so, what happens if you place a separate worldbrush m/c over the grate? Have you tried changing the m/c to tdm_nodrawsolid_metal?

Thanks for your comments. Since the only way I could simulate the behavior I want in 2.07 is through a complicated mix of existing features, I decided to move to 2.08, where I could write the missing piece of function. With that done and tested, it makes it real easy to achieve my goal. No teleportation, no swapping new versions of AI in to replace old versions, etc. Starting with 2.08, you can stop a patrolling AI in his tracks and send him to a new patrol route. No longer need to wait for him to reach a path node (which might be far away) where you've previously changed the target. The old way is fine for "shift changes", where there's no immediacy in switching routes. The new way leaves the old way in place, but allows for a "head for the hills" scenario at the moment of alert.

Pretty cool.

I just re-based my WIP from 2.07 to 2.08, and immediately spotted a problem. At one distance from this lamp type, the smoke particles are rendered just fine. When I move closer, the smoke particles act like they can't be found. See the two attached pictures. Anyone else see this?

A moveToEntity script event takes an AI off his patrol right away and sends him off to the defined entity, but he walks. I want him to run, and there's no way to tell him to run via scripting. The worst case for me would be to have to wait for 2.08, and write a new runToEntity script event. I was hoping to put out the next 2 WIPs on 2.07, w/o waiting for 2.08, though.

I'd like to create a "the place is going to blow up, everyone immediately head for the exits" behavior for the AI in my WIP. I've tried a flee solution, but that creates utter chaos once the AI reach the flee nodes they pick out. I want more control in what they do once they get there, and I don't want them all fleeing to the same flee point. Using a change target on a path node doesn't cut it, because the AI has to reach the path node where the change was made, and I want them skedaddling right away. Sitting, sleeping, and standing AI have no problem when a change target is used on them directly, because they're not currently moving. But most of the AI in the WIP are on the move, so changing the target on them doesn't work. I tried using a stopMove followed by a change target, but they don't stop, and they don't head for the exit. Any experience with this? Thanks.

Biker asked if I would post this screenshot of his WIP on Shadowhide's city map ...

To see how I did it in WS5, open ws5_commerce.map in DR and search for this entity: Switch11 It targets other entities, and by examining the group, and looking at the routines Toggle11() and ToggleRoom() in ws5_commerce.script, you should be able to figure out how to trim it all down to work for your case. Ignore script references to the 'panel indicator' and the 'door'.

Cool!

If you've properly visportaled the run from the emitter to the listener, you shouldn't hear anything through the walls. If you do, you prolly have a worldspawn leak somewhere between emitter and listener.

No, the sound will leave the room through its visportals.

The wiki has pages that cover sound propagation. Simply put, if you have visportals in your map, and the sound emitter is at point A and the listener is at point B, think of running a string from A to B, following the natural "path" from A to B (along hallways, through door and window openings, through gaps in your worldspawn brushes, etc.), then pulling the string taut. The string should tuck up against the edges of all visportals it runs through (or pass through the portal somewhere away from the edges, depending on the architecture). A's sound will propagate along the string. You can see a picture of propagation in the "Sound Propagation" section on this page. (However, the picture shows the sound traveling through the center of the visportals, which is WRONG. The sound for those examples would run through the southern edges of the portal faces.)

I don’t know how to answer your question since I haven’t seen what you’ve done

Filter out all entities, decals, clip, and patches. that should leave you with worldspawn brushes. visportals must seal to the worldspawn brushes. it’s ok if visportals stick into the void. it’s ok if the visportal face shares a worldspawn brushes face. it’s ok if a visportal face sticks into a brush. some mappers swear the last 2 ‘rules’ are illegal, but I’ve never had problems with them.

Texture Creation, per the Wiki.