Red Orchestra 2 Console Commands

• Rising Storm 2 Console
• Red Orchestra 2 Console Commands Script

Slomo 2 - Sets game speed to double - Increase number to go faster Slomo.5 - Sets game speed to half - Decrease number to go slower Summon classname - Summon or spawn an instance of the specified classname (this is a package.class string). Teleport - Teleports the player to the surface they are look at. BugIt The ‘BugIt’ command is a useful console command that will take a screenshot of whatever is currently displayed on your screen and output 2 files: a bmp file and a text file. This can be used to quickly take screenshots of stuck locations, collision issues, and environment issues that are encountered on maps.

These are all the console commands that can be used in Killing Floor. Note that not all are actually useful; some are remnants of UT code.

All of those marked 'cheat' require that you first enable cheats using the enablecheats command.

All those marked 'UT' are provided by UT code, although possibly updated by the game.

• 2Commands

Binding a command to a key

To bind any command to a key simply enter the following in the console, replacing parameters where necessary:

set input <key> <command>

You may also set a command to be called when the key is released, like so:

set input Z Behindview 1 | OnRelease Behindview 0

When you exit the game, the settings will be saved to user.ini.

Commands

Cheats

These are provided in the CheatManager and KFCheatManager classes.

Cheats (Other)

Most or all of these are provided in the cheat-related classes but are used for debugging.

Console

These are provided in the Console and ExtendedConsole classes.

HUD

Rising Storm 2 Console

These are provided in the HUD and HUDKillingFloor classes.

Debugging

These are provided natively by the engine.

Admin

These are admin commands, used for managing players and the game itself. These are provided in the AdminBase class.

Player

Most of these functions are provided in the pawn and controller classes, and related classes.

The following is a list of items that LDs and Environment Artists should follow for a map to perform well. Most of these were lessons learnt while optimizing RO2 and should also serve as a guideline for modders to make sure that they don't run into the same pitfalls.

• 1Terrain
• 2Static Meshes
• 3Materials
• 4Dynamic Actors
• 5Draw Calls

bCastDynamicShadow

This flag should be OFF. Setting this flag to ON will cast dynamic preshadows by the terrain for both per-object shadows and whole scene dynamic shadows, which can be very expensive depending on the number of dynamic primitives in the scene. Preshadows (which are dynamic shadows from the static environment onto dynamic objects) only make sense if the terrain has hills and valleys throughout the scene. If the scene just has a few mounds here and there it might be worth modeling the mounds with static meshes and have the terrain blend in at the bottom. The side effect of disabling bCastDynamicShadow is that terrain deco layers (e.g. grass) will not cast whole scene dynamic shadows. But considering that shadows from deco layers usually are low-res and don't look great, it is a good price to pay for a substantial performance boost.

Terrain Layers

The RO2 engine allows for a maximum of 12 textures to be blended for terrain. These 12 textures could be part of 2 terrain layers (6 textures each), 3 terrain layers (4 textures each), or any other combination thereof. This is a hard limit for the engine, and exceeding this limit will result in rainbow colored terrain patches. However, fetching and accessing so many textures is not cheap and since the terrain usually takes up a large portion of the screen, it is recommended that you keep the number of blend textures to a minimum.

One example for this is that say you have a terrain which comprises or dirt, rubble and snow and one part of the terrain is solid concrete. Instead of making 4 terrain layers of dirt, rubble, snow and concrete and blending between them it is more optimized if the terrain uses 3 layers of dirt, rubble and snow, and the concrete portion is modeled separately as BSP, static mesh or even another terrain actor. Doing this will reduce the overall cost of rendering the entire terrain since the concrete layer texture fetches are eliminated for the rest of the terrain that doesn't need it.

bCastDynamicShadow

When placing a static mesh in the level, you should decide whether you want it to cast dynamic preshadows or not. Preshadows are dynamic shadows from the static environment onto dynamic objects, and can be very expensive depending on the number of dynamic primitives in the scene. Turning off this flag for a lot of static meshes in the environment in the scene such as debris, rubble, etc. will improve the dynamic shadow performance.

Once the lighting in a map is finalized, you can also go through and set bCastDynamicShadow to false for all static meshes that are already in shadow (such as the truck in the following image, which is is shadow of the building) since any dynamic shadow cast by it will be drowned by the static shadow cast by the environment.

Distance Culling

Using distance culling effectively will allow you to have a lot of detail in your environment whilst still allowing the map to perform well. There are 2 ways to do this :

• You can either put a CullDistanceVolume around the map and the let the map build process choose the appropriate cull distances for the placed static meshes in the level. This method is not ideal though, and might cause certain cover objects, etc. to disappear at a distance (which is not desirable).

• Or, you can manually set the MaxDrawDistance for each object.

Using Material LODs

In order to make the best looking environment materials as well as keep the overall performance cost low, consider using material LODs. The concept is very simple - assign the best looking/highest instruction count material to the base LOD for a static mesh, and then create another LOD for the static mesh (this can have the exact same triangle count as the base LOD) and assign it a simple material that does not have expensive operations such as depth biased alpha, specularity, cube maps or even normal maps. Such subtle lighting effects cannot be perceived from a distance anyway, and will make improve the fill rate for the rendered scene.

bDisablePerObjectShadows

If you place an actor onto a level that casts dynamic shadows, the shadowing cost for it is one per object shadow and in certain cases a preshadow as well. If bDisablePerObjectShadows is set it will only cast dynamic shadows for the primitive if it is within the whole scene dominant shadow radius. This reduces the cost associated with shadowing for the primitive. If whole scene dominant shadows are not enabled, the primitive will not cast any dynamic shadows.

Red Orchestra 2 Console Commands Script

bAllowMergedDynamicShadows

If this flag is set, any primitive that allows per object dynamic shadows will be considered for being merged with other primitives that allow merged per object dynamic shadows and are close enough. As a consequence, the number of dynamic shadows in the scene are reduced.

The radius used to merge primitives is dynamically adjusted based on the distance of the primitives from the viewer. It starts at MinShadowGroupRadius (when the primitive is closest to the viewer) and increases up to MaxShadowGroupRadius (when the primitive is ShadowGroupRampCutoff away from the viewer). The rate of increase is determined by ShadowGroupRadiusRampUpFactor. For anything beyond ShadowGroupRampCutoff, the MaxShadowGroupRadius will be used. All these settings are available in the engine INI.

About Draw Calls

As the UE3 rendering engine is a Direct X 9.0 renderer, it is limited to one CPU core to tell the GPU about what to draw. It does this via a Draw Call. Each object you place in the world is at least one draw call (if not more due to shadows). The CPU can become the bottleneck of a level if it is trying to tell the GPU to draw a detailed scene and chokes on the amount of draw calls. This is why it is best to limit the amount in any given scene. With the Red Orchestra SDK it is very easy to make many types of levels, from wide open plains (or with rolling hills) to detailed interior settings and building to building fighting. However, depending on what the scale of your map is, you will be limited in the amount of 'detail' you can place in the level.

Limiting Draw Calls Per Scene

Suggested Maximum Draw Call Limit: 2000

Using the console command Stat d3d9rhi' a Level Designer/Artist (or anyone) can go through a level and find out the amount of Draw Calls and optimize based on areas where it has increased beyond the suggested maximum.

The details settings for both users and in the SDK allows Level Designers to put some objects on different levels of the setting so those with faster computers (in this case CPU core speed) can see more details without harming performance for those with slower machines. It is best to do this with 'fluff' detail that is not gameplay important but just makes the level look better overall.