Talk:Material surface properties

Is it possible to add one's own $surfaceprop to the game? My coder and I have been looking but with little succes. We wanted to add some more types of metal to our mod. Any suggestions? ---Jimius 12:12, 4 Jul 2005 (PDT)

just add an entry to surfaceproperties.txt. Sorted! MLSTRM 14:45, 21 September 2009 (UTC)

Portal 2 custom textures

I was trying to put in custom textures in portal 2 and when I used a snow $surfaceprop hammer stopped working (portal 2 hammer doesn't have error reports; IT SHOULD; but I think that the code used to read $surfaceprop in portal 2 is different from the orange box so when you use an "invalid" $sufaceprop it stops working when loading the resources at startup, because as soon as I took out the texture in question of the materials folder it worked fine) so is there a way to import the "invalid" $surfaceprops from the orange box or should I compile a list of "valid" $surfaceprops and stick to it

Asphalt

Can't find surfaceprop asphalt for material MARK/BLENDROADCONCRETE001A, using default

Need I say more?--Markboydude 18:47, 20 August 2011 (PDT)

Test Map

I created a test map for a Garry's Mod racing game a while back that contains almost all surface properties available for HL2 in the form of world geometry. I'm wondering if the map would be good to post on the wiki's surface property page so people can see the interactions?

Here's the map on dropbox: gmr_test_surfaceproperty.bsp I also made some of my own documentation. Its on GoogleDrive

The map was never put on the server and thus never used to test the racing game mode like I had planned. It took me a while to make all the .vmf files and put them in the map. I would like it to be public so other people can make use of it. --Bamboy360 12:17, 28 February 2014 (PST)

Jumpfactor

Is there a way to edit the "jumpfactor" of a material in Counter-Strike: Source or Counter-Strike: Global Offensive and have it working upon packing the map? The only way I've gotten this working is through the surfaceproperties_manifest by adding your own per-map surfaceproperties_mapname file. These are placed in the "Custom" folder (Cstrike directory) and once packed, don't seem like they override the game's surfaceproperties_manifest.

You mean solely packed in the bsp with no additional files or plugins anywhere? No. --Sirhephaestus (talk) 00:52, 25 January 2024 (PST)

Any plans on expanding the information on this page?

It would make sense for every surface property to have its information on its own page. Particularly for strange ones like water, or slime. More information can't be bad, right?

It would be good to have more information, but in my opinion most surfaceprops aren't unique enough to feel like they need their own pages. Loudslappingsounds (talk) 01:47, 24 December 2020 (PST)

Where do tf2's surface properties go?

I was looking into the surface properties manifest text file when I found a couple of undocumented surfaceprops, there being grenade_napalm, wrecking_ball, demoman_grenade, scout_baseball, scout_ornament, ball_bouncy, passtime_ball, and snow (good chance that last one is modified to fit tf2's physics in some way). Where should they go accordingly? --Whatausername64 (talk) 18:31, 9 June 2022 (PDT)

$surfaceprop rubber sound issues

Just an FYI, the rubber $surfaceprop has sound clipping and should not ever be used, at least in .

VMTs with no $surfaceprop will have issues

Not including a $surfaceprop in a vmt for brushes will cause the material to take on the sound (and perhaps the other properties as well) of whatever the last material you interacted with that did have a $surfaceprop defined. Tested in --Sirhephaestus (talk) 18:56, 29 May 2024 (PDT)

"Availability" section

I feel like we should author the Availability section a bit, or maybe reformat the whole list even.
Some surfaceprops are only in one game, and some are added in one game, used in the next, but not ported to the game after. For example "Watermelon" is in HL2, it is listed in the L4D2 surfaceprop but commented out, and i think csgo had it again.
So since this list is pretty odd by now, we should do something, i think. I had three ideas on how we could make this easier:

• Do it like Tool_textures_(Source) where we got a box of "base HL2 surfaceprops" and then below another box for game specific ones where we could add stuff like the l4d2 melee weapon surfaceprops, or the ep2 jalopy tire.
• Add the "in" and "not" templates to every "availability" box, but i think this might expand the list vertically quite a lot.
• Make two new columns, one for "in" and one for "not in" in which we just add the game logo template like this:

Surfaceprop	Description	In	Not in
Watermelon	For the fruit.

Any ideas?
--MrFunreal (talk) 12:27, 3 January 2025 (PST)

Good ideas. I find the last one interesting because if both columns "in" and "not in" are empty, you can tell that one should find out theirselves because no one has investigated yet (which isn't communicated at the moment).

I think your first idea with distinct tables could make sense: one table for "since hl2", eventually more "since" tables and one table for the rest? Not sure if that works out but combined with the "(also) in" and "not in" columns, this could become good, not sure.

Apart from that, in the current state I personally find it better if the column "Availability" is on the left (as long as it doesn't get wider than "in all games since X"), such that the widest column "Description" is on the right.

Right, it's complicated. But can we make it "better" by splitting by game? I don't know. I think its current sorting by material categories is ok so if we change that ground up, it should become convincingly better.

Since people come here to find legal values for the $surfaceprop VMT material property for their game (they do, don't they?), a per-game overview makes sense. I'm asking myself whether one table with all games' surface properties and an availability column (like the current one) is sufficient or whether per-game subpages with one unmistakable table could also come into question (for example Material surface properties/Half-Life 2 containing only hl2 surfaceprops).

I once wrote a small program to generate the List of CS:GO Surface Types. The table I made for that page is of course very wide (well, in case we go for the subpages I mentioned above, such tables could in fact be good) but maybe I can reuse the program to generate a different table for our purpose, combining multiple games? I would just have to find out what we want to have in that table.

--popcorn (talk) 16:11, 3 January 2025 (PST)

That's one WIDE list. Personally i'd use this page when making models or materials and can't remember what surfaceprops even exist. So all the data is not that relevant for those moments.

If i had my way, i would personally go with one list that has the "in" and "not in" columns. Because i think if we had a list for each and every game this page will become very tall to scroll through, and most lists will be 90% filled with the same basic surfaceprops. And making a list for "only" the special things that other games have, like "strongmanbell" in l4d2 and csgo would be odd, cause that's a custom thing two games have.

I do like your point of "if the logo is missing, its because nobody bothered to check yet", which would be like an implied "Todo, check other games".

But i got a feeling that if you add the "availability" to the very left, then any "not in" might become very wide. And a "Since" is also not really that useful, Because who's to say that the next game actually uses it. Like jalopytire. Introduced in hl2ep2, but only in ep2.

I own all the HL2 games, css/csgo, l4d1/2 and some more. I wouldn't mind scraping through all the surfaceprops and authoring the list for all the games i have with the one large table.

Preferably this type of table, because if you look at it in "edit mode" it looks clean and easy to write in. (Colors are just copied from somewhere. We can even color boxes inside the table like the current one)

In	Not In	Surface Property Name	Description
		Watermelon	For example purposes, this list has a very wide "In" and "Not in" to make the point that the surfaceprop name is pushed quite far to the right into the list.
(in all games since ) (also in )		Strongmanbell	A "Since" template would make this first box really wide. Unless we use a spearate "Since" column that does not use this template? But even then. I feel like the surface property name should be the first in the list.

Should i give it a go and for now make the separate lists for each of the Special, Concrete/Rock, Paper... surfaceprops, spanning all games at once, with the "in" and "not in" to the right? It can easily be reordered afterwards if we change our minds.
--MrFunreal (talk) 05:47, 7 January 2025 (PST)

Yes, sure, go ahead. Only suggestion I'd have is that the name of the $surfaceprop should go to the left because as you mentioned, people want to know what materials exist and I would expect the main key of the row to be in the first, not in the third column.

OT: Um... "clean and easy to write in"? Compared to regular table wikisyntax? And if I'm noticing this right, the indented {{table}} seems to break indentation below it... Why not class=wikitable (or standard-table)? I know, your example may look cooler, but this template nesting is not nice to maintain, defeats the purpose of tables in wikisyntax, and – if only there was a corresponding table class creating the same look – would be unnecessary template load. Maybe request a new css table class?

--popcorn (talk) 07:57, 7 January 2025 (PST)

Ah, i see. The table for some reason doesn't "un-indent" below. But the tables on this page won't be indented to begin with. shrug. I'll do the default boring table then.

--MrFunreal (talk) 09:12, 7 January 2025 (PST)