The Ultimate "SRB2 Frequent Issues" Troubleshooting Thread

Look for latest-log.txt.
It should be in the same folder as srb2win.exe, i.e. where you installed the game.

This file is your console log. It holds everything that your console has printed over time.

Also in the same folder as srb2win.exe.

The RPT file is sort of an error log. Everytime your game crashes, it appends to this file (or creates it if it doesn't exist) information about the crash, like what was it doing code-wise before it crashed, along with what other modules (read: not game modifications, but DLLs like drivers and others) were loaded during the session.
May not exist in some OSes.

If you're trying to recreate a crash, make sure to start from a blank/non-existant RPT file. That way the file will only be populated by the crashes that you are trying to get instead of any crashes that may have happened before that.

This is where the RPT log comes in.
The game is built off an old codebase. As such, some things may decide to break at random.
It can be hard to pinpoint the exact cause of such a crash, but the RPT log may give the developers some insight as to what could be going on at the time of the crash.

Consider reporting the issue somewhere (the project's Gitlab is a good spot, but you can also do so in the this message board's Bug reports, or even the Discord's troubleshooting channel), and include both your latest log and RPT log so the developers can attempt to figure out the cause of the issue.
Note that a solution may not exist.

Depending on the issue, the game may not attempt to write to the RPT file - This is most commonly true with issues that don't cause the game to crash with an error window, such as hangs or forced exits.

See the bottom of this post.

Are you playing on https://srb2web.surge.sh/ ?
That web port is essentially busted - It is missing critical files.

It is unnatural for SRB2 to take longer than mere seconds to start.

Check the last line of the log.

If it is I_InitJoystick()..., the cause of the hang is usually caused by a joystick.
The cause is unknown as of yet.
Try unplugging all joysticks and launch the game again.
You might need to restart your computer.

This error is exactly as it says - Windows reports the graphics renderer is "GDI Generic", which is usually telltale that your computer can not access your GPU.
If it isn't because you lack a display renderer (how!?), this can often be caused due to missing drivers.
Update your display drivers. You may need to visit your video card's manufacturer's website, if applicable.

Your computer does not support OpenGL 2.x and above.
Update your drivers.
If they're already updated, your GPU simply does not support a newer version of OpenGL.

Go where srb2win.exe is located. From there:
1) Right-click the executable.
2) Click Properties.
3) Click the Compatibility tab.
4) Click Change high DPI settings.
5) Tick Override high DPI scaling behaviour..

(Thanks DylanDude)

SRB2 has a known strange incompatibility with this particular controller - Specifically, non-Xinput controllers.
There are a few workarounds. One of them involves the use of x360ce to make Windows think this is an XBox controller.

Same as previous point.
Yes, it's that buggy.

Press BACKSPACE on top of the control to unbind it.

If you bound the wrong button to an important control and you can't get rid of it, you can try to edit config.cfg (found in the game's folder - you can open this with Notepad).
Find the offending control and remove the line.

If that doesn't fix it, you can go nuclear and delete the file - Note that you will lose all of your binds and options this way.

OBS's game capture functionality hooks onto the game to pull what it is rendering.
Discord... not sure, but perhaps does the same thing.

The game isn't particularly stable when something is hooked onto it in this manner.
Consider using Windows Capture in OBS, or simply not streaming in Discord.

This issue is caused by trying to load a pre-2.2 character mod into 2.2.
SRB2 2.2 and on changed the format required for character sprites (now using the new sprite2 system), causing older mods' character sprites to be unrecognizable to the game.

Make sure you are playing a mod intended for the current version of SRB2 (make sure you didn't pull the mod from the outdated releases forum, for example), or that you are playing with the correct version of SRB2 (if you're trying to play old mods with an old SRB2).

This issue is caused by some pre-2.2.9 mods that color HUD patches.

2.2.9 and on changed the required input values for the drawer.getColormap function.
A modder usually needs to use the constants provided by the game, in this case TC_DEFAULT, but many (including yours truly) opted to use numbers instead (-1). This is bad code practice, and what raises the issue in first place.

Welcome to Doom netplay. The game doesn't currently feature clientside prediction.

The input delay is proportional to the amount of latency you are experiencing. Try reducing your lag for a better experience.

