qople - First Person Tools

canonical link to CPACK - where to get the author-maintained version

This is the documentation page for the first person game mode. Information for players can be found here.

The FPS scripts were made with extensibility and versatility in mind, but because of that some parts of them may seem a little daunting. This page's goal is to act as a guide and a reference to hopefully lower that barrier to making your own first person levels.

As a general rule, all weapon and attribute names must follow the same capitalization rules when used as inputs, no matter what script they appear in. Weapon names are all lowercase (“cannon”) and attribute names are capitalized and camel cased (“MaxRange”).

Almost all weapon attributes have the same effect on all weapons. This holds true even if that weapon doesn't normally have that attribute. For instance, in “FPS: Anti Up” (map #586), the cannon is given AC simply by having an item upgrade give the cannon anticreep-related attributes.

Attributes that do not end in a “.0” are integers (they ignore anything past the decimal place when finding their effect).

• DPS Monitor
• Wall Tool
• InfoCache Controller

This script controls all aspects of first-person movement: speed, collision, respawn, etc. “Run when paused” should be turned on so it can return normal controls if the player leaves first person mode while paused.

Script vars:

• moveSpeed: The maximum speed the player can hit, in cells per update. High values will lead to clipping.
• accelTime: The number of updates it takes for the player to reach full speed from a standstill.
• decelTime: The number of updates it takes for the player to stop from full speed.
• playerHeight:The height of the player above the ground, in cells. The default is 9. Changing this in combination with the move speed will effectively change the scale of the map.
• allowMoveOnVoid: Whether void is counted as an impassable wall, or terrain height 0. Values other than 0 allow movement on void. Only really makes sense to allow it if the level has a planet.
• collisionThreshold: The highest terrain difference that the player can walk over.
• startX, startZ: The cell coordinates of the player's spawn and respawn point.
• startRotation: The direction that the player points when they spawn, in degrees. 0 faces them in the positive Z direction. Clock-Wise rotation.
• stunDuration: How many updates the player stays stunned for. Consecutive stuns do not stack.

Contains logic for health and firing weapons.

Script vars:

• maxHealth: The max health the player has. 30 is the default. Damage taken is proportional to the square root of creeper, with a depth of 1 dealing 0.1 damage per update.
• bonusRequirement: The percentage of health the player must stay above for the custom objective. Set to negative to disable.
• startingWeapons: A string containing a list of the weapons that are unlocked upon starting the level, separated by commas. Order doesn't affect this.
• weaponOrder: A list of all weapons that are in the level, in order of their hotkeys. Changing the order of this will rearrange the weapon hotkeys.

A weapon pack that determines the starting settings for the cannon, mortar, and sprayer. It follows the same format that other weapon packs should, so this section applies to custom weapons as well.

All script vars except for those ending in “Other” simply set the starting value for the weapon and attribute in the name. See weapon attributes for a more detailed description.

Script vars ending in “Other” are for setting attributes that are not already listed for a particular weapon. The string is case sensitive, and must be formatted as a list of attribute-value pairs. The weapon name should not be added to the attribute name. An example would be:

DmgDepth: 0.5, DmgDist: 5, Rate: 10

Note that each key-value pair is separated with a colon, and different pairs are separated by commas. Whitespace is ignored.

Handles various settings that persist across the gamemode. Also creates the wall tool and DPS monitor on game load.

Script vars:

• useWallOverride: Whether to use a 2000 terrain override on cells with terrain 19 and 20. If it's on, updates all cells on game start or compile.
• wallUpdateRate: How often the wall overrides should be updated during game time. 1 checks the whole map every frame (not recommended), 90 checks over it every 3 seconds, and so on. Has no effect if useWallOverride is 0. Setting to 0 disables the updates, so the overrides will not change if terrain changes.
• chargeTotems: Makes all totems charge in a way usable in a first-person level. Rules are as follows:
  • Totems will gain charge at an increasing rate while the player is within 15 cells.
  • Partially charged totems will stop charging when the player is outside that radius, but will not lose charge.
  • Totems will lose charge when there is creeper on the center cell of the unit.
  • Disabled totems (“unit: off”) will not charge, and any existing ammo will be removed.
• selectionMode: Controls selection and building behavior for hybrid levels. The options are:
  0: Default behavior
  1: Disables building in first person mode
  2: Disables building in and out of first person
  3: Same as 1, but also overrides selecting units
  4: Same as 2, but also overrides selecting units
• selectableWhitelist: A comma separated list of unit types that are still selectable when unit selection is turned off by the script. The DPS monitor is internally added to this list.
• buildWhitelist: A comma separated list of unit types that are still buildable when building is turned off by the script.

