Patching levels with lump files: Difference between revisions

From Valve Developer Community
Jump to navigation Jump to search
m (this is removed in source 2013 MP (not sure for SP))
m (typos)
Line 2: Line 2:
{{Game link|Half-Life 2: Episode One}} added a simple system to allow mapmakers to patch levels by shipping only the level lumps that have been altered. It is usually used to update entity lumps, changing a .BSP file's entities without a recompile necessary.
{{Game link|Half-Life 2: Episode One}} added a simple system to allow mapmakers to patch levels by shipping only the level lumps that have been altered. It is usually used to update entity lumps, changing a .BSP file's entities without a recompile necessary.


Technically, it is written to handle any .BSP file lump, but there are lumps that itself heavily depend on other lumps. For example, altered geometry in a map even slightly changes many lumps, and each changlhed lump would need to be selected by hand. Once many lumps have been changed, until tools made for checking changed lumps have been setup, you may as well compile a new .BSP. Until tools
Technically, it is written to handle any .BSP file lump, but there are lumps that itself heavily depend on other lumps. For example, altered geometry in a map, even slightly, changes many lumps, and thus each changed lump would need to be verified by hand. Once this many lumps have been changed, until tools made for checking altering lumps have been setup, you may as well compile a new .BSP file.


{{warning|Removed in {{src13mp}} games.}}
{{warning|Removed in {{src13mp}} games, and onwards.}}


== Creating and using new lumps ==
== Creating and using new enttity lumps ==
The steps involved are as follows (assuming that a previous version of the .bsp file has already been shipped):
The steps involved are as follows (assuming that a previous version of the .bsp file has already been shipped):


Line 23: Line 23:
  <bsp name>_l_<id>.lmp
  <bsp name>_l_<id>.lmp


After loading the .bsp, the engine will then load .lmp files starting at id 0, and stopping as soon as it fails to find a .lmp for the next id. Each .lmp file overrides any existing lump in the .bsp, or preceding .lmp files. If a new lump has already been shipped as a <code><bsp_name>_l_0.lmp</code> file, that lump can overridden with a <code><bsp_name>_l_1.lmp</code> file.
After loading the .bsp, the engine will then load .lmp files starting at id 0, and stopping as soon as it fails to find a .lmp for the next id. Each .lmp file overrides an existing lump in the .bsp with the corresponding lump type, or preceding .lmp files. If a new lump has already been shipped as a<code><bsp_name>_l_0.lmp</code>file, that lump can be avoided being overridden with a<code><bsp_name>_l_1.lmp</code>file.


== Hammer compile profile ==
== Hammer compile profile ==


The following lines of code can be entered into Hammer's advanced compile dialogue to automate lump creation:
The following lines of code can be entered into Hammer's advanced compile dialogue to automate lump creation of the entity lump:


  '''$bsp_exe'''
  '''$bsp_exe'''

Revision as of 21:40, 22 May 2021

Half-Life 2: Episode One Half-Life 2: Episode One added a simple system to allow mapmakers to patch levels by shipping only the level lumps that have been altered. It is usually used to update entity lumps, changing a .BSP file's entities without a recompile necessary.

Technically, it is written to handle any .BSP file lump, but there are lumps that itself heavily depend on other lumps. For example, altered geometry in a map, even slightly, changes many lumps, and thus each changed lump would need to be verified by hand. Once this many lumps have been changed, until tools made for checking altering lumps have been setup, you may as well compile a new .BSP file.

Warning.pngWarning:Removed in Source 2013 Multiplayer games, and onwards.

Creating and using new enttity lumps

The steps involved are as follows (assuming that a previous version of the .bsp file has already been shipped):

  1. Make a backup copy of the current .bsp.
  2. Make the desired changes to the level, and compile a new (revised) .bsp.
  3. Use "%sourcesdk%\bin\vbspinfo" -X bspname to extract the entity lump into a .lmp file.
    Note.pngNote:The .lmp file will be created in the same directory as the input .bsp.
  4. Put the .lmp files into your gamedir\maps directory (if they aren't already), and ensure their <id> numbers are correct (see below).
  5. Make a backup copy of the revised .bsp.
  6. Restore the backup of the old .bsp, and run the map to test it with the new .lmp. Make sure it works properly with the updated entities.
  7. Ship the .lmp files only.

ID numbers

.lmp files are automatically named in the following format:

<bsp name>_l_<id>.lmp

After loading the .bsp, the engine will then load .lmp files starting at id 0, and stopping as soon as it fails to find a .lmp for the next id. Each .lmp file overrides an existing lump in the .bsp with the corresponding lump type, or preceding .lmp files. If a new lump has already been shipped as a<bsp_name>_l_0.lmpfile, that lump can be avoided being overridden with a<bsp_name>_l_1.lmpfile.

Hammer compile profile

The following lines of code can be entered into Hammer's advanced compile dialogue to automate lump creation of the entity lump:

$bsp_exe
-game $gamedir -onlyents -keepstalezip $path\$file
C:\Program Files\Steam\steamapps\<Steam account name>\sourcesdk\bin\vbspinfo
-x0 $path\$file.bsp
Copy File
$path\$file_l_0.lmp $bspdir\$file_l_0.lmp
Delete File
$path\$file_l_0.lmp

If you are creating a lump file with an ID number other than zero, change the last two commands accordingly.

Note also that a Hammer bug currently prevents the use of $SteamUserDir or %sourcesdk% in the second command; using either will lead to "access denied" error messages.

See also