Thank you Preach!

I knew as much from my Quake source spelunking days, and you pretty much confirm this.

I also am aware, that back in those days, in SP mode, network was being simulated using memory buffers, so that both SP and MP code could use share single NET logic. I also understand that that is the reason, we have separate SSQC and CSQC nowadays.

What I have been unable to dig out, is the currently supported map bounding box with regard to network code (even in SP).

Experimenting with QSS and it's netplay (just coop part), it seems that protocol was vastly improved as we could now easily play the AD game by just forwarding single port as readme says. I remember there being problems in the past.

Given the protocols saw new developments, would it be safe to assume network packet positional limits were updated?

Would anybody here know?

If nobody here does, it seems for now, the best way to find out this information would be to use Luke power and investigate whether QSS & FTEQW advanced protocols support bigger coordinates, right?

I wanted to avoid code dives by searching first, but my search-fu is not what it used to be and I can't find any current quake protocol limits (nor descriptions).

Thank you for pointing out though, that if such protocol is supported, map being BSP or BSP2 is entirely different thing, as I guess coordinates of both BSPs are stored in floats which are potentially unlimited thus both map formats would be able to express huge player positions without wrapping up. 

bsp29 (read: vanilla) supports bounds of up to +/-32767 units.
this limit is enforced due to the node+leaf lumps using signed shorts for their bounds. actual vertex info etc uses floats though. FTE has some special magic that allows it to ignore those leaf+node bounds and recalculating them itself, which basically makes that limit irrelevant. alternatively bsp2 upgrades them all to floats also.

this combined with protocol upgrades to network coords as a float means that the theoretical maximum map size possible is +/-FLT_MAX, aka +/- 3.40282346638528859812e+38F which is such a large number that you'll basically only ever see it written in exponential form. hint: really really big.

in practical terms however, the floating point precision will degrade far before you reach those bounds. acceptable precision is a much more subjective limit. so you should probably limit yourself to +/- 4,194,304 units, give or take an order of magnitude.
this is the same limit enforced by the qcvm. expect problems ranging from inaccurate traceboxes to severe gpu issues (like entire walls disappearing without even zfighting).

BSP2 files have a maximum file size limit of about 4gb. I suppose it may be possible to hack around to get 8gb out of it perhaps if you place the largest lump last, but that kind of thing is somewhat crazy talk. personally I don't have enough ram for that sort of behemoth.
plus you really don't want to force the engine to have to walk that many nodes. not everything will scale well.

so yeah, don't bother trying to find any hard limit, its high enough to be kinda irrelevant. that's the theory anyway. 

Thank you Spike!

I presume you are *the* Spike responsible for awesome QSS fork and FTEQW, correct?

So with modified protocol there is basically no limit, but numerically, many game's internal algorithms will start to break much sooner than that. Good to know that there is such mode of failure possible! I was certainly not expecting that.

From your knowledge of the codebase you then estimate this upper limit being roughly around 4,194,304 in both directions (positive & negative).

Okay it's not "that big", but still considerably bigger than 8000u that Preach estimated for old protocols and way more than 4000u shown in some Trenchbroom screenshots (or maybe that's same limit, Preach just posted maximum "width" from -4k to +4k, which it probably is).

Well I think one may quickly hit 8k limit relatively easily, if not very careful.

But from this information it seems, that anything that fits within +-16~32ku is relatively okay. Right?

Then I also presume that 4gb for map limit is when using "standard" ericw compilers, without any sort of magic reordering. First: this reordering, like to allow for 8g, would require modified compilers, right, it's not like it can be used already? Second: does this take into account external .lit (I am not sure QSS supports them but FTEQW certainly does)? Or external .lit have another 4g limit of their own? It being 4g, which is nice round number, I presume it's because file "chuk" size is measured in uint32_t, right?

My main question however is: this new protocol, is it active automatically? I assume you don't need to do anything and game should be using it by default. Correct, or?

I am asking because I've been playing this one specific map once, which I don't know name of right now (but could dig it out, if wanted), and I have a hunch, that when noclipping around while studying geometry, I accidentally wrapped around. I am not sure, if I really wrapped around, as my memory is hazy and I was too mesmerized by the architecture and forgot what exactly happened, but it made me remember there might be a map size limit. Could it be that new protocol was somehow not active (due to map fitting within 8Ku for example)?

