December Lab Report #12 of 12 - Journey Onward news - Zircon Engine - a "DarkPlaces Mark V" project mod for Quake

January 28: (Download Beta #33 - Win64 Binary, #32 - Linux Binary)

Stress test: Zircon Zero Ping Movement @ 1000 Ping - 20% packet loss.

Challenges dealt with: Doors, elevators, rotating doors, taking fall damage, collision with entities -- plus "missing doors" because player rounds corner entering new visibility area and server has not sent updates.

Related: [200 ping video] [Singleplayer]

A "Z" indicates "Zero Ping Movement Is Active". "DP7" indicates free movement is suspended due to standing on a train or elevator or such.

[Note: When I watch the video, my eyes are glued to the slightly jerky train ride. This was a problem in Half-Life and I have seen in it other games. I can imagine communicating or calculating train movement speed and eliminating that.]

Sounds in Quake are unreliable and with packet loss, there can be missing noises or doors that make noise forever (the end of a door sound in Quake is having it play "null.wav", if that packet drops the door noise will be forever). Zircon does reliable sound for Zero Ping Movement.

Zircon is not running a new protocol to do this, it extends DarkPlaces Protocol 7 in a backwards compatible manner. A DarkPlaces client could connect, they just don't get "Zero Ping Movement". One goal of Zircon is to keep 100% DarkPlaces compatibility.

Zircon has 6 or 7 protocol extensions to do this, modelling how FTEQW can extend the Quakeworld protocol.

January 28

Zero Ping Movement can jump just slightly higher and you can take unexpected fall damage from a ledge jump that should not cause damage -- jump_flag hitting -658, just across the threshold. I have the server-side slightly reduce "jump_flag" accumulation by about 15 (*).

* if the "jump_flag" field exists -- with DarkPlaces and total conversions it runs, I do not want to make the assumption that field exists in QuakeC.

PlayerPostThink
	if (self.jump_flag < -650) {
	   // Take damage
	}

I also have the prediction "Elevator Step". I did this a while back, prevents awkward visuals if the server moved the elevator to a space "you think you occupy, but have not told the server yet". However, in some situations, "Elevator Step" could repeat -- especially on a lagged connection.

Lagged connections is what Zero Ping Movement is for, I want it to do as well as it can in that scenario.

I have changed it to only "Elevator Step" once per server communication, as "Elevator Step" only can need to fire if the server moved the elevator.

Zero Ping Movement is best when you can't tell if it is on or not.

January 28

Rocky day. Zero Ping Movement had issues during a dedicated server test. Then after looking through the code and checking out to see what went wrong, the power went out for a few hours of winter darkness.

Dug into the code after the power was restored, I found my mistake.

Time to make sure it everything goes according to plan and to triple test everything.

January 27

Upcoming: Zero Ping Movement hardening -- it hates DarkPlaces cl_movement_minping which caused the worst possible movement warping imaginable --- rewritten to ignore cl_movement_minping if Zero Ping Movement is possible. It did not play nice with rotating doors at all. I expected that and was ready to adjust for that scenario.

January 27

Upcoming: I have enough data on the Remaster crash with the ammo box crash that I should be able to eliminate the crash.

A Different Mystery, Solved But Not How I Like: Sometimes a bug report investigation ends with "no action possible".

Left: Zircon / DarkPlaces render slightly different from Quakespasm (Right). I was hoping this was a texture load issue for Zircon/DarkPlaces. Sadly, it is not.

The texture is actually missing in the .bsp. Typing "r_drawentities 0" in Quakespasm reveals the missing texture.

DarkPlaces draws slightly differently and in many cases DarkPlaces naturally avoids Z-Fighting (textures that share the same plane) using a method LadyHavoc once described (but I have little chance of ever finding the conversation).

But the short version: there is a brush with no texture that occupies the same plane or nearly so as the tip entities. In Zircon/DarkPlaces some of it can be seen. In Quakespasm, none of it can be seen. This difference could be due to sorting or floating point calculation or draw order.

January 26

New: Quake Re-Release does not have default.cfg which can cause start up with no movement controls. Zircon now will detect this situation and use a WASD keyboard setup with always run on.

A user said for Quake Rerelease "pick up shells in E1M1 game crashes with player dropped" ... I don't experience this with Zircon -- if anyone knows of how I can cause this problem for myself, please let me know.

"sv_players_walk_thru_players 1" option and "sv_clmovement_soundreliable 1" option (which can prevent clients with high packet loss losing sound messages).

January 25

Added a hardcoded "windtunnels" exception to Zero Ping Movement, hardcoding a windtunnels exception is the only way to get unmodified progs.dat wind tunnels (trigger_push) to work with Zero Ping Movement.

Added "sv_players_walk_thru_players 1" -- which is works both normally and with Zero Ping Movement. This is for a serious multiplayer coop server to not much worry about a player blocking a small opening on purpose to impede a game -- not a common problem, but this largely removes that as a factor.

(There are other more situational ways for a player to interfere with a game, like refusing to get off an elevator so it never goes down).

The "showmodel" command is not far from being a vegetation planter or a tool to throw some trash 
on the floor in a map.  I've never looked around in J.A.C.K. or TrenchBroom to see if there is a 
good way to do that.  J.A.C.K. has a way that mostly can do that, is it pinpoint 
precision?  Not sure.  Thinking ...

Writing this one was more involved than I expected, DarkPlaces has the SOLID_CORPSE movetype which could be used on a player ... but QuakeC by default only allows SOLID_SLIDEBOX to use teleporters, so the player movetype must be SOLID_SLIDEBOX.

DarkPlaces Beta has a new feature called "clipgroup", I may have been able to use that instead setting all players to clipgroup 1 in the engine immediately after PutClientInServer. Maybe I will rework and use that instead.

January 24

"Zero Ping Movement" complete playthru of Episode 1 at 600 ping went fine. Previously, sometimes doors and lifts would make "noise" forever. The reason for this was lost sound notifications, the lifts and doors in Quake stop playing sound by sending a sound request for "null.wav" to play. Quakeworld has a reliable sound option that DarkPlaces also supports and forcing that made the sound issue go away.

January 24

Future: "Zero Ping Movement" had a bit of bobbing artifact (the player could slightly bob when not moving) which has been eliminated in code and it was a bit difficult to get out of the water. Quakeworld has some "help get out of water" code in the prediction, I adapted it into Zero Ping movement.

"Zero Ping Movement" doesn't support rocket jumping or anything giving the player velocity like wind tunnels or blast radius velocity at the moment -- and it might stay like that because I think 300 or 600 ping play might become awkward with it --- still want to consider how to make wind tunnels work without hard coding it.

Might write a server option allowing players to walk through each other. I remember playing on a coop server once and some player stood in a doorway.

January 24

AZERTY Keyboard fix for "superscript 2" key, this is the key in the same place as tilde on a French AZERTY keyboard. 95% chance Windows is fixed. Linux fixed? I don't own an AZERTY keyboard and don't currently know of a way to test on Linux.

Zircon's code is for the keyboard is the same as DarkPlaces.

However, Zircon is built using SDL2 and SDL2 is producing 2 different scancode for that key depending on the compile method (Visual Studio build with SDL2.dll vs. GCC static linked SDL2). So I added code to cover the other scancode scenario.

January 23

I have given KleskBY Version #1 of "Zero Ping Movement" to test with (1000 ping and rampant packet loss only mildly affects gameplay). The concept was his idea and he coded a very good version in client-side QuakeC. I told him I'd commit to getting him that concept in the engine with zero overhead.

"The Road To Proper Zero Ping Multiplayer" was an ongoing campaign and commitment to achieving this goal. It was a most brutal challenge. I had to fight and scale and learn almost continuously.

Pictured: One of KleskBY's games.

January 23

1000 PING = NO PROBLEM: One-Thousand Ping - 55% Percent Packet Loss

Working through some remaining "Zero Ping Movement" quirks. Bounding boxes of Ogres, etc. communicated to client for better collision = done. Minor weirdness of slight bobbing sometimes when done moving = solved. Remaining: doors/func_wall state always sent to client = TODO. And weird die in lava respawn in the same place in the lava = needs solved.

Update: TODO = Not. sv_cullentities_nevercullbmodels 1 should solve, however I want to see if the client will cull the out of sight ones like what I hope the engine does with static entities).

When planning how to interact with the server correctly for "exceptions" like teleporters (this is already a non-issue, but want to change the method a little to use same mechanic for other special events), can't using timing because super lagged connections may require more time than "the usual". Can't use number of frames, because we don't want anything sensitive to frames per second. Means might need to rework some mechanics into a perpetual never-ending handshake type of interaction.

January 22

"0 Ping Movement" -- Had trouble with respawn in multiplayer games -- engine had 3 places where I needed to take action, not one. Solved. Considering adding transport mechanism to let the client know bounding box sizes for models ... reason = 2 models in Quake have bounding boxes in QuakeC that do not line up to their actual bounding boxes -- and client-side we need to do collision with them.

In The Good News Department: Simulation using 300+ ping and 55% packet loss, playing through Episode 1 of Quake was a very workable experience. If 300+ ping and 55% represent a terrible scenario, the performance of Zircon 0 Ping Movement made this terrible scenario = not even annoying.

Notes: At 300 ping or higher, visibility data is more important ... may consider having engine ALWAYS transmit all map brush models. When the lag is very bad, you can turn a corner and doors and lifts are not immediately visible because the server has not sent them. Again, the performance and playability in the super bad connection scenario was quite good -- but I'd like to improve on the map object visibility some.

Notes: Sometimes looping sounds continue forever with a super-bad connection -- like a door opening or func_train moving .. determine what causes a sound to stop playing and find out why it is not occuring with super-lag sometimes

