Search the Community

(I apologize for the odd poll question layout. I wasn't able to add five yes-no questions, because polls are limited to three questions.) Hi everyone, I've recently been working on some patches for issues that I've read about from players on the TDM and TTLG forums — and Discord. My goal is to make it as easy as possible for players, especially new players and those who need usability/accessibility options, to find what they need in order to have a better TDM experience. I've already written the GUI and game engine code for these settings, which I've been using in my personal build. The reason for this poll and discussion is to both guide the finalization of my work and collect data to help inform the dev team. Which patches I submit depend on the outcome of this poll, discussion, and what the dev team agrees to accept. Once decided, I can coordinate with the dev team. I've attached screenshots of what the new settings menu would look like if all of the settings are accepted. Below, I have detailed each menu setting, so you can have an easier time understanding each one. Very important to keep in mind: None of these settings change TDM default behavior. They are all opt-in. If you are already happy with the behavior of 2.10, 2.11, etc. and these menu settings are accepted, nothing will change for you. Rename "Always Run" to "Run Mode" with options "None, Always, Toggle" After 2.11 was released, @i30817 requested that "toggle run" be added to the settings menu. Its cvar is already in TDM as "in_toggleRun" (same as Doom 3). I propose renaming the "Always Run" setting to "Run Mode" with options: "None", "Always", and "Toggle". None = in_alwaysRun 0; in_toggleRun 0 Always = in_alwaysRun 1; in_toggleRun 0 Toggle = in_alwaysRun 0; in_toggleRun 1 Show Blackjack Helper @Wellingtoncrab suggested that the new blackjack helper be added to the settings menu. Its cvar was added to 2.11 as "tdm_blackjack_indicate". More info: It's the new blackjack helper added to 2.11. When the game detects that the blackjack can be used for a successful hit or KO, the blackjack will rise slightly. I propose a "Yes/No" setting for this. Slider for "View: Head Bob" @ChronA requested a way to disable head bobbing, because a viewer watching him play was having severe motion sickness. Also, there was a bug in TDM that made setting the head bob in the console not stick after loading a saved game. (Even with 2.11, if a mission overrides the "tdm_player_thief.def" file and sets "pm_bobroll", "pm_bobpitch", "pm_bobup", and other cvars, it will override player preferences.) As far back as 2008, players have had trouble setting head bob. Another one from 2018. At the end of 2022, @Shadowex3 registered just to voice the need for a way to control head bob. I propose that a slider be added to adjust the amount of head bob. This would use a new "pm_headbob_mod" cvar with a value between 0.0 and 1.0 (default 1.0, no change). The "pm_headbob_mod" would be a multiplier for "pm_bobroll", "pm_bobpitch", and "pm_bobup". The advantage to this approach is that missions like Volta 2 and Hazard Pay would not need to adjust their "tdm_player_thief.def" files for head bob to work properly. And, the player can still adjust "pm_bobroll", "pm_bobpitch", and "pm_bobup" as they like. Slider for "View: Mantle Roll" This is similar to head bob for those who are sensitive to motion. Its cvar was added to 2.11 as "pm_mantle_roll_mod". A Thief player on Discord said, "2.11 will have a cvar to tune down the mantling animation at last." I propose that a slider be added for "pm_mantle_roll_mod". Auto-Search Bodies @Zaratul requested the "auto-search bodies" feature from Thief 1 & 2. Its cvar was added to 2.12 dev16783-10307 as "tdm_autosearch_bodies". I did a poll on the a Thief Discord server and roughly 20% of players there use the Thief auto-search bodies feature. I propose a menu setting for this, so that players coming from Thief 1 & 2 can easily find it.

Awesome! Post is up! https://forums.thedarkmod.com/index.php?/topic/22200-beta-testing-the-house-of-delisle/#comment-487365 Thanks!

So many misconceptions here, I guess I should say something. Yes, 32-bit is perfectly OK in general. There is limitation of 2GB of memory in 32-bit mode. And that's a hard limit: a process cannot use more than 2 GB even if you have 16GB RAM physically installed and 32GB pagefile for swap. When trying to allocate more, process will simply crash on 32-bit platform. If your workload fits well into this limit, then there is no harm from it. If it does not, then it becomes an unavoidable blocker. If you have a very big map, you simply cannot dmap it on 32-bit, but if your map is small/medium size, it does not matter for you if executable is 32-bit or 64-bit. Speaking of variables in code and 64-bit mode switch, some of them stay the same size, but some of then switch from 32-bit to 64-bit. All the pointers inevitably become two times larger, and all sizes in STL types do the same. Also, 64-bit process has more overhead for heap allocations. It means that the process consumes more memory in 64-bit, and consequently can work slower since the cache size does not change. You can probably see increased memory consumption yourself: take a big brushy map, and dmap it both in 32-bit and in 64-bit modes, looking at memory consumption in process explorer. While this point is not very strong for native applications and games, it is a major problem for managed languages like Java, where pointers are everywhere. For instance, modern JVM still uses 32-bit pointers internally, as long as you don't request for more than 32 GB of heap memory. They say it is 30% faster 64-bit mode does not offer any new capabilities except for more-than-2GB memory. There are many other differences between 32-bit and 64-bit, but they are all about performance. 64-bit mode does not offer better precision. Floating point numbers are 32-bit and 64-bit both on 32-bit and 64-bit, working with same performance. In fact, 32-bit mode also offers 80-bit floating point numbers. Moreover, before something like TDM 2.06, this awful 80-bit arithmetic was used everywhere for intermediate values when computing complicated expressions. We got many precision problems when we disabled it, and we are still fixing them (e.g. there is a bunch of such fixes for dmap in upcoming 2.08). Now 80-bit floats are disabled both for 32-bit and 64-bit builds of TDM. So it turns out that 32-bit mode offers more floating point precision, although these 80-bit numbers cannot be used universally in Visual Studio anyway. (assembly geeks can also notice that 32-bit mode without 80-bit arithmetic has a tiny bit of overhead for passing floats into functions, due to old calling convention) Speaking of integers, both 32-bit and 64-bit modes offer integers of size up to 64-bit. The 64-bit integers are emulated on 32-bit platform and are pretty slow, but TDM never uses them. 64-bit GCC also offers builtin 128-bit integer type, but Visual Studio does not, and so TDM does not use them. Anyway, I can hardly imagine what we could use them for (assembly geeks can also notice that using 32-bit integers in 64-bit mode occasionally have a bit of overhead, due to some additional extending instructions) And of course bitness of executable does not affect GPU The main performance advantage of 64-bit mode is having 2x more registers in CPU: both GP registers and SSE/AVX registers. When compiler goes out of registers in a tight loop, it has to "spill" into memory. This memory is surely in L1 cache, but L1 cache accesses are still slower than registers, plus more dependencies between instructions. In TDM, there are many computationally heavy routines done in SSE/AVX (aka SIMD), which we had to rewrite for 64-bit mode. Because the original implementation by ID was written in inline assembly, and 1) you cannot use 32-bit assembly on 64-bit build, and 2) VC does not allow inline assembly at all in 64-bit build. So there are two completely different implementations of SIMD routines now: the first one (by ID) is used in 32-bit mode, and the second one (by us) is used in 64-bit mode. As far as I remember, the second one is often pretty low on registers, so if we start using it in 32-bit mode, it will work a bit slower. Some of the new routines written by us are already used in 32-bit mode, e.g. AVX code. Quite unlikely I would say. Only that 32-bit build will start working slower than 64-bit build. People with low-end machines should use 64-bit build, so it's not a big problem. As you see, performance difference is a very complicated question. Out of all I wrote, I think the most difference comes from: 64-bit build wastes more memory (pointers, heap overhead) 64-bit build has more registers 64-bit and 32-bit builds have different SIMD implementations To be honest, no idea which build wins now.

No, not really, have only seen him on the forums many years ago. He deserves a lot of credit for providing the SVN infrastructure in the beginnings of the project, it's been only later when we transferred this to a hosted server. Memory is blurry, but I think my time working on TDM and his don't overlap that much - I had been getting more active, and he pulled back a bit. He bootstrapped quite a few important systems, IIRC he's been working on light gem and the first Stim/Response and Inventory implementations. From what I recall, he gave the project an organisational backbone in the technical department which is crucial to keep things together. Folks like Spring and NH who have joined long before me could give more insights, I guess. (Looking at my join date makes me feel old either way. From TDM's current view point, the year 2006 seems like right at the beginning, but actually the mod had already been existing for two years by that time I joined. With the first release in 2009, 2006 is rather in the middle. Heck, I haven't touched the mod code for at least 10 years - and I can still remember a few things, which is a testament of how much it occupied my thoughts back then).

This happens during game launch and not mission startup, if mission startup means entering the game world. This happens before the main menu is displayed for the first time. I've attached a series of screenshots. Does FBO code run before the main menu displays for the first time? I tried these settings and did not see any difference in console output. To me, it looks like that first frame is showing garbage memory - whatever happens to be in memory at the time. In other words, it seems that the "qglRenderbufferStorageMultisample()" function is not clearing/initializing the buffers before rendering. I'm not a graphics programmer, so I don't know. That's how it seems to me. Maybe an updated Glad library would have a fix? I tried running apitrace. Here's some output: apitrace: loaded into ./thedarkmod.x64 apitrace: redirecting dlopen("libGL.so.1", 0x1) from ./thedarkmod.x64 apitrace: tracing to application.trace apitrace: redirecting dlopen("libGL.so.1", 0x102) from ./thedarkmod.x64 apitrace: warning: unknown function "glRenderbufferStorageMultisampleAdvancedAMD" apitrace: warning: unknown function "glNamedRenderbufferStorageMultisampleAdvancedAMD" apitrace: warning: unknown function "glPolygonOffsetClamp" apitrace: warning: unknown function "glEGLImageTargetTexStorageEXT" apitrace: warning: unknown function "glEGLImageTargetTextureStorageEXT" apitrace: warning: unknown function "glGetUnsignedBytevEXT" apitrace: warning: unknown function "glGetUnsignedBytei_vEXT" apitrace: warning: unknown function "glDeleteMemoryObjectsEXT" apitrace: warning: unknown function "glIsMemoryObjectEXT" apitrace: warning: unknown function "glCreateMemoryObjectsEXT" apitrace: warning: unknown function "glMemoryObjectParameterivEXT" apitrace: warning: unknown function "glGetMemoryObjectParameterivEXT" apitrace: warning: unknown function "glTexStorageMem2DEXT" apitrace: warning: unknown function "glTexStorageMem2DMultisampleEXT" apitrace: warning: unknown function "glTexStorageMem3DEXT" apitrace: warning: unknown function "glTexStorageMem3DMultisampleEXT" apitrace: warning: unknown function "glBufferStorageMemEXT" apitrace: warning: unknown function "glTextureStorageMem2DEXT" apitrace: warning: unknown function "glTextureStorageMem2DMultisampleEXT" apitrace: warning: unknown function "glTextureStorageMem3DEXT" apitrace: warning: unknown function "glTextureStorageMem3DMultisampleEXT" apitrace: warning: unknown function "glNamedBufferStorageMemEXT" apitrace: warning: unknown function "glTexStorageMem1DEXT" apitrace: warning: unknown function "glTextureStorageMem1DEXT" apitrace: warning: unknown function "glImportMemoryFdEXT" apitrace: warning: unknown function "glGetUnsignedBytevEXT" apitrace: warning: unknown function "glGetUnsignedBytei_vEXT" apitrace: warning: unknown function "glGenSemaphoresEXT" apitrace: warning: unknown function "glDeleteSemaphoresEXT" apitrace: warning: unknown function "glIsSemaphoreEXT" apitrace: warning: unknown function "glSemaphoreParameterui64vEXT" apitrace: warning: unknown function "glGetSemaphoreParameterui64vEXT" apitrace: warning: unknown function "glWaitSemaphoreEXT" apitrace: warning: unknown function "glSignalSemaphoreEXT" apitrace: warning: unknown function "glImportSemaphoreFdEXT" apitrace: warning: unknown function "glWindowRectanglesEXT" apitrace: warning: unknown function "glMaxShaderCompilerThreadsKHR" apitrace: warning: unknown function "glAlphaToCoverageDitherControlNV"