Once again thank you so far! This was exactly the answer I was hoping for. 

qss defaults to fte-999. note that config files that try forcing `sv_protocol 666` can disable this.

fte's default is to guess whether to use its 'bigcoords' extension based on whether an entity is outside the +/-4k boundary or not. an info_notnull is enough to force it. it uses ents rather than bsp geometry so that eg pseudo-skyboxes or otherwise unreachable scenery can exist without losing backwards compat (so yes, its possible for it to guess badly). You can always set `sv_bigcoords 1` to force it, if you want.

so yes, config files are different, but they're otherwise equivelent.


QSS uses fopen et al, and thus is likely to be limited to 2gb file sizes.
FTE uses 64bit file offsets, but this is more for pk3s than anything else. Abusive bsps are completely untested.
the 8gb value is a theoretical max - if any map actually reaches it then the performance when actually playing it is likely to be so abysmally low as to be futile to try playing it.
Personally I prefer the occasional loading screen if only for a sense of progress, something that can be lost when you're 'stuck' trying to make progress through a 256mb labyrinth of a bsp. an 8gb bsp would likely just be painful. 

This is great information, thank you!

So where would be "the good place (tm)" to record it for posterity?

After all let's be frank, func_msgboard is lovely, but it is not best searchable archive around (it is quite a good archive otherwise, like historically).

There used to be quakesrc.org (I think was the name), which was quite a treasure trove, but then it died and for a time, it looked like all the knowledge was lost.

Is for example quakewiki.org community approved?

I remember there were some dramas around doomwiki not being hosted on community resources at first and then company hosting it tried to monetize it and as far as I understand that caused doomwiki to move away. Then there was a period of confusion because of this.

quakewiki.org seems like community hosted, and it seems it is slowly getting beter, month to month, but is it acceptable put this there? 

quakewiki.org is legit, but hasn't had a lot of user contributions so the breadth of information there isn't much.

However there is a page about network protocols:
https://quakewiki.org/wiki/Network_Protocols

And there is an intent to make sub-pages dedicated to each protocol. I did one for Fitzquake:
https://quakewiki.org/wiki/Fitzquake_Protocol

So, the information you were looking for should have been listed in pages for "netquake protocol," "protocol 999," and "FTE protocol," if those pages existed.

---

In terms of func not being very "searchable", do you mean the search interface is missing some feature(s), or do you mean something about the contents of the the posts and threads that means the information can't be found (e.g. people aren't using consistent terminology in their posts?) 

I decided to write this draft:

https://quakewiki.org/wiki/Map_metrics

Some information might be wrong (I just assumed - I need to take look at the source to backup my claims).

It's also pretty rough and could be shortened, reflowed a bit or split into multiple subpages, but for now I think it's okay. I will work on it following weeks. I decided metrics section should be as expansive as possibile and should be linked from main page between "compiling" and "entity guide" page. If anybody thinks else feel free to edit.

I started with map boundaries and plan to add other metrics as I go (discovering and documenting them I remember seeing somewhere pretty good collection of some metrics to base from).

I plan to add footer backlinks here later.

---

Now that I know what to search for I noticed my QSS emit "Using protocol fte999" so I now know when it is using bigcoords, thank you very much Spike!

By the way how much stable is master branch? Seems pretty solid for me.

---

metlslime I mostly meant it is lacking knowledge base structure, but what you pointed out too. It's hard to start searching deeper if you don't know what and how.
And I admit I totally missed "search" button first time around.

---

Do you guys know if admins of quakewiki.org visit here? I would like to ask how to make backup I would be really sad if it dissappeared one day same way quakesrc did. 

I plan to extended protocol pages later. A do not know enough about the protocols atm to extend those pages meaningfully. 

When i kill an enemy i get knocked out of the map and stuck there, This has happened once before on a test map but i just used Undo till it fixed itself. I cant do that this time. My map. I can post condump if needed. 

Is there a way to use more than one sky texture in a single level? Maybe a map hack? 

 

