How To Fly

From Multiverse

NOTE: This article is currently being revised to work with 1.1. Please check back later.

by Jeff Krebsbach, Software engineer, Wardog Studios

Introduction

Force of Arms takes place in a science fiction universe of humanoid war-machines called "mechs" (Mechanized Armor), that battle for control of worlds on behalf of inter-planetary corporations.

In our game, we wanted to give players (mechs) the ability to fly. Of course, by default, with the Multiverse platform, players must stay on the ground (that is, the avatar must always follow the terrain). We knew there was a /fly "slash command" that enables a player to fly. When we started looking into the /fly command, we thought it would be as simple as binding a key and moving on, but it was slightly more involved....

The fly command

The first thing you need to do is to create a client command to fly. You can add it to /Scripts/MarsStandardCommands.py, or create a new Python file to contain your commands.

def HandleFly(args_str): 
   ClientAPI.InputHandler.FollowTerrain = False

Enabling flying

There are two ways to implement flying in the Multiverse Client:

• With a script that executes on startup; this enables flying for all players by default.
• With a key binding; this enables players to fly when the press a certain hotky.

Enabling flight by default

We enabled flight by using a script in the Client Interface\FrameXML folder. To do this, we first needed to ensure that the Client runs the script on startup by adding the UI file to the world "theme file" or .toc file. The theme file we need to alter is \Interface\FrameXML\mars.toc.

The UI files listed in mars.toc define aspects of the Sampleworld UI. Some of these files depend on other files, so it’s not wise to modify, move, or delete them. Make a backup before modifying mars.toc and be sure to read the Overview of Developing Client UI.

When the client is started, it loads all the UI files listed in mars.toc. Here is the Force of Arms mars.toc file parsed during the OnLoad process:

## Title: Basic UI Elements
## DefaultState: enabled
MvFonts.xml
MvFrame.xml
MvDialog.xml
MvChat.xml
FoaSplashScreen.xml
MvMinimap.xml
FoaStatusDisplay.xml
FoaRadarDisplay.xml
MvTooltip.xml
MvStatus.xml
MarsUnit.xml
FoaDemoWorldHelp.xml
FoaExitScreen.xml

We added the last two files, FoaDemoWorldHelp.xml and FoaExitScreen.xml. We created FoaDemoWorldHelp.xml by modifying MvSocialHelp.xml to display an introductory note to players as they login with a welcome message and some instructions on how to move. We also added the following script widget (<Script> element) near the end.

Putting the script inside the <OnLoad> tag makes the Client run the script when it loads the "help screen" UI. If the player brings up the help screen again, the script will reset the value, which is good if errors have occurred. Of course, you could also use a separate script to accomplish the same task.

<Scripts language="python">
  <OnLoad>
    FoaDemoWorldHelp.Show()
    FoaDemoWorldHelpTitle.SetVertexColor(0.1, 0.1, 0.1)
    FoaDemoWorldHelpTitle.SetAlpha(0.9)
    FoaDemoWorldHelpTexture.SetVertexColor(1.0, 1.0, 1.0)
    FoaDemoWorldHelpTexture.SetAlpha(0.9)
    FoaDemoWorldHelpOKButtonTexture.SetAlpha(0.6)
    ClientAPI.InputHandler.PlayerSpeed = 30000
    ClientAPI.InputHandler.FollowTerrain = false
    ClientAPI.InputHandler.CameraTargetOffset = 8000 * Vector3.UnitY
    ClientAPI.Network.SendTargetedCommand(ClientAPI.GetPlayerObject().OID, 
                                          "/parm Camera.CameraMaxDistance 200000")
  </OnLoad>
</Scripts>

They joys of writing Python scripts to convey values from one script to another can be found at Dive Into Python. Feel free to use our example...

We use this script to change a few settings at load time, using values found in the Input Handler Subsystem wiki page. The script:

• Increases the default player speed from 7,000 to 30,000 mm/sec.
• Changes the camera settings to reflect our ten-meter-tall mechs to make filming easier.
• Enables flight ability.

The command /parm InputHandler.FollowTerrain false is the key to three-axis "flight." Once this command is sent to the ClientAPI.GetPlayerObject().OID, the player can fly using the <Page Up> and <Page Down> keys. This controls the vertical axis of movement (up and down). Holding down the right mouse button allows full directional control, and thus when moving forward, the model may move in any direction.

The key item to these commands is how the /parm command is used in quotes. Using a /fly instead of /parm InputHandler.FollowTerrain false will not work. The same is true for speed changes.

Enabling flight with a key binding

The other method is to use key bindings (in the Bindings.xml file in the FramesXML folder). This will enable a player to fly after he presses the specified hotkey.

This is done quite simply by mapping the commands to keys, for example:

<Binding name="TAKEOFF">
  ClientAPI.InputHandler.FollowTerrain = false
</Binding>

<Binding name="LAND">
  ClientAPI.InputHandler.FollowTerrain = true
</Binding>

The next step is then to assign keys to the Binding Names of TAKEOFF and LAND in the bindings.txt file. When used, TAKEOFF will allow the player to fly within the game world from the current location. When LAND is activated, the player will immediately hit the ground below, once any movement is made.

Setting movement speed

To set the default player speed, use the following script:

ClientAPI.InputHandler.PlayerSpeed = value

Where value is the speed in mm/sec. The default speed is 7 m/sec (7000 mm/sec).

You can write a script to change the player's speed with hot keys. For example, assigning the number keys (0 to 9) provides a variation in speeds.

In our testing of Fly mode, the top speed we were able to achieve (while having the ground in sight) was obtained at about 750,000 millimeters per second (2,700 Kph or 1,678.5 Mph). This would appear to be the top speed the platform can handle at this time, and the performance of the client does play a crucial role. At such high speeds, the frames/second degraded substantially and occurrences of "rubber-banding" (moving forward and then brought back to a previous point) were common. A speed of 200,000 millimeters per second appears stable, with up to 500,000 being possible for high-end machines.

Future possibilities:

• Create a script that, before enabling flight, checks with the server to verify if the player or model is capable of flight.
• With improved performance, the platform should be capable of super-sonic air travel and even combat at a 1:1 scale. Of course this can be spoofed by using a different scale, such as a 4:1 scale in which time is increased by a factor of four (one hour of game time equals four hours of real-time).
• With some code, when flight mode is disabled, the player falls. The code could determine damage to the player character based on the distance of the fall and velocity of impact.