I worked on this today, but I haven't been able to track down the problem yet. I found that the previous message or info about the previous message is not cleared from memory completely. Interesting results happen if: Trigger message. Wait for message to fade out. Save game. Edit "tdm_message.gui" and change "rect" to something else, such as "100,100,206,160". Load game. Trigger next message. (The previous message parchment will blink for a single frame at the previous "tdm_message.gui" "rect" value. The next message parchment will fade in at the current "rect" value.) (See attached screenshot.) It seems the messages are not being removed from memory after fade out. @duzenko @Obsttorte Any ideas? Are scripts completely controlling this feature? If not, where in the game code is it handled? The following shows the code change made to "guis/tdm_message.gui" for this example to expose part of the issue. // A GUI for showing little messages to the player, used f.i. by the training map: windowDef parchment { - rect 0,-10,206,160 + rect 100,100,206,160 nocursor 1 background "guis/assets/mainmenu/oldparchment_backdrop3" matcolor 0,0,0,0

I would not yet regard gpt as general intelligence but it certainly has aspects of it, and more will emerge in this model or the next I'm sure. Exciting and scary times! Meanwhile another idea occurred to me regarding continuity. I'm going to do a test where I create a conversation with just my fiction rules and possibly the plot summary, etc. then share it publicly. I can then start a new conversation for the story proper and refer it to that shared url every few messages to refresh its memory of the core essentials. I'm not sure the plot is essential actually because even if it deviates from the original plot idea, it could still work. What needs to be constant is the rules, and significant story progress (eg, Mr Johnson died in Chapter 7 so no, he can't be baking bread in Chapter 12!)

This looks like a very promising mission, unfortunately I also get a segfault (yes, on linux) just as the "That's got to be Clerwick" line finishes and before the relevant objective is updated: WARNING:civilian_20 (-7040.11 1891.67 -339.75) can't sit: too far from sitting location civilian_20_path_1 (-8060 12 -348) Resizing dynamic VertexCache: index 4096 kb -> 8192 kb, vertex 4096 kb -> 16384 kb Resizing dynamic VertexCache: index 8192 kb -> 16384 kb, vertex 8192 kb -> 16384 kb CLERWICK LOCATED! EVACUATING SHOEMAKER PLAZA AND INITIATING THE COURIER! WARNING:GetPointOutsideObstacles: civilian_15 - no valid point found WARNING:GetPointOutsideObstacles: civilian_15 - no valid point found NEW OBJECTIVE signal caught: Segmentation fault si_code 128 Trying to exit gracefully.. --------- Game Map Shutdown ---------- ModelGenerator memory: 86 LOD entries with 144 users using 43346 bytes, memory saved: 55552 bytes. WARNING:idClipModel::FreeTraceModel: tried to free uncached trace model (index=0) --------- Game Map Shutdown done ----- Shutting down sound hardware idRenderSystem::Shutdown() ...shutting down QGL I18NLocal: Shutdown. ------------ Game Shutdown ----------- ModelGenerator memory: No LOD entries. Shutdown event system -------------------------------------- Sys_Error: ERROR: pthread_join failed shutdown terminal support About to exit with code 1 In another, maybe unrelated quirk: if I reload 5-6 times, even in different locations, FPS starts to drop dramatically until the map is no longer playable. Exiting/restarting TDM and realoading fixes this. I've only seen such behaviour in the past when I used noclip at some point of the map, which however I have not done here. Any clues? EDIT: I restarted the map and I was able to get past that point, so it was probably a transient glitch. Already *very* impressed by the mission BTW...

I guess the difference is because of long-standing issue was with stencil shadows: https://bugs.thedarkmod.com/view.php?id=5851 Other then that, multisampling is a big waste of memory bandwidth, so antialiasing will never become totally free in TDM.

id Studio did a poor job in defining its categorization of variable nomenclature, so in subsequent documentation and discussions there are divergent views (or just slop). In my series, I had to choose something, and went with what I thought would be clearest for the GUI programmer: Properties, which are either Registers (like true variables) Non-registers (like tags) User Variables (also true variables) I see that your view is more along these lines (which perhaps reflects C++ internals?): Flags (like my non-registers) Properties, which are either Built-in (like my registers) Custom (like user Variables) Also, elsewhere, you refer to "registers" as temporaries. I am willing to consider that there could be temporary registers during expression evaluation, but by my interpretation those would be in addition to named property registers. I'm not sure where to go next with this particular aspect, but at least can state it.