January 21:

"0 Ping Movement" version 1 will be ready for testing later today. I was able to complete Quake Episode 1 (7 levels plus start) with the new prediction mode.

The purpose of "0 Ping Movement" is for Zircon to offer a prediction mode where there is a consistently smooth in-world experience on a server even with a relatively poor connection -- where having bad ping and moderate packet loss -- have little effect on the gameplay.

(This next one compressed a bit poorly = grainy .. to stay with the 4 MB image limit, but the movement is the important part.)

January 20

Typing: "showmodel progs/player.mdl" will display a model in-game for examination. showmodel path aware autocompletes all .mdl/.md3/.obj/.spr.

KleskBY has released a project, it can be downloaded at Rite Of Reckoning. Does not require Quake, just unzip -- double click the .exe and play.

showmodel (model name) [frame number] [z origin adjustment] [scale]

January 19

More refinements and tightening to "0 Ping Movement". It is passing all the connection simulation tests so far. This is with simulated lag of 300 ping and supposedly 55% packet loss and it does not affect it all when it comes to movements (actions like shooting would be a different story).

I only say supposedly because I thought the scoreboard in DarkPlaces shows packet loss and it is showing zero, but the lag simulator tool is definitely set to 55% packet loss. And with zero ping movement, you won't notice packet loss when it comes to movement.

All the evidence suggests, time to take to take this to next phase and harden against doors/elevators/etc.

January 18

Upcoming Zero Ping Movement, Attempt #2. Attempt #1 had physics timing issues except in a very narrow range of circumstances. Attempt #2 has not shown any timing issues so far, the planning for Attempt #2 was mapped out in a way to avoid the timing issues in Attempt #1.

100% Client-side movement - Prediction on steroids. It's so accurate the movement matches what the server expects closely and is hitting the "Easy Hall" and "Hard Hall" triggers.

The client is not using any positioning or velocity from the server at all.

Combined with the tests on Quakeworld servers done over the last month to get very accurate client-side prediction for collision with non-map elements and adding extensions to the DarkPlaces protocol (while keeping complete compatibility) to get more information to the client for these calculations, Zircon will soon have a movement mode that should make bad ping or packet loss have a much lessened effect on gameplay.

