Racing Ghosts (As this unfolds)

[Baker]

[frag.machine]

Joining the train late:

So, can the "ghost" player actually interact with monsters, doors and other elements ? Is this an actual fake player guided/positioned by the demo information ?

Also, can you playback a ghostdemo and record a regular demo at the same time, rinse, repeat so I could simulate several players together in the last demo recorded ? I can see this being EXTREMELY useful for machinima purposes.

Last, please, make all those details (ghost transparency/ghost waits or not byt the player/whatever) configurable by cvars.

Regardless the answers: great idea and good job, Baker.

[qbism]

[Baker]

[qbism]

Regarding rockets and weapon effects, those emitted by the ghost should be in the demo most of the time. Although the demo doesn't "know" who they're from. So all of those items in view of the original player would be seen. Again, the chance of "double-image" confusion, if the ghost overlay contains a grenade launched by an ogre from the same position as the real ogre in-game as an example.

There's going to be one more engine with sv_novis soon. Although it sounds like it could be dangerous without enough support from increased limits, protocol, etc.

[mh]

sv_novis 1 really just started life as a hack to allow entities to be seen through translucent water. It doesn't pretend to be robust, and really does need protocol and other limit extensions. If SV_WriteEntitiesToClient and client-side visedict addition are coded to fail gracefully (rather than crash or overflow buffers) - which is the case with ID Quake - then the worst that can happen is some entities don't get added or drawn.

A few things can firm it up. In SV_WriteEntitiesToClient you could do a first pass through the entities writing those that are visible, then do a second pass writing those that are not. That would mean that if an entity fails to send it's probably not that big a deal as it likely would not have been visible anyway. Sorting entities by distance to the client and sending from nearest to farthest would also help some, at a (small) performance cost (this only need be done for the entities that are not visible). There are also some entities that you probably must send (monsters, doors, plats, other players) and some you could get away with not bothering to send if need be (gibs, heads, dead bodies, bubble sprites) so there's another sort key. Basically, it amounts to being a bit more clever about how you manage sending entities to the client. I haven't bothered doing any of this in my own code, as I've never extended use of sv_novis 1 beyond it's initial purpose as a hack (plus my limits are already stupidly high anyway so I don't really need to).

Client-side it's quite trivial to just extend the visedicts array. Extending cl_entities is a bit more work (if you want to avoid reserving too much memory for this array), but since this is defined at size MAX_EDICTS which is the same size used for server-side, it's probably not necessary (unless you've been mucking around with the size of the server-side array, in which case you're in "might crash" country even without sv_novis 1 support - another of the nice little traps Quake lays for you).

There's one more place server-side that PVS is used and that should probably be addressed, and that's in PF_checkclient where it's used to check if enemies can see you for accelerating aim tests. Sending all entities to the client is also something that should probably be done if the viewpoint is inside a solid leaf (i.e. we're noclipping).

[Baker]

[taniwha]

Baker: nice. I'd recently though of doing something like this, but not gotten around to it. 1.5x is probably plenty thanks to all the lights and static entities that wind up being freed immediately.

[mh]

I changed sv.edicts from an array of edict_t to an array of edict_t *, which needs a little more work and some seriously ugly code (particularly in PR_ExecuteProgram) but accomplishes the same goal. With hindsight my memory management system didn't need it; I could just MEM_RESERVE enough space for 32k edicts in a new CQuakeHeap and pull from that, but I balk at the reworking required elsewhere. Maybe someday.

There's just something seems deeply wrong about crashing the host, potentially at runtime (edicts can be allocated at runtime), and expecting the player to increase a cvar to some arbitrary higher value that they don't know and may potentially may be exceeded again.

[Spike]

guessing the number of entities required is a horrible thought indeed, especially if your guess can be wildly affected by the number of lights on a map which are _generally_ removed immediately after spawning and thus do not contribute to the required limit.
Your 8k limit will cause maps like that 10k knights map to fail.
Your 512 minimum limit may result in crashes if you have 16 players all on some moderatly large/open map spamming nail-spewing grenades, depending on the mod. Especially if its also running a mod like frikbots that auto-adds waypoints to the map.
I do not like mere guesses.

mem_reserve memory is really only one step up from bss. the only difference is that you're likely to have functions to re-reserve it again. which means that you're now allocating and releasing lots of pages instead of simply reusing. in a worse-case scenareo you're still bumping in to the hunk limit (compounded by the size of the map, which is likely to be huge if you have 6k+ ents specified on it).
I'd recommend just using malloc if doing so didn't also break assumptions about qc's ev_pointer types.
FTE has a separate heap for such vm-accessible memory, giving mem_reserve type behaviour for ents/strings, solving qccx pointer hack exploits, and fixing all 64-bit vm issues. Your milage may vary.

[mh]

MEM_RESERVE needn't be like that. You know you've a max of 32k edicts, you know how big an edict is, so your first VirtualAlloc call reserves space for this total size. As needed you commit in reasonably sized blocks - memory usage only ever goes up as required, so there is no runtime release/realloc happening, and if you commit enough for - say - 128 new edicts each time you need more space, you've got very little runtime allocs happening. Most of the time you're going to be referencing an edict slot that has already been allocated. When starting a new map you wipe and recreate. It's basically a primitive garbage collector. Very fast, no fragmentation, never runs out of space, immune to leaks, everything in linear contiguous memory so it's nicely cache-friendly, very little extra bookkeeping or boilerplate needed, but also very non-portable.

[qbism]

What situation "needs" 32000 entities? Besides experimental maps designed for the purpose, I haven't been able to find a bigmap that threatens the Msg_WriteShort limit of 8192 edicts. My highly scientific process includes running around Unforgiven maps, stirring up as many monsters as possible while occasionally checking "entities" in the console.

[mh]

No situation, but in theory Fitz 666 supports it, and that means it can happen (in practice you'll crash elsewhere long before you reach that figure).

[Baker]

[mh]

DirectQ's renderer can probably handle that number of knights but it's network code can't, and I expect it's progs interpreter will have some trouble too. I'll probably add an MDL benchmarking test that just spawns these models client-side; it's fun to test these things out.

The big problem with cvar-izing max edicts is that it places responsibility onto the player for something that should be the engine coder's job - it's a cop-out, it's saying "I can't be bothered fixing this right, you deal with it". It's true that making an estimation the way you've done so is a good first step, and a hell of a lot better than what was there before, but it's still got a case where this estimation can be exceeded and you don't seem to have a graceful failure case for that (I'll admit that I haven't looked at your code in a while though). Adding another 128 (and probably lower-bounding at 1024) will help for sure, and will make the failure case quite unlikely, but it's still there.