almostmatt1

Give v2.22 a go, it is linked at the top of the first post in this thread and should work (apologies if it doesn't, I don't use Windows these days but if this has issues as well I'll fire up a VM and do my best to work it out for you). Unfortunately I can't help with the v2.23 .dll issues, v2.23 is entirely Rockys project, I ran into .dll issues with it as well on Windows a while ago but didn't look into it because I run my own custom XDRE version.

Which version are you trying to use, and where did you get it from?

Well. 3 minutes after posting this, I read this from the same thread I linked: If the value of the first byte is... "255 - depends on the signature that starts from the next byte: ... -> "PR+UM" - PrBoom+ with UMAPINFO, check byte 27 (i.e. 28th byte) for the "true" compatibility" Cool. Great. My brain is very smooth. Apologies for the spam.

Dunno if this would be more appropriate in "General" but I figure no group spends more time with demo files than speedrunners so hopefully this is okay here. I am writing a TAS tool that reads demo files and analyses their existing inputs, but I don’t have a clear understanding of the demo header and how its length changes, particularly when it comes to UMAPINFO. I need to work this out to accurately know where to begin looking for movement information. I understand how the byte values correspond to player movement and inputs and understand how to locate the demo end marker, but the header stuff is giving me some trouble. This very helpful thread has some useful information, and also links to useful information elsewhere. From what I can gather, the value of the first byte indicates the game version and the game version corresponds to a certain fixed-length (unless it's mbf21, apparently) header. So for example: - If the first byte value is 109, the demo is vanilla format, so the header is 13 bytes long, so the first byte containing movement information is the 14th byte. - If the first byte value is 202, the demo is Boom format, so the header is 109 bytes long, so the first byte containing movement information is the 110th byte. So far so good, and I've written some code that appears to accurately deal with this. My problem is where Keyboard_Doomer wrote the following in the aforementioned thread: “Demos that make use of UMAPINFO have 27 extra bytes before the standard header - that means the header size is 40 (27+13) bytes for vanilla complevels and 136 (27+109) bytes for Boom and beyond.” If I could detect whether this is the case in a particular demo file I would be able to easily adjust for this, but I don’t know how to detect whether this is the case. Further I honestly don’t really know what it means for “Demos to make use of UMAPINFO” and have been unable to locate any information about this, including on the umapinfo repo. Also I've tried looking through krafs demo analyzer tool code for clues, but I don't know ruby and haven't been able to work it out from there (having covid brain at the minute doesn't help). Could someone please explain what it means for a demo file to “make use of UMAPINFO”, what kind of information is stored, and what information within the demo file itself exists to notify a source port that this information is present?

This was almost two years in the making which means almost two years of chatting with Rocky, sharing notes, ideas, progress, etc. I'd just like to publicly state how good it was to work with him and that I don't think I could have gotten to the end of this project working with anyone else. He has been consistently very hard working, level-headed in the often huge set-backs we encountered, never had any ego attached to work of his that needed to be scrapped or improved upon, and was always totally understanding whenever I needed to take a step away for a while due to burnout or whatever else. When I would send over progress of mine, the majority of the time he would go to the effort of scrutinizing it and finding valuable improvements to my work instead of taking the easy route of just accepting whatever I threw his way and moving on. He's been unfailingly kind, mature and extremely easy to work with for years of collaboration. Mix that with how freakishly good at TASing he is, and there is no-one I could have had a better time working on a demo like this with. It's awesome that one of the best Doom TASers to ever do it also happens to be one of the most solid people I've ever met online and I'm grateful he's around.

Doom II Map 18 Stroller Co-op in 0:01.66 - lv18strxc166.zip Though this is a 2-player demo, it uses player start positions 1 and 3 and so is a misc demo. YouTube:

Doom II Map 01 No Monsters in 4.34 by @RockyGaming4725 and myself - lv01ox434.zip YouTube:

CyboFun2 D2All Pacifist in 1:02 - cballx102.zip This is an edit of cball103.lmp by @4shockblast, which you can download here or view on YouTube here. It has a Map04 that is 1 second faster, a little punching added to Map03 to alter RNG for Map04, and a slightly faster Map06 (just by tics, not seconds). I'd like to stress that this is still mostly shocks work. YouTube:

Nice run! I couldn't resist the call of that Map 14 :) Cydonia Map 14 NM-Speed (+ Pacifist & Reality) in 0:03.31 - cy14nx331.zip YouTube:

Swift Death Map 24 NM-Speed in 0:01.26 - sw24nx126.zip YouTube:

Thanks! I'll poke around in Slade and see how I go. I appreciate the heads-up on those points. :) Thankfully it shouldn't pose a problem. I'll only be going through this process at times where the player movement being brute forced occurs prior to monster interaction or in the No Monsters category, so the combat implications of the blockmap are sidestepped and the only factors should be player movement and interaction with map geometry remaining consistent before and after the edit. I've done it a couple of times before in instances where this blockmap issue doesn't pop up (by that I mean I did not do any tricks that rely on the position of the blockmap) and so far it's worked quite well. If movement behavior remains consistent between the original and edited wads, demo inputs achieved using the edited wad can be played back with the original wad with no concerns. On the point of submitting them - for TAS (tool-assisted speedrun) demos, which are submitted separately and labelled as such, the whole endeavor is about using tools to see how quickly the game will technically allow itself to be played rather than actually playing it normally and legally, so unlike regular non-TAS speedrun demos any methods used in pursuit of this are fair game. They exist on the same tables but are marked differently aren't competitively compared to human runs.

Disclaimer, I have only an very basic understanding of mapping in general so my apologies if this is something basic. I'm using Ultimate Doom Builder and am definitely willing to trying out new programs if they can help. I make Doom TASes, a process that involves a lot of brute forcing input combinations for specific outcomes. The larger and more complicated a map is the longer the brute force process takes. For example, I did some tests a while ago and brute forcing 1 million input combinations in Doom 2 Map 1 took 74 seconds while brute forcing just 10,000 input combinations in Sunder Map 19 took 700 seconds. Most differences aren't nearly this dramatic, but they're significant. I'll often run brute forces that take hours if not days, and often it is viable and massively beneficial to edit out huge unnecessary portions of a map prior to starting the brute force. The problem I've encountered is that when I edit a map in Ultimate Doom Builder, when I save it, the position of the blockmap relative to the positions of the walls changes. This is an issue because there are some tricks that rely on the blockmap existing in a particular place. If you get perfectly close to a wall which is to your South or West you can maintain up to 14.5 units/frame of momentum in multiple directions while stationary (yes, this a kind of "wobble" trick), but if the wall happens to directly sit on a blockmap line this momentum limit does not exist. Additionally this trick is not generally possible when the wall is to your East or North (momentum simply dies and stays at 0), but if the wall happens to be on top of the blockmap line it is possible to maintain momentum in these directions (definitely East anyway, I don't actually recall testing North now that I think of it). So, this creates a situation where edited maps that I create for faster brute force times occasionally stop being viable in situations where walls either previously did and now don't, or previously didn't and now do, exist on the blockmap, because I need the behavior of these tricks to remain consistent. Is it possible to take a map, remove large parts from it, and have the position of the blockmap remain unchanged?

Happy Birthday Kvo! UV-Speed D2All in 1:01 - 4kvoallx-101.zip YouTube: Map 15 UV-Speed in 0:08.69 - 4kvo15x-869.zip I'm an idiot and spent a while going for the wrong route but didn't want to scrap this so I'm posting it as an I.L. to show a TAS that doesn't do the void glide. The map 15 in the D2All does the void glide and is 6 seconds faster. YouTube:

Thanks as always for your hard work! I'd also like it if opl could be put back in, please.

Loved this!