From Valve Developer Community
Revision as of 14:16, 25 February 2012 by Cfoust (talk | contribs) (Texture lighting)
Jump to: navigation, search

What is the developer's contact information? It's hard to report bugs, ask questions, etc.

For myself, when I try to run Propper, I get "The procedure entry point GetCVarlF could not be located in the dynamic link library vstdlib.dll" and then it closes.

If I try to run it through Hammer, nothing happens at all.

Make sure that you have ticked the checkbox next to "propper -game $gamedir $path\$file" in the advanced compile window. StephenB 14:56, 22 December 2010 (UTC)

I'm probably doing something wrong. I'm not entirely sure of the folders that need to be created. A fuller example would help.

--sagesource 07:38, 8 October 2009 (UTC)

The tool doesn't currently work with the Orange Box SDK. I'll fix this soon. Hopefully I can make the tool create the folders you need--I just can't figure out how yet.
NEVER MIND WHAT I JUST SAID, IT'S FIXED. cfoust 18:48, 17 November 2009 (UTC)
Use this talk page or email me at [email protected] cfoust 03:05, 12 October 2009 (UTC)

This looks really nice. I look forward to seeing this turn into a full featured tool.--cheesemoo0 20:10, 27 October 2009 (UTC)

Wonderful. Now the only frustration is trying to use it for Left4Dead, since there doesn't seem to be any list of the textures common to both Ep2 and L4D. Still, that's not your fault. Many thanks! sagesource 18:51, 27 November 2009 (UTC)

This tool is great! I have tried XSI before but I didn't like it, I didn't know where to begin. Thank you very much! StephenB 15:41, 22 December 2010 (UTC)

Unwanted/Superfluous collision parts

Just found Propper the other day after mucking around with Crafty, XSI and Blender unsuccessfully for simple Hammer -> Model conversion. However, I sometimes run into the issue that in a structure with vertical bars, Propper will create an additional rectangular collision piece that covers all the bars as well as the space in between the bars. This issue appears to be similar to the one reported by someone else in this Facepunch thread. The unwanted piece of the collision model in my case looks exactly like the one in the image shown there. Though my model is a lot larger and is created from lots of brushes, including 61 vertical bars distributed along 3,724 Hammer units. The fact that there are other brushes intersecting with the bars might be significant. I'll send you my map and the generated model if you want them. --Isor 14:45, 23 May 2010 (UTC)

Testing revealed that this doesn't appear to be an issue with Propper, I created a smaller test model and found that the SMDs created by Propper are correct. You can work around Studiomdl's wrong optimization by making the intersecting bars stick out at one end or changing the collision model so that no bars intersect at all. --Isor 12:41, 24 May 2010 (UTC)

You can get around this by adding the line $maxconvexpieces to the qc file (Orangebox only) and then recompiling with studiomdl. Future versions of Propper will do this for you. cfoust 01:46, 1 June 2010 (UTC)

No, this isn't that issue. I correctly used $maxconvexpieces as necessary. As I wrote, a mostly correct collision model is output - Studiomdl just "optimized" some intersecting bars incorrectly. As I wrote, I tested with a smaller model (4 brushes) and found that you can work around the issue by forming your model correctly/avoiding intersecting brushes. The issue that you are talking about can't be worked around by changing brushes (only by deleting some; or using $maxconvexpieces or -fullcollide). --Isor 14:00, 1 June 2010 (UTC)
Oh, I think I understand now. Studiomdl considers any two vertices with an identical position and normal to be part of the same hull. I see how this could easily happen if you have brushes that overlap. cfoust 22:02, 1 June 2010 (UTC)

FGD order

I'm trying to configure Propper for TF2, but I can't put the tf.fgd before propper.fgd! Edit: Never mind, checked the FAQ!--Vihannes 14:48, 6 June 2010 (UTC)

Origin of propper_info entity: not scaled by Propper

Selecting the origin of the propper_info entity as model origin doesn't correctly work with scaled models. I.e. I let Propper scale the model down and it correctly writes the $scale line to the .QC but the position specified by $origin isn't adjusted. Apparently this has to be done by Propper (you currently have to edit the .QC), $origin isn't affected by $scale. --Isor 19:37, 10 June 2010 (UTC)

Texture lighting

If I use a texture that is lit/emitting light (.rad), after compiling does it still work (aka emit light)? I would like to convert one of my fancy street lamps into a static model so I can decrease brush count.

Sounds like something you could easily try yourself. —Mattshu 07:16, 8 January 2012 (PST)
No, models don't respect lights.rad. You'll have to pair it with light entities. Or place an invisible func_brush that uses your light-emitting texture. cfoust 14:16, 25 February 2012 (PST)