And the modder will either have to do nothing except avoid a short list of items that can't work with it like -- totally invisible entities that aren't part of a map -- or -- avoiding very thin triggers.

More testing to do including elevators, doors, rotating doors and rotating floors like drawbridges. And see how it interacts with csqc.

January 16:

Enyo running in Zircon Beta Release 29

Saw the single player release "Enyo" and downloaded it. Then I saw the teleporter which looks very badly in Zircon/DarkPlaces. DarkPlaces does not support alpha for static entities (func_illusionary, torches, ..).

Without changing the DarkPlaces protocol or altering the server signon svc messages -- both which would break compatbility with DarkPlaces, I added support for static entities supporting alpha in Zircon. Strictly speaking, this is "impossible" to do keeping compatibility and not altering the static messages, it was achieved by sending information before the static entity communicating the extra effects.

Zircon 29 supports these for static entities:

alpha, colormod, scale, additive attribute EF_ADDITIVE, fullbright attribute EF_FULLBRIGHT

This means a func_illusionary or other static entity in Zircon can have alpha, can be color modulated, can have a scale other than 1, can have an additive effect or can be specified fullbright.

January 15:

0 Ping Movement was "completed". I could not tell if it was on or not immediately, I was a little freaked out how great it was. The prediction turns on or off seamlessly.

THEN BANG: Did a high ping test, did a high packet loss test. Everything was too fast.

Checked countless clocks --- there are many timings in DarkPlaces, for packets, time since last packet, real frame time, client frame time and a dozen others -- and all the velocity and origin sets in the prediction code -- no small number since DarkPlaces supports physics customizations like crazy (Q3, QW, Q2, Warsow, CPMA, ...).

I located the issue. DarkPlaces stores a sequence of move events for the prediction. Timing is everything and how often and where a calculation occurs is important. In this case, I need to rework the movement calculations to occur only once for each movement sequence unless the player is getting moved by an elevator (or similar) and then that requires recalculating all the simulated moves.

The type of engine coding involved in working with network, movement, physics and clocks is a rough and rocky road. The reward for walking down this road is incredible, 0 ping movement with 200 ping and high packet loss (will it do satellite internet ping 1200 too? It might?)

I engine coding because I like squaring off against complex challenges and then overcoming them.

January 14

KleskBY WIP ...

An undocumented DarkPlaces feature discovered reading the source code months ago (combined with reading the Xonotic QuakeC to see how it is used), you can get a decent blur with this just by typing it in the console:

r_glsl_postprocess_uservec1 "5 5"; 
r_glsl_postprocess_uservec1_enable 1; 
r_glsl_postprocess_uservec2 "5 1 1"; 
r_glsl_postprocess_uservec2_enable 1; 
r_glsl_postprocess 1

Will add to the rainy day todo list: expose this in a more friendly manner.

J.A.C.K. Map Editor has an update (Jan 7 2024):

Changelog

January 13

Zircon's Quakeworld player prediction collides with monsters -- Quakeworld clients do not do this -- giving Zircon a nice feel fighting monsters (in Quakeworld, you can move into a monster and you will jerkily get position corrected by the server), however it was colliding also with dead monsters. Inspired by JoeQuake's cl_deadbodyfilter, Zircon knows the dying / dead monster frames and now Zircon no longer collides with dead monster bodies or monsters in the process of dying.

/Back to ironing out upcoming new Zircon 0 Ping Multiplayer prediction mode for DarkPlaces Protocol 7.

January 12

KleskBY has a mod in the works and Zircon will be gaining a new cvar controlled shader effect in a future version as byproduct. The upcoming 0 Ping Multiplayer is getting smoothed out, during testing encountered an elevator issue that so far has resisted attempts to resolve. Swimming could use some work, it doesn't "feel quite right" somehow and seems to lack the swimming noises.

