grayman

Okay, thanks.

A different problem re: weather patches and skyportal. When you select a rain patch, it tints, the wording disappears, and any skyportal brushes beyond it disappear. When you select a skyportal brush, it tints, but you can now see through it. For the images below, #1 is normal, #2 is with the rain patch selected, and #3 is with the skyportal brush selected. You can see the skybox out in the void in #2 and #3.

Just posted a note on 2251, the item-dragging problem. I don't think this is fixed yet.

I took a copy of the pre-release. I can verify that the "looking through a snow texture" bug has been fixed. And thickening patches works correctly now. Greebo, you want us to close issues now, or wait until the official 1.4 release? Thanks!!!

My brain just blew up.

This thread has a good discussion on how to make signs and text decals ... http://forums.thedarkmod.com/topic/11159-add-text-to-your-signs-signposts-walls-etc/page__p__219209__hl__signs__fromsearch__1&?do=findComment&comment=219209 Maybe that will help.

The closest you can get with what's currently available is to use snd_move. This sound will play when the door is opening and when it's closing. The drawback is that it's the same sound both ways. For a squeaking/scraping door, that's okay. If you get into scripting, then you can keep track of whether the door is open or closed with frob stims, and play a sound when an open door is frobbed. I don't know if there's a boolean test like $doorname.isOpen() that could be used instead. Door events aren't symmetric. We have this problem with sounds, and there's also a problem with triggers. You can trigger something when a door begins to open, when it's fully opened, and when it's fully closed. But you can't trigger something when a door begins to close. If we had that, then you could trigger your closing sound with it.

Internal leak was the first thing that came to mind, because a few of those green portals should have been red or not shown, which they became once you stepped out of the leaking area. Glad to see you caught it. I've found numerous pinhole leaks just from walking around and wondering why I was seeing portals I shouldn't be seeing, even red ones.

Okay, thanks for the tips.

Cool. I just learned that CTRL-Tab changes the ortho view! I don't use more than a few of the key controls in DR (and I cuss a lot when I mistakenly go for "H" and hit "J" instead), so my other apps are safe.

Fidcal: I wasn't on the thread until after the Christmas contest, and I can't find an example of what should be posted in my entry's thread. And how do I "open a poll"? Could you post link(s) that would help us newbies out? Thanks.

It's a weird feeling when I see a picture like that that makes me want to move the mouse around to see more of the ceiling, the walls, etc. Very nice.

When manipulating vertices, how can you separate two vertices that occupy the same point? Sometimes if you select the vertex point and move it, only one vertex moves. Sometimes both move, and it's a problem when manipulating patches. Thanks.

Thanks for the suggestions. I'm putting in multiple small speakers. No time for experiments, since this is for the vert contest. I agree that the engine should treat sounds differently underwater.

Has anyone noticed that if you bump into or walk over a movable atdm:* entity (bucket, shovel, coin purse, etc.) sitting on a patch, there's a good chance it will fall through the patch? This might have something to do with slightly embedding an item into a patch, like a bucket sitting on a dirt patch and you embed it slightly for realism. It doesn't matter if the entity's origin is above or below the patch.

I've placed an info_locationseparator on a horizontal visportal that has a sound above it that I don't want to hear below it. (Wave-lapping sound above water that I don't want to hear when I'm in the water.) I've given it a "sound_loss/100" spawnflag, which I would think would be enough to kill the sound entirely. However, I can still hear the sound in all its wave-lapping glory when underwater. What am I missing? The visportal itself works fine. Thanks.

I've found that this type of light only works in the area where it resides. If you have two or more outside areas separated by visportals, and you want moonlight in every area, you have to create one light per area. This clobbered dmap performance in my case, so I've avoided using them.

I reached the halfway point last night, so I'm on schedule. I wasn't around for the xmas contest. Are these things beta-tested like normal maps, or is testing limited to ourselves, because it's a contest and you don't want to give away too much ahead of time?

When you use sys.waitFor() and sys.wait(), the main loop will paint a certain number of frames before handing control back to your script. Is there a way to have it NOT paint a moving entity's positional changes during these function calls? I want to display beginning and end positions of a move, but I don't want to display the "in-between" positions. Using *.hide() won't do, because the entity becomes invisible for a moment, so it blinks off the screen, then back on when I do the *.show(). I'm trying to visually freeze something, make positional changes, then make those changes visible.

Perhaps you missed my post of last night. Go back to page 45 of the posts and look on the bottom. There's no map-only solution to opening an angled door. You have to do it in a script.

Ok, will do. I'm using them in my vertical contest map.

WRT the door rotation . . . The engine only rotates about the xyz axes, so for an object that wants to rotate about an abnormal axis, you have to script out the rotation. Rotating an object about an abnormal axis requires: 1. Rotate from the current orientation so that one of the local xyz axes lines up with one of the world xyz axes. 2. Rotate about that world axis. 3. Apply the inverse rotation you used in step 1. So if you have a door in the xz plane and you lean it back 45 degrees (like an outside cellar access door), and you want to rotate that door about its long hinge axis 90 degrees so it's open . . . 1. Rotate from the starting orientation back to the xz plane, which is a 45-degree rotation around the x axis. (i.e. stand the door back up straight) 2. Rotate the door -90 degrees around the z axis. 3. Rotate the door -45-degrees around the x axis. (the inverse of step 1) The door would now be opened along its long axis, but it wouldn't look good in the game, because you missed all the intermediate positions the door should be taking as it opens. So you have to break up the z-rotation (step 2) into smaller bits, say 3-degrees at a time. Pseudo-code would be: for (i = 0 ; i < 30 ; i++) { rotate the door 45-degrees around the x axis; // stand it up rotate the door -3 degrees around the z axis; // rotate it (90/30) degrees rotate the door -45-degrees around the x axis; // lean it back down wait a frame; // the door gets painted in its new partially-opened position } Each frame would show the door in a more open position, rotating around the abnormal axis which is its long hinge side.

A fullbright selflit blue skin is also missing, but I didn't create one 'cause I'm not using blue.

I now have fullbright yellow and white shrooms. These are missing in the standard set. Can they be added in 1.03? I just used the standard names I would expect TDM to use in a future release: For the *.skin file: skin mushroom_selflit_white { model models/darkmod/nature/mushroom_01.lwo model models/darkmod/nature/mushroom_02.lwo model models/darkmod/nature/mushroom_03.lwo model models/darkmod/nature/mushrooms_01.lwo model models/darkmod/nature/mushrooms_02.lwo tdm_mushroom_a_selflit_green tdm_mushroom_a_selflit_white } skin mushroom_selflit_yellow { model models/darkmod/nature/mushroom_01.lwo model models/darkmod/nature/mushroom_02.lwo model models/darkmod/nature/mushroom_03.lwo model models/darkmod/nature/mushrooms_01.lwo model models/darkmod/nature/mushrooms_02.lwo tdm_mushroom_a_selflit_green tdm_mushroom_a_selflit_yellow } For the *.mtr file: tdm_mushroom_a_selflit_white { qer_editorimage models/darkmod/props/textures/mushroom_white_d_ed surftype15 description "moss" noselfshadow noshadows forceOpaque { blend add map models/darkmod/props/textures/mushroom_a_a red 0.5 green 0.5 blue 0.5 } } tdm_mushroom_a_selflit_yellow { qer_editorimage models/darkmod/props/textures/mushroom_white_d_ed surftype15 description "moss" noselfshadow noshadows forceOpaque { blend add map models/darkmod/props/textures/mushroom_a_a red 0.8 green 0.8 blue 0.5 } }

Thanks for the quick response.