grayman

The solution of adding the cinematic key to the hat def didn't work. I don't think the lack of this key is the problem. The hat shows up in the movie; it just stays put while the priest walks away. I shortened the time I'm in the movie, to see if the hat would snap back onto the priest's head. And it did. So the problem is that the hat prop needs to stay bound to a moving cinematic AI. I don't know if there's a fundamental difference between a hat prop and a hammer prop, but I changed the priest to a Builder guard, to see if other props had the same problem. His hammer moved with him when he walked, so it might just be hats, or this hat specifically. At this point I'll stick with the skullcap priest. I lack the time right now to try solution #2.

If you're pointing me to where I can learn about changing heads, I've already tried that. Unfortunately, the hat isn't a separate entity that I can bind to the head. You get the hat when you pick the head. Everything looks fine in normal map mode. Priest walks, hat stays on his head. The problem occurs when I view it through a func_cameraview.

Update on this ... The default builder priest uses the head ai_head_builder_priest. His hat stays behind. The second head choice is ai_head_builder_bishop. His hat is the same hat, and it stays behind. The third head choice is ai_head_builder_priest_plain. His model doesn't use a separate hat model, and includes a skullcap. The skullcap has no problem staying on the priest's head in a movie. So the third head is the only one that can be used in a movie. Though I haven't tested with other AI, I suspect any that use a separate hat model will have the same problem.

I'm making a movie for my vert contest entry. I have a priest (atdm:ai_builder_priest) who walks to his mark and starts talking. I've given him the key/value pair "cinematic/1", so he'll show up in the movie. However, he leaves his hat behind. It stays in its original position, suspended in the air, while the hatless priest strides to his mark and says his lines. Any clues on how to make his hat stay on his head? I'm just using the default model. Thanks.

I have nothing to contribute here, other than to note that your second (bad) brush has 7 sides.

My performance issues are solved. I ended up using the "boxed-in with visportals" method and the "include new textures before you need them" method. There's a slight speedbump when entering these rooms now, but it's certainly not bringing the machine to its knees. Thanks to all. Oh, and I found out that rain falls from the back of rain patches (as does snow from snow patches), so I flipped my rain patches and now that little ascending movement at the spawn of a rain streak is gone. Maybe it helps performance, maybe it doesn't.

I just realized this a couple days ago when looking at how one of my complex func_statics was nearly pure white on the screen with all the tris. Since it's high up on a ceiling, I figured eliminating all the places where the brushes touched would help. And it did. You don't notice the 1/2-unit separation between brush faces, and the number of tris dropped considerably. So that's another trick you can use to bring down tris.

Astounding! Modeling is certainly an art form.

Thanks for all the suggestions. (And so fast, too.) I'll start implementing and see what happens. I'm hoping to start beta tomorrow night, but I have a bunch of stuff to complete to hit that. Getting hung up on this performance issue at the last minute wasn't in the plan.

On my (old) computer, any framerates above 10 are relatively smooth. I can get up into the 60s from time to time, but on the other hand, I can also suddenly drop to 0. I have two areas in my vert map that I'm battling with at the moment. I've made as many brushes into func_statics as I can, added as much visportaling as makes sense (it all works), but when I initially enter these areas via doors, the framerate drops to zero when the doors' visportals open. Both areas involve skyportal textures; one area has drizzle rain and the other has heavy rain splashes on a glass ceiling (no rain, though). On my computer, dropping to 0 FPS is the kiss of death. It can sit at 0 for a while as I slowly move around, but if I ever get the FPS back up (by going into a corner, say), it stays up and I can leave by the entry door, shut it, turn around and open it again, walk all around, and FPS stays up in my normal 10-20 range. So my question is: when entering a new area for the first time, are there ways to keep the framerate up, i.e. preloading textures, blah blah? What is the engine doing differently when you enter an area the first time as opposed to entering it the same way later? Thanks.

Woops. CTRL-MMB doesn't work for me. Did you have to set it up somehow?

Thanks!

When I move the camera using the arrow keys, if I click the RMB, the movement speed increases along the horizontal plane. I can't find anything in the DR docs about moving the camera quickly (I discovered the RMB effect by accident), and I'm wondering if there's a way to get the vertical component of movement included in the speed increase. This has mostly become a need with a tall vertical map. On the other hand, is there a way to select a brush or item in the ortho view and have the camera snap to that position, much like it does when you select an entity from the entity list? Thanks.

I've been mapping since February, and never really gave a thought to the visportal red and green lines that appeared in the sky (using a skyportal) when I was using r_showPortals. WTF? VPs in the sky? So what, move on. Until the other night, when I realized the lines in the sky are from the skybox's camera view. So, if you're using a skybox, and debugging your portalization, you have an additional tool available, a camera that can give you a bigger picture of what VPs are on and off. Maybe the experts here already knew that, but it was one of those Aha! moments for me.

On my older computer, I'm happy with anything above 10. The game seems pretty smooth to me at that level.

We'll do this after the vert contest is over.

Thanks! DL'ing now.

Really? Cool. I won't use it in this map, since the tower is abandoned, with parts moved elsewhere for a new tower. So I don't want anything working. But if you want to start with this and come up with a true working clocktower mechanism that anyone can use, that would be great. Do you want to pull it from the map after the contest is over, or do you want something earlier?

Some shots from my vertical map. High up in an abandoned clock tower during a thunderstorm. #1 w/o lightning. #2 w/lightning. And, before you ask, the mechanism doesn't work. The machines that drive this (and the clock hands) have been recycled elsewhere, and I don't have enough contest time to create true bevel gears.

And I've found no other problems in testing. Thanks for this.

Here's another example of the transparency problem: The glass texture in these pictures is textures/darkmod/glass/clear_warp. #1 shows the glass brush unselected. In #2 it's selected. It's disconcerting when you select a brush and it "disappears". I'd love to make the test map for you, but I've got to get this contest entry finished.

I'd like to see one. I spent 2 days trying to make a "look down on the city from a height" skybox, and gave up when I got tired of creating itsy-bitsy buildings. I went to Plan B, which is a single graphic that represents the city from a height. I don't use any modelling programs, but I was thinking of trying to create a model city in POV-Ray and shooting that from a height. Maybe after the vert contest is over. I used terragen once in a POV-Ray scene, so it would be interesting to see how it relates to skyboxes.

I think this is a regression. It used to work okay. And it only affects selected faces. Unselected faces are working fine.

You can make the patch a frobable func_static, then give it a Frob response whose effect is a trigger. The trigger target can be a func_remove, whose target is the name of the patch. Touch the patch and it's removed.

Sample rain shader from tdm_weather.mtr: textures/darkmod/weather/rain_drizzle { deform particle2 tdm_rain_drizzle qer_editorimage textures/editor/rain nonsolid noshadows { //needed to emit particles blend filter map _white } } The sky_portal shader from tdm_portal_sky.mtr: textures/smf/portal_sky { qer_editorimage textures/editor/portal_sky forceOpaque // will still seal levels noshadows noimpact sort portalSky { map _currentRender clamp screen // fix up the projection based on the screen coords translate global6 * 0.5, global7 * 0.5 scale global6 * 0.5, global7 * 0.5 } /* { vertexProgram portalSky.vfp fragmentProgram portalSky.vfp fragmentMap 0 _currentRender } */ } So rain has a single blend, but sky_portal has none.