Quake3World.com https://www.quake3world.com/forum/ |
|
AEon's Quake 4 Mapping FAQ - v3.2 https://www.quake3world.com/forum/viewtopic.php?f=10&t=19720 |
Page 1 of 1 |
Author: | AEon [ 04-30-2006 10:38 PM ] |
Post subject: | AEon's Quake 4 Mapping FAQ - v3.2 |
AEon's Quake 4 Mapping FAQ
Edited by AEon (C) 2006 (* Marks changes since v0.97) Intro
Note: In some cases a short description is not enough to explain the more complex topics, thus links to more in-depth articles are provided. Focus: Multiplayer maps are the focus of this FAQ: DM (Death Match), Tourney, TDM (Team Death Match), and CTF (Capture the Flag, later maybe). But the information should also be applicable to other mods. Editor: The examples use Quake 4's built in editor, but should also be workable for the latest GTKradiant (v1.5). HTML Version: If you prefer a niced-up version of this FAQ, with working Index and Anchors see: Index
The Basics Movement Related Elements Detail Elements Debugging & Finalizing the Map Additional Information FAQ Related Getting Started *Setting up Quake 4 for Mapping?
In one folder - the development folder - you install all the mods, editors, SDKs, and custom content (textures, models, etc.), and your different map versions. Usually you also start unpacking parts of Raven's original pak00#.pk4 archives. And if I remember correctly, this can lead to an un-pure local install (prohibiting online play). As you will see the install can get very untidy. The other folder - the test / online folder - is basically a clean install of the game that you use to try out the "finished" versions of your map .pk4. It is also the folder you should use to play online. Why use a second clean install? Because it lets you test your map for potentially missing custom content. A classic for Q3A used to be textures that came with GTKradiant, but were *not* part of the original game, thus would very often be missing in final map packs. Bad! So by simply walking through your map, you now can "see" if your pk4 has every relevant file included. Additionally you can also easily check the console warnings. Step by step: *Launching Q4 and the Editor?
Step by step: Links: Configuring Q4 and the Editor?
Why the need for different configurations? Because when mapping you will run everything at desktop resolution (i.e. editor) and probably pretty much at the best quality level your hardware can handle. Doing so will yield a better feeling for how your map "should" look, when you run Q4 from editor via F2-key. On the other hand when playing online, you will probably want to turn down all the graphics settings (low quality), lower the resolution, and also want special key bindings for online play (e.g. mod specific, or chat messages). Using these two configurations lets you change between them easily, and your multiplayer settings will also come in handy testing your map at *low* settings. Info:
Comment: I use the 3 mouse buttons, W, A, S, D movement keys, and the keys 1 to 0, Q, E, R, T, F, C, X, Y, Shift, Ctrl, Space as shortcuts to bring up weapons directly. But all the keys to the right of the keyboard are free to bind. (AEon) The mp.cfg:
Code: // MP Colored Nick Name // -------------------- // ^0 Default ^1 Red ^2 Green // ^3 Yellow ^4 Blue ^5 Cyan // ^6 Pink ^7 White ^8 Gray // ^9 Black seta ui_name "^1^^3AEon^1^^0" // MP Chat Messages (fun) // ---------------- // ^0 resets colors to default console/HUD color bind "h" "say '^7...^3Hi EvErYoNe^7... 8-)^0'" bind "m" "say '^7...^3ShMiLe^7... :)^0'" bind "j" "say '^7...^3WheEeEeEe^7... 8-))^0'" bind "k" "say '^7...^3ThAnKs^7... :-)'" bind "l" "say '^7...^3LaTeR fOlKs^7... :o)^0'" bind "i" "say '^7...^3AaArRrHhHgGg!^7...^0'" bind "n" "say '^7...^3NiCe OnE^7... :-P^0'" bind "o" "say '^7...^3OuChiLiE^7... :-|^0'" bind "p" "say '^7...^3OoOoPpPsSs^7... :D^0'" bind "u" "say '^7...^3SoRrY^7... :-)^0'" ...more coming soon... The mapping.cfg:
Code: ...coming soon... Useful mapping Tools & Mods?
Downloads: How to Build a Map?
Links: The Basics What are Q4's Heights & Distances?
Step by step: How to Compile a Q4 map?
Step by step: Links: How to apply Visportals?
Basically what this does: Imagine 2 rooms with a doorway connecting them. You place a brush that completely fills out the doorway, and place the Visportal "texture" on brush face that covers the doorway. Now when you stand in room 1, but cannot see the doorway in your field of view, room 2 will not be rendered. Thus optimizing FPS. Important: Walls will *not* autoclip the view like in Q3A, you need to make every area "airtight" with Visportals! Step by step: Links: How to properly add lighting?
How to add outdoor (ambient) light?
Step by step: Links: *How to Clip MP Maps?
In Q3A this was especially useful (botclip) to optimize the map for AI. And apparently custom bots exist for Q4 as well. Note: I am aware of the Oak Bots, these seem to work well enough with player_clip but Raven recommends the usage of clip. It was proposed that monster_clip should work much like Q3A's botclip, but is does not. monster_clip actually breaks the bot movement! Step by step: More examples of clipping: Links: |
Author: | AEon [ 04-30-2006 10:40 PM ] |
Post subject: | |
Movement Related Elements *How to add Respawn points?
Info:
Step by step: *How to add Jumppads?
The Model: Decal under jumppad model: Cushion Model: The JP effect: The Trigger brush: JP Destination: JP Light: *How to add Acceleration Pads?
The Model: Model Clip: The AP effect: The Trigger brush: AP Destination: *How to make Teleporters work?
The Q4 teleporters are made up of several parts, some mandatory like the trigger and the destination, the rest are nice visual clues for the player: The Teleporter model, a simply patch mesh decal, a trigger brush, a teleporter destination, a teleporter effect, and possibly a teleporter ambient sound and light. The Model: Decal under teleporter model: The TP effect: The Trigger brush: TP Destination: TP Light: Tips:
Comment: I'd open Q4DM1 in editor and copy/paste the parts of the teleporter into my own map and edit those. Links: *How to add Weapon/Item Spawn Pads?
The Model: Decal under weapon base: The TP effect: Weapon / Item: How to build a Ladder?
Step by step: Links: How to build an Elevator?
Step by step: Links: How to add Sliding Doors?
Comment: Personally I avoid using doors in MP maps, but a sufficiently complex map may require dynamic control of Visportals via doors. Step by step: Links: Detail Elements How to add a Skybox?
Step by step: Links: *Using Q3A Skybox textures in Q4?
To make this work you will need a special "skybox" shader and abide to the new filename conventions for skybox textures introduced by Q4. Example Q4 Skybox Shader:
Location: Abiding to Q4's folder structure place the 6 skybox textures (image files) in q4base\gfx\env\. Naming: Replace the below <skybox> tag with the name of your skybox files, i.e. with q4base\gfx\env\iceflow_up.jpg you should name <skybox>: iceflow. Shader: Give the your skybox shader a unique name by replacing below <mapname> tag with the name of your map, e.g. textures/aetri/skybox. Code: // Skybox code based on Raven's: // textures/skies/Red_Sky // e.g. textures/aetri/skybox textures/<mapname>/skybox { qer_editorimage textures/editor/sky.tga noFragment forceOpaque noimpact noshadows { blend add // e.g. gfx/env/iceflow cameraCubeMap gfx/env/<skybox> texgen skybox } } Q4 Skybox Filename Convention:
Location: Usually the Q3A environment textures (skyboxes) will reside in baseq3\env\aedm7\<skybox>_<tag>.tga, you will want to move them into the Q4's default skybox folder: q4base\gfx\env\. Rename: To make the skybox textures work in Q4, you need to rename the Q3A files in the following manner: Code: Q3A Name Q4 Name -------- ------- <skybox>_bk.tga <skybox>_left.tga <skybox>_dn.tga <skybox>_down.tga <skybox>_ft.tga <skybox>_right.tga <skybox>_lf.tga <skybox>_back.tga <skybox>_rt.tga <skybox>_forward.tga <skybox>_up.tga <skybox>_up.tga Using the Custom Skybox:
*How to place Models?
Step by Step: How to add basic Fog?
Step by step: Links: *How to add Ambient Sounds?
Step by Step: *How to trigger Sounds?
Step by step: Links: How to add simple Terrain?
Step by step: Links: How to add Particle effects?
Comment: I have no idea how badly this impacts the FPS (Frames per Second), q4dm1 uses it a lot though. Step by step: Links: |
Author: | AEon [ 05-01-2006 07:09 AM ] |
Post subject: | |
Debugging & Finalizing the Map How to Test a MP Map (Console Commands)?
To actually spawn a multiplayer server by typing spawnserver mp/<mapname> on the console is a better way to go. This may not set the proper game mode though. E.g. DM, TDM, ... When testing you map many times, the best way to ensure you are running it in the correct gameplay mode is to write a small configuration file, and run that: Step by step: Links: How to Debug a Map?
Step by step: Links: How to wrap things up into a pk4?
pk4 "archives" much like the pk3 files for Q3A are basically zip files that mimick the folder structure Q4 uses. So you can use any zip tool to "collect" and "place" the files. Just rename the .zip file with .pk4 when done. Why use a pk4 file? It is the only accepted way for community maps to be distributed, it is less messy to install, and lets servers provide your map for automatic download. Where do your .map files go? Relative to the pk4's path multiplayer maps go into maps/mp/<mapname>.map. The absolute path in your Q4 folder would be Quake4\q4base\maps\mp\<mapname>.map. pk4 Structure:
Comment: I would recommend id's naming convention for map pk4 files: map_<mapname>.pk4 (e.g. map_aeglow.pk4). This makes it clear that the pk4 is indeed a map or set of maps, and not a texture set etc. And trust me, there will be many files the q4base\ folder! Code: q4base/map_<mapname>.pk4 addon.conf // Enables autodownload def/ <mapname>.def // Defines <mapname> // map loadscreen path gfx/guis/loadscreens/ <mapname>.tga // Loadscreen image gfx/guis/mainmenu/ <mapname>.tga // X360 Thumb image maps/mp/ <mapname>.map // Level source file <mapname>.proc // Compiler output <mapname>.cm // Compiler output <mapname>.aas // Compiler output AI <mapname>.aas32 // Compiler output AI materials/ (any custom material files) models/ (any custom models files) scripts/ (any custom scripts files) sound/ (any custom sounds files) textures/ (any custom textures files) Enable autodownload of map pk4 via addon.conf: Custom Loadscreen via .def file: Links: Additional Information About the Q4 SDK?
It does contain a lot of potentially useful info if you do plan on using any other custom content like textures and material (the new "shader") files, as well as a few good pointers and tips. (Obsidian) Links: Other FAQs & Tutorials?
FAQ Related *Notation
Credits
Special thanx go to KungFuSquirrel, Kat, Method, Toireht, tequila!, obsidian, pjw, hemostick, ... Features: Comments by Raven Designer "KungFuSquirrel" (coming up). History
ToDo List
|
Author: | tequila! [ 05-01-2006 01:13 PM ] |
Post subject: | |
Here's what I use for debugging junk, there are a few more commands in there than you listed. Info on how to use the "Debug Hud" can be found at: http://www.iddevnet.com/quake4/LevelEditor_Performance ---------------------------------------------------------------------------------- Code: bind "BACKSLASH" "toggle r_showprimitives" // triangle counts
bind "[" "toggle con_noPrint" // prints 3 lines of the console bind "]" "toggle com_showFPS" // show FPS bind "p" "toggle r_showlightcount" // lighting overdraw* bind "o" "toggle r_showoverdraw" // geometry overdraw** bind "i" "toggle r_showtris" // show triangles*** bind "y" "toggle r_usescissor" // uses OpenGL scissor when rendering*** bind "u" "toggle r_showportals" // show vis portals**** bind "k" "toggle ui_showgun" bind "l" "toggle g_showhud" bind ";" "g_showdebughud 5" // or bind ";" "toggle g_showdebughud 0 5" bind "'" "g_showdebughud 0" bind "/" "noclip" ---------------------------------------------------------------------------------- * Lighting overdraw, black = 0 lights, red = 1 light , green = 2 lights, dark blue = 3 lights, cyan = 4 lights, etc. "r_showlightscissors 1", combined with "r_showlightcount 1" can be useful in understanding exactly how light overdraw is determined by the engine. Using those two commands plus "r_showtris 1" is also handy, for learning, as you can see exactly why very large triangles tend to have worse light overdraw than small triangles. This is why it is sometimes recommended to split up large surfaces - sometimes it is worth adding a few more triangles to save yourself some light overdraw. A floor with a bunch of chicklet lights around the edges is a classic case for splitting a large surface. ---------------------------------------------------------------------------------- ** Geometry overdraw, blue = good, red = bad basically. ---------------------------------------------------------------------------------- *** Setting "r_showtris 2" and "r_usescissor 0/1" (toggle it) can be useful for learning how the engine works.. not something you really need later on - at least not often IMO. As long as you understand exactly what vis portals do, you can infer this information simply by using "r_showportals 1". ---------------------------------------------------------------------------------- **** Vis portals, green is an "open" portal, red is a "closed" portal. Nothing beyond a closed portal is drawn or even sent to your video card per frame. Everything in front of a closed portal is sent to your video card for the geometry to be translated from world space to perspective space. (Not sure if that is the proper terminology) Open portals in your scene act like windows, using OpenGL's "scissor" function to only actually render, pixel by pixel, what you can see THROUGH whatever open portals are in your current view. Turn on "r_showportals 1", and "r_showtris 2", and then toggle "r_usescissor" to see difference between triangles which are only translated, versus triangles that are actually rendered pixel by pixel. Triangles which are translated only are cheaper than those that are both translated and rendered, but it should be noted that the translation stage uses some of your CPU and VPU time available per frame; it is not free. ---------------------------------------------------------------------------------- edit: Edited a few things. One thing I should have been more clear about, "r_usescissor" is by default set to 1, and should be kept that way for playing. There's no reason to turn it off for actual playing unless you like fewer FPS. Edit by AEon: Niced up bindings a bit. |
Author: | pjw [ 05-01-2006 04:57 PM ] |
Post subject: | |
tequila! wrote: Debug Hud I was just going to post this, and you beat me to it. Long time no see; how the heck are you?
[Edit: Sent you a PM, so as not to crap up the thread.] |
Author: | AEon [ 05-01-2006 07:34 PM ] |
Post subject: | |
tequila! wrote: bind "o" "toggle r_showoverdraw" // geometry overdraw** I had most of your commands in my autoexec.cfg, that I plan to really clean up and post, but the Geometry Overdraw is new to me. Nifty Quote: edit: Edited a few things. One thing I should have been more clear about, "r_usescissor" is by default set to 1, and should be kept that way for playing. There's no reason to turn it off for actual playing unless you like fewer FPS.
That's one of the things I also found strange when reading the FAQs. The feeling I got was it would be off by default. Will turn it on now by default, I assume this would really help in MP gaming online? I edited your post slightly, placing your bindings in a code tag. BTW: Code: bind ";" "g_showdebughud 5" bind "'" "g_showdebughud 0" can be elegantly condensed to Code: bind ";" "toggle g_showdebughud 0 5"
since toggle now understands a "list" of possible numerical states. Thanx, will carefully read all the info and add it to the FAQ. |
Author: | AEon [ 05-03-2006 01:15 AM ] |
Post subject: | |
Already have to split the FAQ into 2 Posts... ieeks... |
Author: | obsidian [ 05-03-2006 07:24 AM ] |
Post subject: | |
AEon wrote: Already have to split the FAQ into 2 Posts... ieeks...
You sir, are amazing. I'd hug you except tigers have a tendency to pounce and bite. |
Author: | AEon [ 05-03-2006 05:50 PM ] |
Post subject: | |
Thanx Only noted these past few days that Q4 mapping seems to be off to a troubled start, even more so than D3. Not only here at LEM but also over at D3W.org's Q4LE... hmmm. As that may be a few of the Q&As are starting to be interesting by themselves, meaning containing information spread over several sites. So hopefully the FAQ will be of some use at some point. Alas my copy of has yet to arrive. Sigh... |
Author: | KungFuSquirrel [ 05-03-2006 09:37 PM ] |
Post subject: | |
Seems odd to be compiling an FAQ without having touched the game yet yourself. Pretty good coverage so far... things I've noticed: -Visportals work best in pairs. Just having a single portal in an open connection between rooms won't close. Think of it as defining chunks of level to draw at once. Because you can see one end of that chunk, the entire chunk draws. If you have a longer hallway between rooms, and then place a portal at each end, you'll get a better result. When you're looking down the hallway into the other room, the portals overlap and open. As soon as the back portal is no longer visible from the near portal, it closes, blocking the other room. You'll see a lot of narrow double-portaled chunks in our maps for this reason, or an occasional portal in the middle of a room to cull off exits on the other side. Hopefully that's a clear enough description... The triangle gain you get from portals (or most anything else, really) is insignificant, and can be useful for helping light overdraw on faces without having to offset textures or add trims. What is dangerous about portals is the batch size splitting. You can really ramp up your draw calls if you portal too aggressively, but they can also go too high if you don't portal enough. It's a fun balance to find. Portals also automatically toggle off and on when placed inside func_doors (the portal face should be on the same plane as the origin). Handy! also, crossing vis portals is like crossing the streams ghostbusters. Don't ever do it unless it's time to save your map from a giant marauding marshmallow. Oh, and fading portals! these fade from fully visible to a specified image over the units specified in the material file. Might be worth a mention as well. Handy for windows in some dire cases. -ambient light. Be careful with this; it still adds a light pass to everything. Also, ambients sort of bake a highlight onto normals, so mirrored textures and flipped objects can look really ugly if you go too bright. You can sort of see this on MP characters in the MP maps. Great for illumination, but terrible for visuals if you're not careful. -clipping. For our maps we used player clip, but I'd recommend regular clip at this point. Community-made bots need an aas32 file, and player clip does not define AAS. -Q4 has limited portal sky functionality that can easily be 'hacked' via script to get a proper parallax effect. Use skycaulk in areas where you want the portal sky to draw, then use a func_portalsky_camera (I may have just typed that wrong, actually) placed in a smaller skybox area using a regular sky texture and whatever you feel like (terrain models, structures, effects, etc.) -All terrain in Q4 was modeled in Lightwave. I would highly recommend against using patch or old-school tri-souped terrain. Modeled terrain allows more controlled/defined shapes, better silhouettes, and texture blending based on vertex color. -Particle button/functionality is completely removed in Q4. You have to manually set an "fx" key or use the effects editor in the game. I recommend the latter; you can use the entity editor to drop new effects, align them, orient them, edit them, etc. etc. and then save out your .map file with the changes. Much easier than manual placement. -Biggest performance console command, r_showbatchsize, is barely touched on. Toggling this on shows how efficiently triangles are being sent to the video card (which likes to eat triangles at about 500+ at a time). I've stopped using r_showtris entirely in favor of this; raw triangle count barely matters vs. draw calls/batching and light overdraw/shadows. Managing draw calls is arguably the single most important aspect of render speed optimization. It's covered pretty well in our performance guide on iddevnet, but I'd recommend detailing it out so it's not overlooked by anyone who might find this first and not bother to follow the links. -oh, and compile time. vis portals (the geometry splitting on portals, for example) and some lighting information (for shadow purposes) are calculated during compiles. For an MP -noaas or -aasonly32 compile it should still be pretty quick, but complex geometry and lighting can jump that up quick. Larger SP maps could take in the range of 15-30 minutes. But given how long these used to take previously, that's still not too shabby. Great resource, though, let me know when you get it to a more permanent location and I'll toss it onto the iddevnet links list. |
Author: | AEon [ 05-04-2006 12:50 AM ] |
Post subject: | |
KungFuSquirrel wrote: Seems odd to be compiling an FAQ without having touched the game yet yourself.
Yep ... but then again I have been working with id engines a while, and also did a week of D3 testing, and tested a few things in the Q4 Demo. But there are bound to be errors. Will carefully read your feedback later, thanx! |
Author: | AEon [ 05-04-2006 02:54 AM ] |
Post subject: | |
Quote: Visportals ... double-portaled chunks ... A few nice sketches that illustrate this would probably really help. I guess one tip - as always - is to look at Raven's maps and see what they did. If someone would just scribble things out on paper and scan that, I'd sit down and do a nice version in Photoshop. Quote: The triangle gain you get from portals (or most anything else, really) is insignificant, and can be useful for helping light overdraw on faces without having to offset textures or add trims. What is dangerous about portals is the batch size splitting. You can really ramp up your draw calls if you portal too aggressively, but they can also go too high if you don't portal enough. It's a fun balance to find. Still need to learn and understand this. And - much like hint brushes - placement of portals seems to be an art form. Quote: Portals also automatically toggle off and on when placed inside func_doors (the portal face should be on the same plane as the origin). Handy! A detailed Q&A on how to get Visportals to work with Doors would be handy. Or is placement "inside" enough? Quote: Also, crossing Visportals is like crossing the streams ghostbusters. Don't ever do it unless it's time to save your map from a giant marauding marshmallow. Good to know Quote: Oh, and fading portals! I skimmed those but were beyond me, someone would have to write something up on those. I am not sure how interesting these are for MP maps though? Quote: Ambient light... Be careful with this; it still adds a light pass to everything. Basically that brings the lightcount to +1 for everything. Quote: Also, ambients sort of bake a highlight onto normals, so mirrored textures and flipped objects can look really ugly if you go too bright. You can sort of see this on MP characters in the MP maps. Great for illumination, but terrible for visuals if you're not careful. Aha... lighting will be tough... sigh. Quote: Clipping. For our maps we used player clip, but I'd recommend regular clip at this point. Community-made bots need an aas32 file, and player clip does not define AAS. Then I did understand the information correctly, player_clip does not create AAS data, but full clip does. Will add the info. Still have to find a custom bot though. Quote: Q4 has limited portal sky functionality ... Screams for another Q&A... hint Quote: Biggest performance console command, r_showbatchsize, is barely touched on. Toggling this on shows how efficiently triangles are being sent to the video card (which likes to eat triangles at about 500+ at a time). I've stopped using r_showtris entirely in favor of this; raw triangle count barely matters vs. draw calls/batching and light overdraw/shadows. Good to know. Quote: Managing draw calls is arguably the single most important aspect of render speed optimization. It's covered pretty well in our performance guide on iddevnet, but I'd recommend detailing it out so it's not overlooked by anyone who might find this first and not bother to follow the links. Will do that... Quote: Oh, and compile time. Visportals (the geometry splitting on portals, for example) and some lighting information (for shadow purposes) are calculated during compiles. For an MP -noaas or -aasonly32 compile it should still be pretty quick, but complex geometry and lighting can jump that up quick. Larger SP maps could take in the range of 15-30 minutes. But given how long these used to take previously, that's still not too shabby. If I understood what the "community bots" actually require, one could probably optimize the compile options to either completely skip AAS generation for all local tests, and only turn on a "full" compile for distribution. Quote: Great resource, though, let me know when you get it to a more permanent location and I'll toss it onto the iddevnet links list.
Thanx ... the FAQ will definitely stay in this thread, and I am also posting it over at Doom3World.org's Q4 LE forum. But at some point I'll do a niced up HTML version for my site (planetquake.com/aeons). The phpBB to HTML parser for this is already written (used it for my KotOR II FAQ). Thank you for the feedback, definitely appreciated. I am sure as soon as I actually start mapping, tons of new things will come up. |
Author: | KungFuSquirrel [ 05-04-2006 04:10 AM ] |
Post subject: | |
Make sure you're talking about "clip" and not "full_clip" - "full_clip" also blocks visibility and all weapons fire, which is not so good on a wide scale. I'll try write up some more detailed info for you tonight; it was getting late last night or I could have probably given you a few other examples. |
Author: | AEon [ 05-04-2006 04:16 AM ] |
Post subject: | |
Wonderful, much appreciated. I'll probably be quoting you all over the place, that way folks that "really" understand things will not have to live with my missinterpretations . |
Author: | AEon [ 05-06-2006 09:30 AM ] |
Post subject: | |
Finally Q4 arrived yesterday, and in 13 hours I played through the SP game... whee... Now for the MP part. Ironically I had actually been thinking of converting q3dm17... to my surprise that had already happened. A bit glitzy though IMO. But that still leaves q3dm7 ... might really be fun to use a new "design" defined by existing maps and use the q3dm7 layout. Maybe... Well in any case this means I can finally test the FAQ... |
Author: | AEon [ 05-20-2006 05:19 AM ] |
Post subject: | |
Note to self... Add a section about support for Oak Bots and on how to properly make them work, i.e. clip. http://www.quake3world.com/forum/viewtopic.php?t=20450 |
Author: | wviperw [ 05-27-2006 01:31 PM ] |
Post subject: | |
Quote: * Tips: Raven suggests ramp-clipping stairways, to allow for ramp-jumping.
The 1.2 patch fixed stairs so mappers should *no longer* clip stairs. If they want ramps then they should be making ramps. (this should be updated on iddevnet as well probably). |
Author: | AEon [ 05-27-2006 05:47 PM ] |
Post subject: | |
Hmmm... yeah read that as well. But the stairs in q4dm1 I was trying to ramp jump on did not let me do so. Or do folks actually *want* to "turn off" ramp jumping on stairs? Personally I'd want to be able to use stairs much the same way I would use ramps for ramp jumping. Are stairs some sort of "strategic" gameflow thing? I usually used stairs as decoration, clipping them off to be ramps (with player clip). |
Author: | wviperw [ 05-27-2006 07:44 PM ] |
Post subject: | |
Yes, there is a gameplay difference between stairs and ramps that matters. When strafing over "real" stairs the player maintains horizontal momentum whereas when strafing over "ramped" stairs the player loses horizontal momentum and gains vertical (popping the player up in the air due to the ramp-jump). This can be quite detrimental to the player's health if he gets popped into the air on a set of stairs that should *not* have done so, since it can ruin the player's speed and give his an opponent a potentially easy rail. |
Author: | AEon [ 05-28-2006 08:11 AM ] |
Post subject: | |
I noted - with my limited strafe jumping skills - that ramps in AEdm7 slow me down most of the time, badly. Whereas in Q4 I'd tend to ramp jump about. So presently AEdm7 seems to be more Q4 "friendly". |
Author: | AEon [ 06-23-2006 04:31 AM ] |
Post subject: | |
Just updated the FAQ to v3.2 in this thread. Also see: Æon's Quake 4 Mapping FAQ v3.2 - HTML changes since (internal) v0.97:
|
Author: | obsidian [ 11-13-2006 05:05 PM ] |
Post subject: | |
After much bashing my head against the table... Under "Launching Q4 and the Editor", With the patched versions of Q4, you also need to add set r_useSMP 0 along with disabling multisamples to get the editor to work. |
Author: | AEon [ 11-13-2006 11:14 PM ] |
Post subject: | |
I am surprised that set r_useSMP 0 is not set to zero by default. Or do you actually have a dual processor system? |
Author: | obsidian [ 11-14-2006 06:04 AM ] |
Post subject: | |
Hyperthreaded, so it set itself to 1. The editor spits out the same bunch of errors as the multisamples one. I did some head scratching for a while since I was positive that I disabled multisamples. |
Author: | Method [ 01-06-2007 12:55 AM ] |
Post subject: | |
Very nice work on formatting the information, AEon. Very easy on the eyes to read. -Method |
Author: | A1yssa [ 02-03-2007 05:32 AM ] |
Post subject: | |
I use to play online every day, so I use a high tweaked cfg...pasted in the autoexec.cfg. where can I find a cfg for my mapping time? |
Author: | wviperw [ 03-13-2007 05:29 PM ] |
Post subject: | |
For teleporters, you should use 'textures/common/trigshotclip' for the material rather than 'textures/common/trigmulti'. |
Author: | Bill_Brooks [ 03-22-2007 07:54 AM ] |
Post subject: | My Site FPS has moved to a new host. |
After 8 years of no trouble I just lost my host for my site. So I bought a .com and hosted it with godaddy. So in a few days all links to F.P.S will be broken. The old url http://fps.brainerd.net Should now be http://www.wemakemaps.com The site name will change to We make maps but you could leave it as FPS if you want. I haven't done any thing in Q3 for a long time now but I do still have many tutorials and the best collection of map models in one spot that I know of. |
Author: | addseo1115 [ 07-18-2015 02:08 AM ] |
Post subject: | Re: AEon's Quake 4 Mapping FAQ - v3.2 |
where can I find a cfg for my mapping time? จีคลับคาสิโนออนไลน์ |
Author: | AEon [ 07-18-2015 03:05 AM ] |
Post subject: | Re: AEon's Quake 4 Mapping FAQ - v3.2 |
Never got around to releasing that info IIRC... been such a long time ago. A lot never got done for that FAQ. |
Page 1 of 1 | All times are UTC - 8 hours |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |