Need information on Source mods: Files that go with maps

[Terr]

I'm working on adding a user-editable config file for PackBsp, that specifies what "map includes" exist for common mods and game engines, and I need help to get it to a good default state.

What do I mean by "map includes"? Resources that depend on the map-name, like:

• maps/mapname.ain (AI annotations for navigation, all engines?)
• maps/graphs/mapname.nav (Navigation mesh, all engines?)
• materials/overviews/mapname.vmf (Overview image for DoD/CS:S, maybe others)
• materials/overlays/mapname_radar.vmf (Radar overlay for CS:S)
• maps/mapname.txt (Map description, all engines?)

I think I've got most of them down for TF2 and CS:S, but I'm not sure about DoD, Portal, or the various HL2 editions, or even which things are default for a particular engine (Source2006/ep1, Source2007, Source 2009/orangebox)

So if you're a mapper or modder and you can think of something like those "map descriptions" or "map overlays" etc. that you do when making a custom map, please post about them here.

[Noodles]

You'll need the server list map image for TF2

[Terr]

You'll need the server list map image for TF2

I was told those images (the ones seen in the "simplified" server browser) can not be packed into the BSP for distribution, but have to be their own separate file on-disk to work. (Presumably because they need to be accessed quickly without opening up the map-file.)

[Mr. Happy]

Your talking about the .res file that lists custom assets, that's not neccessary if the assets are packed in the bsp.

mapname_particle_manifest.txt and mapname_detail.vbsp should be included.

[Terr]

mapname_particle_manifest.txt and mapname_detail.vbsp should be included.

Particle manifests are already handled, as well as the detail sprites' VMT file.

AFAIK:

• The detail-sprite .vbsp is not necessary to pack, since it is only used during the compiling process to semi-randomly generate the detail props in the BSP. It isn't used at runtime.
• While the detail-sprite VMT (and referenced VTFs) does need to be packed, it is specified in on the worldspawn entity, and can be named whatever.

[omnicoder]

I noticed last time I used it that it doesn't check overlays, infodecals, screenoverlays or projecteddecals.

[Terr]

Prior to 2.0.1 it didn't see infodecal and info_projecteddecal, since those use the FGD type "decal" rather than "material".

But AFAIK the other two entity types using "material" in the FGDs, and ought to be detected.

[Terr]

Oops.

It seems env_screenoverlay and env_projectedtexture will both need some custom code, neither one works "normally".

[omnicoder]

trigger_vphysics_motion also contains a non-browsable property for choosing a sprite material, so I'm guessing it's affected as well.

[Terr]

env_projectedtexture is annoying. Apparently the only way to set the material used is through an Input, and currently I don't support I/O stuff. (Because it's a pain in the ass to try to predict what will come out of that system, especially when we start talking about things like AddOutput.

trigger_vphysics_motion also contains a non-browsable property for choosing a sprite material

I may give it the same custom-code treatment env_screenoverlay and the color-correction entities have gotten... Or it may be enough now to justify a general config-driven solution for these special case entities. Ex:

Code: Select all

<entclass name="env_screenoverlay">
    <prop name="OverlayName1">
        <prefix>materials/effects/</prefix>
        <suffix>.vmt</suffix>
        <type>MaterialNode</type>
    </prop>
    <prop name="OverlayName2">
        <prefix>materials/effects/</prefix>
        <suffix>.vmt</suffix>
        <type>MaterialNode</type>
    </prop>
    <!-- Properties ending in 3-10 not shown -->
</entclass>
<entclass name="trigger_vphysics_motion">
    <prop name="ParticleTrailMaterial">
        <prefix>materials/</prefix>
        <suffix>.vmt</suffix>
        <type>MaterialNode</type>
    </prop>
</entclass>
<entclass name="color_correction">
    <prop name="filename">
        <type>MiscFileNode</type>
    </prop>
</entclass>
<entclass name="color_correction_volume">
    <prop name="filename">
        <type>MiscFileNode</type>
    </prop>
</entclass>


[omnicoder]

Another oddball is material_modify_control.

[Terr]

After poking around with GCFScape (I wish I could search multiple GCFs at once) it seems:

• material_modify_control prepends "materials/" and appends ".vtf"
• trigger_vphysics_motion ought to be a "material" type (prepends "materials/", appends ".vmt")
• env_screenoverlay prepends "materials/effects/" and appends ".vtf"

[Terr]

Okiedokie, went ahead and cut a release for 2.0.3. It adds workarounds for issues I'll need to solve better later.