Also: During some other testing noticed that the Quakeworld collision with monsters is also colliding with them as corpses. The Quakeworld monster collision with corpses has been was resolved by using a method used in JoeQuake (cl_deadbody filter uses dying/death frames, which are hardcoded into JoeQuake and this fits with what the Quakeworld clients do, which is use a hardcoded list of monster models).

Note to self: Testing out coop at the Let's Play QW Coop server run by Freewill, noticed that the server does not host map .lit files (Zircon will try to download those, and does so on the maraakate.org coop server). No Quakeworld clients currently download the .lit files except Zircon, but it is not hard to imagine FTEQW and/or ezQuake adding such a feature in the future because it isn't hard to implement -- and the .lit files add a lot to the appearance of the maps.

Technical: Previously I stated incorrectly that I didn't see any collision against func_illusionary in DarkPlaces or Quakeworld -- those are static entities. During exploration, I created a func_wall with SOLID_NOT (not a static entity) and DarkPlaces prediction correctly walks through that, so there is something I not seeing about how brush model collision is working in DarkPlaces, so time to redouble the efforts to understand that part of the engine.

Todo: Investigate 2 oddities that jakub1 discovered.

January 9

New: Builtin +zoom alias "bind mouse2 +zoom". "showtex 2" displays the texture on-screen with picture of texture for certainty (showtex 2 displays texture pointed at including liquids, showtex 1 ignores liquids). Better rendering of the Quake 3 map mxl_school.bsp (trees no longer fullbright).

Menu->Multiplayer->Join Game loads the server list 10 times faster, although it reduces the accuracy of the ping times. Other changes in readme.

Release 27 is for a clean "before" and "after" for Zircon 0 Ping Multiplayer.

January 8: Technical Details

Zircon 0 Ping Movement (Upcoming)

For compatibility with standards, something that the authors of DarkPlaces and FTEQW strived for, which is why much stuff in "complex Quake engines" works so well today -- I looked through FTEQW to see what clc and svc codes do not interfere with FTEQW. And also picked ones that do not appear to conflict with Quake Remaster codes.

DarkPlaces has prediction and it is pretty good. But moderate packet loss can result in occasional to frequent choppy movement.

• Packet loss is something that a server operator has no control of!
• Packet loss is something that no user can control.
• Packet loss is something that no game modder can control.

So if you made something great that has multiplayer or cooperative support, there is no way to ensure that the experience is nice.

This is an effort to simply take that kind of problem off the table by giving the client a little more freedom and the server being more accommodating to client movement with limits and exceptions.

1. Server Connection

Zircon already sends availability to protocol extensions during "connect xxx.xx.xx.xx" as it sends "prespawn 524" to a DarkPlaces server instead of "prespawn", which is ignored by DarkPlaces. This number contains bit flags of supported extensions. Zircon server will read those bits, compare versus what it supports and send back svc_stufftext "//hint zircon_ext 524" indicating what extensions are shared and a Zircon client will see the zircon_ext and know how to interact with the server.

This process is inspired by the process used for Quakeworld (particularly FTEQW).  I don't know the 
super-ancient history of Quakeworld, but I believe this process originated with ZQuake -- the 
predecessor to ezQuake however it may be older than that.  I get a feel when reading Quakeworld 
source codes that this was a very early problem for Quakeworld which saw updates and new features
when it pioneered serious online play.

2. Client Movement Messages (cl_movement_ex 1 -- Zircon 0 Ping Movement)

After a Zircon Client has established a DarkPlaces Protocol 7 connection and has seen that "Zircon 0 Ping Movement" is available, it will send slightly different messages to the server, sending clc_zircon_move instead of clc_move. Origin and velocity are sent to the server.

The Zircon client can actually turn off "0 Ping Movement" and use regular DarkPlaces prediction by typing "cl_movement_ex 0" in the console. The server has the potential ability to veto the client movements and tell it to use DarkPlaces prediction (so in the future a possible cheat-client that wants to do things like teleport is unable to do so).

3. Server Read

The server will read the clc_zircon_move messages and give the client more freedom of movement, letting the client move more freely (within reason). If a client hits a teleporter or such, the server sends:

svc_zircon_warp (move sequence number) - and the server stores this sequence number, overriding client moves until clc_zircon_warp_ack (sequence number) indicating that the client for sure knows where it player is supposed to be located and is now predicting from that location.

When the client receives "svc_zircon_warp" that means movements will be overridden by the server until further notice. The client must send "clc_zircon_warp_ack" back to the server every frame until the "all clear is received" and use DarkPlaces predicted movement until the server sends the "all clear" which is "svc_zircon_warp 0".

This teleport mechanism also applies to spawning. If the server sees "svc_fixangle" which occurs for teleporting, cut-scenes and spawning, it will send out the "svc_zircon_warp" until client acknowledges it with clc_zircon_warp_ack.

4. Client During "svc_zircon_warp" period.

The client needs to use the server dictated player origin in calculated movements (DarkPlaces prediction) until the "all clear" which is "svc_zircon_warp 0".

Summary Of Zircon 0 Ping

This process has been constructed to make the client/server interaction nearly fully immune to packet loss problems and function great even with reasonably bad ping (I don't know how a satellite internet would work with it, satellite internet is like 1200 ping -- it might even work fine!)

The process should be immune to packet loss, it assumes any message could be lost.

Limitations:

1. Monsters or rockets that knock you around will not move you.
2. Windtunnels will not work.
3. Collision against entities not sent to the client is not possible. A totally invisible entity with alpha 0 or something without a model and no effects. TODO: comprehensive list.

It is probably possible to cause 1 and 2 to work by implementing the teleporter veto mechanism to force the client to use DarkPlaces prediction during those events.

Status - January 7:

KleskBY zero ping movement implementation is almost fully coded (a few hours at most). This allows entirely lag-free movement with bad ping and packet loss. After any initial quirks with a world with no moving parts is tested, will see how to reacts to doors/lifts and then rotating objects.

Update January 5:

Zircon now has improved client-side movement prediction that collides against monsters and other non-player/non-map entities (for both DarkPlaces and Quakeworld). (cl_movement_collide_models 1, default)

Neither DarkPlaces nor Quakeworld have player movement collide against monsters -- and it feels weird. For DarkPlaces or Quakeworld, I don't think a player can actually walk through a func_illusionary map object (a fake wall or such you can walk through).

This is Phase 1 of KleskBY's zero ping movement.

Technical Details Of How Zircon Enhanced Collision Works

This is mostly for DarkPlaces engine devs or a very capable modder:

Client-side the engine only knows the model bounding box. QuakeC has "setsize" which allows setting a size, this size may vary from the actual model. For best collisions: if sv_gameplayfix_setmodelrealbox 1 (sets the size to model mins/maxes) is used and in QuakeC setsize is not used for any solid object.

I may in the future have the server communicate the bounding box to client.

Here is what Zircon is doing:

• Connected to DarkPlaces server, if RENDER_STEP is received (walking monster), Zircon will collide against them. Zircon can still try to walk through scrags.
• Connected to Quakeworld server, if model matches hardcoded monster list (a Quakeworld tradition started in ezQuake), Zircon will collide against them.
• Connected to Zircon server, the Zircon server will mix in a flag RENDER_SOLID_NOT_BAKER_256 for entities with SOLID_NOT, SOLID_TRIGGER, SOLID_CORPSE. The player will not collide with these entities and will collide against all others. The name of this flag -- "RENDER_SOLID_NOT_BAKER_256" -- is intended to scream "added to DarkPlaces" and not part of the typical render flags.

Zircon to Zircon, a player will collide against monsters and not collide against func_illusionary map objects, something that to the best of my knowledge neither DarkPlaces nor Quakeworld are doing at all.

Status - January 5

KleskBY 0 ping multiplayer is being implemented, here in a hour or two I will do a Stage 1 test against Quakeworld coop to see if my client-side prediction collision is good against monsters and the like. I noticed 1 issue in recent Zircon I need to tweak (*).

Meanwhile: I was examining Danil's Mod and looked at this video, I asked the author the map name and tried it out to see how it looks in Zircon. This looks cool, but I see DarkPlaces vs. Q3 rendering differences, like the trees look fullbright and a few other discrepenancies in shaders.

Issue: Super-speed server-side chunk downloads does not kick in automatically due to an oversight.

Status - January 4:

KleskBY's zero ping movement is in process of being added to Zircon. DarkPlaces does not send enough information to the client for this type of movement to be implemented, so Zircon is reworking the networking to accomodate this while keeping DarkPlaces compatibility.

For the last month, most Zircon modifications have been network whether adding Quakespasm protocol 999 or enhanced FTE extensions for Quakeworld or making downloads super fast to get immersion and scale up for this.

The idea behind KleskyBY's prototype is that regardless of ping or packet loss, the player can run around with 0 ping and the server accomodates this.

Pictured: KleskBY and I both have 180 ping + moderate packet loss, it does not affect us at all. POV: KleskBY.

In order for this to work, the client has know enough about the world. For instance, a knife stuck in the wall is not solid to the player because that will be added to inventory. How does the client know that particular entity shouldn't be "blocking"?

func_illusionary entities need to work. The player should not get blocked by rockets or enforcer lasers. There can be invisible objects that need collision that normally do not get sent to the client (alpha 0 entity or unusual entity with no model?). Pusher objects, rotating object, func_train may need extra consideration.

And, despite the best planning, sometimes the client will be "wrong" about a movement. Need to plan out when and how to notify the client that a movement needs rolled back.

Update - January 2

Zircon now has server side support for chunked downloads (🏓 typically 200 times FASTER 🏓) than DarkPlaces map download speed with default settings). Zircon also supports downloading Quake 1 external colored light files (.LIT) when connected to a Quakeworld server.

