grayman

The materials folder has tdm_models_nature.mtr in it, and inside that are the mushroom skin definitions. These definitions are included: tdm_mushroom_a_selflit_green tdm_mushroom_a_selflit_red However, when selecting mushroom skins, the red selflit is available, but the green selflit isn't. The green dull selflit is available, but not the fullbright one. Anyone know why green fullbright doesn't show up in the DR mushroom skin list, even though it's defined in the *.mtr file?

Since we work in 2D views (XY, ZX, ZY), we can limit the discussion to 2D. In your example, the 2 axes in the view are XY. If you want to mirror a NE-quadrant object into the NW quadrant, you want to mirror across the Y axis. For each point (x,y) in the object, you change the x value to its negative. So (x,y) becomes (-x,y). An editor would provide you with a "Y-mirror" button to do this. If you want to mirror the object to the SE quadrant, you want to mirror across the X axis, using an "X-mirror" button. In this case, each (x,y) point becomes (x,-y). If you want to mirror the object all the way across to the SW quadrant, you'll do either an X-mirror followed by a Y-mirror, or a Y-mirror followed by an X-mirror. So (x,y) becomes (-x,-y). ZX- and ZY-view discussions follow the same logic.

The algorithm applied in a 2D view is a simplification of the 3D algorithm; one of the axes is held constant. All I can say is Google "geometric mirroring" or "mathematical mirroring" and look at the 2D and 3D examples. In every case, the object is flopped across the plane (3D) or line (2D). It's not flopped "along" it. And "axis" and "direction" are interchangeable in this context. So I still maintain that (in 2D) Y mirroring flops the object across the Y line, X mirroring flops the object across the X line, and Z mirroring flops the object across the Z line. Our discussion here won't change the geometric meaning of mirroring. We can all interpret DR's "mirroring" term in our own contexts. You've established yours. I've established mine as having to remember that when I hit the "X mirror" button, I'm getting a Y-mirror applied. Ditto for Y and Z. No biggie.

Here's a page on mirroring: http://www.mathsisfun.com/geometry/reflection.html Scroll down to the "Some Tricks" section. See how X-mirroring flips the object vertically? And y-mirroring flips the object horizontally? DR does the opposite in each case, mirroring the object horizontally and vertically, respectively. Ditto on the ZX and ZY views. So, while DR is doing mirroring, the buttons are mis-labeled. That's why I contend that's it's a simple fix: either rename the buttons, or swap the links in the code to call the correct routines.

I found the "merge entities" button. However, it only works with func_statics. There doesn't appear to be any way to merge other entities into a group so that they can be correctly rotated. I have a corridor of mushrooms with their little attached lights that I want to rotate. A single working rotate button would be a godsend, since you can imagine my hesitation at doing this by hand. Yikes! But into the fray I go, since, after all, there's a deadline ...

How do you merge entities?

In mathematics, the term "mirror about x" means to mirror across the x axis to the other side. I'm not saying it doesn't work. I'm saying that as used in DR, it's misleading. It's an easy correction to make, though.

Right. I've even had trouble with origins being left behind in a group translation. That long, eh? Okay, thanks. I'll do what I have to do by hand, then, item by item.

And a minor nit about mirroring... The "mirror about X/Y/Z" functions are swapped in each orthogonal view. For example, when using the X/Y view, and you ask to mirror about the X axis, it mirrors about the Y. And vice versa. Ditto for the Z/X and Z/Y views. Might be worth straightening out in the future.

I have a collection of items, and I want to rotate the collection. Is there some way to do it that retains the spatial relationships among the items? Worldspawn brushes and patches work fine, but when you try to rotate collections of entities, they just scatter to the wind. Worse yet, many origins go off on their own, ending up far from their owners. It seems that selecting a group of entities, and asking to rotate them, involves finding the center point of the collection, and rotating each item about that point. The x,y,z axes of each item would adjust accordingly. What logic is being applied to rotating collections? I've tried toggling the "Free Model Rotation" mode, but I can't see what it's doing, and I can't find any explanation on the wiki pages. Thanks.

If you're asking me, it's XP, service pack 3.

Okay, thanks.

Though my own zombies have no doors they have to deal with, I second the motion to have zombies that can batter open a door, pass through, and not close it behind them. Since doors open in a specific direction, the mapper will have to make sure that when a zombie bangs on the door it opens away from him. Good fun to be standing in a shadowy room and a door bursts open to reveal a lurching zombie. The door could even be specially made for a zombie, coming off its hinges and crashing to the floor.

[attachment=5031:arch3.jpg] Delete the rest of the arch. (Outside patch, inside patch, back patch, and the two patches on the underside of the arch.) Select the patch you've made corrections to and execute a thicken patch with - extrude along vertex normals - thickness 48 (what your arch depth was originally) - check "create seams" And you end up with this: [attachment=5032:arch4.jpg] Now, I don't know if this is what DR was supposed to give you in the first place, but 'tis a far far better arch than what you started with. Hope this helps.