I made some sky boxes you can add to the original. They are a bit wobbly, but you can try them out. It is a sphere static with a project animation. See page three.

https://www.quaddicted.com/forum/viewtopic.php?id=392&p=3 

SilentMonk - if you use a skybox and a QuakeC mod, you can issue a console command through the mod to change which skybox textures you're using. You could for instance have a sunset texture when the player starts outside, trigger the console command while they can't see the sky (a windowless interior room), and next time they step outside night has fallen.

This approach does hurt your map's ability to be engine-agnostic - it doesn't degrade gracefully in older engines, and it relies on custom engines having a consistently named console command. I set up something similar in the final map of the Travail pack, but in the end rather than changing the skybox we just hid it with some completely black brush entities to make night fall. I actually wanted it 100% black to make some special effects work properly, but that wouldn't always be preferable to having stars. 

Thanks for your answers @madfox and @Preach. I should have mentioned that I am particularly looking for a solution that works without using a mod. Sorry for not being more specific. But that was still very valuable info I can probably use in the future. 

Is there any way - in standard Quake - not a mod - to have the keys - in a single map. Rune, Base, Medieval - overriding the model which is specified by the choice set in "worldtype" 

I think this is possible with map hacks.

One possible obstacle is if the key models you want can’t be precached somehow.

Check out the “teaching old progs new tricks” thread just in case. 

thank you, I had read about this possibility. It would be a major hassle though to set it up correctly and if I do it this way there would only be the static model in the map. I guess with some more trickery it could be killtargeted at touch and somehow give the player a key. But this introduces some more possible problems down the road. In this case I was hoping for a different solution with a "real" rotating key model instead of a static frame. 

SilentMonk - the only thing that worldtype does is control what type of keys the world has. Why would you not just set it to the type you want?

If you're trying to have more than one type of key at the same time, that's a no-go. Even if you could do it, the gameplay effects would be illogical, because everything else in the game doesn't make any distinction between keys from different worlds:

• The player inventory and HUD only supports one, so if you could spawn sliver keys from two different worlds, the player could only pick one up at a time
• Doors only code what colour of keys open them, and the player only remembers the colour of key collected. So you couldn't create a door that opens for the silver keycard but not the silver runekey - all silver doors are opened by any silver key

What Metlslime is suggesting is an alternative which does work. For one type of door, you use "fake" keys. To create a door that is opened by the "Green Keypass":
• Give the door a targetname instead of a key flag, so that it only opens when triggered
• Create a trigger_multiple in front of the door which sends a message to the player "You need the Green Keypass"
• Use hacks to create a spinning BSP object to represent the Green Keypass
• Create a trigger_once around the keypass which:
---- kills the BSP object
---- kills the message trigger
---- spawns a trigger which opens the door (through another hack) around the door

This doesn't work 100% perfect in co-op (in effect all players gain the Green Keypass when one of them touches it), but for a Single Player map it's pretty indistinguishable from actually having a third key. 

Thank you very much Preach for this long and informative answer. I was under a wrong assumption all the time - but your info closed all the gaps and cleared things up for me!
And thanks again Metslime! 

I know you want to avoid using a mod but just in case: in progs_dump 2.0.0 you can use any model for a key and customize it's name and a bunch of other goodies. 

Thank you @dumptruck_ds I have had a look already. It offers a lot of great things I have been dreaming about. 

Let's say I'm making a little "episode" of several levels. Would I be able to rig up a "Congratulations" screen of text like the normal ending of Quake?

I tried searching through end.map and wasn't sure where to look. Tried searching this forum, but I failed to produce search terms that narrowed it down. 

The end txt 9is captured in the boss_gate function. When captured four runes and defeat the old one with the messier object entering the transporter thing simultaneously, you'll get to the end screen. From there it is altering the progs.dat txt file with your message.

You need a setup with each episode a rune. Then make an end map in which you encapsulate the defeat of the oldone, or one of your own end bosses.

It can be easier to use the freeware version and use the killing if Cthong as your end level. That way you can look at the original files to compare with yours. 

the text for the intermission screen is in quakec, not in the map itself. So to change it you would need to make a mod.