Overview

This step isn't necessary (and in some ways it's better not to do this at all), but for learning purposes it's good to understand exactly what we'll be working with.

For this step we're going to trim the main datablocks that we'll be working with (specifically Rundown and LevelLayout) so that they only contain one level.

This also doubles as an exercise in using VS Code.

Isolating blocks

Setup

To start, we'll grab a copy of the unedited Rundown, LevelLayout and GameSetup datablocks. You can follow along with how to generate them using MTFO from or grab them from the archived versions at . You can also view the final version of our edited datablocks here: . Put these inside a folder in the GameData directory of BepInEx. You'll have something like this:

Open your GameData folder with VS Code.

Deleting rundown blocks

Open the Rundown datablock and delete the headers.

Now we'll delete all but one rundown from the "Blocks" part of the datablock.

First, find the "Tutorial Holder" rundown's block. This contains the game's tutorial, and its presence is hardcoded so we can't delete it.

Go to the start of the block, collapse it, and copy it. (Or, if using VS Code, you can use Control + Shift + [ to collapse the block your cursor is in).

Paste it at the bottom of the blocks.

Find the rundown that contains whichever level you'd like to use as a foundation. In this case, we'll use Rundown 6.

Collapse it, copy it and paste it at the bottom of the blocks.

Delete all the other blocks, aside from our two at the bottom (it's easiest to do this by collapsing them all). Once we're down to just our two blocks you might need to fix some formatting. There should be a comma between our two blocks, but not one at the end.

Deleting all but one level from the rundown

We only have one rundown and we want to keep only one level in it. Let's go with B2.

Collapse all the tier blocks.

Delete everything but B tier.

Confirm that the 2nd object in B tier is B2 "Contaminant" and collapse the tier blocks

Delete all but the 2nd block.

B2 has now become B1 and is the only level in the rundown.

Deleting secondary layer

Contaminant is the only level in our rundown, but it still has a secondary layer. Let's thoroughly remove the secondary layer from the Rundown datablock. We'll have to remove quite a few sections, see the image below for what we have to remove. We need to remove the bulkhead information from the main layer, and also a bunch of stuff from the secondary layer. After we're done, the secondary layer should look the same as the third layer.

Deleting level layout blocks

Now we have to do the same to the LevelLayout datablock. We'll find the correct level layout ID and delete the rest.

In the picture above from our rundown block, you can see that LevelLayoutData is set to 162. That's our main layer level layout.

Open the LevelLayout datablock and find the block with this ID.

Repeat the same process as for our rundown blocks: collapse it, copy it, collapse all blocks, delete them, paste the copied block, delete the comma.

Remember VS Code has to process over 200k lines here so don't be too harsh if it lags a bit. Deleting at least a part of the blocks does have practical use here as VS Code and its plugins won't take time to load when editing huge files like this one.

There should only be a few thousand lines left in this file.

Modifying game setup datablock

Most of the work is now done, and we only have to do a minor tweak to the GameSetup datablock. Open it up and change the "RundownIdsToLoad" to only contain the rundown ID for your rundown. The rundown's ID is the "PersistentID" number at the bottom of the rundown's block.

Regarding changing IDs

We talked briefly about changing the ID of our rundown block earlier. While this is not a necessary step anymore thanks to GTFO API, it was originally agreed with devs to change all custom rundowns' ID to 1. If you did do this, you'll obviously have to change the "RundownIdsToLoad" to match.

You're also allowed to change the LevelLayout block IDs. If you do so, then you'll have to change the "LevelLayoutData" from the rundown's block to match.

Verifying

Remember to save everything.

Launch the game. You should now see only B1 in the rundown menu.

Drop into the level. You should now have only the one rundown, and the level itself should load just fine. If you have freecam or some other mods, you can use them to check what the level looks like more easily. See if anything has changed.

You should see some marker (all sorts of objects placed in the level, a whole different topic) placement differences, also the lack of the secondary layer.

Oh and we deleted the bulkhead key, controller, and the bulkhead door (which is now just a security door) from the main layer. If you want to restore that, you can do so by restoring these 3 fields from the original datablock we kept as a backup (you did keep some as a backup, right?):

• ZonesWithBulkheadEntrance - zones in same layer (main) that have bulkhead entrances.

• BulkheadDoorControllerPlacements - where to place bulkhead door controllers. If a zone with a bulkhead entrance does not have a door controller, the entrance will not require a bulkhead key.

• BulkheadKeyPlacements - where to place bulkhead keys in the layer.

Make sure you restore the ones under MainLayerData and not secondary. You can also just copy the whole MainLayerData block.

Later sections of the guide will assume you restored these (or didn't delete them to begin with).

If you did actually restore and verify again, the terminal near the bulkhead might be near the zone door in front of the door controller now.

The Rundown, LevelLayout and GameSetup blocks are now cleaned up and we can move onto the 2nd step in the guide.

This wiki is connected to the .

So you want to contribute to our wiki! Great! Let's get that forbidden knowledge on here with this simple N step program.

Step 1: Follow this link to join as an editor of the wiki.

Step 2: Sign into GitBook using whatever account you'd like your edits to be credited to

Step 3: Click the big EDIT button in the top right hand corner of your screen.

Step 4: Edit the pages to your heart's content (but do split unrelated changes into multiple requests). If you would like to bring your edits to the next level, consider reading up on the markdown format GitBook uses.

Step 5: Submit your changes for review using the button in the lower right corner.

Step 6: Method 1 (preferred): join the modding discord and send a message in the wiki channel about your change request. Questions and suggestions will be discussed there.

Method 2: (if you don't want to join discord) The change request will be reviewed and you may receive comments with questions, suggestions, and discussion. They will have to be resolved before merging.

Step 7: When all discussion is resolved, the change request is merged.

Thanks for helping the community by spreading your knowledge!

Overview

Not all fields have functional use in-game. Some are used just to display something, like level descriptions for example. Now that we have isolated one level in our rundown, let's change some fields to distinguish it from R6B2.

Naming the blocks

First let's change the "name" fields of both rundown and level layout. As we know, this is one of the fields shared by all datablocks and must be unique in the file. It is never visible in-game without mods, but having good names helps with readability and lets us describe the block. This is especially relevant here since JSON has no comments (although there are ways).

The exact names are up to you. I can only try to give a few tips, whether to follow them is up to you:

• Keep a consistent style of naming.

• Describe what the block is concisely. A longer name is better than a shorter one that has no meaning.

• Don't use abbreviations you might not remember.

Here are the names I chose.

This is the only field we're changing that's usually invisible to the players.

Changing data displayed to the player

Remember a lot of text fields are of the LocalizedText type, these can be both numbers and strings. If you want localization in your custom rundown you can use the LocalizedText type, in this guide we'll only use strings. You can always check the original text you're changing by looking for the ID in TextDataBlock.

Let's mark the fields we'll focus on:

• In rundown datablock:

  • "Title" - the displayed title of the rundown;

  • "SurfaceDescription" - displayed when clicking the "intel" button (nobody reads this though);

There are more but this is enough for now.

Since this all has no impact on gameplay (except ZoneAliasStart but that has minimal impact), the values are up to you. Here's what I used:

The results:

There are more fields related to visual data in rundown and level layout but with this we have enough to make unique vanilla-style rundown & level information. We can move on to the 3rd step in the guide.

Overview

This page is for people who want to get started with modding GTFO but don't know anything about it. If you're a programmer and you want to write actual mods, check out the introduction to .

Always remember that the official discord server is not the place to discuss anything modding related. Talk about it in the instead.

Prerequisites/Recommendations

Datablocks are all stored in JSON, you need to get familiar with this text format. Basically it's a way to have data as text stored in a way that can be read by both humans and computers. There's an infinite number of guides and ways to learn JSON. One place to start is .

The text files can be edited even with notepad, but for your sanity I recommend using something more advanced. The most common option here is . It allows you to easily manage entire folders of files at once, provides syntax checking, highlighting, easy searching, replacing, and lots of other good stuff. You can also add some vscode extensions for yourself such as to further make your life easier. Either way you'll be looking at massive amounts of JSON so best be prepared.

Knowledge of C# or programming in general can definitely help but is not required for modding using datablocks.

RegEx is very helpful for quickly finding and replacing data.

Introduction

Datablocks (also referred to as blocks or db) are GTFO's way of storing various information about the game. While I'm positive they don't directly edit the files ever, them choosing JSON is a convenient way for modders to read and change that information. What is stored in datablocks is completely in devs' control. Sometimes it may seem arbitrary what is stored there and what isn't, so some modders make plugins that allow even more control over the game.

Some examples of what we can find in datablocks:

• The stats of weapons, enemies, and players (HP, speed, damage etc);

• Terminal logs and passwords;

• Enemy population in levels;

Everything that is stored in datablocks can be edited. As previously stated, the developers control what is stored in datablocks, making them limited in some aspects. Some things have set rules that you cannot see in datablocks. Some things may be very hard to get to work as expected. Some things cannot be done using only datablocks. Learning to use them can take a lot of effort, and you will have questions, so don't hesitate to ask in the .

MTFO Installation/Setup

For a quick, hassle-free setup it's recommended that you use , a mod manager built to work with Thunderstore.

Installation with R2Modman/Thunderstore mod manager

1. Install the latest version of the mod manager

2. Launch the mod manager and select GTFO

3. Create a new profile and name it

Best practice is to create one profile per rundown so you can switch between them easily.

You can find the profile folder by going through the mod manager to Settings -> All -> Browse Profile Folder

Manual Installation

1. Download and , then follow their installation instructions (they should just require you to extract the packages in certain folders)

2. Run the game normally. To play vanilla again, you'd have to manually delete the mods (or remove/rename some specific files)

Getting the datablocks

Now that MTFO is ready, there are still a few things left to do to get datablocks

1. After installing the mods, launch the game once for MTFO config to generate

2. Move to BepInEx\config and open MTFO.cfg

3. Set "Dump GameData" to true, save the file

A few things to note:

• You can always regenerate the datablocks by just deleting them from gamedata-dump and launching the game again

• Disabling the dump setting is optional

• Only keep one folder of datablocks to load, otherwise you have no control over what's loaded

Get started

To get some familiarity with editing datablocks, we're going to do 3 things in this section:

1. Change a weapon's stats;

2. Enable a weapon from a previous rundown;

3. Switch the stats of an enemy to those of another.

You can test either after every step or all at once. A few tips before we get started:

• can be used to get a lot of information about blocks.

• LocalizedText is a special type that can both point to a text block and be read as a plain string.

• All enums can be passed as numbers or strings. I personally recommend using strings since they often give more information than plain numbers, but both work equally fine.

Remember, after initial generation, all datablocks should be located in GTFO\BepInEx\plugins\GameData_XXXXX\

Changing a weapon's stats

Let's keep this one simple. We're going to find the pistol's stats and change its damage to 100 and firemode to automatic. Weapon stats are kept in Archetype datablock. There are multiple ways to determine which block belongs to the pistol, but for now let's "assume" that the correct block is the one with the name "GEAR_Pistol_Semi_v2".

• Note: lines under 3155 and 3184 are collapsed in vscode editor to reduce clutter. You'll see this used a lot.

Among the fields we can see the ones named "Damage" and "FireMode" (the latter is an enum and will appear as a number if you're not using enums as strings). Change the damage to 100 and firemode to auto. Additionally, let's change the public name to "Balanced pistol" so we can see the custom blocks were loaded without having to drop into a level.

After saving, you can launch the game and test, or you can test after all the changes.

Enabling a weapon from a previous rundown

All datablocks share some fields. One of these fields is called "internalEnabled" and basically determines whether that block exists for the game or not. To enable a previous weapon, the only thing we need to do (assuming the old blocks have not been broken by game updates) is set this field to true in the correct places. For now we are going to enable the combat shotgun. Open PlayerOfflineGear datablock and find the block named "ShotgunAuto". Set "internalEnabled" to true on that block.

When you save this and launch the game, the combat shotgun should be available under special weapons.

Switching the stats of an enemy with those of another

Aside from "internalEnabled" there are 2 other fields that are shared by all blocks. One of them is "name" which you don't see used in-game, but it does help identify the block you're looking at. The last shared field is "persistentID". This is the field used by blocks to reference other blocks. Note that "persistentID" and "name" cannot repeat in the same file.

Let's change a striker's stats to those of a big striker's using these references. The main block of an enemy is Enemy datablock and the stats we're looking for are stored in EnemyBalancing datablock. The reference field is named "BalancingDataId".

To change the stats we just need to find the big striker's balancing data, get its persistentID (in this case it's 16), and set it on the striker data.

And that's it, wave strikers now have the balancing stats of a big striker. If you want, you can also change the balancing data of "Striker_Hibernate" as well for easier testing and more suffering.

• If you want to undo all your changes, you can delete the edited files and let them regenerate.

• If you're wondering what fields do what, you can either interpret the name or check out the .

• Most fields that hold references to other blocks are of the type "uint" aka "UInt32".

Introduction to errors

If you edit datablocks enough, you're bound to run into errors, also called exceptions. There's an infinite number of causes so it's impossible to know all of them, but it's important to know where to start looking for information, at the very least so you can pass on more when looking for help. If you do run into something you can't fix yourself, you can ask in the in the modding discord.

When launching the game with mods enabled, you'll see the BepInEx console as a separate window. This console is useful for many things, but most importantly for users, it shows errors in red text. All logged messages have the type and source as a prefix. E.g. [Error: MTFO] error message shows that there was an error caused by the mod MTFO. Most of the time errors are caused by the game itself, in which case you will see [Error: Unity] as the prefix. In this case I would always recommend to look for the error in the game logs instead of BepInEx logs. These are located in %userprofile%\AppData\LocalLow\10 Chambers Collective\GTFO If you closed the game already, their name will be of the following format: GTFO.[Date].[Time]_[PlayerNick]_[NetworkStatus]. If the game is still open, it'll instead be GTFO.[Date].[Time]_NICKNAME_NETSTATUS. For the most part you will be looking for the most recent file created. While in bepinex console the error message is one line, the game logs provide the stack trace, which is the full source of the error and often provides much more information than just the error message.

Let's take a look at an example. BepInEx console shows this error message:

While the game logs show this:

NullReferenceException is one of the most common errors that says next to nothing about the cause. All we know from BepInEx console is that an error happened. But the game logs show that the source is from melee weapons. Even if this error doesn't give enough information to you, it will allow other people to find the cause if you ask for help.

Also note that some errors can cause even more errors. When debugging, check the oldest errors first.

Remarks

• GameDataBlockBase, trying to save x without being setup error is most likely caused by errors in your JSON. Check your syntax and if you pass incorrect types, such as string instead of int.

• You can use git to track changes. This allows you to easily see everything you changed at any time, which is useful for many purposes and especially debugging.

• If something doesn't work correctly, check if your mods are up to date. Rundown updates often break them.

Recommended content

Check out the main page for general information about datablocks. Learn to use datablocks reference to get information about specific datablocks.

Once you have some experience, you can check out the if you're interested in making levels/rundowns.

Overview

As you probably already know, levels in GTFO are generated, and their data is stored in datablocks. In terms of difficulty, editing levels is between intermediate and one of the most advanced things in datablocks. This guide is not meant to teach all thing related to level editing, but it will hopefully give you enough to get you going in creating your own levels.

This goes without saying, but if you're looking to learn, I highly recommend editing and testing the blocks yourself as you read along.

Throughout the guide, I'll be posting datablocks or parts of them. If you move along, you won't have to copy-paste them, but you can verify they match using for example.

Prerequisites

At this point you should be familiar with JSON, datablocks, and the following:

Recommended:

• or some other modding toolkit

Guide content

The guide is made of 5 parts:

1. Isolating a level

2. Editing rundown and level metadata

3. Adding and editing zones

The datablocks we work with in this guide:

• Main:

  1. RundownDataBlock

  2. LevelLayoutDataBlock

Useful links

• (OriginalDataBlocks)

• (but actually just level layout editor)

Overview

Warden objectives are a core part of any level and they're quite convoluted complex just by themselves, especially with the new event system (that we won't look at). Our level is quite a nightmare by now but we're still not done torturing it for science. It's time to change the warden objective.

But seeing how in the next part we're adding a secondary sector, here we're going for 3 objectives:

1. Uplink terminal for main;

2. Empty (unsolvable) objective for secondary;

3. Reactor objective for secondary.

Uplink terminal

Alright, so, as you might guess, the zone we'll be adding this to is the zone we created, and we're looking for it to land in the 2nd terminal (further down the zone).

Funny enough we just yeeted an uplink objective with the original level's secondary layer, so let's steal that and also steal the text info from an uplink made before localized text became a thing (because we're not looking to deal with localization right now).

We'll open up the WardenObjective datablock, and start by copying objective 274 (the original secondary objective) and the Header - GoToWinCondition_ToMainLayer fields from 19 (an uplink objective without localized text). After changing also changing the ID and name we get this:

Let's go through a bit of analysis before we change it. Know that not all fields are relevant and not all fields behave the same on different objectives.

• Type is . Here it's 8, terminal uplink.

• The info fields are straight-forward and can be easily checked in-game. Pay attention to strings in capitals in [] clauses, these are special values that get converted in code.

• Waves during uplinks are set to settings 44, population 1. Population is standard, settings are set to standard and special only, single wave (10000 points), 5 enemies per group and 8 seconds between groups.

The terminal picking and exit condition (elevator or exit geo) are set elsewhere, we'll look at that later.

Pretty much all of these settings are fair enough, we just need to change the uplink count to 1 and increase the exit scan speed.

Now let's configure the objective in rundown db.

Only 2 things to change here - the datablock id and the local index, the rest are already correct (make sure you edit the ObjectiveData inside MainLayerData).

Note that ZonePlacementDatas is a list of lists. If I recall correctly, the outer list is for different uplinks (if we had kept 2 uplinks for example), the inner list is for different locations for the same uplink (rng between runs).

The only other thing to note is WinCondition. 1 means exit geo. This field only affects info fields to my understanding, and only for the main layer. The actual exit location is always the exit geo if there is one.

A quick test shows that all went according to plan, just one thing was forgotten - a door towards exit was previously locked until the objective was completed. We can copy that for our uplink objective and edit the text or we can disable the lock. I'll go with the latter and set PuzzleType to 0 on zone 9.

Empty objective

This is used for times when you don't want to deal with creating an objective but still need one (i.e. while you're still making a level) or when you have other means of completing the objective.

We're looking to make an objective as simple and universal as possible and in my experience the easiest way is a gather small items objective that spawns no items. The only thing you need to do once you have this block is set the objective ID in rundown db and you're done.

The block in question:

We'll try this out once we get to making the secondary sector.

Reactor

Reminder that you shouldn't make objectives before you have the level.

Before we get into any specifics, remember that reactor is an objective heavily relying on waves. If you've read the heat explanation in the mod , you'll know there's a heat bug in base game and reactors will definitely mess with that, so you not only have to build your waves around the bug, it'll also affect the rest of the level and all other attempts until the game is restarted.

Let's steal R6D1 objective and text info from elsewhere. Reactor blocks are pretty huge thanks to each reactor wave defined separately, and this one also has a bunch of events. We'll have to analyze it in parts. Here's the whole block before editing:

Reactor objective type is 1; text fields are self-explanatory so we'll skip them.

Immediately on landing (EventsOnElevatorLand) we have 2 events, the first turns the lights off and the second adds a subobjective. We don't need either so we'll remove those events.

Then we have EventsOnActivate, I believe run upon completing the scan after inputting the startup command. Weirdly enough only one event seems relevant here - turning the lights on. The others don't seem like they would do anything - the 2nd event is type 0 (none) and the last is type 10 (StopEnemyWaves) but there are no waves to stop as far as I know. Maybe I misremember, or maybe there have been some changes to the level during development and they didn't get cleaned up properly. Either way we need none of these so we'll remove them as well.

Since we're on events, let's check the last remaining event in this block as well - "Events" under the 4th reactor wave. Usually the zone-unlock events for verification would be here, but R6D1 doesn't do that. Here we have one event - type 5 with trigger 1 - sound on start, with a timed delay. Looks like this is the tank spawn roar. We're removing it.

One last thing before we look at reactor waves - DoNotSolveObjectiveOnReactorComplete. This is used to make R6D1 seem like it's a terminal command objective when it's actually a reactor. Set this to false so the objective is completed after reactor.

Alright, reactor waves it is. Here's the first block:

The first settings are all about time. Time for warmup, wave, and verify phases, as well as for repeat phases marked as "fail".

VerifyInOtherZone determines if you get the code on HUD or if you have to find it on a terminal. ZoneForVerification is the local index of the zone to place the code in. No placement data here, which means we don't get to choose weights.

There's 4 waves total here - settings, population, and spawn type are all familiar at this point. The only thing new is "SpawnTimeRel" - when to start spawning the wave. Say, 0.55 would result in 80 * 0.55 = at 44 seconds into the wave. Remember that settings can delay spawn, groups don't all spawn instantly, spawn cap exists etc. so you have to be careful about not overdoing the waves, otherwise people will have to fight through the verify time.

I won't dive deep into the settings and population. I can guess that they'll mostly be very specific in spawn timing, enemies, and especially population points.

The other 3 blocks are the exact same thing, just different numbers, so there's no need to analyze them for me. This is all up to level design and balancing, and we don't do that here. I'll delete the 4th wave and leave everything as-is.

Here's the final block:

Time to finish this.

Overview

Finally, the last part of the guide. level guide using as many mods as possible when?

We have already settled on the objective, but we have to make the sector before we apply it. We're not going to generate a third sector because it's the exact same process.

Setup

Start with making a new level layout. For a placeholder let's copy the block we have, delete all zones but 0, and clean up all the nightmares we added. Change the alias start to 200, and remember to rename and change ID.

Here's our placeholder layout:

We already have a placeholder objective, so let's move straight to rundown db.

Enable the secondary layer, set layout, set to build from zone 4 in main layer, set datablock ID to the unsolvable objective.

If you want to lock it with a bulkhead key, all you have to do is add an entry to main layer bulkhead door controller placements and set it to spawn in the same zone as the bulkhead. Remember to also take care of keys in that case. I'll go with secondary always unlocked.

Quick test to see if secondary did spawn and it did. Time to generate the proper layout.

Layout

Let's keep this small, to reactor basics. The first zone is fine. We're adding a bridge and a reactor geo for a total of 3 zones.

First thing to do here is find the custom geos. Remember you can only spawn something as custom geo if it is in that complex resource set's custom geos. In rundown db we can see we're using ComplexResourceData 1. Open ComplexResourceSetDataBlock, find ID 1. To make it easier to find what geos we have, I'm going to use breadcrumbs to find the custom geos:

For the most part we care about the Objective block. I'll copy that to a new file to make search easier.

I can see reactor gives 3 results and bridge 0, and I'm not sure the 3 reactor results are actual reactors anyway. Time to consult the (although the search in google docs doesn't seem to be the best search ever).

As suspected, the 3rd result was not an actual reactor geo. I'll take the first reactor (geo_64x64_mining_reactor_open_HA_01) and the classic reactor bridge (geo_64x64_mining_refinery_I_HA_05). I can see that both of these are in complex resource set 1 so I don't have to modify it.

Right, so, copy the first zone 2 more times, fix local indexes, add custom geos, and test.

Now this took me a few times with LG being finicky, but I got both geos to spawn in the correct directions. If you want to try for yourself with just pointers, check out how the map generates and adjust start positions and coverage. As I understand (I don't), LG will quit trying if it can't generate what it wants, and it can also skip generating the custom geos if it fills up the coverage size too early (normally when custom geo is set, that's the only thing that generates in the zone, but parts of random-generated geos can carry over from previous zones, filling up the size).

LG is rocket science that deserves its own guide if any poor fool ever bothered to make one, and on top of that it's still changing, so we won't dive too deep into why things happened here.

Anyway here's the level layout I got:

Some results:

If you have your own working layout, you don't have to copy mine. Note that there are some questionable terminal placements in there.

Objective

We've already made the objective, so we just need to apply it in rundown db and test it out. If it works, we don't have to do anything here.

Future me says it works fine. Excellent. The secondary layer is complete.

Final test

With the nightmare fully assembled, it's time for the last test. Go beat the whole level.

I'd love to insert a full video of me clearing it with Calle QA recording in the background, game muted (except for the combat music mod playing looming dread), cheats enabled, but I'm not gonna do that.

Afterword

Finally done, feels like this took forever to write. Hopefully it wasn't so bad to get through as a reader. I hope you learned something, especially something about how to learn from existing examples and debug. Remember, you're not even limited to base game blocks. If you ask nicely, I'm sure most modders will let you use their blocks as examples.

I also highly recommend checking out the various different mods that expand datablock limitations.

Now if you'll excuse me, I need to go cast this abomination of a level into oblivion and then turn myself in. Good luck on your future endeavors.

Overview

Git is a version control system. That basically means you get to see all the changes you (or someone else if you're collaborating) have made to files in a repository. Git is commonly used for storing files online and even publicly for anyone to see, such as on GitHub, but it's fully functional for offline use as well. For now, we're only covering offline use.

In VS Code, the main view for Git is the source control view, seen at the top left side of the window:

The changes are shown on the files themselves:

...and their contents, marked as red for deletions and green for additions:

How useful this is depends on how you use it, for example:

• You can easily return to a version of your content that you know for sure is working.

• You can undo one little change at a time to see where exactly things went wrong.

• You can keep it as a form of documentation for the changes made over time or the changes required for certain things to work.

Using Git is completely optional but (speaking from experience) it can save hours wasted debugging and even dropped/restarted levels (for rundown developers) when no fix for problems is found.

Installation

If you haven't installed git yet, the source control view will show something like this:

Download and launch git installer from there. Most users should use 64-bit standalone installer.

When going through the installation, most default options should be fine. Just one change you might want to make:

Either way, for basic git use none of these options should matter much.

Now that git is installed, reload VS Code and open the folder you want to start working with, such as a fresh MTFO dump (moved to a folder where mod managers won't mess with it), or your own rundown if you have one. The guide will use .

First step when working with a project offline is to initialize the repository. If you open the source control view now, you should see something like this:

We're almost ready to start using git, but first there's 2 commands to run. We have to set a user name and email for commits author tracking. For offline repositories this shouldn't matter much and can be changed later, but remember that you can't change author information on existing commits. To run the commands, open a new terminal in VS Code:

In the terminal, input the commands with your own values:

git config --global user.name "somename"

git config --global user.email "somename@gmail.com"

Now you're ready to start using Git.

GitLens extension

VS Code has extensions that bring additional functionality to the editor. GitLens is one such extension for Git:

It will not be covered here, but if you see some functionality in the guide that you don't see in your own VS Code, it likely comes from this extension.

Basic Git use in VS Code

Now that we're ready, let's initialize the repository. Once it's done, the source control view should list all your files as new since we haven't started tracking them yet:

Let's stage and commit all of them as the initial commit:

1. Press the + icon to stage all the changes (make sure you press it to the right of the "Changes" text instead of a specific file) - you're selecting the files to include in the commit

2. Write the commit message - "initial commit"

3. Press the commit button to finalize the commit.

Now the source control window should only show the "Publish Branch" button. This is an offline project so we're not going to do that.

There may have been a lot of unfamiliar terms used just now. The git glossary is (google is also an option), but let's look at some fundamentals:

• Stage (verb) - to stage a change is to prepare it for a commit, i.e. include in the commit. Git allows you to select just the changes you want instead of everything that's been edited (including selecting only specific parts of files).

• Commit - a snapshot of the hierarchy and the contents of the files in a Git repository; a single point in the Git history. A commit is like a specific version of your project.

• Commit message - a description of the changes made in a specific commit.

Practical use

So now we kind of know how to work with Git and it does track the changes in our project correctly, but how do we make use of it? For starters, when do we commit? And what commit messages do we use?

That's completely up to you. If you are developing a rundown on thunderstore, one thunderstore version can be one commit, with commits like "V 1.0.1", "added C1" etc. You can make it more detailed, for example "adjusted ammo balancing for C1", "added shadow baby charger", "added hel hammer launcher". There's probably just 2 things I could mention:

• Generally, smaller commits are better than large commits - keep them more focused, easier to define and less progress lost when reverting;

• Make sure your changes work before you commit. A commit with a broken project version is the last thing you want.

Now let's say that we did indeed break something (but didn't commit) and want to use Git to help fix it. The first straightforward way is to see the specific changes you made and change them back. We don't want to revert the entire commit or entire files, just some one line that's probably broken. We have 2 easy ways to do that.

For the first, go to source control view and select a file with changes, then find some specific change:

Click the arrow in the middle to revert the change:

The change should be reverted, just remember to save the file.

For the second method, go directly to the changed file and line. You should see a blue line near line numbers:

Click it. You should now see the changes inline. At the top right there should be a revert icon:

Click it to revert the change.

In 2 other common cases where you want to revert a whole file or all the changes since the last commit, it's easily done through source control view. All you need to do is click the revert icon on a file or next to changes:

Reverting that specific change would restore the deleted file.

Now if you break your project and don't remember what was different when it worked, you can simply look and see. Hopefully this prevents some painful debugging for you.

Git keeps the entire history of the project since the repository was initialized, so you could go back to a version of your project from years back if you wanted to. You can also look into storing a project privately or publicly online as well and even working with other people.

Since R6 is gone now and so are the source blocks, some things have changed and the guide may be hard to follow. You may want to see what blocks were used when originally developing the guide, or perhaps you just want to check/copy a specific block. Either way, the guide blocks are now stored on git:

You can also check out the commits to see any changes made since initial release. I will also cover some changes here as well.

R7 update

Since MTFO now supports loading only specific blocks (also to fix some crap broken by R7 like players' shoes, shooters with pouncer stance and so on), the blocks have been minimized.

Preface

Overview

This is the meat of the guide. We're going to add a zone, add sleepers, alarms, blood doors, spitters, respawns, resources, a generator puzzle, a pitch black zone, fog.. there's tons of stuff we can do here.

However, as always, we can't explore everything or we'll be here all week (and this part is already really long). I'll try not to go into too much detail on the meaning of fields this time either, since you can check the relevant blocks' reference to see what all the fields do.

First, in Visual Studio, click Project > Add Class and change Class1.cs to Patch.cs

Next replace the pre-generated code with the following

After that go back to our Plugin class and add the following line to your Load method

new Harmony("NewbiePluginAuthor.MyFirstPlugin").PatchAll();

You can now compile the plugin and when you click the About Rundown button in-game you will unlock a new rundown

Explaining how this works

The line we added to our load method means that when the plugin loads it will create a Harmony instance and apply all the patches it can find (note we supply Harmony with the same GUID we saw earlier). The [HarmonyPatch] attribute we gave our Patch class helps Harmony find it (though it isn't always required depending on how you go about patching).

When Harmony finds our Patch class it'll then look for any patching methods. The attributes we gave to the MyPatch method label it as such a patching method. The [HarmonyPostfix] attribute tells Harmony a little about how we want to do our patch while the [HarmonyPatch(...)] attribute tells Harmony what we want to patch. In this case it specifies that we want to patch the Setup method in the CM_PageRundown_New class. Our patch replaces the action of the about rundown button with our own code.

First create a new project and choose "Class Library" - "A project for creating a classlibrary that targets .NET or .NET Standard"

Then write a name into the Project name field, such as "MyFirstPlugin" and click "Next"

Next ensure you have ".NET 6.0 (Long-term support)" selected as your Framework and click "Create"

Click Project > Edit Project File and replace it with the following

Finally save the changes to the csproj file

1. Download Visual Studio by click "Free Download" underneath the Community section

2. Run "VisualStudioSetup.exe" from your download folder

3. Continue through the process until you get to the "Installing" window with the "Workloads" tab

First Click Build > Configuration Manager in Visual Studio

Then in the Configuration Manager window, change Active solution configuration from "Debug" to "Release", then click close

Next Click Build > Build Solution

This is a very basic summary of patching. See the for more details.

Why patching

Typically, when making a plugin, developers will want to change how something in the base game behaves. Of course, in order to change the normal behavior we need to know what piece(s) of code in the base game determine that behavior so that we can target them with a patch. This means that part of the challenge of making a plugin is determining which method(s) to patch in the first place! If you're unsure how to go about determining which methods to target consider asking in our .

In Visual studio right click "Class1.cs" in the solution explorer and rename it to "Plugin.cs". Choose "Yes" to rename all references

Copy and paste the following code into "Plugin.cs" replacing the entire contents of the file

What is Wwise?

Audiokinetic Wwise is a software development kit (SDK) for audio content creation and integration in games and other interactive media, the tool used by 10CC to integrate audio into GTFO. Wwise also includes a soundbank system, which allows developers to organize and access their audio content, using sound events. To add custom sounds to GTFO, we will have to use Wwise and create SoundBanks within the application.

What is a SoundBank?

A SoundBank is a container of sound events, and the objects and audio data required to play them. GTFO uses SoundBanks created by Wwise to play all of its audio in-game, ranging from its dynamic music system to enemy sound effects.

Who is Mr Bro?

Hi there, my name is Mr. Bro and I'm a big fan of the video game GTFO. Everyone has been asking for ways to add custom sound and here is a guide on how to do so! Looking into it I have found a way how to use Wwise to create custom soundbanks and have created a plugin to put these soundbanks into GTFO. Personally it was very difficult at first, but I look forward to hearing feedback from other players and continuing to improve my creations!

Step 1: Download the Wwise launcher from the link below. From inside the launcher, download Wwise version 2017.1.9.6501.

You also probably want to use audacity to convert audio files to the .wav file format, because that's what Wwise requires. The download link is below.

Step 2: Using Wwise version 2017.1.9.6501 create a new project, and uncheck all of the asset groups, none are required for our SoundBanks.

Step 1: In the project explorer, right-click on the Default Work Unit in the Actor-Mixer Hierarchy, and in "New Child", select "Actor-Mixer". Name this Actor-Mixer "SFXmixer"

Step 2: Right-click SFXmixer and create a new folder, and name it whatever you want. We will be putting all our sounds into this folder.

Step 3: Drag your .wav files directly into this folder in the hierarchy inside Wwise. It should prompt you with import settings, click import.

Step 4: Click on your sound, and in the Sound Property Editor, click on the "Positioning" tab. Check the "Override parent" box.

Step 6: Change the positioning to "3D". (Note: You can change the volume of your sound, or make your sound loop continuously in the "General Settings" tab)

Setup and playback

1. Download and install foobar2000

2. Download and open

3. Open foobar2000 and choose File > Add Folder

4. Find and add the following folder: ~\Steam\steamapps\common\GTFO\GTFO_Data\StreamingAssets\GeneratedSoundBanks\Windows

5. Open the SoundbanksInfo.xml in a text editor to see what audio files the game uses

6. In foobar2000 search for the file id with Ctrl + F

7. Double click the audio to listen to it

Converting files

1. In foobar2000 right click a track

2. Choose Convert > Quick Convert

3. Choose an output setting and click Convert

Step 1: In the "Events tab", click on the "Default Work Unit" in the "Events" folder, and create a new "Play" sound event. Click on the "Play" sound event you created.

Step 2: Click back onto the "Audio" tab, and drag your sound from the hierarchy into the "Target" box in the Event Editor. (Note: This Event Editor will only display given you clicked on the "Play" event in the Events tab)

Step 1: Add BepInExPack_GTFO, MTFO (if you don't have them already) as a dependency to your profile/mod.

Step 2: In your profile, add the .bnk and .txt file to the path: