MoonDog

Are you.... are you serious?

JA++ does have a bit-field calculator. http://japp.jkhub.org/?page=calculator

Er... no. The script makes it so whatever you assign it to as a spawnscript can't be used by players, and you can set it's scale in the parm1 field of the entity while you are ent modding. And to make it a spawnscript on the entity you add the keys "spawnscript" "script_name". As for more detailed instructions, no. The screenshot is more than sufficient.

You can't make solid objects with entity modding. The objects aren't solid to begin with. That is done with the various clip shaders in Radiant. (Or autoclipping through q3map2, but like mrwonko said it's not advisable. Creates a clip plane for every tris in the model. Grossly expensive.) Your best option would be to use misc_model_health_power_converter entities with no model of it's own indicated. That entity has a small hitbox you can take advantage of in entity modding to simulate real clipping. However it get's expensive if you try to get too complex with it. Anyways just try this. Get the origin of the model you are using and make a misc_model_health_power_converter in the same location. A quick word about this. The entity will still be usable as a health converter, which can be cheesy. Make this script the spawnscript of the entity. The setscale line can be safely ignored. Unless you plan on using it to scale up or down one of your models. In which case just put "parm1" "number" in the entity. *Disclaimer: You can't affect the hitbox of the misc_model_health_power_converter. Ex: Change it's scale or shape.

Something like that would also benefit from a larger blocksize.

They are brush models. Meaning they are level geometry given properties as entities. For example a square brush made into a func_door. All the brush models are sorted into an index which is called a Brush Model Index and stored as a lump in the bsp(I think). In any case, they are each assigned a designation and can be seen in the entity list within the BSP by looking for the designation "model" "*number". Anyway I'm pretty sure Boba Fett's Ultra Utility can list all of the brush models for you, as well as their origins in relation to the 0,0,0 origin of the bsp. Try !bmodels.

You don't need two triggers first off. One trigger can target a multitude of entities. Second, your origins and angles are probably wrong for the brush models. (I'm not sure which one *1 is btw, *8 is a tiny piece of an elevator and generally works better.) Use Boba Fett's UU. Get in game and do !brushmoveorigin bmodel. Ex: !brushmoveorigin *8. In order to move the cloned brush model to the origin you are currently occupying, UU will give you the proper origin to use. This is because the origin of the original bmodel is treated as 0, 0, 0 when it is being cloned. You can't give it an origin based on the 0, 0, 0 of the bsp. It simply will be some place completely different. Next, check your angles. You have spawnflags 3 on the first entity. Which I can only assume is facing and clientonly. So make sure your facing angle is correct. Same with the second trigger. Which appears to be facing, clientonly, usebutton. Also, I'm not sure why you have targetnames on your triggers. You can probably get rid of those. Lastly, just delete one of the triggers. Give the target_teleport and the target_print the same targetname and target the trigger at them. Easy.

Generally, yes that is a good rule. You only need things to remain structural if you want them creating splits. You should read this. http://www.quake3world.com/forum/viewtopic.php?t=3620

Yeah, sorry. I misread your post. Happens occasionally.

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.

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.

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.

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?