63 lines
5 KiB
Text
63 lines
5 KiB
Text
There are multiple ways to embed a program into a browser. The 'web'/emscripten 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.
|
|
|
|
Hosting Quake:
|
|
To get fte running on a web page, you will need:
|
|
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:
|
|
http://triptohell.info/moodles/web/ftewebgl.html?+connect%20ws://example.com:27500
|
|
The browser port is set up to ignore most args when linked to from another site. This blocks other sites from screwing with any saved user configs.
|
|
|
|
Built-in http server:
|
|
The http server provided by sv_port_tcp will provide a page (either directly or with a redirect) to a version of the webgl client.
|
|
Thanks to allow_download_* cvars, only certain things may be downloaded.
|
|
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).
|
|
|
|
Additionally, there are also some files generated by the server.
|
|
index.html (and no resource) - attempts to provide a link to the webgl version of fte.
|
|
all other files match what you would be able to download over udp.
|
|
|
|
|
|
|
|
Manifest files:
|
|
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...
|
|
|