By RBR not launching at all, we mean that absolutely nothing happens (not even an error message) when you try to run the game either via RichardBurnsRally_SSE.exe or Start Game in RBRCIT. In RSRBR, RSCenter would do its usual preparations before
running the game but eventually it just stops loading and then nothing.
Now, unless you've knowingly turned off UAC (= User Account Control), safe to say the main culprit in about 95% of cases would be Data Execution Prevention ("DEP" to friends).
(A clean, unmodded game would never have this problem, it's only after
you start installing plugins or mods on top of it and Windows realises
that the game has been tampered somehow and is keen to overprotect you.
Worth noting that this behaviour is largely inconsistent, and can also
crop up when you least expect it.)
Anyway, on with the solution:
RBR/RBRTM/RSF: Run RichardBurnsRally_SSE.exe as an administrator + add it as an exception in Data Execution Prevention settings.
RSRBR: You need to run
exe-files like RichardBurnsRally_SSE.exe as an administrator + add them
as exceptions in Data Execution Prevention settings. IMPORTANT! In a 64-bit Windows, do not add 7z.exe to the exceptions.
How to run as admin: Right click on .exe (File Type: Application) → Properties → Compatibility tab → Check Run this program as an administrator → Apply.
The DEP settings: Type sysdm.cpl (.cpl refers to Control Panel) in the Windows search box and run it → On the Advanced tab go to Performance settings → Data Execution Prevention tab (check Turn on DEP for all programs and services except those I select and add RichardBurnsRally_SSE.exe to the list.)
Note! You shouldn't have to
restart your computer for these changes to take effect, but you may have
to do just that, so do not dismiss these solutions too quickly in case
nothing seems to improve at first try.
RBR crashing on launch but before the profile selection (usually with the RichardBurnsRally_SSE.exe has stopped working or Visual C++ Run-time Library error message) is obviously a more complex matter as it can so easily be just about anything but a DEP related issue – although it's not totally out of the question (an error message doesn't necessarily eliminate this possibility). However, you should still primarily focus on other possibilities like a plugin (the likeliest culprit) or a mod you may have installed a minute ago.
Like if you do suspect a plugin, it should be easy to test. Just disable it in one way or another (renaming the main file from *.dll → *.no is the easiest method) and run the game again to see what happens. Depending on a plugin, it could be a simple case of missing files in its own subfolder and reinstalling it may magically fix the issue (although if this was true, you really should consider changing or at least updating your archiver). If the issue persists after reinstallation or two, then it may be wise to begin eliminating a potential DEP issue next.
None of this probably helped you in any meaningful way and it wasn't meant to, let's get that right, as this is one of those issues where all we can really say is "good luck!".
One monitor: You've set the game's resolution too high for your system (compared to your monitor's max resolution). Edit the XRes and YRes lines in RichardBurnsRally.ini (again) to fix it.
Multiple monitors: As you can imagine, RBR doesn't have a built-in triple screen support like some newer car driving games do, so turning on NVIDIA Surround/AMD Eyefinity or equivalent solutions is very much required.
The primary solution is to do what you're told, so download and install DirectX End-User Runtimes (June2010). (Note that directx_Jun2010_redist.exe as such doesn't install the DirectX files, it only extracts the installer files to the location of your choice. The actual installation then begins by running DXSETUP.exe.)
open \Plugins\FixUp.ini: centerMenu=0 → centerMenu=1
To clarify: RBR doesn't crash, it continues to run normally otherwise, so unless you've muted the menu sounds/music you should still hear them.
The solution is to right-click on RichardBurnsRally_SSE.exe → Properties → Compatibility tab → check Disable desktop composition. That should do it.
So you can get out of the game, but you can't return to the game. This is perfectly normal as alt+tabbing works only in windowed mode (RichardBurnsRally.ini: fullscreen=false).
Before anything else, let's make it very clear what these issues are NEVER about: Visual C++. And also, you can easily make the game crash by impatient alt+tabbing during the loading screen, so above all, respect the game! #RespectRBR
Porridge has heard there are roughly three ways of how RBR would crash during a splash screen: 1) Loading freezes to about 25% and pressing any key exits the game instantly; 2) the Visual C++ Run-time error complaining about... well, whatever it complains about; and 3) loading stops at 50% because you amateurishly forgot to import the model to \Cars (in fairness, from 50% onwards, it should "always" be about the car). There may be some subtle variations to these but porridge wouldn't know because RBR has never crashed on him.
Generally writing, the problem is with either the car you selected or the stage you're going to. Or both. Or something else entirely. Simple as that.
For a small minority of gamers certain stages – most notably Semetin – are known to crash during loading screen when they are driven more than once in a session/rally. Other less talked about stages are Carvalho de Rei and Verkiai. (Although at time of writing, porridge has already forgotten most of this topic).
The first recommendation would be to delete RBRTestPlugin (dll + subfolder in \Plugins), and if you're VERY lucky, it may help things considerably, but the reports do show that for the vast majority the crashing will continue, even if without the infamous Debug Error! message. But still, it's worth trying regardless. (Removing RBRTestPlugin may stop you from running the game, but the first chapter should help you through that.)
To further solve these crashes, WorkerBee chipped in by adding a feature called Enhanced Trackloader in FixUp 3.0. However, it isn't an automatic (global) change when it comes loading stages as it does require the user to split the "problematic" lbs files to new .lbs and .lb2 files with splitlbs.exe that can be found inside FixUp's \bin folder.
But does it work?
No-one knows, the fix remains largely speculative, at least we are not aware of anyone with the problem having even tested it. After all, online plugins like RBRTM do not currently support splitting the lbs file for online rallies (lbs files are CRC checked too), so if it did work, it'd only be useful in offline driving. More info: here.
So, to lower the threshold for gamers with techno fear, let's split Semetin 2009's lbs files as an example:
First we're going to find out the ID of the stage from \Maps\Tracks.ini → Semetin 2009's ID is 582.
Copy files track-582_M.lbs and track-582_O.lbs to \Plugins\fixup\bin.
Drag them one at a time onto splitlbs.exe (splitting multiple files doesn't seem to work).
→ splitlbs makes a backup of the original by adding an extension ".orig" + splits the file into lbs and lb2 files
Cut the newly-created lbs and lb2 files and paste them back to \Maps.
(Nov 2020: Added the 2nd point based on information shared by heartbeat60 and Igor Borgacci, thanks guys!)
If we were to leave possible antivirus and Windows 10 features aside (that can often be countered by using the windowed mode, or – and this is quite revolutionary – by adjusting their settings) and focus purely on RBR, then you may find the culprit(s) from the following:
1) Flawed sound or co-driver mods, often self-inflicted by some heavy modding. For instance, a single pacenote would crash the game if its Snd0 line is missing (the crashing should happen every single time when that particular pacenote is about to be triggered).
2) For some gamers – by no means everyone – playing without VSync can cause freezing/crashing that would usually occur at specific points but not necessarily on every run of stages such as GB Sprint Extreme and Swiss (they are the known examples, there may be others).
That's normal because any changes would need to be saved into the
profile (like MULLIGATAWNY) too, so changing settings during a stage is
only meant for temporary changes. The only way to actually save your
profile is via Options in-game.
(First it's absolutely crucial to differentiate RBR's basic feature discussed in the chapter above from the nasty and more surprising issues covered in this chapter!)
There are known cases – albeit rare – where the controls are not saved at all if a desktop shortcut is linked to RichardBurnsRally.exe instead of RichardBurnsRally_SSE.exe. So always link the shortcut straight to _SSE.exe. (Obviously running the game via RBRCIT is more than recommended and none of this should be of any concern with RBRCIT.)
If you play in windowed mode and your controls tend to disappear always when resuming RBR – forcing you to re-assign them everytime – something's gone horribly wrong, let's get that absolutely right. What you should do is to go to your SavedGames folder and delete pfYOURPROFILE.acm (a file that contains only your controller settings) and then re-assign the controls in-game. And, to avoid the same issue in the future – if it hits you once, it'll probably hit you again – you may want to make the .acm file read-only after you have re-assigned everything again (known in the trade as The Borgacci Method).
Open input.ini and change the problematic controls from false → true.
However, if you need to invert FFB (not that I've ever heard of anyone
needing to do that), the option can be found in-game. But please, do
read the next chapter as well.
(Note! This fundamental RBR bug has now been fixed courtesy of mika-n as part of his fantastic plugin NGPCarMenu.)
It's an annoying bug, no doubt, but at least it's the same for everyone! To normalise them, you have to remember to use them on the start line and it'll be fine. We can assure you that you'll forget to do that every now and then, but that's all part of the annoyance! Note that the same issue recurs when resuming RBR in windowed mode, so it's not exactly advisable to go and surf the net mid-stage.
The game's default degrees centre-to-lock is a modest 60 for the wheel animation, but you can change it to anything you like by first extracting LM_Driver.ini from Misc.rbz to \Misc (create it if needed) and then edit its line Max Steeringwheel degrees. Care! Turn off the file's read-only attribute before editing. You can read more about files located in Misc.rbz here.
An alternative and perhaps more preferable solution to the hardcore is to remove the steering wheel (either with RBRCIT or even manually) and get rid of this snag altogether.
Vanilla physics & NGP v1–5: The vanilla presentation of this particular setting has understandably caused a lot of confusion amongst newcomers because the values (vanilla physics: 360–792) are misleading and seemingly random, but essentially it is the same setting than the similarly worded ones in games like rFactor or Automobilista: How much the tyres are turned at full lock. That's it. Just don't ask us how the devs came up with the values they did.
NGP6: The NGP creator extraordinaire WorkerBee removed the possibility to edit Max Steering Lock and also changed its original meaning in the process. Now it's only meant as a hint how you would set the degrees of rotation IF you wanted to match the real thing. The value is center-to-lock, so for instance, the modern WRC/R5 cars would all have 270 (as they are supposed to have 1.5 turns lock-to-lock).
The following table lists the suggested lock-to-lock steering angle for NGP6 cars:
Excerpt from the current ReadMe.PhysicsNG.txt: "Only genuine NGP cars will work with [NGP6] plugin. All other cars are limited to using only reverse and first gear." This essentially means that with the NGP6 plugin, you can only use the official NGP6 cars put out by WorkerBee. To make this abundantly clear:
- You can't add to the car selection in RBRCIT by mixing NGP and vanilla physics anymore like you may have done in the past.
- The Original RBR Cars (also present in RBRCIT) will not work either, simply because they do not have NGP physics.
In both of these cases, NGP's own showRevision (enabled by default) would read like this on a special stage:
Next Generation Physics rev. ### INACTIVE !!! (required rev. ###) NO GENUINE NGP CAR
However, if you do get this problem with what is supposed to be a real NGP6 car, simply Update carList.ini → re-download NGP plugin just in case → Update All Existing Physics in RBRCIT, and test the same car after re-applying it. In more complex cases, this may not be enough but it'd be a waste of space to go through all eventualities. (I mean, one VIP once stated that re-downloading the model had fixed this issue for him but having since tested using a wrong 3D model on a car without a hitch, I'm not convinced.)
Go to game's Options >> Gears >> Gear protection → off.
(Note! These chapters have been put together in pre-FMOD era; some of them do still apply even with FMOD sounds but most of them don't.)
Tyres "skidding" even on straights: Open \Plugins\FixUp.ini and set soundRefreshRate to 60 (reasonable values are from 30 to 90). It goes without saying that using soundRefreshRate is pretty much mandatory when VSync is turned off, but surprisingly, some gamers have indeed reported having this kind of a sound issue even with VSync enabled normally, which is why this definitely deserves a mention.
The engine sound changes when resuming from the menu or turning Pacenote Plugin on and off: Go to \Plugins and delete/remove eq_mix.dll. The plugin in question only comes with things like RSRBR, so the chances are that you have never even known to have it, let alone used it, hence getting rid of it shouldn't cause any heartache.
Strange "warping/echoing" blow-off valve sound: There hasn't been enough cases (that we know of) to make properly weighed conclusions about the subject, but usually it's been a case of edited NumberChannels setting (like 64 or above) that has caused this particular bug and reverting back to default 0 (zero) has been the cure without exception.
Broken engine sounds (.eng): Let's face it, RBR is an unfinished game and one of the most peculiar and unnecessary bugs pointing this out is that half of the original engine sound files simply don't work at all and the game crashes during the loading screen. The broken .eng files in question are bubbla, fiat, Saxo and vaux (feel free to delete them in \Audio\Cars). The rest – subaru, subaru2, mitsu and test – are OK (although test is basically the same sound as subaru). But since the original sounds aren't all that good, you can download some addon ones from sources such as Nanamiso (some of the mods are for other games) and MEGA (mostly the same mods by Nanamiso, but a decent collection nonetheless).
NGP6: The engine NOLOAD sound lower than before: This is normal: it is an NGP6 feature explained here.
The clattering of NGP cars: It was a common belief that the clattering sounds would be a sign of cars tending to bottom out on bumpier roads with default setups, but according to WorkerBee himself, this is not true and the sounds actually originate from the bump stops instead. Now, if you're not a setup engineer yourself and you only wish to partly silence this annoyance, you can download Kaderabek's mod and replace the files in \Audio\Impact\Ranged. Care! For setup engineers it is worth knowing that RBR unfortunately uses the same sound files when cars do bottom out.
By "certain", porridge would mainly refer to classic format stages such as Swiss I + II (III and IV are fine), Fernet Branca and Verkiai, but the following nuggets will apply to other similarly heavy stages.
In RBR, two of the biggest frame rate stealers – ignoring FixUp's AdaptiveFFB now – that some stages are not particularly fond of must be Dynamic Car Reflections (better known as UseCubicEnvironmentMaps in RichardBurnsRally.ini) and the shakiness of the driver cam (cam_internal). Both have a pretty similar impact on FPS by comparison, but naturally the easiest and wisest move would be to disable the former (because it's pointless) and consider the latter only if you really want to have a static cockpit cam or if you wished to retain those allegedly dynamic reflections for whatever reason. (The easiest way to set up static driver cam comes with NGPCarMenu)
You could do both, of course, but let it be known that there would be no real upside in terms of frame rate (on the mentioned stages, at least) and even if there was, it'd be next to nothing.
Another classic optimising measure has been to disable car shadows (RichardBurnsRally.ini: RenderCarShadow=false, add the line if needed), because at the end of the day, what do you need shadows for if you rather watched a screensaver than an RBR replay? Turning it off can indeed give you a small boost, but intriguingly – and porridge may be wrong about this – Fernet Branca is an absurd exception with its performance actually dropping a bit without car shadows. How can this even be, porridge wonders without a clue but then again, maybe you should test it yourself, and that is if you're truly interested which you probably aren't. To be fair.
(Do remember that sky options like Heavycloud Heavyrain are more ideal for testing the limits of your hardware than the usual default Crisp Clear would be, because they tend to be "heavier".)
The problem where frame rate takes a long time to normalise itself (even 10–20 secs), can only be about AdaptiveFFB. As FixUp's own readme clearly states, you should use AdaptiveFFB only with VSync. But that's probably only half of the story, because if you already have VSync enabled, and it's still doing it, which – according to some reports, at least – is indeed possible, it is likely because AdaptiveFFB isn't really meant to be used alongside the so-called gaming monitors (120hz or above). So while you can always try to fiddle with the ffbBufferCycles setting (0→1→2) first, you may also want to give in immediately and change back to the original, award-winning FFB of RBR.
This is a known issue that cropped up at earlier stages of NGP6. In an attempt to fix this for NGP plugin 6.3 release, WorkerBee included a configurable physics update rate (RichardBurnsRally.ini: physicsUpdateRate), check out ReadMe.PhysicsNG.txt for details.
However, for a lot of users there seems to be a trade-off with this fix: if you increase physicsUpdateRate to, say, 150 (essentially anything above your monitor's refresh rate), it would more than likely fix the 70 minute bug, yes, but it may then introduce a new type of annoying micro stutter that would start immediately once the game is running. So, is it possible to find a value between 137 and 153 that would get rid of both types of stuttering? Perhaps. But it's wise to prepare yourself for a bitter disappointment and simply learn to live with the 70 minute bug, which may not be easy considering that with certain online plugins you have to often endure long legs in one sitting. All this is something that promoters may have to take into account in the future.
Apparently, not all 144hz monitor owners have recognised this issue on their setups though, so in case you want to experiment this on your own hardware, remember that you don't have to actively play RBR for the first hour, leaving the game running in the background is enough.
(This fundamental RBR_RX bug was brought to our attention by Keeb, thanks!)
When one first drives any stage with Random/Bad Weather in either Quick Rally or RBRTM, and then goes to RBR_RX, the RX plugin would only be able to launch Cote d'Arbroz in rain. Apart from restarting RBR (surely the fastest way), the only trick to normalise this would be to return to another mode/plugin to start any stage with Good Weather.
One thing to note here, of course, is that this kind of jumping between different plugins without crashing wasn't even possible before mika-n's groundbreaking NGPCarMenu.
Change Render Quality from low to high in RichardBurnsRally.ini. Some addon stages (such as Northumbria, Bruchsal-Unteröwisheim and Undva) are known to not support the low setting.
From the official 1.02 patch notes:"The black lines appearing on the road is caused by the users forcing the driver to use AF (Anisotrophic Filtering) and/or FSAA (Full Scene Anti-Aliasing). By default it is set to be application controlled, which the game works fine with. This can have other graphical side effects, such as poor looking fonts and 2D graphics, because if you force to use these techniques they are applied to everything that is rendered instead of the application selecting where to use it. Also it does degrade the performance." There you go. Couldn't have put it any better.
This will indeed happen if you disable vSync in FixUp, it is what it is. With some cars you may be able to just edit the camera in such a way that hides the flawed animation, but you can also let RBRCIT remove the wipers entirely from all cars, or, you can do the same yourself manually by opening a car's own IniFile: Find [i_wiper_r] and [i_wiper_l] and edit the line Switch = false → Switch = true.
Not an everyday occurrence, it has to be said, because not only it requires massive skin files, likely it'd crop up only on certain stages such as Shurdin and Ouninpohja (they are the known examples). At day's end, here are the two reasons that would usually cause this issue:
1) The car's textures have been exported with a "wrong" preset and the files have ended up unnecessarily gigantic because of it. You can try exporting the DDS files again; using the preset BC3/DXT5 should be enough for all textures, but if you'd like optimise even more, you can use BC1/DXT1 for anything non-transparent.
2) The car's texture quality is way too high (like 8192x8192), which would render a simple re-exporting insufficient. You'd also have to rescale the texture files first to something less excessive (like 2048x2048 or even 1024x1024). Fixing only the transparent files may be enough, or maybe not. If you're using a skin made by someone else and you're not that interested in doing the dirty work yourself, remember that you can always reinstall the default skin as they tend to be reasonable enough.
Important! Both of these flaws would be well capable of making the game crash during the loading screen too (especially for VR users).
Not only do you have to have the same car installed but also it has to be installed to the exact same car slot when watching replays, otherwise the replay will load but not play back. (Although let it be known that in RBRTM, there have been some rare and isolated cases where even a matching car and slot have not worked but they're just that: rare and isolated cases.)
Let's face it, the default settings are just fine for 95% and for those who know their English, the following table should not act as a substitute for FixUp's own documentation (ReadMe.FixUp.txt), it is merely complementing it. Note! In case you don't see FixUp.ini in \Plugins yet, that's because you have to run the game first.
nVidia Profile Inspector (link) is used for modifying game profiles inside the internal driver database of the nvidia driver. All game profiles are provided by the nvidia driver, but you can add your own profiles for games missing in the driver database. You also have access to hidden and undocumented settings, which are not provided by the drivers control panel.
Installation & Settings:
Download the latest nVidia Profile Inspector by clicking on Assets and click nvidiaProfileInspector.zip file after download, decompress the files (nvidiaProfileInspector.exe & reference.xml) in its own folder (X: \ nvidiaProfileInspector). Double-click the nVidiaProfileInspector.exe file (check that it is running with administrator privileges) and you will see the following window:
At the top left of the profiles we start writing "Richard Burns Rally" until it appears in the drop down menu as in the image below and select it:
Then we make the following settings:
And then on the top right we double click on "Apply changes".
If you do not want to do the whole process you can download the file with the settings ready from here (Richard Burms Rally.nip) and import as below and at the end click "Apply changes" again.
The following screenshots show the noticeable improvement:
!! DISCLAIMER !!
Puresimrally.gr is not responsible for any damage or destruction to the equipment of the operation of any software or hardware of your computer, applications, settings, etc. you use them EXCLUSIVELY at your own risk!