The problem lies entirely in the control points. Here's a workaround, but it's a bit of work... Starting with this: Go into vertex mode. Note the skewed control points. Move the outer and middle control points where they should have been placed. The inner control points are from your original curve, so they're ok. (Next picture too large, will continue in next post ...)

In this script code: entity myBonfire = sys.getEntity("bonfire"); myBonfire.LightsToggle(); TDM complains at map start that LightsToggle() can't be found. The example on the wiki page assumes a holder/flame entity. The bonfire I'm working with is just a light. And the wiki example uses "sys.findEntity()" and TDM complains that it doesn't know about that. "sys.getEntity()" appears to work, though. Not sure at this point what the recommended method is, so I don't know what to put in a bug report. extinguish/ignite is the only mechanism I've found that works, and if the plan is to deprecate them in the future, I'll need to replace them with the correct methods. I'm also using extinguish/ignite in massive quantities in Cleighmoor to good effect, so I'll need to replace all of those as well. Those are on unlit torches that can be lit via script.

Final solution: Set the entity's "extinguished" spawnarg to "1". (Thanks, Tels.) Use frob_ignite() to ignite it. Use frob_extinguish() to turn it off. The flame's light will toggle on/off if you sys.trigger() the entity, but the flames stay on. So triggering isn't enough. The frob_ignite()/frob_extinguish() methods handle both flames and light. Not sure why they weren't working yesterday. Thanks!

Reading this, I drooled so much over my keyboard that I had to use my iPhone to enter this reply. Seriously, I'd love to upgrade, but that's not in the cards at the moment. And the danger of creating maps that low-end players can't play would haunt me.

Ok, good. I looked, but didn't see any 'drunk' voice sets. I'll look more closely. Thanks.

Very VERY nice post, jdude. And timely, for me. I'm doing an abandoned mine and I'll try these techniques. Thanks!

I've gotten through all the FMs released up until a few months ago. I haven't played Heart or NHAT 2&3 or anything else I might not know about yet. There might have been places where the framerate approached zero, but I don't recall. Certainly nothing that stopped me from continuing. RTTC is the only one I can't play, but it has nothing to do with AI. I turned tris on and the whole screen practically turned white, and my computer can't handle that level of complexity. As for the test map, it's six brushes, two lights, a player start, and the card-playing prefab. I'm not saying it isn't playable, because with the players fully onscreen, I get 17fps and anything above 10 is fine. The test was to see how much fps dropped when the players came on to the screen. In my case, using my video settings and older computer, I experienced a 64% drop in framerate. I just need to be careful in my map designs to not allow more than a couple AI onscreen at the same time. That'll let me test what I'm making. I guess that's the answer to my own question at the top of this thread. And for the record, my computer is: 3GB usable ram, single Pentium 4 @ 3.4GHz, and ATI Radeon HD 2400 w/256 video ram. Not a great vid card for gaming, but I do very little of that any more. TDM is the only thing I've played on it over the past few years.

If you set up an AI to use the bottle-drinking animation, and also set his "drunk" spawnflag to "1", he won't use the bottle-drinking animation. He'll just use his normal idle voice barks. It seems reasonable that a drinking AI can be set to "drunk", but the animation and the setting don't work together. Comments? (Unfortunately, an AI set to "drunk" doesn't sound drunk, but that would mean creating a whole mess of voices that (I assume) don't currently exist.)

My one-room test map has a couple friendly guards sitting and playing cards. So there's no large area to monsterclip. And there's no visportaling needed or used. And unless they're quietly considering which paths they would choose if an enemy showed up, all they're doing is playing cards. If they're offscreen the framerate is 45. If they're onscreen the framerate is 17. So to me it looks like a slowdown due to rendering them. I had a couple video settings that weren't dumbed all the way down. Doing so improved things a bit, but not enough. At this point, I've swapped out the card game for a single drunk guard, using the bottle-drinking animation.

I want a bonfire off at map start, and turned on later. I placed a light_fireflames_huge in the map, and set the "start_off" spawnflag to "1". TDM ignored it. So I tried the *.Off() method in the map's main() function. TDM ignored it. So I tried the *.frob_extinguish() method in the main() function. TDM ignored it. Does anyone know how to turn off this light, or do I need to have it on all the time and move it into place when I need it? Thanks.

I remember reading it, but I don't remember which thread it was in. I haven't tinkered with interleaved thinking. The problem might be more of a rendering problem than a thinking problem. I created a one-room map with 2 team 0 card players in it. With the card game completely offscreen, I get 45FPS. Rotating to include one of the two players drops the rate to 27FPS. Viewing both players drops the rate to 17FPS. The amount of thinking is constant, so rendering the slight AI movements is probably causing the slowdown. Maybe I'll cut back to one guard playing solitaire.