How to use XDRE [TAS information]

EDIT 20th June 2023 - Just adding a couple of download links:
XDRE 2.20 - https://notabug.org/38_ViTa_38/xdre-releases/raw/master/xdre-2.20-msw.zip
XDRE 2.22 - https://drive.google.com/file/d/1RWa8gsCMHgk258PTn4qOQmZBKdQTjsQP/view?usp=sharing
DSDA-Doom 0.26.2 (in active development, it's possible a more recent version exists when you read this) - https://drive.google.com/drive/folders/1KMU1dY0HZrY5h2EyPzxxXuyH8DunAJV_

EDIT 5th March 2023 - 3 years on from writing this guide, the state of Doom TASing tools has changed. The DSDA-Doom source port now exists and as of version 0.25 it provides full TAS building functionality, including thing/linedef/sector tracking & the ability to brute force. However as of the time of writing the current state of DSDA-Doom gives both it and XDRE certain advantages and disadvantages you may wish to consider.

 

XDRE is now unmaintained, but DSDA-Doom is being constantly improved and is receiving additional features. Certain benefits being unique to XDRE will disappear over time and XDRE will likely eventually become a functionally inferior choice, but it will remain a valid and acceptable option if you do still wish to use it. I will do my best to update the following information as time goes on to reflect upcoming changes to DSDA-Doom, but this thread will remain concerned only with how to use XDRE. The major points are:

XDRE uniquely allows you to:
- Manipulate RNG seeds for relevant complevels

- Create multiplayer demos

- Create demos with deathmatch player start positions
- Has a more intuitively flexible brute force mechanism, for example you can brute force frames 10 and 12 to look for a solution on frame 14. This is possible to do with DSDA-Doom but is more complicated to achieve without accidentally altering the inputs of frames 11 and 13, introducing more work and higher potential for errors.

- As of the time of writing, you may also find XDRE's system of entering inputs more intuitive to use than DSDA-Dooms.

 

DSDA-Doom supports so many additional features not strictly related to, but useful for, speedrunning and TASing that I could not possibly list them all here, but some key points are:

- Support for complevel 21
- The ability to seamlessly switch between slow motion + segmenting/rewinding mode & pure frame-by-frame building mode

- Support for additional brute force conditions (minimum, maximum, as close as possible)

- Does not require operating an additional GUI, all inputs are made in-game

- An in-game console with many commands for testing and experimenting with a massive variety of situations, such as instantly triggering an intercepts overflow occurrence, changing the properties of things (including the player) in-game, and running pre-defined scripts

- The dsdademo demo format which allows you to, amongst other things, use in-game cheat codes in demos that can then be played back. For example you may wish to test some things without worrying about health, so you could turn on god mode. This of course would not result in a demo that could be submitted to DSDArchive, but does allow for many additional interesting and exotic ways to TAS something unique and fun.

- XDRE 2.20 brute forcing is significantly slower than DSDA-Doom brute forcing (and other versions of XDRE). 

- XDRE 2.22 (and 2.21 I believe, but I may be wrong) have a bug where the program crashes when entering maps with either missing floor or ceiling textures, I don't remember which. This means some maps cannot be TASed with these versions of XDRE, but can with DSDA-Doom.

 

Please don't hesitate to reach out if you have any questions about any other differences between the two.

 

===============

ORIGINAL POST BELOW

===============

 

This thread explains what the basic functions of XDRE are and how to use it. Instructions for how to use the Brute Force feature can also be found in the "Brute Force - Glides" & "Brute Force - 0.000 Trick" sections. I have included an introduction and explanation of what Brute Force actually is in the "Glides" section, and recommend that one be read first. This isn't an advanced tutorial by any means - already competent users won't find any value here, this is just an effort to help new users get started.

I've tried to be thorough, with the intended reader being a slow learner who has no idea what the program is at all, so some will find this tutorial bloated and slow. It's written in a sequential way, starting with using XDRE just to watch demos, then using it to make demos in simple ways, then moving on to performing more advanced tricks. If you wish to jump ahead, go for it, but if you're starting completely inexperienced you could be making things a little harder on yourself. 

 

I certainly don't consider myself authority on the subject and myself have much to learn, but have for some time felt that an introductory resource would be valuable, so this is my attempt at one. If any information is wrong I would be appreciative if it were pointed out and I will make any adjustments necessary. In time I will also be adding some pictures. 

 

INTRODUCTION

 

1. What is XDRE? 
2. Cheating
3. Where to get XDRE & different versions of XDRE
4. Examining a demo in XDRE
5. Altering the header information
6. Entering simple inputs into XDRE

 

BRUTE FORCE: GLIDES

 

7. What is brute forcing?
8. Explaining the brute force window
9. A brief discussion of appropriate brute force ranges
10. Using brute force to perform a glide

 

BRUTE FORCE: 0.000 TRICK

 

11. Reminders & Description
12. Using Brute Force to make it happen
13. Performing the trick without losing momentum

Edited July 22, 2023 by almostmatt1 : Adding links

1. What is XDRE?

 

XDRE (Xepop's Doom Replay Editor) is an program that allows the user to view and/or edit the specific actions of individual tics of Doom demo files. It can be used to view or edit tics for demos recorded regularly, or used to build whole demos from scratch. TASes built using XDRE are subject to all the regular limitations of recording doom demos. This means that jumping, crouching and freelook are still not possible, and that using cheat codes is still not possible.

 

All sorts of incredible things can be accomplished using this tool, but learning to use it can be a little slow and frustrating, but with patience it's much easier than you’d think. Building a 4-player co-op Nightmare! 100s turbo TAS filled with tricks might be where you wish to end up, but it's far from where you will be starting. TASing has a very high skill ceiling, so proceed patiently and enjoy the process.

 

2. Cheating

 

XDRE can be used to simply examine the inputs of regularly created demos, and this is fine. You may be curious to do so to work out, for example, if you opened a door/hit a switch as early as possible, or if you can turn a corner quicker, etc. Simply EXAMINING a demo in XDRE is perfectly fine, if no alterations are made.

 

ANY USE OF XDRE TO ALTER TICS MAKES THE DEMO A TAS. There are no exceptions to this. This ranges from anything as seemingly innocuous as removing "WT" tics at the end of the demo when looking at the end screen, to anything as obviously egregious as totally rebuilding sections. You are using a tool to assist your speedrun.

 

Using XDRE to create or edit a demo and submitting it is completely fine, if your demo is marked as TAS. Making a TAS and attempting to pass it off as a non-TAS demo is absolutely cheating, and is unacceptable. This is a very simple distinction, but some don't get it right. Make sure that you do.

 

Doom is now an old game and the knowledge that has been accumulated amongst its experienced members is vast. It is easier than ever to detect a cheated run, and if you intend to try to pass off a cheated one as real, you will be caught. This guide will not discuss the various ways that cheating can be detected, and don't ask.

 

3. Where to get XDRE & different versions of XDRE

 

You can download XDRE from this link. Grab version 2.20 (xdre-2.20-msw.zip). "Why not 2.21?" As it says at the top of that page, "Warning: 2.21 does NOT work on real Windows!", and I assume most will be using Windows. 2.20 will suit your needs and be totally sufficient. If you wish to know what has changed between versions, your 2.20 version contains the file "README" that you can look at. Like a regular source port, XDRE requires IWADS to function (and by extension, PWADS of course require IWADS). The IWADs can be bought on Steam.

 

4. Examining a demo in XDRE

              4.1 Just looking

              4.2 Gathering basic information

 

              4.1 Just looking

XDRE can load PWADS as well as IWADS, but we'll load an IWAD .lmp. First you will need to open The Ultimate Doom in XDRE, simply by dragging "doom.wad" onto "xdre.exe" once it's in the xdre folder. At this point two windows should have opened, one having a bunch of boxes and numbers titled "XDRE 2.20" (I'll call this the input screen), and one being a black empty one called "PrBoom-Plus 2.5.1.4 (XDRE 2.20)" (I'll call this the game screen). Drag these windows to either side of your screen so that you can see both. The game screen can be resized.

 

Now you can load a .lmp file. For this example, the demo we will be using is The Ultimate Doom e1m1 UV-Pacifist in 8.97 seconds by 4shockblast, called p1m1-897.lmp. On the input screen click file, then load, then find and open the demo. With the demo opened, you should now see the previously black game screen now shows the familiar beginning of e1m1, and the numbers in the input screen have now all changed. On the left side of the input screen the column now displays a list of inputs. This is where we can examine the movements of 4shockblast in each individual tic of his demo. In the top right of the input screen you can find the ‘Input’ box, where we will be giving all our instructions. Pressing 'i' progresses the demo forward by a single tic, and 'j' regresses it backwards by a single tic. Press 'i'.

- On the game screen, you’ll see that the demo has progressed forward very slightly - 1 single tic, to be exact.

- On the input screen, you will see that we are now selecting the second tic down on the column of inputs shown on the right. We should now be selecting a tic that reads "MF50 SL40 TR45".

Experiment with watching the demo and going backwards and forwards.

 

              4.2 Gathering basic information

The input window shows a lot of information, and initially, some is particularly useful.

- Current tic & time: Tic number considers the entire demo, level time defines the time of the map you’re within and so changes in demos spanning multiple maps.

- Distance moved: Shows the distance, in units, that was moved from the previous tic to the currently selected tic.

- X & Y: Shows your exact X & Y coordinate.*  **

- X dist. & Y dist.: Shows the distance on the X axis & Y axis that you travelled from the previous tic to the currently selected tic.*  **

- X mom. & Y mom.: Shows your current X & Y momentum on the currently selected tic.*  **

Examining your own demos in this way, as stated, can be useful for finding areas of improvement or just gathering interesting data. "Damn, I opened the door 9 tics later than I could have, I need to work on that." or "Cool, I got perfect damage rolls when taking down that imp."

 

* When building tases, especially when performing tricks such as glides and momentum preservation, this information becomes incredibly important, much more so than when just watching demos. Even if you don't fully understand this information immediately, give it a look as you progress through examining the demo file, since the sooner you understand it the better.

 

** "But, hang on... Why does and X/Y dist. & X/Y mom. often have a negative value, even when 4shockblast is going forward? Wouldn't a negative value mean you're travelling backward? I don't get it." Going 'forward or backward' is not specifically what these boxes identify.

On a doom map, all the things (enemies, items, even the player/s) each occupy an exact position with X & Y co-ordinates. Since the map has a central point, negative or positive values for momentum and distance travelled determines directional information from this point, not "whether Doomguy is running forward or backward". Negative or positive values in these boxes only define and differentiate which direction you're running in, a value that is unrelated to (but of course inevitably controlled and influenced by) whether you're going forward, backward, sideways, straferunning etc. A reminder:

- Y movement indicates travelling north.

- -Y movement indicates travelling south.

- X movement indicates travelling east.

- -X movement indicates travelling west.

- If you are facing directly north and move forward, your Y momentum and Y distance travelled will be a positive value.

- If you turn around so you're facing directly south and move backward, your distance and direction travelled will be the exact same as above. You are travelling north and your Y momentum and Y distance travelled will be a positive value, even though you're "moving backward".

- If you face directly south and move forward, you will have travelled south. You will have negative Y values, despite the fact that you are "moving forward".

 

5. Altering the header information

 

To view and change the header, go to the input screen, then click "demo" at the top, then click "header". This is information needed to identify some things about the demo to play it back properly. If you still have "p1m1-897.lmp" loaded in XDRE (load it up now if you have not), you can see that the info given in the header is relevant to the specific demo. There's a bunch of boxes here, but importantly:

- Complevel is 3. If you are not familiar with complevels, the most important ones to know are:

              - Complevel 2 = Doom 2.

              - Complevel 3 = The Ultimate Doom.

              - Complevel 4 = Final Doom (The Plutonia Experient & TNT Evilution).

              - Complevel 9 = Boom format wads.

              - Complevel 11 = MBF format wads. 

- Skill is 4, meaning Ultra-Violence. 1 would be ITYTD, 2 would be HNTR, 3 would be HMP, and 5 would be Nightmare!.

- Episode is 1, and Map is 1.

 

So we have an example of how important this information is, and how potentially fragile things can be: 4shockblasts position, and therefore movement, in p1m1-897.lmp is influenced by having been damaged by enemies. If this damage does not occur, 4shockblasts position will be altered, and his subsequent inputs will no longer be accurate, leading to a desync. Go into the header information and change the Skill from "4" to "1", changing the difficulty level from "Ultra-Violence" to "I'm Too Young To Die". Then proceed through watching the demo, and you will quickly discover that things no longer go as smoothly. This is a good example of how the header information accuracy is vital.

 

The other info isn't useful right now and much is self-explanatory, but some good ones to know about for later:

- -respawn means the monsters will respawn, necessary for the "UV-Respawn" category.

- -fast means that the monsters will run and shoot faster and projectiles will be quicker, necessary for the "UV-Fast" category.

- -nomonsters means... no monsters.

If you later wish to build UV-Respawn, UV-Fast or NoMo demos, these will be changed. Change their values by entering "1" into the relevant box, then click apply. If watching a demo recorded regularly in these categories, this box will already be altered when watching the demo back.

 

6. Entering simple inputs into XDRE

              6.1 What inputs look like

              6.2 Entering inputs

              6.3 A brief consideration of optimisation

 

 

              6.1 What inputs look like

We're going to create our own basic built demo and no longer require "p1m1-897.lmp". Close down XDRE, then drag "doom.wad" onto "xdre.exe" to give us a fresh start. The game screen will initially be black. Go back and forward a couple of frames and you should now see the beginning of e1m1. No matter the wad loaded, XDRE will start on the first level. We will first go to the header and change some information. To make things a little easier, first we will set -nomonsters to 1 so we're playing NoMo. Set the complevel to "3", appropriate for Ultimate Doom demos. Change longtics to 0, so we go from longtics to shorttics instead. Change levels by changing Episode from 1 to 3, but leave map as 1. Click apply, and watch the game screen change. We're now at the beginning of building an e3m1 No Monsters TAS.

 

Some basic inputs (there are more that can be found in xdre.ini, but for now) (note, they are case-sensitive):

we # - Moves player forward, and the # determines the speed.

wq # - Same, but running backwards.

sd # - Strafes to the right. The # determines the speed.

sa # - Same, but strafing to the left.

re # - Turns to the left. The # determines how far to the left we turn. ‘-‘ also turns left by 1.

rt # - Same, but turns to the right. ‘=’ also turns right by 1.

u - Use.

n - Creates a new tic after the one you are currently selecting.

c - Copy the tic you are currently selecting.

x - Deletes the currently selected tic.

f - Fire weapon. Not needed for a nomo run, obviously, but shoot some walls to get the hang of it.

g # - Changes weapon. The #, from 1 - 9, determines which weapon is selected. G0 removes this input.

 

For some inputs, you need to type the input into the Input box, and then press the spacebar to enter it. This applies to running, strafing, and turning. For other inputs, you need only type the input into the Input box and spacebar is not required, they are applied automatically. This applies to firing, using, copying/deleting/creating new tics, and changing weapons. The characters that subsequently show up in the input list (remember, the column on the left of the input screen) aren't exactly what you type.

- We type "we50"/"wq50" to run forward/backward 50, but displayed is "MF50"/"MB50", meaning "Move Forward 50"/"Move Backward 50".*

- We type "sd50"/"sa50" to strafe right/left, but displayed is "SR50"/"SL50", meaning "Strafe Right 50"/"Strafe Left 50". *

- We type "re10"/"rt10" to turn left, but displayed is "TL10"/"TR10", meaning "Turn Left/Right 10 shorttics".

 

* 127 is the maximum possible input value, but any running or strafing value over 50 is considered turbo, and if used, your demo needs to be marked accordingly. SR40 straferunning will have input values of 50 forward/backward movement and 40 left/right strafing. E.g., MF50 SR40, MB50 SL40 etc. SR50 straferunning will have an XDRE input value of 50 forward/backward movement and 50 left/right strafing. E.g., MF50 SR50**, MB50 SL50. 

 

** If you are confused, remember that 'SR50' can refer to both the straferunning technique (Strafe run 50) and the value of 50 when strafing to the right in XDRE (Strafe right 50).

 

 

              6.2 Entering inputs

Lets now actually build something! We should be looking at the beginning of e3m1. In the game screen: there's a switch in front of you too distant to press. You can enter the use command ('u'), but nothing will happen, you need to be closer. To run forward, type "we50" into the input box and enter it (press spacebar). The first tic now displays "MF50 U": we have moved forward and pressed use. So far so good, but the switch still wasn't activated. We are still too distant and need to keep running forward some more to reach the switch. Here you have two options:

- Press 'i' to progress to the next tic, then enter "we50" (press space to enter) and "u" (spacebar isn't required), replicating the previous tic.

- Alternatively, press 'c' (spacebar isn't required) and it'll copy the tic. A bit simpler.

 

Now you have two "MF50 U" tics, but we still haven't pressed the switch. Press 'c' a few more times to copy the tic more... okay, we're definitely close enough but the switch isn't being activated, what's wrong? “Use” wont work if it was used on the previous tic, whether it there successfully activated anything or not, meaning we can only use it on individual tics and not spam it until something happens.

Go to the first tic, and press 'x' to delete all the tics other than the "WT" ones that were there when we started, so now there are only several "WT" tics in the input column. Move forward again (MF50) on tic 1, copy that tic, then enter "use" on the second "MF50" tic. You should now see in the game screen that you have activated the switch. In the input screen, towards the bottom left a box next to "Used a line" should now read "true", whereas before and after this tic (when "use" is not successful), it reads "false".

 

Now you'll have a few seconds while the platform raises. If you scroll through the available WT tics there aren't enough tics to see this happen, you'll run out before the platform raises. Scroll down to the last "WT" tic and press 'n' to create new tics, which will start as "WT" tics. Do this until the "current tic" number is 121. At this point the platform is totally raised. Remember, the imps are nowhere to be seen, since we set '-nomonsters' to 1 in the header before.

 

We now need to move to the switch to the left of the door up ahead. We're facing too far to the right, so we need to turn to the left. Adjust the angle by entering "re7" and pressing space (or press '-' 7 times). Then enter the command for MF50. If you copy this "MF50 TL7" tic, you will be copying both the forward movement and the turning. Instead of copying the "MF50 TL7" tic, create a new tic after it, enter the MF50 input, and copy THIS one (remember, hold ‘c’). Copy MF50 until "Current tic" reads 190, then on tic 190, turn to the left 20 shorttics to face towards the switch (MF50 TL20). After this, add four more MF50 tics, and on tic 194, enter the use command to activate this switch. So far so good.

 

Now you know how to create, enter inputs into, copy and delete tics. You know how to run forward, turn, and use switches (and by extension, open doors). You now have all the necessary tools to finish the level, if you want to practice.

 

 

              6.3 A brief consideration of optimisation

It feels pretty cool to use XDRE to change inputs, but what we have so far done is pretty damn slow - we have hit the second switch at 5.57 seconds, and for reference, Loopers 0:15.97 NoMo world record of this level hits this switch at 4.34. Considering tases are meant to be superhuman, losing more than a second when we're less than 6 seconds into a demo is not a desirable pace. We'll walk through an example of how to do this again, but making three changes to save some time we'll start running towards the second switch sooner, we'll back up before running to the second switch, and we'll straferun (SR50) instead of running forward.

 

Start the demo again. There's no 'new demo' option in XDRE, you either have to close it down and re-open, or delete every tic in what you've made so far. If you go to the very start of the list of inputs and delete every single one (read: press 'x' when there are no inputs in the list), xdre will crash and you will have to start again, so I recommend the former option. If you do start again, remember to modify the header exactly how we did before. We'll start the same way: two "MF50" tics, activating the switch on the second one. Instead of now waiting, on the third tic, enter the command for "MB50". Copy this tic until we reach tic 18, at which point we’ll collide with the wall behind us. You can probably tell from the game screen that we have made a collision, but there are two important boxes in the input screen that also tell us something has happened. On tic 18:

- Y mom. is 0.000000. For the 15 tics before this, we had negative Y momentum, meaning we were moving south. Since we have hit the wall, we can't go any further south, and so have lost momentum in this direction.

- Distance moved is <0.0, where it was >12 on the previous tic. This is a sure way of knowing we've hit something.

 

Since we've reached the wall behind us, there's no further to go so stop copying the "MB50" tics. This is the position from which we're going to be SR50 straferunning to the second switch. From tic 19 and onwards, create new WT tics until we're up to tic 100. X coordinate should be 288.05, and Y should be -1679.5.

 

Determining the optimal angle to run at just comes down to trial and error, but for this example I'll cut to the chase, we will be turning to the left 38 shorttics (TL38). Any more to the left and we will hit the decoration in front of the switch. So on tic 100, we're going to turn to the left by 38 shorttics, and SR50 towards the switch (tic 100 should display: MF50 SR50 TL38). On tic 101 onwards, we'll be SR50 straferunning with no turning. Copy tic 101 until we reach tic 161 and activate the switch. The time is 4.63, so we have saved 0.94 seconds over our first attempt.

 

As mentioned we can obviously also start running sooner. Scroll back to the wait tics before tic 100, and delete 5 "WT" tics (remember: 'x' key to delete selected tics). Scroll forward again, and you'll see we're now beginning to run on tic 95, and have hit the second switch on tic 4.49. From here it's again a matter of trial and error to work out how many "WT" tics can be deleted before we are running too early and colliding with the wall/step in front of us. Scroll back, delete some tics, scroll forward, see if it's okay. I encourage you to experiment but I'll cut to the chase again: The earliest tic we can start SR50 running on is 84. If we start running on tic 83 or earlier, we will run into the wall in front of us (which, as before when we were running backwards, can be seen both on the game screen and by the sudden decimation of our Y mom. & Distance moved values). Now, we can hit the switch on tic 145 at a time of 4.17. With a few simple changes, we've saved 1.4 seconds over our first swing at building this section, and are ahead of the non-TAS NoMo WR by 0.17 seconds. There's another little thing we can do, though not as impactful. We can actually activate the switch on tic 144 instead of 145. By turning between TR20 & TR26, we can activate the switch on tic 144.

 

Hopefully this small example has given you a little practical experience with how to examine inputs, how to enter inputs, and a few simple things you can consider to potentially squeeze anything from a couple of tics to a couple of seconds out of whatever TAS you wish to work on.

This section will explain what the brute force feature of XDRE is, and how to use it to perform a glide. Since the term "glide" is commonly (and confusingly) applied to several distinct tricks, specifically, I'm talking about the "squeeze glide". This is written with the assumption that the underlying mechanics of performing this trick in regular play are understood. If not, read this Doom Movement Bible post.

 

 

7. What is brute forcing?

 

"Brute force" isn’t a term exclusive to XDRE, and a google search will help give you a better understanding. Here, Brute force is a feature of XDRE allowing it to check over a very wide set of potential inputs, searching for the exact ones required for a specific pre-determined outcome. Common uses of this could be: "What exact inputs do I need in order to perform this glide on this tic?" "What exact inputs do I need in order to perform the "0.000 trick" on this tic?" It can look over hundreds of thousands, if not millions (if you have the time), of potential combinations of inputs in order to find the right ones the solution you need. Obviously, this performs a job that a human simply cannot practically accomplish. If brute force is successful you will have a pop-up saying "Found it!" Otherwise, "Whole range examined. No cigar."

 

In this explanation, we'll use it to perform the glide in Doom 2 map 02. Load doom2.wad into XDRE, and open BF-glide.zip. Skip forward to tic 310. Click tools, then brute force.

 

8. Explaining the brute force window

 

The brute force window is divided into two sections.

- On the right, you define what you’re looking for.

              - You pick which relevant pieces of information you wish to be found, whether looking for a single thing or multiple things on the one tic. E.g. You wish to be at a Y position of exactly 1064 (exactly between the two walls in the 32 unit wide gap, having performed the glide). Tick the correct box, leave it on "=", type the number.

              - You can specify exactly what tic you would like all this to happen on. By default, this will be the tic that was selected on the input screen when brute force was opened.

- On the left, you enter the information for the range of inputs you want brute force to check over.

              - "Run cmds" is where you specify the range of running commands that you want brute force to check. You can run forwards and backwards, and specify the speed. For example, if you want brute force to check everything between MF50 & MB50, it will try "MF50, MF49, MF48... MF1, WT, MB1, MB2... MB49, MB50", until it either finds what it is looking for or determines that the search is impossible. This information will be entered as "50:-50". Positive integers mean forward running, while negative integers mean backward running, the colon meaning "between this and this". So, "50:-50" means "test every run cmnd value between MF50 and MB50".

              - "Strafe cmds" is the same as above, but for strafing. Positive integers mean strafing to the right, while negative integers mean strafing to the left. "50:-50" = "check everything between SR50 & SL50."

              - "Turn cmds", also the same, but for turning ranges.* Positive integers mean turning to the left, while negative integers mean turning to the right. "32:-32" = "check everything between TL32 & TR32."

              - "Add" & "remove" - adds tics in the above box that you want to brute force. The number of each tic added will be the tic you are selecting in XDRE at the time of opening brute force. If you are selecting tic 1000 and want to brute force tic 999 & 1000, simple click add twice and change the first tic to 999. The ranges need to be determined for each tic separately, meaning you can specify different ranges for different tics.

 

*note that XDRE 2.20 brute force does not support longtics. Longtics will not be used in 99% of cases anyway, but it is something to keep in mind.                 

9. A brief consideration of appropriate brute force ranges

 

This isn't an entirely necessary section to read if you're in a hurry, but it explains the importance of using appropriate ranges when you're brute forcing.

 

It's possible that you might have the thought, "If brute force will go through every possibility of inputs, why not just brute force a whole 10 second section or something to make sure the entire thing is perfect?" Ignoring the fact that regularly building a section is sufficient and easy enough with enough knowledge, there is something in this question that I feel does have some value in discussing. With a bit of quick math, we can quickly see that the range of input possibilities for each tic can very quickly become insanely high. Lets say we want to test the range of everything possible for a single tic, excluding turbo ranges and weapon changes.

Run cmds: 50:-50 (this and strafing contain 101 values, as it includes 0)

Strafe cmds: 50:-50

Turn cmds: 127:-127 (255 values, also includes 0)

Fire: both

Use: both

101 x 101 x 255 x 2 x 2 = 10,405,020 possibilities for a single tic.

 

If we DO include turbo speeds and all potential weapon changes (brute force doesn't change weapons of course, but to give an idea of what is possible):

255 x 255 x 255 x 2 x 2 x 9 = 596,929,500 possibilities for a single tic.

 

Okay, lets scale back our parameters: no firing or using, no turbo speeds, turning only up to 25 in either direction, no weapon change. But this time, for two tics.

101 x 101 x 51 x 101 x 101 x 51 = 270,661,103,001 different possibilities.

 

Already over quarter of a trillion! Imagine if we had the running and strafing range of turbo speeds, if we had fire and use, if we had all the turning angles. Imagine if we had longtics?? But, ignoring all that: considering a brute force of 512,000 possibilities takes approximately 17 minutes and 30 seconds to run through all possibilities (based on a test looking for an impossible outcome timed until failure), if we assume that this rate is constant no matter the size of the brute force, a test with 270,661,103,001 possibilities would take approximately 17 years, 219 days, 9 hours and 12 minutes to check all outcomes. Let me remind you that this is a search for only 0.06 seconds of playtime, and still falls quite short of testing all the possibilities. If we brute forced just 4 or 5 tics with absolutely maximum parameters, it is quite possible the human race would end first.

 

Okay, obviously I'm getting ridiculous and using an extreme example to prove my point here, so let’s bring this idea back to the real world: Let’s say you're already in a good position to perform a glide. By intelligently choosing appropriate ranges for your search, you can bring your brute force time from hours to minutes, depending on the circumstantial specifics. Some stuff to ponder (just some examples, not recommendations): If you're brute forcing a single tic, you can get away with searching through a very high range. It could take an hour or so, but that's about it. You could easily get away with a range as wide as this, which should only take around 20 minutes (quicker if it finds the answer, of course):

Run cmds: 50:-50

Strafe cmds: 50:-50

Turn cmds: 32:-32

When brute forcing multiple tics, it is very important to scale back the range so it's something the process can handle in a reasonable amount of time (also, so you have some slight control over the outcome - only fast run and strafe cmds when searching for an instant glide as quick as possible for example). For example, assume we are starting in a good position before brute forcing a glide. It's fairly reasonable to use this range for both tics for a glide:

Run cmds: 50:40

Strafe cmds: 50:40

Turn cmds: 8:-8

This should take a maximum time of approximately 1 hour and 40 minutes. This isn't really necessary but if you're wanting to, for example, set something up in the morning, go to work/school, and come home to see if XDRE has found you a solution, something like this (for two tics) would take approximately 9 hours:

Run cmds: 50:37

Strafe cmds: 50:37

Turn cmds: 10:-10

Okay, I haven’t really been fair here; saying “this is how long it’d take to go through everything” does not mean “this is how long it will take”. Whether a brute force would take 60 minutes or 60 years to check everything, it could find the answer within minutes or seconds, but it’s easy to fall into the trap of setting up a gigantic search that will waste a lot more time than setting intelligent ranges. 

 

10. Using brute force to perform a glide

              10.1 Getting into a good starting position

              10.2 Entering inputs and making it happen

 

              10.1 Getting into a good starting position

Related to the previous section about appropriately wide brute force ranges: brute force is implicitly very powerful in its ability to make difficult tricks happen but it's always worth putting in some effort manually before brute forcing to make the process easier.

 

- If you are just vaguely in seemingly the right spot, (e.g. you're standing in front of the gap but still a unit or so too far to one side), even a very wide brute force has a high chance of failing in its attempt to make a glide happen, gliding is too precise a trick.

- You can hit the wall, lose your momentum, and spend half a dozen tics or so getting into a good spot before starting the brute force. (This is what happens in the worked example below). This will make the brute force work, but it takes a few extra tics and kills momentum, and since TASing is meant to be an effort to create a demo of the highest quality possible...

- You should adjust your movement when approaching the gap, either through changing your angles or slightly adjusting your running and strafing values (or both), to be in as precise a position as possible the instant you reach the gap. This is necessary to perform an instant glide, as they are very precise. If not an instant glide, it means you’ll be able to brute force very soon after collision, minimising tics spent setting up.

 

If you're needing to know what the position you need to be in is to glide, you can spend some time running against the gap until the units you see on each side of the screen are pretty much even, then checking the X or Y position, obviously whichever is relevant to your case. Looking below, you can see three units on each side of your screen, meaning you're pretty much in the middle. After you know roughly where the position you need to be in is, you can use the XDRE coordinate values to get more exact. Remember, you can always roughly slam into the wall and sloppily work out your required position, and then go back and do it more cleanly.

Getting back to our worked example: When the glide is successful we will be in a Y position of exactly 1064, so I have manually gotten very close to this - 1064.000015. You don’t need to get THIS close, but the closer the better.

 

              10.2 Entering inputs and making it happen

Make sure you're still selecting tic 310. Open brute force. In the brute force window, we’ll enter the information on the right-hand side: what we want brute force to find.

- "On tic" should be 310, and will be, since you were selecting tic 310 when you opened brute force and this is where we want the outcome found.

- Since we want be at a Y co-ordinate of exactly 1064, tick the box and enter the number.

- The other information can here be ignored. Optionally, however, it may be of some use in other circumstances to specify an X value. Here, when the glide is successful, we want to be at an X co-ordinate of < 1056. If Y = 1064 but X = > 1056, we will be in the correct Y position but won’t have actually entered the gap, we will still be too far east. Just something to keep in mind for other glides you may attempt; for now, leave it alone.

 

On the left hand side we will enter the range we want to check. As mention, if forcing only one tic you can go pretty wide here. Let’s go:

Run cmds: 50:-50

Strafe cmds: 50:-50

Turn cmds: 32:-32

This'll take a couple of minutes, go grab yourself a coffee or something. Eventually you will have a box that pops up that says "Found it!" The glide was successful, and you can from here keep running forward through the gap. This glide setup and execution is slow, but when you understand how to do it, working out how to do it faster is easier than you may think. 

This section details how to use brute force to perform the "0.000 trick". The trick itself and how it can be used/how it differs in different situations is explained, but a disclaimer: this exact method to not lose momentum (e.g. my 'setup' and ranges) is what I do, but I am 100% sure a better way exists! When I'm confident in better information I will adjust the section accordingly, but this method has worked quite well for me so far, and still generally gets maximum potential outside of non-grid-aligned instances. Two additional notes:

- "Doors" and "walls" are interchangeable, it applies to both.

- While this trick contains an element of preserving/maintaining your momentum against a wall, it does functionally differ from the so-called ‘momentum preservation trick’, which can be read about in this handy Doom Movement Bible post.

 

11: Reminders & Description

              11.1 Reminders

              11.2 What is the 0.000 trick?

 

              REMINDERS:

- This trick only works on walls that are directly (N)orth, (E)ast, (S)outh or (W)est. Walls that are at an angle on the automap don't work.

- If the wall is not aligned with the blockmap grid (Look at the automap when playing regularly and pressing 'g'), his trick can be performed only on S & W walls - meaning, the walls are directly in front of you when you are facing south or west. In this instance, you can preserve up to 14.5 X and 14.5 Y momentum.

- If the wall happens to be aligned with the blockmap grid, this trick is available for N, E, S or W walls. Potential momentum preserved is not limited.

 

 

              11.2 What is the 0.000 trick?

Normally if you run straight into a wall for a while after collision, not much happens. However, if you get as physically close as possible to a wall, you are able to build up momentum against that wall, even while your position stays the same. Walls that aren't on an angle have an exact whole-number X or Y value, and when you're as physically close as possible, you'll be 16 units away from that (remember, Doomguy is 32 units wide and his position is his center). So, if the wall is at Y = 1000, Doomguy will need to be at Y = 1016 or Y = 984. We can't get here just by running into it, we need to use brute force to accomplish this. Doing so is the principally the same as gliding: Give brute force a goal, give it some parameters, let it do its thing.

 

This can be used to build momentum against a door while it's opening. When normally running against an opening door your first tic through it will have very low speed, a Distance moved value of around 1.5 (commonly known as why speedrunners back up while doors open). Using this trick, even within a constrained maximum momentum, this value will be closer to 15 or 16. To do this yourself, download BF-0.000.zip, which is for Doom 2 Map 31. It concludes with running to the west towards a door, but ends on tic 100, before collision actually occurs.

 

12. Using Brute Force to make it happen

              12.1 Working out the desired position

              12.2 Brute Forcing to get to that position

              12.3 Making sure to not exceed the momentum limit

 

              12.1 Working out the desired position

After determining whether it's a Y or X co-ordinate you're looking for (simply, are you travelling north/south or east/west?) just run against the wall, and your X or Y coordinate will show you're a small distance away from a whole number. In BF-0.000.lmp, keep running and you’ll see that we are at an X position of -1383.934402, very close to -1384, the position we're aiming for. This door is west and not aligned with the blockmap grid, so the trick is possible, but only with 14.5 Y and/or X momentum.

 

              12.2 Brute forcing to get to that position

Keep running but after tic 117, insert 5 WT tics, and on the first one turn right by 32 so we are facing perpendicular to the surface. Skip forward to tic 122. We'll try brute forcing the same range as we did for the glide trick. For one tic:

Run cmds: 50:-50

Strafe cmds: 50:-50

Turn cmds: 32:-32

And look for X = -1384.

For me, this brute force took about 3 seconds. On tic 122 we should now be at an X coordinate of -1384.000000. Enter the use command on this tic so the door starts opening. On the next tic, enter MF50 & SR50, and note that you have X momentum, despite still running straight against the door. I'd imagine you should have had the same brute force result as me, but either way: After the brute forced tic, make whatever turning adjustments are required for an angle of 40960, and SR50 straferun towards the door.

 

              12.3 Making sure not to exceed the momentum limit

In this situation we can accumulate a maximum of 14.5 momentum, and if you SR50 indefinitely and monitor your X momentum you will notice that after it gets above 14 or so, it'll soon go back down to 0 on a subsequent tic. This obviously limits on our maximum speed and highlights why blockmap grid-aligned doors and walls with no momentum cap are uniquely valuable.

 

Simply reduce the speed at which we're running against the door to get around this. Instead of "MF50 SR50" tics against the door until it opens, use "MF35 SR35" tics. Then, on the first frame that you shoot through the door, go back to MF50 SR50. Your Distance moved value should be around 16 on the first tic through the door, instead of the 1.5 or so it would have been by running against this door normally.

 

              13. Performing the trick without losing momentum

This is where my earlier disclaimer applies: this exact method may not be optimal, but it'll work, and it could you a basic method from which to develop a better one yourself. Sometimes doing any sort of setup is not necessary, but in my personal experience, doing so has made success more consistent. In this example, keeping momentum isn't necessary for optimum speed since we need to in fact slow down to keep momentum under 14.5; despite this we'll re-do this section, but getting to X = -1384 on the first tic of collision and without losing our momentum. When this is applied to situations where more momentum can be maintained, or when X & Y momentum are both being built, it is more valuable than it is here.

 

I like to consider the input values of the tic of impact and the two tics before this. Open BF-0.000.lmp again, and once again copy the MF50 SR50 tics until collision with the door occurs on tic 114. We will be brute forcing tics 113 & 114, and adjusting these beforehand as well as 112 before the brute force.

- Change tics 113 & 114 to MF45 & SR45. We will be brute forcing a little faster and a little slower, so this gives us some wiggle room.

- Alter tic 112 so you have the minimum forward input (if necessary, maximum backward input) for tic 114 to collide with the door. So, if tic 112 is "MF2 SR2", collision will not occur on tic 114; if tic 112 is "MF3 SR3", collision WILL occur on tic 114. Adjust tic 112 to "MF3 SR3".

- Now tics 112, 113 & 114 will be "MF3 SR3", "MF45 SR45", & "MF45 SR45".

 

Open brute force. Add two tics, change them to 113 & 114. For each, force a Run, Strafe & Turn range of "42:50", "42:50" & "8:-8". Search for a X coordinate of -1384 on tic 114. Start the brute force. Mine "Found it!" in under 30 seconds.

 

We run into an immediate problem: On the very next tic, if we keep running forward, our momentum exceeds 14.5 and goes to 0. Even if the next tic is WT, our momentum exceeds 14.5 and goes to 0. In fact, counter-intuitively, to keep our momentum we need to at this point move BACKWARDS, and by a lot. For the brute force result I had (I imagine you'd have had the same), if we run directly away from the door, anything less than MB42 SL42 will leave us still going too fast, and kill our momentum entirely. In each situation where momentum preservation is limited, you will need to personally experiment with appropriate inputs following the brute force to give you maximum momentum while not exceeding 14.5.

What a magnificent tutorial! @rodster, wake up, here comes a new XDRE tutorial writer!

 

Here are some small notations.

1. You can enumerate specific range values by putting commas, like "Strafe cmds: -50,-40,-30,-20,-10,0,10,20,30,40,50". Helps to save your time if you need to solve some small tasks using brute force, like dealing a damage to a small distant enemy.

2. You can choose between Angles and Turn cmds by pressing the appropriate button. Turn cmds means you can turn left/right by X degrees on the chosen tic.

Angles are probably broken. Here:

"-127" means TL1,

"-126" = TL2,

"0" = TR128,

"126" = TR2,

"127" = TR1,

while you have your whole angle range as 0...255 in the main window. Very uncomfortable IMO. Don't use Angles!

 

Well, seems like that's all. I don't see anything unmentioned. Thank you for youк effort, Matt... almostmatt!

Edited March 8, 2020 by Dimon12321

Thanks Dimon :) I had seen that Rodster had started something like this a while ago, but it's been some time since the last update to it, so I hope I haven't taken over anything they were working on behind the scenes. 

I had no idea about that first point, thanks for sharing!

Haha, thanks for the mention @Dimon12321 :D it is true though.

 

@almostmatt1 this looks really neat and I love the layout. Thanks for taking your time and making this tutorial! :) And also thanks for mentioning me haha xD

On 3/7/2020 at 12:10 PM, Dimon12321 said:

Angles are probably broken. Here:

"-127" means TL1,

"-126" = TL2,

"0" = TR128,

"126" = TR2,

"127" = TR1,

while you have your whole angle range as 0...255 in the main window. Very uncomfortable IMO. Don't use Angles!

At least in xdre 2.06 (xepop's version), the angles mean the player angle. That means:
0 means player is watching west

64 means player is watching north

128 means player is watching east (flips to -128)

192 means player is watching south (this is -64)

Edited November 4, 2020 by Looper

bro, im in LOVE with you. thanks for this!

 

Haha, you're welcome. Feel free to message me with any questions if I didn't explain anything well enough. 

Thanks for the clear and elaborate guide! :)

 

Got two questions:

1. It's not possible for a normal player to turn during SR50. Should we therefore also limit the strafing speed to 40 when rotating/turning on the same tic (otherwise it'd be a turbo run), or does that not apply in TAS runs?
2. How do you start a co-op run from scratch?

1. No, there's a way to get sr50 in turns that falls under the "genuine TAS" definition
2. Demo > Header > Players, the number there is a linear combination of powers of 2. 1 = player 1, 2 = player 2, 4 = player 3, etc.
So setting that value to 5 would add player 1 and 3 into the game, and 15 would be all of them. "v#" to cycle between them by default (# - player number)

I may be the only one who is not doing these in built demos, [MF50 SL50 TR10], but always reduces SL/SR to 40 on turns. I know Andy Olivera also did this and I saw a pair of occasional demos by others (Looper?), but I guess most people are fine with that. Before the era of built runs it was good habit to write in the txt "strafe-50 is always ON" (e.g. Akse). See these posts.

Alright, thanks for the clarifications. :) I guess SR50 on turns is optional then.

I don't feel confident typing "40" instead of "50". It slows demo building down which BTW is itself a damn slow process