Changing to a func_wall with shadows enabled has cleared up this mess! The light now spreads around the torch holder evenly and it is shadowed under. I guess this has something to do with splitting the geometry? It was a func_detail before.

Thanks again ericw, and I guess I can start compiling with the new tools and see what they are like. 

Geesh, what I would give for real-time, dynamic lighting.
Good to see that you've resolved the issue but when you release your map, you could provide a .rtlights file for DP users. AD can run in DP. 

In a cave, with my head in the sand, apparently. I had given up Darkplaces as completely dead years ago. No wonder I had no idea what Qmaster was talking about.

I thought Quakespasm was the only engine that could reliably run AD. Well, in this case I can look into making an .rtlights file. 

to be fair, new DP builds aren't exactly well avertised. Even the engine's homepage shows an old 2014 build as the latest. One has to go to the /files/ subsection to find the new builds - ironically enough, on the main page this subsection is presented as a repository for old versions... Go figure. It's almost like LordHavoc doesn’t want us to use his engine! 

I have dug this out of my HDD. I haven't tried it yet but it's supposedly better than DP's built-in editor. You might find it handy. No idea who the author is and not exactly sure how to install it, the archive lacks any readme. 

I didn't think implementing Rtlights would be so confusing. Seems one has to do it within the Darkplaces game engine itself? This editor here seems to be nothing more than a progs file, so some kind of mod to run while editing the map in-game?

I can't promise I will be able to make Rtlights file with my map, but I will release the .map file when I am done so someone else can do it. I love the work all these creators have put into their respective engines, but trying to make a single map work a dozen or so engines seems counter-intuitive. 

as you have to manually edit each light. Possible workaround: I might be wrong but I think EricW's tyrutils can output .rtlights files. Can someone else confirm this? 

placement of rtlights is often dependent upon performance rather than merely compile times, as such its generally best to place them inside the same program that will have the performance issues so you can easily see when you've overdone it.

tyrutils-ericw does NOT have support for .rtlights files, rather the engine tries to generate rtlights automatically from the ent lump. This is of course more limited and kinda fuzzy as its trying to support maps that were made without realtime lights in mind.
This also means it doesn't understand surface lights, etc.

the easy way to deal with rtlights is to just ask people to disable r_shadow_realtime_world and let someone else place the fancy lights if they really want them... DP users should be used to that by now, at least for the recent/complex maps. 

 

This map here exceeds the signon buffer which causes old clients to crash. It says "allowoverflow not set", so I take it there's away to work around this? What's the commandline? 

You would have to get rid of entities in the map.

No other way.

For instance, it may be possible that your current map may work with "skill 0" (easy) but with hard. 

- delay spawn stuff (custom QC only?)
- if you have any func_wall or func_illusionary that are not doing anything dynamic, replace them with func_detail_wall or func_detail_illusionary from my beta compiler (but iirc you had a problem with higher clipnodes in my qbsp) 

