Jump to content

MoonDog

Members
  • Posts

    568
  • Joined

  • Last visited

Everything posted by MoonDog

  1. Detail brushes, patch meshes and translucent brushes are not entities unless you make them into entities. *edit* Disregard. I thought you were telling me "All Entities can be filtered with Alt + 2". Misread. As to say, "oh you can do all that with alt + 2". Yes, filter entities as well.
  2. Your flames are making white light. Also it's a bit dark. I'd modify your original design to allow more natural lighting from your sky shader(If it's emitting light.) Or crank up the ambient a tad. You don't want people to have to squint to pick out your geometry. You can still keep the same vibe, but have a better lit play space.
  3. During bsp, a recursive operation splits the map into volumes based on the planes of the structural brushes. (The entire grid of the level is treated as the initial volume) The newly created volumes are called child volumes. If the recursive(repeating) operation encounters more structural brushes inside the child volumes it will create more child volumes inside those child volumes until it no longer encounters structural brushes inside a volume. Now this may seem confusing, but trust me you need to know it. This is the first stage of how visibility is handled. You see, during the vis process, where one face of a volume is constrained by another face a portal is created. (Use the portal viewer on a bsp compiled map and you'll see) This is where terms like PVS(Potentially view able set) may seem familiar. For a player in a node that can see through the portals into other nodes will render the geometry in those nodes. (Which is why you need to think about angles and hint brush usage) IN ANY CASE. You have an extremely unnecessary large amount of structural brushes in your level. Hopefully in my explanation above you can see why. The only brushes you need to be structural are ones that are necessary for culling geometry when it comes to vis in your level. All the small details can be made into detail brushes (The recursive operation ignores these). A some what silly rule of thumb(because it may not always apply) is to keep walls, floors and ceilings structural. For the player is not supposed to see through them, no? Things you don't have to do -Detail brush your patch meshes. (Patch meshes don't affect the vis no matter what you do to them. You can ignore them.) -Detail brush brush models. (These are brush entities like trigger_multiples, func_doors, etc.... They too will not be used to determine volumes. Safely ignored.) -Detail brush most translucent brushes. (Stuff like clip. Obviously this doesn't apply to hint, area portal etc...) *edit* I'm sorry, I forgot to tell you what to do. Select the brushes that do not need to be structural. Right click the grid and press "Make Detail" -or- Select the brushes and press Control + Shift + D. (Preferred) To see how you are progressing filter out detail brushes with Control + D. It also helps to filter out patches Control + P and translucent Alt +4.
  4. Make a target_scriptrunner. Give it a -1 count so it can be used infinitely. Copy the following text and make it into an Icarus script with Behaved. sound ( /*@CHANNELS*/ CHAN_AUTO, "sound/movers/switches/button_09.mp3" ); use ( $get( STRING, "SET_PARM1")$ ); wait ( 2000.000 ); use ( $get( STRING, "SET_PARM1")$ ); Now, you see above how it's looking at parm1 to figure out what exactly to use? Since we didn't make the scriptrunner use on activator, you can simply designate parm1 on that entity(the target_scriptrunner) For example, "parm1" "SwitchName". Obviously you have your two func_usable entities as switches, one with your on texture the other with your off texture. Since you want the Off texture one to be displayed constantly when not in use, give it "targetname" "SwitchName". For the other func_usable with the On switch texture, check the spawnflag box for Star Off. ("spawnflags" "1" I believe) Also give it the targetname "SwitchName". Create a trigger brush over the switch, and target it at the scriptrunner. When the player activates the trigger it hits the scriptrunner, which runs the script. It uses whatever entities are named in parm1, waits 2 seconds and then uses them again. Since one func_usable is on, when used it will disappear. The other one that starts off will appear. After the two seconds the second use will revert the switches back to their original states. Make sense?
×
×
  • Create New...