rich_is_bored

That's it. Well it was good practice I suppose.

I was sure I could find the font used for "The Dark Mod" and while there were some close ones I couldn't find a perfect match. The next best thing is a vector image so you'll find dm_text.svg on my OneDrive... https://onedrive.live.com/?authkey=!AJiXvvAkc6DWFps&id=D6625ED3877C9FB4!1149&cid=D6625ED3877C9FB4

I'm not sure parallel computing has matured to the point where quad cores are mandatory. There are some new Pentiums available for $50 that are just as fast as an i7 but dual core. I built my nephew a system with one and I was a little nervous that it might not be powerful enough but it seems to runs new games just fine. Here's the build... https://pcpartpicker.com/user/rich_is_bored/saved/#view=XnzdnQ

I was the one working on that. Finished it too. You're looking for dm.svg... https://onedrive.live.com/?authkey=!AJiXvvAkc6DWFps&id=D6625ED3877C9FB4!1149&cid=D6625ED3877C9FB4

This is one of those cases where collecting data from players would be useful. Mission statistics come to mind. You can use averages, minimums, and maximums to make some reasonable assumptions about the nature of a mission.

It's my understanding that caulk doesn't block visibility. I'm not even sure it survives the compilation process. A map file is simply a collection of entities, brushes, and patches. The interior volume of the level is not explicitly defined but inferred from entity placement during compilation. Imagine every entity is replaced with a water spout and the level is being flood filled. This is where caulk is useful. You fill the gaps created by non-sealing textures and geometry with caulk to assist the compiler. As far as I know, caulk serves no other purpose. If there is a test case where using caulk in an unconventional way improved performance I'd like to see it.

Unique locking mechanism built into a desk.

Reverse image search. Use something that turns up in the results instead. Profit.

That's a lot of fluff for little benefit. It would be much easier to simply delay the reaction to spotting a body. Continue your patrol for a minute or two, make a remark about someone missing. Return to the scene of the crime and "find" them.

Yep.

Fixed again.

Fixed.

Yeah I figured you'd have feature requests. The link has been updated. Scale is now validated to be a numerical value greater than zero. A checkbox has been added to accommodate Q3. I cannot make the window persist or be on top nor can I parse command line parameters. The API doesn't appear to support any of that. If you'd like to reset the matrix, delete the rotation and modelscale key/value pairs. For the record, an ideal version of this plugin would have no dialog at all. I'd be able to draw a scaling widget directly in the orthographic views and you could drag around it's handles to scale the object the same way rotation currently operates. Any perception of poor workflow is not by choice but rather a product of working within constraints.

Save to your scripts/commands directory... https://onedrive.live.com/redir?resid=d6625ed3877c9fb4!1154&authkey=!AGIwNioQrHbSZZE&ithint=file%2cpy

If you're starting with a model that has no rotation applied the matrix would be [1 0 0 0 1 0 0 0 1] and then [2.5 0 0 0 2.5 0 0 0 2.5] if you're scaling it to 2.5. But you have to think about the complexity of the rules your crafting for yourself. Do I apply the scale before I rotate or after? What's the default matrix look like? Which positions do you modify again? IMHO, it's much easier to simply multiply against everything. There are no special cases to worry about. It just works.

A additional spawn argument would be redundant. A transformation matrix is already stored in the rotation spawn argument. That takes care of translation, rotation and scale. Ideally you'd have a widget in DR to manipulate the scale but it's not all that difficult to manage without it. Wanna scale a model by 2.5? Multiply all nine values in the matrix by 2.5. One caveat you will find is that the collision for models scaled in this way is broken. If you wanted to fix it I imagine the code that handles the rotation spawn argument is where you'd look.

Frequency is a concern for another time. You'll be able to apply envelopes to the sound in the future if we ever get EFX working and that will solve that problem. Instead, just play with values and go with what feels good. You can throw these values into CVars if you like. Then we can all play around and find a good default.

