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@example.com 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)
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)
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.
- 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)
Source SDK 2013
Someone provided some helpful instructions on how to get it to work with SteamPipe and 2013. If other people have had success with it, perhaps they can be added to the page: http://forums.steampowered.com/forums/showpost.php?p=34624716&postcount=8. Druckles (talk) 17:36, 10 February 2015 (UTC)
Not generating .phy files for physics props?
I've made a few props with propper before, but just now I tried to make some mroe physics props and for some reason it isn't generating the .phy files for these ones, so the props don't move and give a "can't create physics object" error in the console. However, Propper doesn't seem to output any errors of any sort, and I can't htink of anything I've done differently with these models that could be causing this. Anyone else ever have this issue? Greenhourglass (talk) 08:13, 29 July 2017 (UTC)