Alright, I went afk for a long time after the post there, I'll add a general presentation and some screenshots. However, this isn't really a news post, it's more of an official support/feature request/error report hub. Not sure if I can make it fit.

Good point, but with the gui as-is there is no way to find the appdata directory. At least the steam directory users can (possibly) find it through the tree.

Also, if the program can find the steam directory (which itself can be challenging, I have it in d:\steam, but it could have been any random directory), then the gui can do a recursive search for a directory named 'quake live'.

1. Yeah that means I didn't reserve enough address space up front. I'll have to find which allocator instance that was for though, as this class is used pretty much everywhere. Could you please tell me if you were running an x86 or x64 build?

2. Should? Maybe! :-) It's a good idea to make the folder selection easier for some QL users, I agree. I'll have to see what can be done for that (now that there is a Steam version too).

As a side note, SHGetSpecialFolderPath is a C API, not C++. Nothing prevents me from implementing the necessary code in the C++ library and exporting an additional function in the shared library (e.g. udtGetQuakeLivePath) in the Windows version. ;-)

Finally, I'm not quite sure why anyone would load that many demos into the application in the first place (except stress-testing). UDT never was a demo management program and I don't want it to be one either. It exists to facilitate demo cutting and gives you information useful for that specific purpose.

I'm currently looking into another pretty important issue:
If the parse job of a batch demo fails, everything gets discarded and sometimes without any error/warning message. So I will work on that as a 2-step process:
1. Make sure I can always report back what went wrong with what demo.
2. Write the individual error codes to an array of "return values" so that the data of all demos properly parsed can be kept and further processed by the GUI.

I don't know how long it'll take for 2) to be fully and robustly implemented but you can expect a new release with all the other improvements very soon either way.

Any news for a 2DDV that allows to play running games as they are being recorded?

Currently, it loads the demo just fine, but only up to the point where the match was when you loaded the demo, even though by the time the 2DDV gets to that point it has kept recording. It should continue to playback after that point but it doesn't.

I currently don't have any plans for the 2D demo viewer. That project is still based on the old code base so a lot of code needs to be re-written anyway (not as dramatic an amount of work as it sounds).

The last roadblock encountered was that Memento_Mori asked Sponge in person at QuakeCon for help with a very specific feature to make this possible in a much better way but that was turned down.

To be more detailed about the problem:
Quake Live uses buffered file writes (the fwrite libc function) to write to the demo file, so it basically waits for the I/O buffer to fill up to write (flush) to disk. Depending on implementation and hard drive specs, the buffer can be 4 KB big or bigger. Maybe this is bearable, I don't really know, we could still try to measure the latency for demos of different game modes on different machines (it will be higher for 1v1 demos than TDM demos, for instance).

I personally would love to have a 2D demo viewer version to be usable by streamers in live games for TDM/CTF. If not even for showing the viz, at least so that streamers could see some useful info like who took the last regen/quad/RA and stuff like that.

I'll be honest, I always thought the medals were really useless for finding anything of value, but you're having me reconsider that because of the "Mid Air" medal. Finding new air rockets/grenades might be nice. :-)

Sure thing! I'm actually required to publish the sources (GPL v2 license) but of course that kind of stuff didn't prevent the CPMA dev team from never releasing their stuff...

As for UDT, all the real work is in the library, which is fairly straight-forward C++03 code with no dependencies (self-contained) and has a simple C(-ish) interface. You can compile a shared library with any half-decent C++03 compiler and use it from your favorite language (in my case the Windows GUI is written in C#).

It would be nice if you could help me understand what the end-game of this request actually is.
I can see 2 reasons for wanting text export and they imply different things for the UDT code base:
1. You convert Quake demos to JSON/XML, modify the JSON/XML files, convert back to Quake demos.
2. You convert Quake demos to JSON/XML and then parse the JSON/XML files to extract information with your own tool. In this case I could store the data in a way that makes parsing much simpler.

Now, I'm still having 2 problems with this.

1. Using text formats for stuff like this is a waste.
It just adds complexity everywhere for no other reason than preserving one developer's time. Not that I'm 100% against it because not everyone is proficient in a language like C, but I'm definitely not sold on the idea that it is the best way to handle whatever problem it is you're trying to solve.

2. What I don't understand is this:
If what you want/need is what QLDT already does, why not just use QLDT for outputting a text file?

Please don't take this as a big NO but I think that if you explain what you're trying to do it would be much simpler for me to implement something helpful.

I downloaded more than 100 GB of demos from different sources with tons of duplicates and unsorted archives. And I want to create simple and clean database for webpage or something else.
Sorted by tourneys, stages, maps, like UQLDDC, but with easy quick search by all parsed info, not only base fixed parameters.

So, I don't need to convert back to Quake demos. And yes, I can use QLDT, but:
1. QLDT's export is partially broken. Any XML-file breaks in the middle or beginning. Or it just for me...
2. Your tool looks more powerful
3. You are available for discussion and resolving any problems

Maybe it should be a standalone converter, or steal a part of source code from QLDT.
I don't know how to do more easy. And don't do it just for me, if so hard. Just accept my vote in future. It is not so important now.

So here are the 2 most important questions:
1. In what format do you store that data? An SQL database?
2. What programming languages do you know and which did you intend to use to process the data and save it to your database?

From there, we can start to formulate a plan of attack.

Also, if you are an IRC user, you can /query myT on QuakeNet. Else, you can send me private messages on ESR to discuss this further.

And don't do it just for me, if so hard.

It's not hard. I just want to make sure we tackle problems the right way. ;-)

Here's how I would go about this:
I create a new command-line tool that leverages the existing analyzers to extract information from an input demo. The application then outputs a JSON file that isn't a text version of the original demo but a file with just the data you want for your own database (map name, game mode, player list, deaths, chat history, matches, end scores, etc). That would be the simplest way to go at this and would reduce the amount of work needed on your side.

I think this would be a good start. If things go well on your side, I can later add new analyzers to extract even more data from the demos. Sounds good?

I'm also really interested in an up-to-date demo exporter - QLDT breaks my demos for some reason, and I don't know any programming whatsoever so I can't fix it. I'm working on two projects right now that absolutely require precise modification of the demos, down to individual snapshots.

I could do it with QLDT, since its format is totally acceptable, but as I said it isn't working with my Defrag demos right now. It used to, but not any more. Could be HK's DFWC anticheat that everyone and their dog is running right now, but even if it is that doesn't exactly help me.

I use nodejs and mongodb. Maybe in this case more correct will be avoid the saving to file and just parse strings from tool's stdout? After that we can do whatever we want - save to file or database.

I am much more worried about versions support. I found a lot of extensions, starting from dm3 and dm_48 of 2000's, continuing dm_66 and dm_67 of 2001-2004's, ending dm68 of original Quake and its different versions and various mods - OSP, CPMA, Defrag... And QL demos has a differences too.

For example, some old demos has not the time stamp of the match. It is very sadly, cause it should be setup manualy. And of course we need to split merged demos and clean them before parsing...

tl;dr: The repository linked above is the original version in which I believe the author has since corrected some bugs in the huffman C wrapper about a week ago. The script dumps demos to JSON. If you do some quick modifications you can very easily get it to dump entire directories at a time.

Here is the format of the output of qldemosummary.py: http://pastebin.com/waDM25XS
The keys in the players object are standard playerinfo stuff (https://github.com/id-Software/Quake-III-Aren...ers.c#L874), but I think some are specific to Quake Live such as su, so, rp, which means subscriber (pro acct), spec_only, and readytoplay. For the dm_90 format, the QL specific things are ws (secondary weapon), p (I forget what this is), wp (primary weapon)

(Useless background info: Over a year ago, I forked this version for something I was working on and added the ability to dump entire directories of demos at a time & some other small things. But there was a bug in the original huffman C wrapper which prevented the extraction of chat messages and score info when trying to sequentially parse a large number of demos at a time (500-1000 or so demos at a time, I forget, it's been a while) so I completely removed that part. From what I remember, python would run out of memory on Windows, but during my tests it was fine on Linux)

I suspect I understand what you mean but I want it confirmed from you. You like when the selected list view item(s) have the blue background color when the list view is in focus and you don't like that the selected item(s) have a light gray background color when the list view is out of focus. Am I correct?
In other words, if you click the item, the list view will get focus and the row will be blue and if you then click a tab on the right, the list view will lose focus and the item will be gray. That's what annoys you, right?

How you wanna change the Cut by Award Tab ? :)

The plan isn't to change it but to replace it with something better. I won't go into details because I'm doing a lot of changes to the codebase right now that need to be done before I even do this.

You load a complete folder / player selection via Dropdown menue / Cut all frags from all Demos what is inside this Folder from 1 player :)

Ah I think I understand now. A way to apply all filters at once on all demos selected. Yes, I thought about doing that and I believe I know a good way to do this.

I'm intentionally not giving too many details now because I don't want to promise that my experiment is going to be successful in a set number of days. I'm working on it. All I can ask you is to be a bit more patient. :-)

confirmed!correct , a blue background is better to see as the grey one. Hopefully You can fix the MidAir filter!
All filters with all weapons and awards @ once would be a cool thing.
When this is possible then maybe you find a way to rename the Cut Demos with weapon frags , like this examble :

You can't check who is who with the latest release. This was more of a feature for myself, if anything. The problem with using the player's index (client number in Quake 3 parlance) is that a) it's specific to the demo and b) it might change if there's reconnects etc. If you still want to know how to get the player<->id mapping, you can get it from Q3MME with "/clientOverride list" and from WolfcamQL with "/players".

I do have plans to make this better by providing the option to specify the player's name (which is guaranteed to be unique in QL but not Q3) or "player who recorded the demo" or "player being spectacted".

Hi, THX for the answere, dunno whats wrong but he not cuts by frags anymore in Cut by frag tab, i add a new Folder but nothing happends only death Tab have a function ! In 35 Or 35a version, whatever Filter i use.

No, this tool's primary focus is demo cutting. The secondary focus is extracting information but I haven't found the time to add all of what I wanted in that area.

About demo viewing: it would be incredibly pointless to be able to watch demos from the tool instead of having it launch Quake 3, Quake Live or WolfcamQL with the demo. I'll add that on the todo for after the next release as decreasing the time it takes to watch/verify new cuts is a valuable goal.

The old UDT (January 2012) already did that (showing who is in spec and who is playing) and I do plan on adding a better version. The problem (to me) is that QLDT and the old UDT only displayed that information for the moment demo recording started (that is, extracting the info from the first gamestate message). I can track player info through the entire demo and display more complete information. The hardest part is deciding how to efficiently store/format/present the information.

It's been on my todo for a while and I think I won't implement it before the next release. Lots of other important changes will come first and I'm getting close to ready for the next release. Gotta pick your battles.

As for a "Search" tab where you can add filters and it displays a list of matching demos etc, that seems reasonable. I'll add it on the todo, but no promises. :-)

For the former I'd be very tempted to say go for both options.
Grab the first gamestate message as it's going to be pretty instant, but give users the option to enable a more aggressive method, as I assume that would take a long time if the demo directory being processed was huge.

ADD: Added a new unified "Cut by Pattern" system with gloabl player selection/tracking settings
ADD: Added the "Mid-Air Frags" cut filter
ADD: Added the "Multi-Frag Rails" cut filter
ADD: Now adding a very small file name suffix specifying the type of pattern that was matched for the cut (if sections get merged, the first match's description is used)
CHG: All cutting filter tabs are now found under the new "Patterns" tab
CHG: Unified cut start and end offset config values shared by all filters in the "Settings" tab
CHG: Bumped up the default max. thread count to 8
CHG: The new minimum required .NET Framework version is now 4.5
CHG: More detailed "Cut by Time" input checking and error formatting
CHG: Improved the contextual menu of the "Demo List" list box
CHG: Improved the list boxes' look for Windows users having a dark desktop theme
CHG: Improved the help text in several tabs
CHG: The "Log" list box will no longer color messages depending on severity to better integrate with the user's desktop UI theme
FIX: Fixed the "Log" list box's highlighted line using the wrong foreground (text) color
FIX: The "Cut by Time" feature will no longer crash with a non-0 gamestate index on non-analyzed demos
FIX: The obituaries analyzer will now find some events that it didn't before; in the GUI this affects both the "Deaths" listing and the "Frag Sequence" cut filter
REM: Removed "Cut by Awards"

This is not very accurate. The problem is the amount of memory address space that gets reserved, not the amount of physical pages committed. Anyhow...

EDIT: Oh..., I misread the error message and just realized from your other post you use the x86 version. If you run a 64-bit Windows, do make absolutely sure you use the 64-bit version of UDT (x64 suffix). Never use the x86 version unless you have to.

In UDT, the biggest problem on x86 is running out of memory address space (crash on reserve). Since that problem doesn't really exist on x64, the biggest problem on x64 is not reserving enough address space (crash on commit). I've been considering dropping x86 support for a while now because 64-bit hardware is ubiquitous.

CHG: New memory allocation strategy (mostly for reduced address space consumption)
ADD: Memory allocation tracking to print detailed information (optional)
ADD: Splitting up batch processing operations by file count to reserve less memory address space (and commit less pages)
CHG: The most frequent parsing errors cancel the operation for the current file instead of calling the crash handler
CHG: Most parsing errors will now print the file name for quickly identifying problematic/corrupt files
FIX: Merging overlapping cuts in Cut by Pattern would create an invalid file suffix and crash because of an invalid file name
REM: Removed the "Processing demo for pattern analysis" message as it cluttered the log with redundant data
CHG: Removing all demos at once in the GUI happens fast
ADD: A new option, "Print Execution Time", for printing the time it took for the batch operation to complete
ADD: A new option, "Print Alloc Stats", for printing the memory allocation statistics of the batch operation
CHG: The minimum required .NET version is now back to 4.0 Client Profile
CHG: The "Demo List" ListView doesn't override the inactive selection highlight colors anymore as it created more confusion than it helped

Err, that's exactly the version I uploaded. Your video has maps that were not added to this list. So either...
a) you uploaded the wrong file, or
b) you created/renamed local .bsp file to match the QL names, or
c) you didn't render them with q3mme, thus contradicting yourself. (quote: "Quake live game, q3mme render")
Which is it?

If you added maps to the config's list, it would be nice to have access to that new data.

Maybe your way to more accurate, because I try to use it and do without quakelive mappack. I have noticed a mistake in my video - https://www.youtube.com/watch?v=hvLiUjCMEKk#t=32 Do not see the pillar in the center of the room for the red armor in ospdm5

This problem can happen if you have the outdated version of the <map>.pk3 file in your wolfcam baseq3. I suggest copying across the latest version. I had this problem with retribution after id changed a couple things around the quad area:

Well, if you use stuff that doesn't exist in the target/output protocol, it gets suppressed by the converter but you could map the HMG's indices (weapon index, model index, etc) to those of the machine gun for instance. One could say it's a non-issue because no demo using the HMG will have anything movie-worthy anyway. :-)

ADD: Protocol 68 to 90 batch conversion support (refer to the read-only config file ConversionRules90to68.xml for known issues)
ADD: Added the "Flag Captures" cut filter
ADD: Added the "Color Log Messages" option
ADD: Now displaying the elapsed time and estimated time remaining during threaded job progress
FIX: ParseConfigStringValueString was failing when the variable looked for was the last one in the list
FIX: 73 to 90 converter: the "protocol" value in config string 0 is now set to "90" instead of being "73"
FIX: Parsing a demo with plug-ins twice with the same context would crash (the plug-in pointer array was not cleared in udtParserContext::ResetForNextDemo)
CHG: String and path manipulation code overhaul (udtString, udtPath)
CHG: Made some minor UI improvements/changes to labels, tab names, tool tips, help text, the "About" dialog, etc

