OBJECTIVE:
To A: be able to see (above water) entities when you’re underwater, and B: be able to see underwater entities when you’re above water.
- Make maps/newfolder
- copy foo.bsp there
- download bsp2prt.zip and vis.zip from:
https://www.quake-info-pool.net/vispatch/create.htm
and put them in your /maps folder
4. at cmd: “bsp2prt foo.bsp”
then
5. “vis.exe -show -level 4 foo.prt”
(You can also use batch files (available at address above) to do ALL bsps in the directory in one go)
6. copy the new/updated foo.bsp to the server. The server will use this to determine who can see what.
Note: Clients who already have (the old) foo.bsp will NOT be forced to download the new version.
============
<Spoike> vispatch doesn’t create any info, it just rewrites bsps
<Spoike> swapping out a specific lump or two for external data
<Spoike> I believe it can do the reverse too, but you still need a vised bsp in order to create a vispatch file. and if you had such a bsp then you wouldn’t need the vispaqtch program.
<eukara[h]> he wants to patch old maps
<eukara[h]> he has no sources for
<Spoike> yeah, I know.
<eukara[h]> what we do for transparent water 🙁
<Spoike> I’m just (badly) saying that vispatch is basically useless
<OneManClan> oh
<Spoike> omc, what you need is bsp2prt
<Spoike> and then run your map through vis
<OneManClan> ah
<eukara[h]> I’m surprised you don’t have a mod_makevispatch or something
<Spoike> that would require having a vis tool too
<OneManClan> Spoike: i have a memory of there beign some ‘setting’, ie weve done this before
<OneManClan> some (fte client) setting ??
<Spoike> and as tempting as it is to include a qbsp into the engine too, the fact of the matter is that someone else (read: ericw) can maintain that sort of thing better than I could
<OneManClan> oe was it a server setting
<Spoike> (though fte does have a light tool…)
<Spoike> OneManClan: sv_nopvs 1
<Spoike> enjoy the wallhacks.
<OneManClan> hmm in my server cfg:
<OneManClan> watervis 1 // players can see through water, 0 =off
<OneManClan> nmmm.. so its ‘1’
<OneManClan> hmm.. not sure how old this is or wherher relevant:
<OneManClan> / PULSECZARS SUGGESTIONS
<OneManClan> / Maps flagged as watervised should turn watervis on automaticaly
<OneManClan> localinfo autoset_watervis 1
<OneManClan> YESSSS sv_nopvs 1!!
<eukara[h]> i’m tweeting that the next AGR allows wallhacks right nao!!!
<OneManClan> wall hacks eh
<OneManClan> ‘wall hacks’ iiuc is a ‘hacked client thing’?
<OneManClan> or is it the bsps that cheaters hack?
<eukara[h]> Attackers Go Red? More like Attackers Get WALLHAX!
<Spoike> r_wireframe 1
<Spoike> (requires sv_cheats, or singleplayer)
<eukara[h]> people can have modified clients that are always wireframe, etc
<Spoike> try that setting with and without sv_nopvs, and you should see what I mean by wallhacks.
<Spoike> yeah, its not hard to hack up a client for it
<eukara[h]> or in the case of FTE, just some custom glsl 😛
<Spoike> I even made a wallhacked ezquake-sw, without even modifying the exe. just for the luls. naturally it got past the obscurity module.
<eukara[h]> lol
<eukara[h]> i forgot that was a thing
<eukara[h]> how did that work again?
<Spoike> someone sends a command which causes all the other clients to get blocked due to the server’s chat-floodprot feature
<eukara[h]> LOL
<Spoike> but yeah, the obscurity module basically just hashes some gamedata with some private string that it gets from somewhere, and other clients can then do the same to check if they get the same result. and if the exe is odified then the module uses the wrong hashes.
<Spoike> and yeah, there’s lots of ways around that
<OneManClan> hmm.. ok so iiuc setting “sv_nopvs 1” on the server achieves ‘see entities through water’
<eukara[h]> perfect. ship it.
<OneManClan> however it means that hacked clients um ‘work’
<OneManClan> or to put it another way
<OneManClan> “sv_nopvs 0” stops(?) people using hacked clients
<OneManClan> ie the ‘seeing through walls’ aspect
<eukara[h]> that’s one feature PVS’ have, yes
<OneManClan> ok so setting “sv_nopvs 1” is … ‘foolhardy’?
<Spoike> pvs is quite loose. you can see maybe one room away anyway. sv_nopvs makes the entire map potentially visible to a wallhacked client.
<eukara[h]> 1) bye bye performance optimisations for the level
<eukara[h]> 2) everything is networked on the map, because it’s always visible
<Spoike> which also means more network traffic, etc
<eukara[h]> basically everything = worse
<OneManClan> ok so ‘dont do it’
<eukara[h]> spike and eukara inc. condemn the act of disabling pvs/vis
<OneManClan> understood
<Spoike> sv_cullplayers_trace can help, making it more tight than before. possibly too tight, but only for players. sv_cullentities_trace 1 for everything.
<Spoike> of course, no pvs = no trivial rejection = higher cpu usage
<OneManClan> everythign is networked whether its in a clients PVS or not
<OneManClan> https://www.quake-info-pool.net/vispatch/create.htm
<OneManClan> nice step by step ^
* eukara[h] backflips into lava
<Spoike> oh look… bsp2prt…
<eukara[h]> Spoike: how about running a trace from every player to the water volumes? toggle sv_nopvs whenever they’re near water! great fix and will reduce wallhacking capabilities by 23%!
<Spoike> effort
<Spoike> easier to just blindly allow them through when their contents value changes.
<Spoike> relative to the viewer, that is
<eukara[h]> I’m trying to come up with the worst, most half assed attempts.
<Spoike> would also allow spectators outside of the map to see everything inside
<eukara[h]> lol
<eukara[h]> ask people if they’re planning on cheating upon spawning, kick if they say yes.
<Shpuld> but also add random factor to it in case they lie
<eukara[h]> exactly
<eukara[h]> use statistics
<eukara[h]> in the future all QW matches will be monitored by some neural network detecting wallhaxx0rs
<Spoike> did you hear of bigfoot’s axe-swings hack?
<eukara[h]> no?
<eukara[h]> sounds scary
<Spoike> swing your axe during prewar just the right number of times, and you can get certain versions of ktx to spawn you and everyone else in the spawn spots of your choosing,
<eukara[h]> lol
<OneManClan> (yea i googled “bsp2prt” to find that page)
<OneManClan> ok, bsp2prt, then vis.bat worked…
<OneManClan> not sure what vispatch.exe does
<OneManClan> “This step will create a new file called EXAMPLE.VIS. This file contains the DATA that others can use to patch their maps using the VISPatch utility that we have been using all along.”
<OneManClan> ??
<Shpuld> replaces the vis information in a bsp file
<Spoike> vispatch extracts pvs data from a .bsp file, and also injects pvs data into a compatible bsp.
<Spoike> strictly speaking, you don’t need the inject part as fte can directly load the .vis files itself
<Spoike> and you have the watervised bsp already anyway, so, urm… mneh?
<OneManClan> what does it mean by “others”?
<OneManClan> ah, so just put the .vis files into the /map folder
<OneManClan> and .. do clients can use the same bsp?
<eukara[h]> distributing the original id1 whole .bsp files = illegal, so people distributed .vis files over the net that you had to manually apply to patch your quake install
<eukara[h]> etc.
<eukara[h]> saves time running vis on the maps
<OneManClan> ahhh
<OneManClan> in my case players already have the original maps
<OneManClan> ie non id1 ones
<OneManClan> so.. if I put the .vis files into the /map folder..
<eukara[h]> FTE loads them
<OneManClan> .. FTE downkloads it
<OneManClan> ahh nice
<eukara[h]> the server controls the pvs crap, so if the server is patched then any client connecting to it is
<OneManClan> ok i uploaded 2farms.prt to the AGR server /maps folder…
<OneManClan> connected , but FTE didnt download the prt
<eukara[h]> .vis
<eukara[h]> not .prt
<eukara[h]> and fte is not meant to download anything
<eukara[h]> just put your patched bsp files on the server
<eukara[h]> that will be easier
<OneManClan> make ppl download maps again?
<eukara[h]> no
<eukara[h]> if all you do is re-run vis on it, none of the other lumps change
<eukara[h]> the pvs/vis lump is server-side.
<eukara[h]> the SERVER controls the PVS.
<Shpuld> for entities, but not for rendering tho?
<eukara[h]> no
<eukara[h]> ent/vis lump = ignored.
<Spoike> load != download
<OneManClan> yea i misread
<Spoike> fte’s r_waterstyle 2+ settings use recursive rendering, which allows it to draw underwater refraction using the pvs info on the other side of the water plane. it doesn’t need the map to be watervised for it (unless you want to see the ents on the other side too)
<Spoike> so yeah, technically you only need it on the server.
<Spoike> however there’s still stuff like r_waterstyle 1, or rtlights, that want the proper vis info.
<Shpuld> oh neat
<Spoike> so shove it into a pk3 and let it autodownload… unless you’re using ezquake in which case you’d need the updated bsps instead of the vispatches.
<OneManClan> wow, it worked!!
<OneManClan> FTE doesnt care if the dates and sizes of the bsps dont match
<OneManClan> no, holdon, the sizes are tyhe same
<eukara[h]> like we said, ent/vis lump = ignored, will cause no redownloads
<eukara[h]> modified pk3’s will
<eukara[h]> they do CRC checks and whatnot
<OneManClan> for now, ill just patch the bsps, and upload to the server
<OneManClan> .. and keep original copies in case of <insert some unforseen side effect>
<OneManClan> thanks guys