I solved the distribution problem in my own way. I used a no draw material as a particle emitter, slapped it on a patch and threw it in the skybox. The patterns are gone. About a week ago I was trying to find scientific data about the color of the night sky to produce a cube map without any other features. This is where I left off with that although it's still not quite right... I stopped shortly there after because the color banding was ridiculous, unavoidable because it's so dark, and I got sidetracked looking for ways to dither it. You can't see it here because this is one of the six sides of the cubemap but in game it's awful. At any rate, I look forward to seeing what you've got cooking.

That's cool and all but I'm simply talking about sound volume. Let's try this again. We know the game currently traces a path from the source of a sound to the player like this... Point A would be the source. C would be the player. B is the closest visportal along the path and where the sound would actually be played. The sound playing at B has it's volume reduced because it is closer to the player and must sound as if it is originating from A. Coincidentally, the path is direct and the sound it is pretty accurate. Now, here the sound is originating on the other side of a wall. Again the path goes through the "closest" visportal and B is reduced because it must sound as if it's originating at A. There are two problems. Does the game account for a change in direction? Assuming the length of path ABC is constant in both illustrations, wouldn't the indirect path result in a quieter sound? The sound had to bounce off a wall to reach the player. We must assume that some energy was lost in the process. The more acute the angle, the more severe the volume reduction. Additionally, there's a second hole in the wall. Is the game accounting for this path or mearly stopping short at the closest path? Every visportal in the same node as the player should be evaluated to see if there is a valid path leading through to the source. If so, the same process should play out for each. You don't need to cast a hundred rays to work this out. All you need is the path from the source to the player the game already calculates. Then you repeat this process, but looking for the next "shortest" path until every visportal connected to the player's current location has been accounted for. If you have a room with 4 visportals, there would be potentially 4 valid paths.

Yes. But we shouldn't be concerned with absorption or reflection on a per material basis. That could get really expensive to calculate. Instead we operate under the assumption that all materials have the same properties and just measure the change in direction.

Just to clarify when I said 'angle of turns' I was referring to sharp changes in direction. The less straight the path, the more bounces would be required for a sound to reach the player.

Sure. If you look at it in a vacuum, it's a dumb boring quick-time event. But if you consider the fact that the game doesn't come to a screeching halt whenever you attempt to lockpick a door, the genius becomes apparent. While you're listening closely to the tumbler, the guards are still doing their rounds. You must be forever alert to your surroundings or be caught at any moment. That's where the fun should be coming from, not some stupid popup minigame.

Portals and leafs should be more than adequate for directional sound. All you're looking to do is trace a path (ideally all possible paths) from the source to the player. Then you attenuate the sound based on the size of portals that have been passed through, the angle of turns, and distance traveled. As far as I can tell, the engine is only accounting for the distance of a single path.

Glad to hear this experiment was useful in some way.

No program is going to identify every fault and correct them for you. I'll give you an example... Above is a plane. It's a single polygon with four edges and four vertices. It's completely flat. I select the upper right and bottom left vertices. I move them both straight up. I have created an impossible shape. It can't be a plane and not be flat. The vertices are aligned like the uneven legs of a chair; rocking when you shift your weight. It's a non-planar shape and this situation is the reason every piece of 3D software renders geometry as triangles. It's impossible to make a non-planar triangle. Imagine a bar stool with three legs. Uneven legs make the stool crooked but the legs are always planted. So knowing that; even though the triangles are hidden from us we know this "plane" is in one of two states... Which one is correct? In this case, either is fine. But in practical use maybe it matters which way the program decides to split the plane. Maybe the smoothing looks wrong with the split running from left to right. Sometimes the artist has to specify because the software can't know what looks best. Now I ask you, how does a program that hides all the details from you make it possible to fix this? You've got to crawl before you can walk. It doesn't matter if it's Lightwave, Blender, Max, Maya, whatever. You will run into problems you don't understand and want to rip your hair out. If you persevere it will all fall into place. About eight years ago I knew nothing about modelling. I started with Lightwave and then migrated to Blender. I spent money on video tutorials but in hindsight I didn't need to. I learned everything important in the first month or so from free content. I can help you if you'd like to learn. Ask questions.