FIX: Logging color-coded errors and warnings would crash when called from unmanaged threads (this happens when the final decided number of job threads is >1)
FIX: 73 to 90 converter: the pm_flags player state field is now kept instead of being zeroed
FIX: 90 to 68 converter: keeping the LG fire events that won't repeat in q3mme
FIX: 90 to 68 converter: no longer breaking player state angles by shifting them as if they were positions
FIX: 90 to 68 converter: now converting the mean of death id in obituary events

The code for this was ready 6 days ago. My attention got diverted by some research stuff... Sorry.

GUI 0.4.5 + DLL 0.6.3 are now available
New: an option to enable or disable the merging of overlapping cut sections matched by different pattern types
Fix: When using Cut by Patterns with more than 1 pattern selected, some cut sections were "ignored"
Thanks to Terifire for noticing and reporting the problem.

FIX: The command-line cutter would crash if one of the demo return codes was not None
FIX: When alt-tabbing out of UDT's own modal dialogs, you couldn't alt-tab back to them: they would steal the focus but not display!
ADD: Demo time shifting (a sort of anti-lag so you can see something similar to what the player saw)
ADD: Demo merging (creating an augmented demo from multiple input demos of the same match)
ADD: UDT_timeshifter: A command-line tool for time shifting demos
ADD: UDT_merger: A command-line tool for merging demos

I've updated the OP with video examples of the time shifter in action. :-)
Demo merging is still WIP but it's giving interesting results already.

