There are multiple ways to embed a program into a browser. The 'web'/emscripten port, the nacl port, the npapi port, and the activex port.
Quick start with browser-servers:
(this uses webrtc, which should give low latency but is incompatible with native servers at this time.)
On the server:
sv_port_rtc /magic //this assumes the manifest provides a default broker. Then start a game (remember to set deathmatch or coop first).
On the client:
connect /magic //connects to the default broker and attempts to start a webrtc connection with whichever browser-server that registered itself with that name.
Quick start with dedicated servers:
(this uses websocket connections, which will have terrible latency on any network with notable packetloss, but can work on any correctly configured native fte server.)
On your server:
sv_port_tcp 27500 //listens for tcp connections, including websocket clients
In the browser client:
connect ws://serverip:27500 // ws:// is assumed if ommitted. it is best to always include the port.
Alternatively, if configured properly, just load http://serverip:27500 in your browser and be greated with the game!
Cvars:
sv_port_tcp - This cvar controls which tcp port non-browser builds of fte should listen on.
This provides qizmo-tcp compat (including the tcpconnect in native clients).
It also provides websocket access for browser clients to connect to regular servers. It should allow quake connections from any site (as is supported for udp).
Additionally, you can use it to serve files, subject to allow_download_* cvars, the same as for vanilla quakeworld clients etc.
Further more, it also provides webrtc broker support. Browsers can use rtc://broker:port/NAME to connect games with potential clients (without them appearing on the server itself).
Brokering should be fairly low traffic, but will result in an extra tcp connection for each rtc client or server active at the time.
sv_port_rtc - This says the broker+resource used to register a webrtc server. Clients should connect using the same string, and by doing so will be able to relay webrtc connection info to the target browser-server.
cfg_save - This command saves your config to your browser's local storage. In combination with seta, you can save most settings this way.
Beware that browsers might still wipe it all eventually.
ftewebgl.html - An html file that embeds the javascript. You can probably modify fte's default if you want to integrate it better with your site, it doesn't change much.
ftewebgl.js - This is the meat of the engine. All in a single file. pre-gzip it if you can, to keep sizes down.
ftewebgl.js.mem - This is just the 'data', and annoyingly the 'bss' section too when emscripten is being buggy. Its version MUST match the js file.
ftewebgl.html.fmf - This is the manifest file that the browser port depends upon to figure out where all of its data files should come from. It will need to be modified for each mod.
Ideally, servers will share fmf files between them, one per mod. This should avoid downloading the same packages from multiple different servers.
*.pak / *.pk3 - These files are pulled in by the fmf. fte's web port doesn't include zlib, so pk3s should not use compression for individual files. Instead gzip them for solid archives with the browser doing all the decompression.
Arguments:
You can pass arguments by eg browsing to the following url:
Unlike over game connections, the server will transparently also provide http content compression only where a .gz file has also been provided (and is more recent and in the same gamedir).
These are FTE's way of reconfiguring FTE for standalone mods. They offer basic rebranding features as well as content updates.
They contain a number of attributes, and frankly its easier to start with an example. Check http://triptohell.info/moodles/web/ for a few.
Note that the content you pull in will still be subject to various copyrights. If nquake is anything to go by, you can get away with pak0, but don't bother serving up the full registered version of quake.
Yes, what you can legally run is limited.
Custom maps do not need to be named in manifests as they will just be downloaded from the game server automatically anyway. They will be redownloaded if the page is refreshed, yes, but this can also be good for people still working on their maps...
The rest of this file is outdated.
Embedding using npapi(no longer supported by any major browser) or ActiveX (deprecated and not supported in Edge):
Insert your 'no-plugin' text here. Be sure to include links to download a copy of one.
</object>
</object>
Two objects. Yes, I know. Evil. But yeah. Firefox will ignore any objects with a classid, and internet exploder won't have a clue what it is if it doesn't have a classid. bah.
Yes, you need to specify the params twice.
You probably want to name them too.
Any supported param is also supported as a field usable from javascript. There's no distinction between them.
Supported fields/params.
bool running: true if active. false if its not running. setting this field will start up quake or shut it down.
string startserver: the server that will be used when the engine starts up.
string server: the current server. if not running, maps to startserver instead. (server=foo; running = true; will result in the plugin going to that server in all cases)
string playername: the name cvar. requires running.
string skin: the string cvar. requires running.
string team: the team cvar. requires running.
string topcolor: the topcolor cvar. requires running
string bottomcolor: the topcolor cvar. requires running
string password: the password cvar. requires running
not supported. string spectator: the spectator cvar. requires running
string mapsrc: the cl_download_mapsrc cvar. Should be empty or a url like: http://bigfoot.morphos-team.net/misc/quakemaps/
if set, its a url that contains a load of bsp files that can be downloaded via http instead of grabbing them off the server.
string fullscreen: vid_fullscreen.
string datadownload: specifies a url to obtain mod data from.
Can contain multiple space-separated entries.
Each entry must have a pak or pk3 file name, followed by a colon, followed by a url that contains a zip file.
Each file should be moddir/pakname.pak for instance.
string game: specifies the actual game+mod to use.
The first entry can be:
quake/q1/qw: quake1
quake2/q2: quake2
quake3/q3: quake3
halflife/hl: half-life (not really supported, but you may have a TC mod that just wants halflife maps)
hexen2/h2: hexen2
nexuiz: nexuiz... moving target. sorry.
Any of the above will tell the plugin to hunt for the given game on the user's hard drive, and to then use that as a base dir, with the relevent game's basedir(s) loaded.
Any other option will be taken as only that base gamedir in an obscure place in the user's profile.
Additional gamedirs can be named, separated by spaces. These are additional mod dirs which will always be loaded despite the user's/server's choice of gamedir.
string curver: read only. Returns the current version of the plugin.
string availver: Tells the plugin what the most recent version of the plugin is. Basically it will cause the plugin to show a warning whenever its not running.
string splash: This is a url to a jpeg/png image to be shown when the plugin is not active.
string stream: when set, (including via stream="foo";running=true;) this will direct the plugin to begin playing a qtv stream.
string map: when set and running, the plugin will change map and use its own server. overrides startserver when not running.
stuff that may be supported at some point
connType: describes how the plugin should connect. join/qtv/observe/map