TDM was never meant to be fully realistic, it would become impossibly difficult were that the case. None the less I still find myself wishing more could be done to make AI feel less like AI, especially when handling hostile encounters (usually the player). While like most aspects this could never be truly perfect, one area feels like it could be noticeably improved: Giving AI some form of long term memory, rather than just one alert level which goes back to zero after a short time. Here is the reason why I'm saying this: Walk inside your average heavily guarded mansion and step into the bright lights, making all the guards clearly see you and chase after you to attack. Once you've had enough fun repeating the process, hide somewhere and give everyone enough time to cool down. At the end of it all, hide somewhere in the shadows where you can barely be seen and let a guard walk past you: The guard will just say "is there something over there", at best waiting a few seconds and saying "probably just the shadows" before walking away... the same man that may have chased after you for 30 minutes and should by any logic know an intruder is still in the house, I mean come on Now I'm aware we have a basic persistence system: If I remember correctly an AI that's encountered the player and was alerted enough to draw their sword will have its acuity permanently increased by a slight amount. This however makes no noticeable difference as the AI behaves mostly the same. They'll keep telling fellow AI an intruder is in the area, this definitely helps but it's only a dialogue change not accompanied by noticeable modifications in behavior as you'd expect. Obviously massive modifications might be hard to do now without upsetting existing players since it would make everything harder. As such any such attempt would likely be an experiment and, if successful, a new menu option for the difficulty settings. Still I felt like suggesting my imagined solution just in case there's a point in considering tackling this. My idea: Replace the one-time bump in acuity with a paranoia level independent from the alert level... think of the existing alert system as short-term alert and the new one as long-term alert. The standard alert level of guards is slowly added to their paranoia level, thus the more time a guard spends being alert and the higher that alert is the more fear increases. Paranoia level may be allowed to decrease over time but at a far slower rate than the alert level: If an alert guard will typically take 3 minutes to fully calm down after losing track of the player, the paranoia level should take at least 30 if not 60 (real life) minutes to fully go down to minimum... even then it shouldn't drop below a certain degree after that point was reached, for instance just 50% of the maximum paranoia. This long-term fear level would have several effects on an AI as they patrol on their normal route... the ones I've thought about are: Increased acuity as they'll be more alert. This system would replace the existing simple bump we have in that regard, with a more fluid effect and also stronger effect. Increased playing of voices and idle animations: Due to being afraid the guard may talk to themselves or others a lot more frequently and babble excessively. Walking could be replaced by running for a while, even on path nodes that don't have the run flag. The AI would still patrol that same route just at a faster pace. As a map feature set by FM's: Some path nodes can be filtered by fear level, may already be possible with the simple system but I never tried it. An AI paranoid the player is still around but having resumed their normal patrol route may choose to patrol a more sensitive area it normally wasn't going to, which would be a fair way of punishing the player for being seen by having that AI start guarding a sensitive location from then on. If the paranoia level is allowed to slowly decrease, the guard may decide to go back on this decision... the player could then do something else for 15 minutes around the map till the guard abandons the paranoid patrol route. Here's an idea I like: AI randomly getting scared for no reason, thinking they see the player in every shadow even when there's nothing there. A scared guard normally walking on their patrol route would randomly become alert for no reason, typically when walking through a dark area, causing them to draw their sword or randomly run around for a second. The problem here is this effect would be random: Imagine you're hiding accordingly but a guard randomly freaks out and bumps into you, most players would find this unfair.

I added a cvar r_volumetricEnable. Note that you should run reloadModels after changing this cvar, just like you need when you change r_shadows. It seems that you don't like shadow maps in general These are the typical pixelization artefacts which I also hate in shadow maps. When there are too many shadow-mapping lights being rendered, some lights are automatically switched to lower resolution, which makes the issue even worse. And one way to somewhat mask this problem is to use soft shadow maps... which are very expensive in TDM right now. Ideally, we should render shadow map with low resolution, then render stencil shadows as usual and use them for shadowing, but use shadow maps for volumetrics. But I'm not sure having both implementations of shadows fits the renderer architecture, unfortunately. This is not noticeable in a still screenshot, but I found this location and I see the problem. I have found a similar case at 3986.7 2463.3 -222.85. I guess I should look into it. It looks like color banding, because volumetrics are computed in 8-bit FBO. I knew about this problem, but it did not look so bad on testmap, and I thought maybe I could ignore it. But in Hazard Pay, there are many places where color banding is strong. I can "simply bump" FBO to 16 bits, doubling memory bandwidth, or adding dithering... I wonder if there is another option. When I flew around this map, the brightness of security cameras looked over-the-top for me too. But now that I look at the map, it seems that volumetric_dust is set to default here. @Dragofer, maybe we should tone down security cameras by default?... Of course, this issue is greatly magnified by gamma-incorrect rendering pipeline, so when several light sources overlap, their brightness gets much larger than just their sum. Not fixable right now I can't understand how a game can be blamed for increased power consumption. Loud noise... probably means that this particular piece of hardware has bad fans. But I agree that this is a sign of greater performance cost in general, which can lower FPS for you in other cases, or for other people. I guess you need to do reloadModels, since this cvar changed shadows model of some lights. It looks like your GPU increases power consumption when you increase memory bandwidth. Computations don't matter that much. It's no wonder you see no performance drop: you have 60 FPS cap. Given that now volumetrics are rendered at half-resolution, number of samples per pixel does not affect performance so badly. Maybe I should just bump them to e.g. 24, I don't know.

