MoonDog

Mitre Joints Part I : Mitre In Radiant terminology, to perform a mitre means to join two brushes at a point by beveling them. The advantages of which include less verts/tris/poly's what have you. In the long term this means better performance. This step is very commonly overlooked. For example, this is where two walls meet. While it could work this way, it's not efficient. Let's have a look at why. Compiling the walls in this manner, and loading up the map with developer 1 and enabling r_showtris shows us the inefficiency of this design choice. Because we are using two faces of the brush unnecessarily, we have created 6 total triangles as defined by 8 vertices. In this very simple design, that doesn't mean much. If you add that up at the end of a larger, more complex design however, performance will take a hit. To save ourselves trouble, we will "mitre" the brushes together. Step one of the process. Select one of the two brushes. Extend the brush until it occupies the same space as the other brush. After you have done so, select both brushes at the same time. Enable the clipper (X) and select clip points at the joining corners. In Radiant you can hold control and then right click to quickly place clip points on the grid. (Except for 1.5.0) Press Shift+Enter to split both brushes along the clip line. Select the two walls and hide them with (H). You'll be left with the two trash brushes we wish to delete. Select them and delete them. Unhide the walls with Shift+H. You'll notice that both walls have been beveled at the place where they join. This eliminates the use of a face unnecessarily. This means we have eliminated 2 vertices and two triangles. Let's compile it and take a look! Remember, type /developer 1 in the console followed by /r_showtris 1. You'll notice that we've eliminated two triangles. Finally, let's look at the two design choices side by side. You'll notice a significant difference. *** An alternate(and way better/faster) method to using the clipper is to use vertex manipulation mode(V), or edge manipulation mode(E). In most cases these are faster. If you are comfortable with these two methods, it will streamline your design process that much more. Be careful with your manipulations in this manner as it could trash a brush quite easily. Here is a gif displaying use of Edge mode manipulation to achieve the same desired outcome. ********* Additional Examples:

Q: I injected a BSP with "misc_bsp". The sky is all screwed up in the new area! How do I fix it? A: When you insert a misc_bsp into an area of portaled void, you may have noticed that the skyboxes for those BSP ares blurred and incurring the hall of mirrors effect. In order to fix this, you must use a "misc_skyportal" entity. What this entity does is create a 360 degree snapshot and apply it to all skyboxes, including the misc_bsp entities' skyboxes. So, what you need to do is insert the entity WITHIN THE SKYBOX OF THE ORIGINAL LEVEL. You see that last sentence in red? Re-read it like 5 times. A good practice is to place the entity as far into a corner of the skybox as possible without putting it in the void. You are going to catch some of the original map on the skyboxes'. This is unavoidable. So try to keep it in an area where it sees as few entities and geometry as possible. Example: { "classname" "misc_skyportal" "origin" "X Y Z" }