This is a rather uncommon issue whose solution hasn't been found yet. SRB2's netcode is notoriously archaic.
It is believed that this issue happens when using tunneling services such as VPNs, Hamachi, or others. Try playing without those.

Usually helps to read the whole error message - The console may spew useful information.

Check that the Master Server address is correct:
Go to OPTIONS > SERVER OPTIONS..., then head to the bottom .
Make sure the Master Server address matches this one: https://mb.srb2.org/MS/0

Sometimes the master server goes down on its own volition. It isn't known for having 100% uptime, lol. Wait a few minutes and try again later.

This is usually caused by having a master server address set to something weird.

Just as the previous point, check that the Master Server address is correct.

If you just started hosting a server, advertised it on the master server, and haven't given the address to anyone... just wait!
Players often prioritize servers that already have several players, so it might take a while before someone decides to join your server. It's just how it is!

If you have checked and your server turns up as "Unreachable", or other players or your friends can't join your game and have told you so, see the next spoiler.

Before starting, make sure you know the difference between a local IP address and an external IP address.
Basically, any addresses that begin with 127, 10.0, 192.168 or 172.16 are strictly local (or are special) and are only relevant to YOU (and your local home network).
If you give such an address to someone, it will only point to a (potentially inexistent) device in their own network.


Make sure you have forwarded port 5029 UDP. This guide may help you: https://www.jameds.org/portforward/
This is usually the firstmost step required for hosting on any game with the classic client-to-server model.
This is not needed if you are joining a game.

If forwarding the port does not do it (or you can't, either because it's not physically available to you, issues related to the router not being yours, or you simply don't want to), you might want to attempt to make a firewall exception for the game.
Also check if your antivirus (if any (Windows Defender doesn't count)) is interfering with connections with the game. Sometimes it blocks them.


Due to the amount of causes that there could be for this issue (some very specific), as well as possible solutions you can attempt (some very specific), I can't list them all, and it might be out of scope for this post.
Consider searching for solutions yourself, and if that doesn't help, ask in the SRB2 Discord!

Make sure to triple check whether the code is actually throwing any error. Open the console, or check the latest log and look for any line that starts with WARNING or ERROR.
These warnings and errors are usually descriptive enough on their own, indicating the possible line that raised the problem as well as what the issue is.

If you can't figure out the reason, Google can help you out, or consider asking in the #scripting channel of the SRB2 Discord.
Make sure to include your code as text - don't screenshot the code. This helps other people check and test your code.

Make sure to be descriptive when reporting it, too. A generic "doesn't work, what do I do?" doesn't tell anybody what the issue is or what you want it to do.

Yeah, I borrowed and tweaked the guidelines from Mojang. These guidelines should be more or less global to any issue reporting procedure, lol.

• Write a concise summary that clearly states the problem. Avoid generic statements like "Help!", "It doesn't work", "It's broken" or "There's a bug", and instead use a short phrase to accurately summarize your issue. You may find it helpful to think about what you would search on to find the issue.
  • Include precise steps to reproduce the issue. Write down what exactly you did that caused the issue. Use a numbered list for the steps, so it is easy for someone else to follow.
  • After listing the steps, clearly state what happens, and what you believe should happen.
• Include the exact text of any messages (e.g., error messages) that appeared at the time of your issue. Avoid paraphrasing the error, always make sure to write exactly what you get.
• Attach screenshots to the report to showcase the issue more clearly (Press F8 to take screenshots). If possible, you can attach a short video as well (Press F9 to record a GIF, then press F9 again to stop).
• If you are aware of any situation in which the behavior you are reporting is used as a feature, mention it in the description of your bug report. This way the developers can decide if they want to keep the behavior or add a respective replacement for it.
• Take your time. Read over your bug report to make sure you didn’t leave out anything and that everything is clearly explained.
• If you are creating a mod and you encounter the issue. it may be helpful to make a minimal working example ( https://en.wikipedia.org/wiki/Minimal_working_example): Make a mod with the least amount of components/code possible that still produces the problem. Sometimes you don't need to include the big map or script you're working on.
  • Instead, make a new map/script, and attempt to recreate the issue from scratch. It helps to start with your map/script that causes the issue and start removing components until the game stops performing the issue. Then add the bad component back, and try to minimize the amount of unnecesary components that have nothing to do with it.