Map Submission

Introduction #

Momentum’s map submission system is how maps are officially added to Momentum Mod.
Map submission is open to everyone, but we have higher standard than e.g. GameBanana or Steam Workshop. Notably:

• Submissions go through a minimum-week-long public testing period where other players can give feedback
• Submissions must be approved by an Official Reviewer
• Once a submission is approved, the submitter can’t modify or delete the map!

The ultimate goal of this system is to avoid the need for leaderboard wipes, ensuring we catch as many bugs prior to approval as possible.

Map Porting

Introduction #

This guide gives an overview of all the steps required to officially port a map to Momentum Mod.
The goal of porting is two-fold:

• Ensuring the map functions correctly
• Conforming to a high standard of competitive integrity

Maps should not be significantly modified.
It’s very important to respect the spirit and intent of the map’s design.

You are free to port any publicly available map with some exceptions:

Fixing Entities and Other Issues

Setup #

Some fixes and required modifications can be automated using in-game Entity Tools.
Changes made with Entity Tools need to be Exported To Lumper and then saved in the .bsp.

1. Open Entity Tools by typing devui_show entitytools in console
2. Go through each section of the Entity Tools and follow to guide to apply correct fixes

You can change the font size of Entity Tools by using devui_font_scale command in console.

When making these changes it’s perfectly fine to Export them only once, when you are done with everything, however there is no downside to gradually saving your progress.

Entity Tools #

Teleport Velocity Mode #

Teleports in Momentum Mod retain player speed by default.
This needs to be sometimes changed as explained in scenarios below.
Go through each teleport destination by clicking Teleport To Destination and apply relevant fixes.

How is the entity modified?

Entity Tools match every trigger that teleports the player to chosen destination and add/change the velocitymode keyvalue.

...

Map Zoning

Introduction #

Zones allow players to measure and submit times to the leaderboards.
This guide focuses on zoning using Momentum Mod’s in-game tool.
Zoning using Hammer is briefly covered in this section

Glossary #

Examples #

Map Review Checklist

This checklist is intended for experienced map porters that already understand general porting concepts.

For more in-depth information on map porting, please see the map porting and zoning guides.

First check:

• The map has been in public testing for at least 7 days
• The map hasn’t already been ported by someone else

Step 1: Review zones #

Region Geometry #

• Zone points are placed precisely and are well aligned to map geometry
  • Zone points are snapped to map vertices
  • Zones meant to fill a platform go all the way to the edge and not inset slightly
  • Make sure to review all regions if there is more than one
• Zone regions are not overlapping
• Zones with multiple regions could not have been achieved with fewer regions
• Start/Stage zones are large enough to prestrafe in
• Start/Stage zones encapsulate the restart teleport destination and use it as the teleport destination entity
  • If there is a teleport destination entity present, it should be used (not a custom position)
• Region heights are not less than 256 units for no reason
  • Regions under a low ceiling should probably end at the ceiling
  • End zone regions at the bottom of a pit the player falls into may be short, even 1 unit tall
• Regions are not so short that the player could possibly fly over them and have to wait to fall into them (especially end zones)
• Regions are not so thin that the player could pass through them without activating them.
  • A minimum of 64 units is generally sufficient, but may not be enough if the player is moving exceptionally fast.
• Regions do not protrude into walls unnecessarily
  • The shape should conform to the geometry, not be lazily covered with a box
  • Multiple regions should be used to cover split paths, not one stretched region
• The Safe Height is high enough to encapsulate any small protrusions on the floor, but also below platforms that can give the player an unfair height advantage. This includes platforms that cannot be reached just by walking or jumping.
  • Explosive weapon modes should generally use the full height while non-explosive modes should use the base height when possible

Checkpoint Locations #

• Checkpoints are placed in a way that minor short-term routing differences do not affect timer splits
  • This means placing them in the middle of straightaways rather than after a turn where the player can hit the checkpoint sooner or later depending on how much they cut the corner (see zoning guidelines)