I still don't understand where is the problem. What else you can try: r_softShadowsMipmaps 0: the new optimization for soft stencil shadows uses more memory, and in some cases might even be slower. r_volumetricForceShadowMaps 0: this flag is for the change where lights with volumetrics are switched to shadow maps even if you have stencil shadows selected. r_shadowMapSize 512: this means using 2x lower resolution for shadow maps. Shadow maps take quite a lot of memory (144 MB at defaults) and fillrate, so lowering it down might help.

That's also an option but it has some drawbacks: The mapper needs to extract and edit the textures in an image editor... we can assume they have Photoshop and know how to change the hue, but many won't bother going that far if it's not a readily available option. Also keep in mind the texture contains multiple colors, for instance you need to edit only the green vest without changing the hue on brown leather, this can be trickier to do... with a texture map it will automatically change only the colored part. It also requires redistributing the textures and increasing the FM size, probably not by a lot but if you want to keep it light and minimize extra assets it can matter. With this approach you can have the same character in multiple colors without loading a new texture in memory for each, a commoner with a red tunic and one with a blue one would use the same textures in memory. Plus you can freely change and preview the color in DR, much easier than having to edit textures. I'll probably try this just for the city watch as a test first then share some screenshots: Shouldn't be too much work for just one character to see what results I get. If that works and is considered okay, I'll do it just for builders nobles and some commoners... should only be done for those few characters that have a colored fabric vest.

https://www.phoronix.com/news/Blender-Ray-Tracing-December So apparently hardware ray-tracing is landing for Intel GPUs in Blender 3.6, which is in Beta now. The release notes page says that this feature made it in. I'm very surprised and disappointed that nobody has demonstrated the performance uplift this brings yet on e.g. the A770-16GB, since Intel's competitors in the market are currently offering "crap ala dog-shit GPUs" at mainstream prices. Before, the A770 was almost as fast as a RTX3060. Maybe now, with proper hardware RT support the A770 will be able to smash the RTX3060 at a lower price while having more memory too, because if the performance uplift is anything like going from Cuda to Optix, it will be epic.

Thanks, I can also recommend gog galaxy. The idea of the custom tags is really nice, I'll have to try this out too!

The *DOOM3* shaders are ARB2 ('cause of old GeForce support) carmack plan + arb2 - OpenGL / OpenGL: Advanced Coding - Khronos Forums

YOU TAFFERS! Happy new year! Deadeye is a small/tiny assassination mission recommended for TDM newcomers and veterans alike. Briefing: Download link: https://drive.google.com/file/d/1JWslTAC3Ai9kkl1VCvJb14ZlVxWMmkUj/view?usp=sharing Enjoy! EDIT: I promised to someone to write something about the design of the map. This is in spoiler tags below. Possibly useful to new mappers or players interested in developer commentary.

Keep in mind also that mission size, and complexity have increased dramatically since the beginning. For a lot of veteran mappers, it can take over a year to get a map made and released. The last dozen missions have for the most part been pretty massive, with new textures, sounds, scripts, models etc. We seem to be long past the point of people loading up the tools, and banging out a mission in a few weeks that's very barebones. We still do see some of those, but I noticed in the beta mapper forums and on Discord, that mappers seem to make these maps, but don't release them, and instead use the knowledge gained to make something even better. Could just be bias on my part scrolling through the forums and discord server though.

Yes, and speaking of memory, yours is better than mine. But in fairness, the whole point of the contest is that we're coming up on the 20th anniversary of the game!

The Unreal Engine 2.x, at least the rendering portion of it, was ripped out. The replacement was called Flesh, and IIRC the guy that implemented it was probably an external contractor who did his job and left, but noone asked him to leave any documentation on it, so he didn't. They also used the first implementation of Havok for physics, literally like version 1.0, which was buggy as hell, and they couldn't get water and rope arrows to work. Memory constraints were an original Xbox thing, but it's hard to tell how PCs from that era would handle bigger levels or no loading zones.