ADD: The file and folder browsing dialogs now open the last used directory by default when it's valid
ADD: Full parse/write support of demo protocols 66, 67 (Quake 3) and 91 (Quake Live)
ADD: Full parse support of demo protocols 3 and 48 (Quake 3)
FIX: Potential crash in the game state analyzer when a player index is out of bounds
FIX: Now cleaning up the long OSP color codes (^X followed by 6 hex chars, case insensitive)

What operation? What settings? And most importantly... what files? Where is the link to the files UDT can't process?
You gave me nothing that can help me with that post. Even the error messages are incorrect or modified, which is useless.

ADD: Analysis data export to JSON (can select the list of analyzers enabled for JSON export in the "Settings" tab)
ADD: "Chat" now displays team messages too and has a "Scope" (global or team) column
ADD: "Cut by Chat" can now be configured to search team chat messages
ADD: "Reveal in File Explorer" context menu entry of the "Demo List" list view: opens the file explorer with the file pre-selected
ADD: "Scores and Stats" tab for displaying the most detailed possible information per match
ADD: "Commands" tab for displaying both commands and config strings (in gamestate messages and command messages)
ADD: Unicode file and directory paths support
CHG: All data analysis information tabs are now found under the "Info" tab
CHG: Performance stats now get printed once per job instead of once per batch (jobs can be split into several batches)
CHG: The printing of performance stats can be enabled/disabled individually in the "Settings" tab
FIX: Colored log lines couldn't be copied to the clipboard or saved to a file
FIX: Now handling string.Format failing in log functions
FIX: Clicking any column of the "Chat" list view was crashing when the list was empty
FIX: "Cut by Chat" now searches the messages themselves, not the raw commands

ADD: New parser plug-ins: stats, commands, config strings
ADD: The parser now reads "big config string" commands ("bcs0", "bcs1" and "bcs2")
ADD: The chat analyzer now stores team chat messages as well
ADD: "Cut by Chat" can now search team chat messages
ADD: Unicode file and directory paths support for the library and all the command-line tools on Windows
CHG: Performance stats are returned through the API and the library no longer invokes the user-supplied Log function to print them
FIX: "Cut by Chat" now searches the messages themselves, not the raw commands
FIX: Potential crash in multi-threaded batch jobs
FIX: Player names extraction from Quake 3 chat messages
FIX: Incorrect pointer arithmetic when iterating the thread's allocators

ADD: dm3 to dm_68 and dm_48 to dm_68 demo converters
ADD: Tracking match start dates in QL demos
ADD: "Cut by Time" context menu item in the "Commands" list view
CHG: The "Value" column of the "Commands" list view will now display its content on multiple rows if one isn't enough to fit everything
FIX: Config string commands that are too large are now written as split bcs0/bcs1/bcs2 commands (this should fix the "idMessage::WriteString" string length critical error when cutting demos)

ADD: The "Matches" cut filter
ADD: A match time to server time converter under the "Cut by Time" tab
ADD: Stats analyzer: time/score/frag/capture/round limit
ADD: Stats analyzer: game state index, match start/end time, count-down start time, intermission end time
ADD: The option to print the JSON data to stdout in UDT_json
CHG: Improved match duration output
FIX: The time-out server time ranges of CPMA demos were broken

ADD: A "Captures" tab under "Info" for listing flag captures
ADD: Options to allow/disallow base/non-base flag pickups in the Flag Captures cut filter
ADD: Showing the progress of the current job in the title bar so that you can see the progress when UDT is minimized
CHG: Jobs split into multiple batches now track byte count for progress instead of file count for improved precision
CHG: Now printing the linear allocator's name whenever there is a fatal error in one
CHG: Improved error handling for demo message I/O (overflows and others)
CHG: Demo message I/O errors can no longer be fatal (there were 10 instances of that), they will cancel parsing of the current demo instead
CHG: Demo message I/O errors now always print the file's name
FIX: Cut by Flag: The flag taken test for the first-person player
FIX: Cut by Flag: Got rid of false positives where pickups and captures get detected during the very first snapshot

