Talk:Material surface properties: Difference between revisions
(→"Availability" section: new section) |
|||
Line 73: | Line 73: | ||
Any ideas?<br> | Any ideas?<br> | ||
--[[User:MrFunreal|MrFunreal]] ([[User talk:MrFunreal|talk]]) 12:27, 3 January 2025 (PST) | --[[User:MrFunreal|MrFunreal]] ([[User talk: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. | |||
:--[[User:Popcorn|popcorn]] ([[User talk:Popcorn|talk]]) 16:11, 3 January 2025 (PST) |
Revision as of 17:11, 3 January 2025
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)