From Quake Wiki
Making mods in FTE can be done the same way you make mods for any other Quake engine. 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.
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
- 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.
Built in compiler
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:
Quake/ Quake/fteglqw.exe Quake/egmod/ Quake/egmod/src/progs.src Quake/egmod/src/everythingelse.qc Quake/egmod/progs.dat (or qwprogs.dat)
If your progs.src contains an output of '../progs.dat' (at least a matching path) then the output will be directly runnable.
The 'compile' command will thus compile progs.src into progs.dat. You can also 'compile csprogs.src' if you want to compile, eg, a csqc mod.
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!
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.
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.
FTEQCCGui combined with FTEQW allows for breakpoints and single-stepping through QC code etc, this means you can debug more easily.
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. When the breakpoint is hit, you'll get either just a print saying it was hit (once) or it'll bring up the editor...
Editor? Yes, editor. In order to debug, set developer 1, and make sure you have an .lno file matching your progs (this file is generated by any form of fteqcc).
Note: A few builtins in FTE detect error conditions and force tracing on, hopefully along with a message saying why.
You can use the traceon builtin to force tracing on as a qc-coded breakpoint.
- f11 will single-step (step-into).
- f9 will toggle a breakpoint
- f5 will resume execution.
- f3 will bring up an inspection line. Type QC values to inspect stuff (or 'foo = 5' to assign to foo - doesn't support calls).
- escape will close the editor and resume execution until the next breakpoint.
There is limited console access. Please be very careful about the commands you exec in this state.
Do note that while debugging, there is no network activity. People will time out if you debug for too long in a single frame.
Dedicated servers do not support a built in editor. If you set developer and hit a breakpoint, a dedicated server will simply print out the source code of each line which is executed, in a cheesy trace fashion.
To recap: developer 1+.lno file = step-by-step debugging/code tracing.
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).
These coredumps will contain information on locals within the functions that are still on the QC stack.
You can also force a core dump with the coredump_ssqc command.
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 are small files that describe various attributes of the game, primarily branding and filesystem configuration for mods or standalone games.
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 have a few uses.
- Large teamplay mods might wish to provide key bindings and customisable settings, like abreviated player name, possibly sensitivity, etc.
- Adding new menus for stuff that the FTE team might have neglected to add to the menus for one reason or annother.
- 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.
Real-time lights allow for nice dynamic light effect in mods.
- r_shadow_realtime_world: if 1, enables static realtime lighting
- Also see How to edit real-time lights in FTEQW?
Support of skeletal meshs
Skeletal mesh formats are very useful for advanced animation features and physics engines. Examples of supported features:
- Animation blending
- Mouse driven aiming
- Physics driven appendixes (for example a "pony tail")
Fully editable particles
FTEQW comes with a very extensive particle system. See the full documentation here.
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:
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 11 (0 is standard lighting).
These are the actual effect names for them:
- FLICKER (first variety)
- SLOW STRONG PULSE
- CANDLE (first variety)
- FAST STROBE
- GENTLE PULSE 1
- FLICKER (second variety)
- CANDLE (second variety)
- CANDLE (third variety)
- SLOW STROBE (fourth variety)
- FLUORESCENT FLICKER
- SLOW PULSE NOT FADE TO BLACK
Note: This comes from the qfusion documentation, not quite sure if implemented the exact same way in FTEQW.
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.*/