ADD: Options to allow/disallow base/non-base flag pickups in the Flag Captures cut filter
ADD: The flag captures plug-in udtParserPlugInCaptures
ADD: A new command-line tool called UDT_captures to build a single-file JSON "database" of demo-taker captures
ADD: UDT_cutter now supports "Cut by Matches"
ADD: Windows builds of the command-line tools can display their progress in the command prompt's title bar: can see the progress when the console is minimized
CHG: All command-line tools will now split big jobs into smaller batches to maintain low memory usage
CHG: Unified the interface of command-line tools for: arguments, help text, stdout/stderr selection, return values (0 is success, 1 is error, 666 is fatal error)
CHG: Now printing the linear allocator's name whenever there is a fatal error in one
CHG: One unified C89-compatible header file for library users: uberdemotools.h
CHG: Improved error handling for demo message I/O (overflows and others)
CHG: Demo message I/O errors can no longer be fatal (there were 10 instances of that), they will cancel parsing of the current demo instead
CHG: Demo message I/O errors now always print the file's name
FIX: Recursive file search in all command-line tools
FIX: Making sure UDT_json never outputs anything else to stdout that the JSON data when -c is active
FIX: Cut by Flag: The flag taken test for the first-person player
FIX: Cut by Flag: Got rid of false positives where pickups and captures get detected during the very first snapshot

FIX: Multiple parsing errors occurring with dm_90 and dm_91 demos because of previous overflow handling changes
FIX: When a job was large enough to get split into multiple batches, some demos ended up not being processed
FIX: Forfeits being wrongly detected in dm_91 demos when the config string for the 2nd place player's name was cleared at match start

ADD: An updater and the option to run it at start-up to look for new releases
ADD: A Steam info dialog showing Steam users, Steam installation folders, game folders and demo folders
ADD: dm_73 to dm_91 and dm_90 to dm_91 demo converters
REM: dm_90 to dm_68 and dm_73 to dm_90 demo converters
FIX: All modal dialogs are now sized to fit to the content instead of using fixed dimensions (thanks to Benroads for reporting on the issue)
CHG: Updated the About dialog to improve formatting and credit Jaime Olivares for ZipStorer
ADD: UDT_converter command-line tool to convert demos to different protocol versions

I'm not aware of a command-line method of parsing dm_9x demos. This can be done with qldt on dm_73 demos.
If udt was able to convert dm_9x demos to dm_73, then dm_9x demos could also be parsed properly.

Why don't you just say what you actually want to do with those demos instead of asking for specific things that make no sense without proper context/explanation?
a) UDT has full support for all of those formats.
b) Converting demos to a previous format has no intrinsic value.
c) What would you want to use QLDT for anyway?

But really, I can't for life of me figure out what you even mean with "command-line method of parsing dm_9x demos". Only parsing a demo is obviously useless, you want to actually do something with the data. So, what is it you want to do with those demos that UDT doesn't allow you to?

tl;dr
Tell me what you want to achieve and then we can have a fruitful conversation and see what can be done about it.

I would like a command-line method(not in-tool GUI output, but output re-directed to a file) of parsing dm_90/dm_91 demos so I can parse the important information about the demo from that output.

Example: demo0002.dm_91 parsed to find player0 is named Cypher and player1 is named Strenx, the mapname is toxicity, the demo-length is 621 seconds, the server version is 1.027, player0's score is 8 and player1's score is 7 at the end of match, etc...

As I mentioned, QLDT can do this with dm_73 demos, but I don't know of a tool that can do this for dm_90/dm_91 demos.

I understand that this has little to do with UDT and UDT's main functions. I wasn't trying to draw attention away from the usefulness of your tools. I saw the demo format conversions listed in your changelog and I got excited, that's all.

Get the binaries here.
The files are called udt_con_$(version)_($arch).$(ext).
.tar.bz2 archives package the Linux builds.
.zip archives package the Windows builds.

The one you want is called UDT_json: you can output analysis data as a JSON stream to stdout or to a file. To get the help for one of the tools, invoke the app with no argument (or --help) to print the help.

This rocks.
I got the "Not enough address space was reserved in allocator" error in the udtVMLinearAllocator::Allocate routine with some clan arena demos, but who really gives a care about CA demos anyway.

Could you package the smallest possible repro case you can please?
I would need the app's name and version as well as the demo file(s) used and the command-line invocation (including the executable name) used as well.

It's impossible that this is worth your time. And I hate all this noise distracting from the awesomeness of your toolset. You can email me at playbackdemos - at - gmail.com if you really want the demos or something.

N.B. 1: There was a way to work around that crash: process a folder with the "bad" demos and a bunch of other ones. That way, the chances of a crash would be drastically reduced.