This section requires knowledge of 4RPL.

Certain parts of the game mode are stored as global variables, allowing them to be read from any script in the level. They are listed below.

The Move.4rpl and Player.4rpl scripts are also registered, so you can get and set all variables they use with GetRegisteredScriptVar. Move.4rpl is registered as “Move” and Player.4rpl is registered as “Player”.

Various parts of the game are communicated via messages. Registering other scripts for these messages can sometimes be useful.

The weaponAttributes table has an entry for each weapon, accessible by its name. That value is another table with entries for all of that weapon's attributes. This means that the simplest syntax for reading the value of a weapon's attribute is (mind the capitalization):

<-*weaponAttributes {"weaponName"} {"AttributeName"}

Although if many attributes need to be read for the same weapon, it can be easier to store the second table to its own (local) variable.

Similarly, the simplest way to change a weapon's attribute is:

value ->*weaponAttributes {"weaponName"} {"AttributeName"}

To put everything together, here is an example that uses everything mentioned so far.

Whenever a bullet creates its weapon effect, it sends a message on the “WeaponEffect” channel. _DATA will be a list with two elements: the first is the name of the weapon, and the second is a 3-dimensional vector of the location where the weapon effect was made. By registering a script for that event, custom effects can be added to weapons without modifying the original scripts.

The base template for this is as follows:

once
    RegisterForMsg("WeaponEffect" "DoCustomWeaponEffects")
endonce
 
:DoCustomWeaponEffects
    #Store data into more readable vars
    <-_DATA[0] ->weapon
    <-_DATA[1] ->effectPosition
 
    #Read whatever attributes are needed for this effect
    #Repeat if necessary
    <-*weaponAttributes {<-weapon} {"SomeAttribute"} ->someAttribute
 
    #Then create the effect. Teleport the player, flip C/AC, damp waves, whatever you want.

The weapon loader and item scripts don't filter what stats are being added to the weapon, so new attributes can be added and read just like the base ones.

New weapons can be added into the gamemode through the use of special scripts. There are two ways to write these scripts: for weapons that use the same logic as those in the “Vanilla Weapons” pack, defining starting stats and visuals is all that is needed. If a weapon needs to do more than what is possible with those options, you can define your own logic.

When a weapon can use the same logic as the base weapons, creating that weapon becomes much simpler. This kind of custom weapon is more about creating a new weapon slot for a custom effect that doesn't fit on the regular weapons, like teleportation.

The things that must be addressed in a weapon pack are:

• Input vars/base stats
• Visual attributes
• Crosshair
• Custom effects, if any

Here is a blank template: (The Vanilla Weapons script can be used as an example)

Visual settings for weapons are in the form of hidden attributes. Some of them are vector types, meaning they cannot be set as input vars. They are:

If the BulletGUID attribute is defined for a weapon, the default bullet will be hidden, and a unit of the given type is created to act as the visual. This unit:

• Follows the same path the bullet would
• Is rotated to match the direction it is moving
• Is spawned with a variable named “parent” containing the unit ID of the bullet that created it
• Is destroyed when the bullet hits something or leaves the map

It can have scripts attached to it that make animations or provide additional weapon logic. BulletGUID does nothing for weapons that do not use default bullets.

When a weapon's Path attribute is set to anything other than 0 or 1, nothing is done for you, meaning you have more freedom about what you do with the weapon, but it is more work to make. It's recommended that these weapons use a negative path to prevent overlap in case more path options are added for basic weapons.

The additional parts of the weapon that need to be addressed are:

• Weapon Targeting: should be done inside the CrosshairUpdated event handler if any visuals depend on this.
• Firing logic: Register for the WeaponFired message to do this. If weapon targeting fails, set the fireTimer global variable back to 0.
• Bullets: Normally the default bullet script figures out its own settings and what it should be doing based on the weapon attribute table and the active weapon. If you aren't using it, you need to do that.

The template for this is:

Writing to the playerPos global will teleport the player. If high FPS is on, a tween frame will be added to make movement smoother. To disable that, set the W component of the vector (the 4th one) to true. To snap the height to the terrain, set the Y component to anything less than -100.

As soon as you stop changing the camera position, normal movement will return.

Code snippets that might be useful for some purposes.

GetRegisteredScriptVar("Player" "unlockedWeapons") "weaponName" AppendToList

SetRegisteredScriptVar("Move" "checkpoint" <-cellX <-cellZ FC)

⇐ Index