Details: Rewriting network code is hard. Especially, network code that does something that wasn't planned for by a large body of existing network code. The chunked downloads support is an extension -- a DarkPlaces client without the capability will get the download the "old way". (More below the pic)

During some testing, I played HellChepsout and the map looked wrong. I remembered the map being very vibrant. Then I realized that the Quakeworld download process for maps does not do the .LIT (Quake 1 colored light file). Zircon will now attempt to download the maps/hellchepsout.lit file for any missing map download.

Details of Chunked Downloads/Implementation.

I had to write a communications side "channel" (out-of-band network communications) on both the client and server side to make this happen. When it was done, it seamlessly integrated in DarkPlaces using the existing download process that DarkPlaces uses (which is quite different than the download process DarkPlaces uses for Quakeworld downloads) with all the extra steps and differences in the mechanics fit on-top of the existing download process. No Frankensteins were created during this process!

A Lab Report About Upcoming Lab Reports

2023 started with Zircon slowly clawing away at DarkPlaces Classic user interface issues and ended with Zircon constructing new complex capabilities on top of DarkPlaces Beta, after rapidly smoothing out quirks in the codebase.

2024 has unfinished futuristic business, high in quantity and high in games to play. Most Lab Reports will have a game to download related to the topic.

Anticpated 2024 Lab Reports: In No Particular Order

1. It's Actually Like Being There!

2. A Very Nuclear Explosion (Based on Insight From iBloodHeuer)

3. Why are there skeletons in my closet?

4. How Very Stylish: It's Quake with Hats!

5. How can Zircon Play That Mod On The Wrong Computer?

6. The Terror of The Red Walls!

7. Why Can't I Get Out Of This Room I Already Left?

8. The Machine Inside The Game Is Also A Machine

9. Your Move, Creep!

10. The Deal of The Century

Thank you to everyone who has helped this year! I remember. I was not much familiar with this site and Mirrorman95, RenegadeC and Xage greeted me. Elsewhere, I quickly ran into Jakub1 who has relentlessly beta tested ever since. Many thanks to everyone else who has helped report issues and support. I think over 95% of any issues ever reported were addressed.