Table of contents

General requirements for all types of content

  • All content hosted on Re-Volt World must be properly packed for ease of installation and RVGL Launcher compatibility. Additional details can be found in the individual content type sections.
  • When updating a package, make sure the packing stays proper. We are not responsible for broken files or improper packing caused by erroneous updating.
  • Unusable (i.e. car/track doesn’t show up in game) or unplayable (i.e. undrivable cars, non-completable tracks) content will be rejected.

Comments, ratings and user interaction

  • Re-Volt World is an international community, hence English is its main language. Please refrain from commenting in other languages. Consider using a translator before posting – as long as you can understand and get understood, all is well.
  • Do not use the comment section for creation requests.
  • Do not comment with a standalone link (e.g. YouTube review of a car/track/mod). Comments should always be descriptive to some extent. Suspicious links will be removed.
  • DMs are open for all users, not just between users and the staff. Do not harass people through direct messaging – please report any form of verbal abuse through the Team & Contact page or via DMs to any of the staff members.
  • Please use the rating function wisely – and don’t be afraid to exploit all five stars in it, it’s not all-or-nothing. “Rate bombing” (i.e. the act of giving creations low ratings out of spite) is considered a form of harassment (see the point above).

The following actions will be sanctioned

  • Uploading malicious software.
  • Uploading NSFW or sensitive content. This includes but isn’t limited to nudity, racism, and discrimination or hatespeech towards categories/minorities of any kind.
  • Mass-uploading in a short timeframe. This only slows down the content review process for us and clogs the homepage. Be respectful to us and to other authors.
  • Mass-rating and mass-commenting with the intent of quickly gaining Kudos or purposely flooding the Recently Rated or New Comments lists. This also includes making use of bots for the same purpose.
  • Harassing staff members if uploads take time to be processed. There is a bot that notifies the Re-Volt World Team when a new file has been uploaded.
  • Using other authors’ content with no mention of them in readmes or descriptions. Always check other authors’ policies before incorporating their assets in your work.


  • Make sure your file is properly packed: cars\[car folder]\[car files]. This also applies to skins, where [car folder] is the original car’s folder name. Improper packaging is always an instant rejection.
  • With unique foldername we refer to the car’s folder name, not its in-game displayed name.
  • Make sure all necessary files are properly read by the parameters.txt and that your car works properly. Major collision/landing issues or near-useless parameters can lead to an instant rejection.
  • Don’t reuse parameters from a stock car. Also applies to parameters with very few lines being altered.
  • Check authors’ permissions if you want to use parts from someone else’s work (and contact them if need be), to make sure that all necessary crediting is due. That includes parameters and decal/resource sheets, and also applies to collaborations.
  • Meme content will be treated the same way as regular content, meaning low-effort creations will be rejected, no matter if meant as a joke or not.


  • For remodels, fill in the Based on field with the original car’s unique foldername.
  • Models must show that some care and time were put into them. Quick edits of stock cars, glitchy/broken meshes and simple geometric shapes will be rejected.


  • Exporting a mesh to .prm is a quick process, so don’t rush conversions. This includes mesh fixes, remapping and texture edits, where required.
  • It is strongly suggested to spend some time into refining the gameplay experience of converted cars. General guidelines regarding parameters are especially important here.


  • Repaints are standalone cars. Please provide all car files in their archives.
  • Skins are alternate paintjobs for cars. Please provide only texture files in their archives.
  • A Skin upload shouldn’t overwrite a car’s main texture. For example, if a car’s original texture is called car.bmp, it is not allowed to upload a skin for it named car.bmp. Always attach a suffix to your skin filenames (in this case, car[something].bmp).
  • For repaints, fill in the Based on field with the original car’s unique foldername.
  • For skins, fill in the Skin for field with the original car’s unique foldername.
  • Single-colour paintjobs won’t be accepted, unless they have custom-made detailing or any similar redeeming factor.
  • Filtered or inverted versions of original paintjobs will be rejected.
  • If the base car has a paintkit, improper use of it will result in rejection. This includes but isn’t limited to painting over a stock skin, not preserving shading/lighting layers, aliasing on details.
  • Details that show lack of care can lead to rejection. Examples include misplaced/ovalised/wobbly rims or mismatched patterns (e.g. stripes) between mapping parts, if the base car is known good.


  • Bundling a paintkit is allowed, but all unnecessary files should be removed before submitting a car. This includes but isn’t limited to .blend files or graphics program project files.
  • RVGL-specific car features like statistics, carboxes and shadows aren’t required but strongly suggested. Custom sounds are optional.
  • If a car uses high resolution textures and/or comes with several skins, consider saving them as .png (and renaming the extension to .bmp afterwards) to reduce disk space of unpacked files.
  • Vertex shading helps a lot in making a model look more professional and complete. Auto-shading programs for .prm files exist, as well as an integrated one in Marv’s Blender 2.79b add-on.


  • Make sure your file is properly packed: levels\[track folder]\[track files] and gfx\[track folder].bmp. Improper packaging is always an instant rejection.
  • With unique foldername we refer to the track’s folder name, not its in-game displayed name.
  • No leftover files should be in the archive (Readme and other file bonuses/rewards for the player are okay).
  • Levels with very confusing raceline are not allowed (ie. tracks where it’s impossible to understand where to go unless you enable AI/Pos Nodes).
  • No level that abuses graphical glitches that prevent normal gameplay in any way will be allowed, that includes (but not limited to) levels that make the game crash and tracks where it may be impossible to complete a lap in any way (even if a rare event happens), levels where the player may spawn in the void, battle tags where a player may exit the area and drop into the void.
  • All models must show that some care and time were put into them. This is especially true for short circuits with a simple layout, as well as battle tag and LMS maps.
  • Track should have no technical issues: no collision bugs, no z-fighting should ever happen at medium to close distance (some z-fighting is unavoidable at high distance).


  • Additional features (animated textures, custom animation objects, sounds, music, etc…) should be curated and must not be half implemented. Technical errors will result in rejecting the creation and we will give advice on how to improve it.
  • A bare minimum level of shading is required, we won’t accept flat lighting tracks with no ambient lights that are just bad to look at.


  • It’s okay to be as accurate as possible as long as it doesn’t prevent the track to be played. If the original track is not compatible with Re-Volt (and RVGL) mechanics, you shall find a workaround to make it compatible. Incompatible levels are going to be rejected.


  • No USER_* in a track name, the tag must be removed from the .inf file. Same for folder names, all tracks exported with Track Editor must be renamed.
  • Modifying some track textures is highly recommended. Tracks may be rejected if it’s a simple export straight out of the Track Editor and it’s not interesting enough.
  • Decorations are suggested, but not necessary.
  • Stock Track Editor decorations (walls, boxes, roof lamps) are fine if they don’t excessively “Pop-in”, in other words use an appropriate clipping distance (FARCLIP).
  • There is a game limitation where the last 4 cars of a 13 to 16 player grid are located in the piece directly before the start grid. Make sure that there is enough space for all 16 cars on the start grid, tracks that do not allow some cars to finish a lap will be rejected.
  • Tracks that use a leftover “oval” to export the structure of the actual track and then change the start grid to make it playable are rejected. Use an editing program like Blender with the Re-Volt addon to remove completely construction leftovers.
  • Tracks that re-use files (for example .fob, .taz, etc.) from other tracks, including stock tracks, will be rejected.


  • All tracks should use the latest .inf technology available (for RVGL), these include:
    • Difficulty, challenge time, practice star, sweep cam, reverse version, etc.
  • No player should be able to get an unfair advantage by being able to get a pickup or a star before or immediately after the GO!.
  • All battle tags, stunt arenas and frontends must use the appropriate gamemode setting in the .inf.


  • Make sure your file is properly packed: the top-most folder inside the archive should always be one of the main RV folders (e.g. gfx, wavs, models, etc.).
  • If your misc. upload isn’t meant to be placed in any of the main RV folders (i.e. technically not game content per se), consider uploading it in the Tools section instead.
  • If your misc. upload aims at replacing any stock asset (models, sounds, HUD…), please provide a backup: to do so, just create a backup subfolder inside the main RV folder(s) contained in your archive. This greatly simplifies the user experience for people who don’t use the RVGL Launcher, in case they want to revert back to the original files.


  • Please refer to the Track Guidelines, as most of them also apply to frontends (the game treats them like tracks and they install in the same folder).
  • Make sure to include any additional steps required to install your frontend in the description of your creation.


  • Make sure your file is properly packed: cups\[cup file].txt.
  • Writing a .txt file for a custom cup is a quick process. Don’t rush cups: proper themes, a well-made preview picture and a comprehensive description are mandatory.
  • Include download links for any custom track(s) used in your cup.


  • Make sure your file is properly packed: the top-most folder inside the archive should always be one of the main RV folders (e.g. gfx, wavs, models, etc.).
  • This category is only for creations that actively modify something in the game: consider using the Resources category for files that require external tools or extra handling to be used.
  • If your upload aims at replacing any stock asset (models, sounds, HUD…), please provide a backup subfolder (inside the main RV folders from point 1) with the original files.