• Checkpoints are placed at locations that feel most like the player has reached a new area and has made clear progress through the map.
  • For Bhop maps, this usually means placing checkpoints at locations where the map teleports you to when you fail a section.
  • Generally, the player should not get sent back before a checkpoint when they fail.
• Checkpoints are fairly evenly spaced and not too close together.
  • A rough rule of thumb is checkpoints should be at least 10 seconds apart in a reasonably optimized run.
• Checkpoints are unskippable and marked “required” except where absolutely necessary.
  • Even when a map has skips, it is usually reasonable to place checkpoints in a way that they are not bypassable.
• Checkpoints are marked “ordered” except where necessary, even if it does not appear physically possible to activate them in an arbitrary order.
• Checkpoints with multiple regions positioned in mirrored paths should be equivalent.
• There should be no gaps between the sides of a checkpoint and the surrounding walls.

Other #

• The position and yaw of start, stage, and bonus TP destinations are ok (preview position with zoning menu)
• Max velocity should be the mapper intended value
  • This is sometimes found on a point_servercommand. Other times this is only listed where the map was downloaded from.
• Cancel zones are used in hub/stage select areas if it is possible to return to hub area without teleporting with a command.
• Start/Stage zones with multiple regions in distinct locations with their own teleport destinations should assign each destination to the appropriate region, rather than using the same one for all regions.
• When the map uses a filter entity to gate progress to the area a zone is in, the zone should be assigned that filter entity even if the zone cannot be physically reached without the filter due to a filtered teleport trigger in the way. If the filter has Negated value of 1, then it should be negated in the zoning menu.
  • This is for general safety and also because it allows zones to be given a different appearance when they are untriggerable.
• (Optional) Stages and bonuses may have names where appropriate to make them easier to identify. Names should only be used when they are intuitive and in the spirit of the map, like the fruit-themed stages of surf_fruits. Track names should not just be used as mapper credits in a collaborative map.
• (Surf only) “Limit ground speed” option should be enabled for stages unless you are supposed to bhop in start zones during a full map run
• (Surf only) Carefully review intended bhop platforms and add Allow Bhop regions if needed
  • Use mom_bhop_area_debug 1 and jump on the ground to check the automatic bhop platform detection.
  • Review WR videos for ramp spine bhops or other commonly allowed bhop skips.

Step 2: Review in-game entities with entity tools #

• Teleport Velocity Mode Tool: Teleport destinations are marked as “Keep Negative Z” when the map design intends to stop the players horizontal velocity, including when there is a floating “cage”.
• Boost Triggers Tool: Check boost triggers for exploits (see required entity conversions guide)
  • For boosts at the start of tracks that were turned into trigger_setspeed, make sure the boost gives the same speed as when walking into the original trigger. Use the “Restore Original Trigger” and “Reload from BSP” buttons (if available) to easily do a before-and-after comparison. Also make sure these boosts have Strict Mode enabled, and do not use “Ignore” mode for vertical speed.
• Gravity Triggers Tool: Gravity triggers should persist gravity changes when the player exits the volume in CS:S maps, but not in CS:GO maps
• Model Scale Fix Tool: Check for any incorrectly sized props
• Bhop Trigger Fix Tool (Bhop only): If the map uses mpbhop triggers (triggers that force bhopping with targetname filters), check if they have been converted (bhop trigger fix entities should be 0)
• Bhop Block Fix Tool (Bhop only): If the map uses func_button/func_door bhop platforms, check if they have been converted to func_bhop
• CSM Fix Tool: CS:GO maps have an env_cascade_light entity if they use CSM shadows

Step 3: Other in-game things to review #

• Maps don’t have invalid textures, cubemaps (unless from TF2), skyboxes or models
• Default spawn position and direction faced (yaw) is ok (reload the map to check)
• Reset triggers don’t face the player backwards when hit (UseLandmarkAngles is set to 1 where this would otherwise occur).

Step 4: Lumper review #

• Check for invalid entities (“Entity Review” tab)
• Remove weapon strip entities unless adding/removing weapons is a part of the gameplay
• Check for Valve assets in the pakfile
• Check that any custom music files are categorized as such using the appropriate subdirectory
• Check that there are no absurdly large textures (e.g. 4-megabyte plain color textures that could be compressed significantly)
• (Surf only) Make sure there is no active “jail” system

Step 5: Submission page review #

• Required games match what is displayed in Lumper
• The submission type is Port if the map first released in another game/server
• Description should mostly match GameBanana submission
• Date created should match the date on GameBanana
• Credits should match GameBanana submission
• Screenshots ideally should showcase iconic/memorable parts of the map. Taking similar screenshots to the ones on GameBanana is also recommended.
• Extra suffixes like _njv, _fix, or _ksf that are not required to fully distinguish the map are removed from the map name.
• jump_ prefix is renamed to rj_ or sj_

Collectibles

This guide covers how to use collectibles in Momentum Mod. Collectibles are a tool that lets mappers create non-linear, staged maps.

Prerequisites #

To follow this guide you should:

• Be on Momentum 0.8.7+
• Have a working Hammer install with the Momentum FGD
• Some experience with entity I/O and filters

What are Collectibles? #

Collectibles are any entity that the player must interact with to continue in the map. They can be thought of like pickups, but any entity can be a collectible, so long as the player can interact with it to “collect” it. The entity filter_momentum_collectibles is used to control entities based on how many collectibles the player has gathered.

Creating Surf Ramps

Note: This guide assumes that you have a basic working knowledge of the hammer editor and the tools used.

Basic Surf Ramps #

Planning #

Before you start to create your ramps in hammer, there are a few factors you should consider:

• How steep do I want the ramps to be?
  • A ramp that is too steep / wide may be considered awkward to board.
  • People tend to use a 5:4 ratio for the dimensions of their ramps
• What size do I want for my ramps?
  • People may find themselves sliding off the bottoms of small ramps.
  • They may feel like they are going slow on oversized ramps, it is important to find a balance.
• How do I want to detail my ramps?
  • Will models be needed to achieve the visual style, or can it be brushes?

These characteristics of your ramps will inevitably be refined through testing, but it is a good idea to start off with a plan for how you want the surf to feel. Look at different surf maps that you enjoy and try to get an idea of how exactly you want yours to pan out.

Giving Players Powerups

Two powerups are implemented: Haste and Damage Boost. They can be given or removed with these inputs:

SetHaste (time in seconds)

SetDamageBoost (time in seconds)

If time = 0, the effect will be removed. If time < 0, then the effect will last indefinitely until removed.

There are also powerup entities: momentum_powerup_haste and momentum_powerup_damage_boost. They both take a ResetTime key like the weapon spawner entity. The haste powerup takes a HasteTime key, and the damage boost powerup takes a DamageBoostTime key. They are both specified in seconds the same way as the inputs.

Hammer++ Setup

Background #

Momentum Mod ships with a customized build of Hammer (named “Strata Hammer”) which includes some, but not all of Hammer++’s features. Our development has been geared more towards stability than new features, with a focus on porting to Qt for cross platform UI and bug fixing. While Strata Hammer should be perfectly usable (and we appreciate testers), it will be a while until Hammer++ features like accurate lighting preview are fully implemented. If you prefer using Hammer++, that is completely reasonable and this guide should get you set up.

Parallax Corrected Cubemaps

This page covers Momentum’s implementation of Parallax-Corrected Cubemaps, created with a combination of custom entities and materials.

Thanks to Brian Charles for his work on this feature.
More technical information can be found on the Valve Developer Wiki Page.

Prerequisites #

To make use of this page, you should:

• Be proficient in using the Hammer Editor
• Have the momentum.fgd in your Hammer configuration
• Know how to use the developer console

Components of a Parallax-Corrected Cubemap #

In Hammer, Parallax-Corrected Cubemaps need two entities to function correctly: