unfortunately just some basic informations I found seeking how to load a world with: -cache via http.
and I would like to find out more about this feature for faster loading bigger map-file's.
I hope someone can point me to the right direction how to make this work ....
well I started playing around but unfortunately couldn't make it work properly!
what I tried so far:
using bzfs to create a binary from a map.bzw file (bzfs -world map.bzw -cacheout map.out)
copying this binary to my http-server and
replacing -world map.bzw
with -cache http://myserver/path/to/map.out in the config.conf file
starting the server and checking to see that it loads just a generic map.
I tried many possibilities but nothing worked so far!
1- what did I miss?
2- what is stored in the binary?
(server configs? files and plugins to load? world: i.e. "size 400 / freeCtfSpawns / noWalls"? world-options: i.e. "-c, -r, -set _gravity -20"? )
3- what information goes into the config.conf file to start a server with a cache-binary?
4- what perms does the map.out and its folder need on the http-server?
THX for helping!
cacheout, cache, world and http?
- Cobra_Fast
- Dev Monkey
- Posts: 322
- Joined: Sat Oct 07, 2006 11:51 am
- Location: Germany
- Contact:
Re: cacheout, cache, world and http?
-world must be in there, so the server knows what map you are playing with as the server doesnt read the http-file.zaphod wrote:replacing -world map.bzw
with -cache http://myserver/path/to/map.out in the config.conf file
The cacheout file contains all the data you've written to the map in a ready-to-use format for the client.zaphod wrote:2- what is stored in the binary?
I strongly recommend generating the cacheout with the bzfs on the server where the map will run, if you don't there is a good chance that the file generated on your desktop has a different checksum than the file the actual server would be using.
It needs to be readable by the server (644, u+rw-x;ao+r-wx).zaphod wrote:4- what perms does the map.out and its folder need on the http-server?
Re: cacheout, cache, world and http?
The permissions don't even need to include write permissions. Set the user and group to whatever your web server runs as (probably www-data) using chown and chgrp. Basically, if you can hit the link in your browser and have it start downloading, it will be enough for the client to pull down as well.
Also note that if your map uses DrawInfo that cache files do not work.
Also note that if your map uses DrawInfo that cache files do not work.
Re: cacheout, cache, world and http?
so basically bzfs uses the map.bzw and the clients the binary map.outCobra_Fast wrote:-world must be in there, so the server knows what map you are playing with as the server doesnt read the http-file.
once loaded; does bzflag store then the binary in its cache or does it reload it on each connection?
in general ::: what would you recommend for loading bigger maps?:
1 -cache http://myserver/path/to/map.out
or
2 -world http://myserver/path/to/map.bzw
and THX for your solid inputs!
- Cobra_Fast
- Dev Monkey
- Posts: 322
- Joined: Sat Oct 07, 2006 11:51 am
- Location: Germany
- Contact:
Re: cacheout, cache, world and http?
The cache file is cached by the client.
I woudl definitely use the cacheout as it's a lot smaller than the bzw.
I woudl definitely use the cacheout as it's a lot smaller than the bzw.
Re: cacheout, cache, world and http?
The raw BZW is never sent to the client (to the best of my knowledge). The only BZW parser is in the server. The client gets a binary file whether or not you use -cacheout/-cache. It's just that bzfs does not send as fast as a web server since it isn't designed for transferring files. It is limited to sending 1024 bytes per cycle, and on an empty server, the cycles can be spaced out a bit since the server sleeps to reduce CPU usage when it doesn't have any work to do.
Also, if the cache file on the web server is missing or does not match what the server says it should be getting (based on an MD5 hash check) it will download it from bzfs instead. This is why you need to load the -world too. First so that it can calculate the MD5 hash, second so it can provide a fallback for the clients. Plus it needs to know the layout of the map so it can handle spawns, and there might be variables in the map, etc.
So, in summary, you always need to use -world (unless you are using a random map, in which case, -cache isn't possible/necessary). And then you can also -cacheout the cache file once and then -cache for when you run the server.
Also, if the cache file on the web server is missing or does not match what the server says it should be getting (based on an MD5 hash check) it will download it from bzfs instead. This is why you need to load the -world too. First so that it can calculate the MD5 hash, second so it can provide a fallback for the clients. Plus it needs to know the layout of the map so it can handle spawns, and there might be variables in the map, etc.
So, in summary, you always need to use -world (unless you are using a random map, in which case, -cache isn't possible/necessary). And then you can also -cacheout the cache file once and then -cache for when you run the server.
Re: cacheout, cache, world and http?
Just one last addition to this topic...
Why doesn't drawinfo cache? Is there any logic behind it? Bug maybe?
Why doesn't drawinfo cache? Is there any logic behind it? Bug maybe?
Re: cacheout, cache, world and http?
THANKS for all your input and help guys!
works and the map is much faster loading! (plus I learned another lesson!)
.
works and the map is much faster loading! (plus I learned another lesson!)
.
Re: cacheout, cache, world and http?
Yeah, a bug.mrapple wrote:Just one last addition to this topic...
Why doesn't drawinfo cache? Is there any logic behind it? Bug maybe?