Track Mods

  • Please refer to the Track Guidelines for packing information.
  • If the Track Mod modifies files for a single track, specify its unique foldername in the Track Mod for field. If more tracks are modified by your upload, you may leave the field blank and write that information in the description.
  • Always fill in the Online multiplayer compatible? field, even if the answer is Yes.
  • You may upload Track Mods for both stock and custom tracks, provided the custom track authors allow modifications of their work.
  • Low effort uploads (e.g. addition of a practice star to a track) will not get approved. A proper preview picture is also recommended.


  • Resources are files that require external tools and advanced knowledge to be used by other creators, or modifications requiring additional manual installation to be used in-game.
  • The folder structure needs to be as generic as possible: [root folder]\[files].
  • If applicable, include an installation guide. The guide needs to be as clear as possible, and it should include generic instructions that can be used in any creation: do not list a specific car/track, etc.
  • Avoid uploading single files if possible. For example, bundle a pack of models together, or make a decal sheet.

2D Resources

  • 2D Resources are any image or texture created by you, that can be of use for other creators: For cars: decal sheets, details, wheel textures, sponsors, etc. For tracks: textures, skyboxes, fxpage effects, etc.
  • Level of quality and polish will be taken into account when moderating these uploads: aliasing, pureblacks, resolution, pixelation and consistency are a few examples.
  • It’s recommended to convert big textures or heavy bundles to .png.

3D Resources

  • 3D Resources are any model created by you, that can be of use for other creators: For cars: wheels, springs, spoilers, axles, shells, etc. For tracks: objects, instances, track sections or parts, etc.
  • If your models include textures, they should be UV mapped to accommodate said textures.
  • Level of quality and polish will be taken into account when moderating uploads: topology/symmetry, UV mapping, vertex shading are a few examples.
  • Recommended formats are .prm and .obj. For .blend format, specify your Blender version in the description.

Sound Resources

  • These are audio files that can be used by other creators or users. Examples: engine sounds, track sound effects, music (without copyright), etc.
  • Use .wav format wherever possible.
  • Things like granularity, pitch, volume and playback (looping) features will be taken into account when moderating uploads.

Misc. Resources

  • This category is for resources that can’t be included in the other categories. Examples: templates for parameters or .inf track files, text guides, etc.
  • Proper grammar, writing quality and polish will be at the top of our consideration when moderating these uploads: lackluster, dirty formatting and outdated/incorrect data will be rejected.