N.B. 2: I've been planning an update of the allocation system for a while that would keep the performance characteristics but make that specific problem go away and help reduce address space consumption on 32-bit builds. It's really more of a question of when I'll find the time than how to do it at this point.

It has an obvious value if you follow competitions or wish to see the history of a player or a player against another player.
I am willing to face the possibility that it is only of value to me because it equates that if you care about demos and the history of the competitions in Quake-related games then you would clearly care about the search tool as well.

I had started work on some UDT stuff I would want to get done first but then development came to a halt a while ago with other endeavors stealing my focus.

However, if you're interested in helping me out a bit, you could try out this beta build and see if you encounter any problem with it. It has basically all the same features as the latest official build but demo parsing is 2+ times faster.

The optimization side of things is pretty much done. I think that there's no low hanging fruit left as far as demo reading/writing goes.

What I wanted to get done first before adding any new features is:
1. Make all memory buffers relocatable and resizeable (with good default sizes based on real-world data) and only use offsets into those buffers instead of pointers. That includes the string buffers.
1. a) This will solve the problem of crashing when not enough memory address space was reserved. It's very rare, but the fact it can happen makes me feel uncomfortable. The current system is also too wasteful of address space on 32-bit machines.
1. b) This will help marshaling the data in the GUI app way faster than right now. Analyzing 3.22 GB of demos takes 20.0 seconds for the library on my PC, but the C# overhead is 3.5 seconds, so 23.5 seconds total. The marshaling approach used right now sucks.
2. Have the C# code (the GUI app) create threads and distribute jobs across threads itself so that exceptions thrown by native code can be caught. Right now, if the library spawns threads and one of them crashes, the C# GUI app won't be able to save the stack trace to a text file before closing.
3. Create a fine-grained API so that other programmers can use the library to decode raw demo data and write their own analyzers. I already know exactly what I want it to look like.

ql's is a huge joke. it doesn't have the simplest of features. Can't even imagine how bored should had been whoever did it. Or maybe his boss was like "make a super basic demo player that just lists the demos, don't make anything fancy... don't u fucking dare do anything more than just listing demos. you have 1 hour max. you still here??"

ADD: Searching for patterns and displaying the results in a new tab: "Search Results"
CHG: Many performance and memory usage improvements, parsing is now roughly 2x faster
CHG: The flag captures analyzer now obtains its data in much more reliable ways (supporting QL, CPMA and OSP)
CHG: The cut/search by pattern player tracking based on names is more robust (doesn't give up the search after a gamestate, handles disconnects)
CHG: The default thread count is now 1 because we can't rely on all users having SSDs
CHG: Improved the scroll to bottom implementation of the log list box
FIX: Not reserving enough memory address space is no longer going to trigger a fatal error anywhere
FIX: Exceptions thrown by UDT.dll can now always be caught regardless of the final thread count decided
FIX: Flick rail false positives when teleporting before a rail frag
FIX: The app will now check that demos selected for write operations have a compatible protocol
FIX: Fixed a few errors in the way performance stats were collected and merged
FIX: Unsuccessful calls to malloc will now invoke the fatal error handler instead of having the library crash later
FIX: The "Copy to Clipboard" commands were keeping selection order instead of using display order
FIX: In the "Steam Info" dialog, if the only item of a list view is not selected, the app uses it automatically instead of complaining about the lack of selection
FIX: In the "Cut by Time" converter: in some cases, a match time exactly at the first or last second would be considered out of range

ADD: A new "Scores" info tab
FIX: Player (dis)connection detection (players who reconnected had their time range wrongly starting at the previous disconnect time)
FIX: A long-standing memory leak happening in all batch-processing operations
FIX: All but the first demo in time-shift batches were broken
Plus various bug fixes and improvements...

i can understand that you've got other things to do - as i said we've got 2018.
can you tell me why the search funstion "flag capture" doesnt work for me? i've got several demos (dm_68) with flag captures, but the tool couldn't find anythig.

Without data to reproduce the issue, no. I could only guess that it's not a CPMA demo and that I didn't add support for baseq3/OSP/whatever, but I honestly don't remember whether I did or not. Could also just be a bug...

The best thing to do would be to PM me on the official CPMA Discord to have a discussion and upload problematic demos there (1 demo per issue would be enough). Otherwise, you can still drop me a link here on ESR. I just won't answer as fast.