| Latest revision |
Your text |
| Line 3: |
Line 3: |
| | However, there are some nice tricks you can use to make it easier/faster/simpler. | | However, there are some nice tricks you can use to make it easier/faster/simpler. |
| | | | |
| − | This is a somewhat random collection of FTEQW specific features and probably needs a clean-up at some point.
| + | === Built in compiler === |
| − | | |
| − | == QuakeC == | |
| − | FTEQW has very advanced client-side QuakeC support and also comes with it's own set of qc_extensions for various features.
| |
| − | * Here is Spike's famous [[CSQC guide for idiots]]
| |
| − | * [https://github.com/shpuld/sui-qc SUI-QC] Shpuld's HUD/UI library.
| |
| − | ** It also serves as a template QuakeC codebase that can be used to make total conversions/games.
| |
| − | ** It's an improved version of CleanQC4FTE
| |
| − | * [https://github.com/shpuld/CleanQC4FTE CleanQC4FTE] is a QuakeC codebase for total conversion mods/games utilizing FTEQW.
| |
| − | ** It's been designed from ground-up to use CSQC as well. Does not come with assets.
| |
| − | ** It's highly recommended to use SUI-QC instead
| |
| − | * For help with QuakeC please visit the [https://forums.insideqc.com/ InsideQC forums]
| |
| − | | |
| − | | |
| − | == Built in compiler == | |
| | FTEQW generally contains a built in version of FTEQCC. You can access it with the 'compile' console command. | | FTEQW generally contains a built in version of FTEQCC. You can access it with the 'compile' console command. |
| | Generally, you would make a mod 'egmod' as such: | | Generally, you would make a mod 'egmod' as such: |
| Line 33: |
Line 19: |
| | Additionally, the 'applycompile' basically does a quick savegame, effectively applying a newly compiled mod without restarting a map. This is useful if you just want to test a single repeatable function without booting players or anything - this won't automagically change any fields! | | Additionally, the 'applycompile' basically does a quick savegame, effectively applying a newly compiled mod without restarting a map. This is useful if you just want to test a single repeatable function without booting players or anything - this won't automagically change any fields! |
| | | | |
| − | == FTEQCC == | + | === Multiplayer testing === |
| − | FTEQW comes with it's own advanced QuakeC compiler called [[FTEQCC]]. Under Windows it even has a graphical frontend called FTEQCCGui. It is also integrated into FTEQW by default.
| + | Unlike other QuakeWorld engines, FTE permits multiple instances of itself. |
| | + | (Note that other quakeworld engines will refuse to start up if FTE is already running, but FTE will start up if they are running, so if you want to test ezquake+FTE compatibility, start ezquake first). |
| | | | |
| − | [http://triptohell.info/moodles/fteqcc/fteextensions.qc fteextensions.qc] includes various keywords that only FTEQCC understands, and only FTEQCC supports FTE's extended instruction set, so if you want ints/pointers/massive mods/etc, you need FTEQCC+FTEQW.
| + | FTE also supports splitscreen! This can simplify testing multiplayer when you can't be bothered switching between two clients. |
| | + | Mostly this should be documented elsewhere, but here's the basics. |
| | + | cl_splitscreen can be set to 0, 1, 2, 3. This cvar says how many additional clients should be used. If you're running a listen server, this is the only cvar you 'need' to set. |
| | | | |
| − | FTEQCCGui combined with FTEQW allows for breakpoints and single-stepping through QC code etc, this means you can debug more easily.
| + | There are a few other cvars, but for testing you can set up one half of your keyboard for the second player. Or you can make some bind to change the value of the 'cl_forcesplitclient' cvar, to force input to a different splitclient. |
| | | | |
| − | == Debugging == | + | === Debugging === |
| | FTE has a 'breakpoint' command. | | FTE has a 'breakpoint' command. |
| | This command accepts either a function name, in which case it uses the first statement of that function, or a file+lineno pair. | | This command accepts either a function name, in which case it uses the first statement of that function, or a file+lineno pair. |
| Line 63: |
Line 52: |
| | To recap: developer 1+.lno file = step-by-step debugging/code tracing. | | To recap: developer 1+.lno file = step-by-step debugging/code tracing. |
| | | | |
| − | == Profiling == | + | === Coredumps === |
| − | * "show_fps 2" will draw a frametime graph
| |
| − | * "profile_ssqc/csqc" will show qc functions are taking cpu time
| |
| − | * "r_speeds 2" is used for figuring out which engine subsystems are taking the most time
| |
| − | | |
| − | == Coredumps == | |
| | If there's a crash which FTE believes to be caused by QC code, FTE will generate a coredump in the current gamedir (generally this is in your home directory somewhere - note the path command to find out where). | | If there's a crash which FTE believes to be caused by QC code, FTE will generate a coredump in the current gamedir (generally this is in your home directory somewhere - note the path command to find out where). |
| | | | |
| Line 74: |
Line 58: |
| | | | |
| | You can also force a core dump with the coredump_ssqc command. | | You can also force a core dump with the coredump_ssqc command. |
| − |
| |
| − | == Multiplayer testing ==
| |
| − | Unlike other QuakeWorld engines, FTE permits multiple instances of itself.
| |
| − | (Note that other quakeworld engines will refuse to start up if FTE is already running, but FTE will start up if they are running, so if you want to test ezquake+FTE compatibility, start ezquake first).
| |
| − |
| |
| − | FTE also supports splitscreen! This can simplify testing multiplayer when you can't be bothered switching between two clients.
| |
| − | Mostly this should be documented elsewhere, but here's the basics.
| |
| − | cl_splitscreen can be set to 0, 1, 2, 3. This cvar says how many additional clients should be used. If you're running a listen server, this is the only cvar you 'need' to set.
| |
| − |
| |
| − | There are a few other cvars, but for testing you can set up one half of your keyboard for the second player. Or you can make some bind to change the value of the 'cl_forcesplitclient' cvar, to force input to a different splitclient.
| |
| | | | |
| | == Manifest files == | | == Manifest files == |
| Line 89: |
Line 63: |
| | | | |
| | Manifest files are useful for standalone games that need to distance themselves from other games using the same engine. They are also useful for auto-updating mods or for mod compilations where mods should not be downloaded up-front. | | Manifest files are useful for standalone games that need to distance themselves from other games using the same engine. They are also useful for auto-updating mods or for mod compilations where mods should not be downloaded up-front. |
| − | | + | == Scriptable menus== |
| − | == Scriptable menus == | |
| | [[Scriptable menus in FTEQW | Scriptable menus]] have a few uses. | | [[Scriptable menus in FTEQW | Scriptable menus]] have a few uses. |
| | # Large teamplay mods might wish to provide key bindings and customisable settings, like abreviated player name, possibly sensitivity, etc. | | # Large teamplay mods might wish to provide key bindings and customisable settings, like abreviated player name, possibly sensitivity, etc. |
| Line 96: |
Line 69: |
| | # Modders might wish to use them to provide easy configuration options to the user. Key bindings, for instance. Mods could also involve server admin componants via the use of KRIMZON_SV_PARSECLIENTCOMMAND (or equivelents). | | # Modders might wish to use them to provide easy configuration options to the user. Key bindings, for instance. Mods could also involve server admin componants via the use of KRIMZON_SV_PARSECLIENTCOMMAND (or equivelents). |
| | # To show off your l33tness. | | # To show off your l33tness. |
| − | | + | == RT lights== |
| − | == RT lights == | |
| | [[RTlights in FTEQW | Real-time lights]] allow for nice dynamic light effect in mods. | | [[RTlights in FTEQW | Real-time lights]] allow for nice dynamic light effect in mods. |
| | * ''r_shadow_realtime_world'': if 1, enables static realtime lighting | | * ''r_shadow_realtime_world'': if 1, enables static realtime lighting |
| Line 113: |
Line 85: |
| | FTEQW comes with a very extensive particle system. See the [[FTEQW Particles System | full documentation here]]. | | FTEQW comes with a very extensive particle system. See the [[FTEQW Particles System | full documentation here]]. |
| | | | |
| − | == Terrain & build in terrain editor == | + | == FTEQCC == |
| − | FTEQW supports large scale terrain maps that can be edited with the in-game terrain editor that comes with the CSAddon. See a small tutorial [https://spawnhost.wordpress.com/2012/08/14/on-the-rocks/ here] (''should be probably mirrored here at some point''). | + | FTEQW comes with it's own advanced QuakeC compiler called [[FTEQCC]]. Under Windows it even has a graphical frontend called FTEQCCGui. It is also integrated into FTEQWby default. |
| | | | |
| − | Terrain is added in worldspawn by specifying the section size (for example 1024) and how many sections you want in the X and Y directions (mins/maxs), for example 16 x 16 for 16000 x 16000 quake units.
| + | [[fteextensions.qc]] includes various keywords that only FTEQCC understands, and only FTEQCC supports FTE's extended instruction set, so if you want ints/pointers/massive mods/etc, you need FTEQCC+FTEQW. |
| | | | |
| − | A terrain can have 4 different textures which are also properly blended. Painting is much like using an airbrush. Using the brush you can also lower and raise the terrain with different brush sizes. Holes in the terrain is also supported.
| + | FTEQCCGui combined with FTEQW allows for breakpoints and single-stepping through QC code etc, this means you can debug more easily. |
| | | | |
| − | The terrain is somewhat separate from the BSP map. You can just delete the terrain files and start over. You don’t even need to recompile the map for this.
| + | == QuakeC == |
| − | | + | FTEQW has very advanced client-side QuakeC support and also comes with it's own set of qc_extensions for various features. |
| − | === Ocean rendering for terrain maps === | + | * Here is Spike's famous [[CSQC guide for idiots]] |
| − | You can add some worldspawn fields to configure the default section
| |
| − | | |
| − | _defaultgroundtexture "city4_2"
| |
| − | _defaultwatertexture "*water2"
| |
| − | _defaultgroundheight -1024
| |
| − | _defaultwaterheight 0 //hurrah, sea level.
| |
| − | | |
| − | Then the default tile is underwater, giving you a nice big ocean type thing.
| |
| − | | |
| − | If you want waves and foam and other extra stuff, then you'll need to modify the glsl, which gets quite complicated (foam needs depth info, which you should be able to get with refraction fbos, but its a bit more expensive).
| |
| − | | |
| − | == FBSP map support ==
| |
| − | FBSP is an extended map format originally developed for the open source game Warsow (using the Quake2 based qfusion engine) with allows better looking pre-rendered lights by adding lightstyles + higher resolution light-maps to q3bsp.
| |
| − | | |
| − | When using q3map2 to compile the bsp map it can be activated with the switch:
| |
| − | -game qfusion
| |
| − | | |
| − | === Light styles in FBSP ===
| |
| − | Light-styles are a set of different styles on how light entities can behave, allowing them to pulse, flick, etc. Setting up a light with a light-style is as simple as creating a new field inside any light entity called "style", and feed with a number between 1 and 256 (0 is standard lighting).
| |
| − | | |
| − | The style has to be defined within the QC code, using the `lightstyle` builtin:
| |
| − | void(float lightstyle, string stylestring, optional vector rgb) lightstyle = #35; /*
| |
| − | Specifies an auto-animating string that specifies the light intensity for entities using that lightstyle.
| |
| − | a is off, z is fully lit. Should be lower case only.
| |
| − | rgb will recolour all lights using that lightstyle. */
| |
| − | (snippet taken from fteextensions.qc)
| |
| − | | |
| − | == Server side anti-lag ==
| |
| − | FTE is able to perform serverside lag compensation.
| |
| − | | |
| − | It is primarily controlled via the ''sv_antilag'' cvar, which shall be present in the serverinfo.
| |
| − | * If the cvar is set to 0, then no anti-lag will be performed, even if the mod attempts it.
| |
| − | * If the cvar is 1, then the MOVE_LAGGED and FL_LAGGEDMOVE bit flags are valid.
| |
| − | * If the cvar is 2, then the server will act as 1, but ALL tracelines will have laggedmove set (but not traceboxes), and ALL movetype_flymissile or movetype_bounce entities will act as if they have FL_LAGGEDMOVE set. This value is to force anti-lag within a mod, without any mod changes. Using this value may potentially cause a mod to malfunction, as it affects all tracelines - this does depend upon the mod. Thus it is better/safer if mods are adapted to use the new flags instead of it being forced.
| |
| − | | |
| − | A separate but related feature found in FTE servers is the sv_minping cvar, which will enforce a minimum specific ping, however this doesn't always ensure a fair ping.
| |
| − | | |
| − | //antilag.qc:
| |
| − | //new cvar, sv_antilag. values 0, 1, 2
| |
| − | float FL_LAGGEDMOVE = 65536; /*if set in self.flags, the entity will collide against a lagged copy of the world. The lagged copy depends upon the player, which is either this entity, or the entity's owner, whichever is the first player.*/
| |
| − | float MOVE_LAGGED = 64; /*if this bit is set within the 'nomonsters' argument of traceline or tracebox, the trace will collide against the lagged world. Uses the ent parameter as the lagged player. If its not a player then the owner is used instead.*/
| |
| − | | |
| − | == A-Star support ==
| |
| − | | |
| − | FTE has builtin A* support through .way files.
| |
| − | The .way file has to be placed in the data directory in order for the engine to see them.
| |
| − | The first line of the file has to be the number of nodes within the file.
| |
| − | | |
| − | The node syntax follows the following format:
| |
| − | pos_x pos_y _pos_z radius num_of_links
| |
| − | linked_node_1 path_cost path_flags
| |
| − | linked_node_2 path_cost path_flags
| |
| − | | |
| − | In order to use it in QC, route_calculate builtin is used (snippet taken from fteextensions.qc):
| |
| − | typedef struct
| |
| − | {
| |
| − | vector dest;
| |
| − | int linkflags;
| |
| − | float radius;
| |
| − | } nodeslist_t;
| |
| − |
| |
| − | void(entity ent, vector dest, int denylinkflags, void(entity ent, vector dest, int numnodes, nodeslist_t *nodelist) callback) route_calculate = #0:route_calculate; /*
| |
| − | Begin calculating a route. The callback function will be called once the route has finished
| |
| − | being calculated. The route must be memfreed once it is no longer needed. The route must be
| |
| − | followed in reverse order (ie: the first node that must be reached is at index numnodes-1).
| |
| − | If no route is available then the callback will be called with no nodes. */
| |
| − | | |
| − | == Cubemaps ==
| |
| − | FTEQW supports cubemaps.
| |
| − | By placing entities named '''env_cubemap''' throughout the map, you're giving the engine calculation points. After (re)compiling the map, run the '''mod_findcubemaps''' command in-game.
| |
| − | Then, make a q3 shader that looks like:
| |
| − | yourmaterialname
| |
| − | {
| |
| − | program defaultwall
| |
| − | diffusemap YourTexture.tga
| |
| − | normalmap LumpyBumpy.tga
| |
| − | reflectmask AGreyScaleTextureThatsWhiteForTheReflectiveParts.tga
| |
| − | specularmap YourSpecularReflectionInfoBecauseWhoDoesntWantShinyStuffEverywhere.tga
| |
| − | //fullbrightmap EwwGlowyBitsIsJustBoring.tga
| |
| − | }
| |
| − | (snippet written by Spoike)
| |