Q: How do I insert models into my map? Why aren't they solid? A: First, let me tell you that your model's will never be solid. Model's are never solid to begin with even in GTKRadiant. What makes a model solid is a brush called clip. Or physics_clip. There are several different types but they accomplish the same thing. It's an invisible structural brush that blocks the player. So, in GTKRadiant you make your model, and then you construct a "box" around it as close to the shape of the object as possible and then make that box Clip. (You could also add the spawnflag to the model to make q3map2 auto-clip the object, but that's beside the point.) Obviously, in entity modding you cannot modify the map in this manner. Thus, your models will remain non solid. HOWEVER! The main method of inserting a model is using misc_model_health_power_converter entities and then specifying the "model" as the object you wish to use. Now, misc_model_health_power_converter has its own hitbox, which isn't very big. But it blocks the player, which is handy for simulating clipping around models. For example, in my FFA3 I have three consoles I use in my Logistics area. I'll show you one. { "origin" "258 2655 700" "angle" "270" "model" "models/map_objects/h_evil/control_station.md3" "classname" "misc_model_health_power_converter" "spawnscript" "unusablesetscale" "parm1" "1.2" }As you can see I'm using the script I showed everyone how to make in my scripting tutorial to make the object unusable as a health power converter, and to increase the objects size to 120% of its normal size. The one downside of this method is that the object will still recover player's HP when you press use, but it's easily correctable with that script.Scripting tutorial Now, just ONE misc_model_health_power_converter hit box isn't enough to make the whole object solid. So, I'll need to make other ones exactly where I'd like the object to be solid, thus abusing them for my purpose. For this step, you don't need to specify a model, just a spawscript to make it unusable. That makes sure it's invisible. Like this: { "classname" "misc_model_health_power_converter" "origin" "257 2655 729" "spawnscript" "unusable" }It's that simple. Note that I didn't just magically specify "unusable" as the spawnscript making it unusable. I actually have a script by that name that only has one line, Seting player usable false. That's all. You'll need to make one as well. There is a second method to make objects on your map, but I wouldn't recommend using it if you don't have to. You make a func_static with a bmodel from your map specified in "model" field. Then, you make another key called "model2" and put the map_object/model whatever in that key. This is handy because you don't need a script for this entity. Not even to set the scale. You can use the key model2scale in order to change the scale of model2, which is the model you desire on your map. Keep in mind, there is no hitbox for this entity, and unlike misc_model_health_power_converter you'll be able to walk straight through it. I'll show you an example of what this would look like: { "classname" "func_static" "model" "*2" "model2" "models/map_objects/imperial/cell_door_frame.md3" "origin" "X Y Z" "angle" "45" "model2scale" "150" }Note that you don't have to use !brushmoveorigin to place this entity. The origin for this entity can be wherever you actually want it. It's very important that you don't go overboard. You can only have 256 entities at a time in one snapshot(area). If you go over this, it will truncate them down to 256 thus making things start to disappear. Also, certain entities like trigger_multiples may stop working. Don't place too many func_statics in one area or any other entities for that matter. Also, only specify model's that come in the assets1.pk3. You want everyone to be able to enjoy your map. This means you have to work with what Ravensoft gave you. Good luck.

Disclaimer: This tutorial assumes you already know how to extract entities from a bsp file, make them into a .ent file and then recompile your changes back into the .bsp file. Q: How do I make teleports without using Ysalimari's or Force Boons? A: This concept is a little complicated, but not overly so. However, you may not understand it at first. I like to use 4 entities to do this, however you MAY use less. First we need a "trigger_multiple". Now, depending on the map you are modding, the bmodels will vary. If you have Boba Fett's UU, type !bmodels to get a list. Try to find one that's physical, and small. !modelshader works good for this(Tells you the textures a certain model uses. If its something like a trigger it will say, no shader/texture found. Meaning, this is an invisible entity. Usage: !modelshader *8) . This is important because you MUST specify a brush model for this entity, or you will get an error when you load the map. Let's look at an FFA3 example. { "classname" "trigger_multiple" "model" "*8" "target" "exampletele" "origin" "1646 -1364 292" "spawnflags" "2" "angle" "90" }As you can see on FFA3 I like to use *8. It's part of an elevator, so it's originally a func_door. However, since we are using an entity that is invisible, the model will likewise, be invisible. Now origin can't just be whatever you are looking at in the GPS/getcoords. We are cloning *8 for this. So, the position of the ORIGINAL *8 is treated as 0 0 0. So, you either have to do some math, or use Boba Fett's ultra utility(Highly Recomend!). Stand at the spot you want the trigger to be(Where you step to get teleported) and type !brushmoveorigin *8. It will give you the coordinates you need to use for the origin of the trigger. You may have to raise or lower Z depending on the Bmodel/position. *IMPORTANT* You are NOT changing the original *8 coding. You can leave that alone. Simply specify the "model" as *8 and you will have cloned it. Now for the other parts of the entity. I like to make it so you have to FACE the entity to use it. (I.E. you can't walk backwards through the tele and still use it.) To do that I simply add the spawnflag "2". (2 is facing). Since we added the facing spawnflag, we have to add the angle you need to face to use it now. "90" happens to be the direction I want people to face before they can use it. (If you need to get angles use Boba Fett's UU. Type !openmenu and navigate to the GPS. It will tell you the angle.) If you want to see other spawnflags I'd recommend downloading GTKRadiant and using the Entity List(N). It will calculate spawnflags for you if you don't have them memorized. Alright, let's move onto the other 3 entities we need. My "target" is "exampletele". So, let's keep that in mind when writing the next ents. Now we need the entity that actually does the teleporting. "classname" "target_teleporter". It need's to have the targetname specified in the trigger_multiple. Also, it will be targeting a "target_position"(Where you will be teleported to). So, let's write it out. { "classname" "target_teleporter" "targetname" "exampletele" "target" "exampleposition" }Well that was simple. Let's get the position. Go to where ever it is you want to be teleported to and use the GPS again if you have Boba Fett's UU. Note the origin and yaw(Angle you face when it spits you out at the position specified. Specify this with the "angle" key.) { "classname" "target_position" "origin" "20 20 20" "angle" "270" "targetname" "exampleposition" }Now this next part is completely optional. I like to print some text to tell people where they just ended up. To do this, you need a "target_print". It needs to have the same "targetname" as the target_teleporter. We want it to be triggered by the trigger_multiple at the same time. So, let's write it out and take a look. { "classname" "target_print" "targetname" "exampletele" "message" "You in the Ghetto neow" "spawnflags" "4" }Looking over it, its pretty self explanatory. In the message field you can use ^ color codes just like you do in game. Also, if you wanted to make a line break you'd use \n. Again we have a "spawnflags" key. On this entity "spawnflags" "4" makes it so only the person who triggered the Entity see's the text. If you left it out, everyone would see the text regardless of whether or not they teleported. So, here's the finished deal: (Let's use // to comment the entities, so we remember what teleport it is) { // Trigger multiple for my first tele ever "classname" "trigger_multiple" "model" "*8" "target" "exampletele" "origin" "20 23 20" "spawnflags" "2" "angle" "90" } { // Teleporter for first tele "classname" "target_teleporter" "targetname" "exampletele" "target" "exampleposition" } { // Position - first tele "classname" "target_position" "origin" "20 20 20" "angle" "270" "targetname" "exampleposition" } { // Text for first tele "classname" "target_print" "targetname" "exampletele" "message" "You in the Ghetto neow" "spawnflags" "4" }Also, for added effect, you can place a fx_runner over the spot the teleporter is to indicate its there. I like to use force/kothos_recharge to indicate the position of my ports. All the effects can be found in assets1.pk3 in your base folder. Just open up the effects folder within the pk3. Indicate the fx with "fxfile" and make sure you include the subfolder. You should end up with something like this: { // FFX for first tele "classname" "fx_runner" "fxfile" "force/kothos_recharge" "origin" "0 0 0" }

This ^ Try running the level in /devmap, /developer 1 as well. You may have some hints as to which shaders are fucked up right there in the console. Make the process of elimination go a bit faster.

Are you referring to how CoD checks contents and dependencies and then builds the fastfile? Yeah, this isn't CoD. You'll be manually packing your PK3. It helps to have a second, completely clean installation of JKA for this process. That way you'll know if you are missing anything. It's best practice, however, to keep your folders well organized; following a coherent naming convention in the base folder. That way it becomes super easy, and far less stressful to pack up your map. #beentheredonethatlostsomesanityalongtheway

http://upload.wikimedia.org/wikipedia/commons/6/63/Quake_-_family_tree.svg

er...? http://japp.jkhub.org/ Some reading will be required. I'm sure Raz0r will eventually add a disclaimer.

You can't connect those dots on your own? Isn't it obvious?

No it's not... They produced very few of their own assets. Everything else is ripped straight out of the JK assets.

An AI should flinch every time you walk by. If it isn't, you clearly aren't abusing it enough.

A level goes through a fuck ton of regular block in geo work before anyone in art even comes close to touching it. So yes. Block the damn thing out in Radiant. Show some work. Then people will be like, "Oh, the project is moving forward. Maybe I will contribute!". Whatever else happens with who you find to art the level, it still needs to be a really good block out FIRST.

I ran two different servers, one Linux and one Windows that worked perfectly fine on JA++ server side. I used the JA++ client side exclusively when I played. I had to do a bare minimum of compiling. So yes, I can agree that it doesn't work when subject to massive amounts of user error. Otherwise, no to whatever else you are about to assert.

You aren't a girl yet! I support your dream though.

Fuck me said paragraphs.

He phrased it precisely in such a manner that one would label as, "proper"... Stop being obtuse. This manual is a bit better. http://q3map2.robotrenegade.com/docs/shader_manual/contents.html. Do as wonko said. Then start looking at the various shader files that came with the game, or shader files from experienced community modders. Dissect them, use the manual as a reference. I get the idea when you ask questions, you expect to be hooked to the matrix and inherit the knowledge. Some work will have to be done on your part...

This ^ Also, you'll need to oversize some things like hallway heights and door frame measurements to accommodate the 3rd person camera.

This is not most engines. This engine is a really old modification of another really old engine. You are not going to be able to just make a collision mesh in the 3D package and have it work. You'll either have to manually clip the models in Radiant, (which I highly recommend you do.), or use Q3map2's automatic clipping for the models. (I highly recommend you do not do this. It takes every tris in the model and makes a clip for it. ) You need to understand how a .map is built into a bsp. How vis works, etc... You can make your aesthetic, environment art completely out of Radiant brushes and patch meshes. Or you can model a vast majority of the aesthetics. Which method you choose is irrelevant. Either way, you are going to need a structural hull that seals the playable space. This hull could be entirely made out of caulk brushes, or certain simple brushes in your aesthetic "layer". The difference being, if you are more comfortable/know how to use a 3D package to make environment assets you can and should. If you are more comfortable making everything out of Radiant meshes and brushes, you could. There are differences in terms of lighting/seams etc.. but those differences are in technical land.

What "purpose"? It doesn't matter in which way you choose to make the level, you are going to need a structural, sealed hull.

I haven't worked with 3DS, so someone else will have to weigh in on that. However, considering your work flow, I think it's a good thing you are using 1.5 instead of 1.6. A majority of what you are going to be doing sounds like model work. 1.5 has translation and rotation gizmos similar to some 3D engines. Makes it SO nice for placing models.

You could pretty much make your entire level in 3DS if you want. You would then use Radiant to place your assets, obviously, and then setup collision/visibility with a well made caulk hull. Then proceed to hint brush the level as needed to improve it.

ASE models. You make BSP, compile it and then convert it into an ase to be placed as a misc_model. GTKRadiant prefabs are a bit weird in how they work. It basically just copy pastes the prefab geometry into the map you have open. CoD radiant allows you to actually insert a prefab entity that you can rotate and move however you wish. Then you can dive into the prefab and edit it freely. Your best bet is going to be ASE models. Or if you are so inclined, getting a 3d package like blender and making assets in there.

Why would models "lag" your map out? Whatever you put in there is going to draw tris. You aren't getting something for free either way. Doesn't matter if you use 99 percent models and 1 percent BSP or vice versa. Optimization happens through smart layout/vis, and doing what you can do reduce tris counts on complex objects. Eliminating unnecessary faces, reducing complexity on objects etc... Also, do define prefab. Do you mean CoD style prefabs? Because that is not how the GTKRadiant do. The GTKRadiant just stamps geometry directly in. What are you trying to achieve? A set of objects that you can place in and rotate freely? Do you mean .ase models?

Doesn't work in SP

I'll take your word for it. I have neither of these games installed, nor do I have the source code on this machine.