Is it possible to have one exit for two maps and solve this via .ent?

Example:
One map (let's call it "origin") leads to another called "target1". Now there is a patch and "target1" gets renamed for some reason to "target2". However, I would like the .ent file written for "origin" to work in both cases.
Is there a way to write an .ent file for "origin" that works like "if there is a map named target1, use that one, otherwise target2"? 

I'm pretty sure that this won't be possible, but I'm trying to understand what's going on with these patches - I don't understand why you don't just rename target2 back to target1? 

I think this is the solution, if I understand your problem:

original release (pak0.pak) has 2 maps: origin.bsp, target1.bsp. And origin.bsp's changelevel entity points to target1.

then you release a patch (pak1.pak) which contains target2.bsp, and also contains origin.ent which updates the changelevel entity to point to target2.

The solution you proposed is not possible AFAIK. QuakeC could have a modified changelevel entity that takes two different mapnames, but doesn't have a way to check if they exist on disk. 

It is as I thought, then. The problem is that there are two versions of the same origin map, each leading to the same target level, but with different names.

It would have been easy if I didn't have to include a patch for the origin map as well, forcing me to decide which target level should be the "chosen one". That really leaves no option other than to include the target map itself to make sure everybody gets the same result. I had hoped I wouldn't have to include an entire map for this, but apparently it's the only way. 

 

I can't get this to work and I don't know what I'm missing.

// entity 175
{
"classname" "info_notnull"
"think" "InitTrigger"
"nextthink" "5"
"touch" "health_touch"
"healamount" "1"
"use" "SUB_regen"
"targetname" "heal1"
"target" "heal1reset"
// brush 0
(blah blah blah)

// entity 176
{
"classname" "trigger_relay"
"origin" "1742 320 1214"
"targetname" "heal1reset"
"target" "heal1"
"wait" "1"
} 

What you're missing is that regular medkits (healtype 0 and 1) only heal the player if he's below 100. Use healtype 2 to go above. And unless it serves a special purpose, the relay isn't needed (wait doesn't work on it anyway); the trigger can fire itself after a delay. 

Thanks ne🅱️ke. 

when building a quake map the area is supposed to be fully dark where the mapper sets all the lighting. i have done re installs of my tools and even changed the compile tools used. right now i am working with trenchbroom and i had been working with worldcraft. anyway, whenever i start working on a new map the floor and even additional brushes are lit up as if i have set lighting and i haven't. when in trenchbroom i do not see any values set for anything in worldspawn for light, _sunlight etc. i am not sure if my settings are messed up in darkplaces as far as lighting goes. my gamma is set to 1 though as i have noticed that just that setting alone can cause issues. i have tweaked settings before where the map rendered dark with no lighting effects going on and will revisit that through trial and error. does anyone know what is causing this?

EARP 

If you have no lights placed in your level (or don't run light.exe), I think it will render fullbright in the engine. 

i am running a version of light.exe but i do not have any lights placed on the map and no values were placed in the world spawn. i read about _sunlight that is located in worldspawn but there is another tag named light as well there (there isn't enough info on these for me to understand how they work). anyway, it is lighting up fullbright despite this fact. maybe i will place an actual light as far as quake goes to see if it becomes dark. i guess it could be my darkplaces settings but that are fudged up. 

m8, if you have no lights in your map it renders fullbright, as metl said 

yes thanks @metlslime @muk

something else is going on but i will take a look at it, adding took care of most of the issue 

I set up four working compiling profiles for Quake 2, Heretic 2, Kingpin and Hexen 2. Next time I open the editor there exist say only Quake2 or Quake 2 and Heretic 2 or None or just Kingpin. It's random as far as I can tell. What am I doing wrong? Is it possible to save or export the compiling profile so I needn't do it again and again? 

Haven't seen a mention of it here, but it seems BSP has been revived in 2018 (around the last time I posted something here) and has been making steady progress since then.

https://www.bspquakeeditor.com/

I remember it being abandoned since 2007. 

This is question about metrics.

Before BSP2 (limit removing), I remember there were several limits to map size, not only due to bsp format but also due to networking packet format, etc.

As far as I understand BSP2, it increases number type of indexes so it allows bigger count of map structures (vertices, faces etc), however this does not automatically mean map (boundaries) can be bigger.

I am playing mainly with QSS and FTEQW and can not find any information on how big maps can be in these engines. Does anybody know? 

Hi 3t0. Without giving you an actual figure, I can point you in the right direction of the problem...

Unlike the vertex/face limits, the limit on the dimensions of a map in standard Quake is not actually due to the BSP format. Instead the limit is due to the network protocol used in Quake, which encodes positions in a fixed precision format that "loops" after 8000 units. Worth noting that even in single player, the game sends network messages between client and server processes on the same machine.

So an engine that supports BSP2 but uses the standard network protocol has the same limits on size as the original Quake engine. That said, QSS and FTEQW may support upgraded network protocols that allow for larger locations to be encoded - now that you know it's about network protocol you might have more success uncovering what limits the engines raise.

One last thing to realise is that if the engines do support larger maps, they'll support them just as well in regular BSP maps as they do in BSP2. Obviously the higher limits will allow you a better level of detail in a map that's testing the limits... 

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.