some engines support bigger/more-precise coords (obviously not vanilla). for those engines you can reduce the signon size by switching from protocol 999 back to 666, or dpp7 back to 15 (iirc dp's bjp3 support is too buggy to be practical).

and if all of the above fails, use QSS or FTE as a server, these two engines both sidestep the signon buffer for almost everything so its max size isn't relevant. you can then connect to said server with your old client. not a great workaround, but hey. 

The map has a lot of entities, but I'd think not more than other maps I've made. It's under 600 edicts. I'd need to remove enough to lower the buffer by roughly 700 bytes, which doesn't seem possible without considerable sacrifices.

As for turning func_walls into func_detail, I already did this where possible. Originally I had made them func_walls in order to lower marksurfaces which I've exceeded as well. I know it can be exceeded somewhat without obvious consequences - question is just how much? The switch made the number go from around 700 to 2000 over the limit, but the map still loads in old Winquake and Glquake. What are the risks here, what is marksurfaces for anyway? In the sense that how clipnodes can be exeeded also, except the repercussions show quickly with broken clipping on entities and geometry. 

I removed some more func entities and the buffer size went down only marginally. There must be something else going on here, entity count alone cannot the only reason. 

Static entities count too. Torches, etc.

Static entities do not reflect in the edict count but are part of the sign-on. 

what is marksurfaces for anyway?
Marksurfaces are a list of the faces touching each BSP leaf. They're used in rendering; when the engine decides a leaf should be visible, it looks at that leaf's marksurfaces to figure out what faces need to be drawn.

At a quick look at the winquake source code, there is no limit on marksurfaces beyond BSP format (65536) and heap size. 

If I'm setting up Jackhammer for mapping in Q1, but am using the Quakespasm engine, do I change the destination files to those of Quakespasm? 

Treat it like any normal JACK/Worldcraft setup. What is your current issue? 

I get this error EVERY time I try compiling a map.


** Executing...
** Command: Change Directory
** Parameters: C:/Program Files (x86)/Steam/steamapps/common/Quake/Id1


** Executing...
** Command: Copy File
** Source: C:\Program Files (x86)\Steam\steamapps\common\Quake\Id1\maps.map
** Destination: \maps.map

* Could not copy the file:
Source: C:\Program Files (x86)\Steam\steamapps\common\Quake\Id1\maps.map
Destination: \maps.map
* Windows gave the error message:
"Access is denied." 

Now it's this:

** Parameters: C:/Users/thepa/Desktop/quake/quakespasm-0.92.1_win64/Id1


** Executing...
** Command: C:/Program Files (x86)/Steam/steamapps/common/JACK/quake/qbsp.exe
** Parameters: "C:\Users\thepa\Desktop\quake\quakespasm-0.92.1_win64\Id1\maps\maps"
---- qbsp / TyrUtils ericw-v0.15.9 ----
Input file: C:\Users\thepa\Desktop\quake\quakespasm-0.92.map
Output file: C:\Users\thepa\Desktop\quake\quakespasm-0.92.bsp

---- LoadMapFile ----
************ ERROR ************
Failed to open C:\Users\thepa\Desktop\quake\quakespasm-0.92.map: No such file or directory


** Executing...
** Command: C:/Program Files (x86)/Steam/steamapps/common/JACK/quake/vis.exe
** Parameters: "C:\Users\thepa\Desktop\quake\quakespasm-0.92.1_win64\Id1\maps\maps"
---- vis / TyrUtils ericw-v0.15.9 ----
running with 4 threads
testlevel = 4
LoadBSPFile: 'C:\Users\thepa\Desktop\quake\quakespasm-0.92'
************ ERROR ************
Error opening C:\Users\thepa\Desktop\quake\quakespasm-0.92: No such file or directory


** Executing...
** Command: C:/Program Files (x86)/Steam/steamapps/common/JACK/quake/light.exe
** Parameters: -extra "C:\Users\thepa\Desktop\quake\quakespasm-0.92.1_win64\Id1\maps\maps"
---- light / TyrUtils ericw-v0.15.9 ----
extra 2x2 sampling enabled
Raytracing backend: Embree
running with 4 threads
LoadBSPFile: 'C:\Users\thepa\Desktop\quake\quakespasm-0.bsp'
************ ERROR ************
Error opening C:\Users\thepa\Desktop\quake\quakespasm-0.bsp: No such file or directory 

It's like it's negating the name I'm giving the file to begin with. 

I think this is what is wrong BUT I don't use JACK too much so maybe some of the more experienced users can chime in:

It looks like you put Quake on your desktop then a folder called quakespasm-0.92.1_win64 inside your quake directory and pointed JACK to that as your game directory. From there JACK is totally confused. You should have extracted the contents of the Quakespasm zip to Quake itself. here's what a normal install would contain as far as folders:

C:\Quake
C:\Quake\id1
C:\Quake\id1\maps - this is where all your custom map/bsp should be

Inside Quake folder you would normally should see: quake.exe, quakespasm.exe and a bunch of DLL files (maybe not if those are hidden, just depends)

Quake itself is pretty small. You should make things simpler by making a new Quake directory:

1) Make a folder called Quake on your C:\ drive as seen above. 2) Then under that a folder called id1 - 3) now go find 2 files pak0.pak and pak1.pak in that other messy Quake folder. 4) Copy or move them to id1. 5) Then under id1 make a maps folder. 6) Next extract Quakespasm zip to your Quake folder -- NOWHERE ELSE . Now you have everything but your map. --- 7) copy your map from the messy folder to C:\Quake\id1\maps 8) run JACK and (this is where I am fuzzy) point JACK to the new Quake folders as needed. Yes Quakespasm is your game engine to play Quake but it's best to put it in the Quake directory.