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.
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)
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)