Awesome tool! Well done!

Thanks. Source is a little messy but I figure if I wait until I get around to tidying it, it'll be awhile. I started adding VTF parsing, I might put out an update to generate light-weight versions of campaigns. We'll see if I get around to it.

I'm sure there are some VMT parameters I should be looking at that I'm not, like $burndetail. If it's not packing something you think it should, send me the details and I'll try to patch it.

I tested it on my campaign, and it seems to find everything. Awesome!

One question about the cubemap textures (i hope this isn't too OT either). Is there any gain from packing them into the vpk? It's the same textures that get packed into the .bsp, right? I've seen them inclued in a few campaigns, but never noticed any missing reflections when I've tested my vpks without them.

Originally posted by Rectus:

One question about the cubemap textures (i hope this isn't too OT either). Is there any gain from packing them into the vpk? It's the same textures that get packed into the .bsp, right? I've seen them inclued in a few campaigns, but never noticed any missing reflections when I've tested my vpks without them.

If it's already embedded into the BSP, then you do not need to separately include it. You can use Pakrat to scan the BSP:

https://developer.valvesoftware.com/wiki/Pakrat

A cool idea for Campaign Packager is to scan the VMF itself for models, materials, sounds, etc. Then it can recursively search through and include related files. If you need a VMF parser, I wrote one in c++ a while back which I can share. Maybe you can convert the code to Perl?

Anyhow, I used Campaign Packager and it worked flawlessly for me. Gonna be super helpful :) Thank you sir!

Thanks guys. Glad no errors so far. Hmm, as far as cubes, I know the patched materials themselves are embedded in the bsp, but are the cubes themselves? I didn't think they were.

It's funny you mention the VMF parsing. I already have one that I wrote to compact texinfos for tool materials.as they still count towards limits. I was going to merge it, mainly to get vscripts and ambient generics but I figured it would be a bit more complicated for the user as the vmfs might be anywhere on the filesystem where the other assets are fixed in layout relative to the game root..

Maybe what I'll do is make a separate tool can spit out the appropriate mission include comments
//PACKMISSION(scripts\vscripts\blahblah.nut)
as well as compact materials, and properly collapse instances. Hammer always messes it up, and I find it annoying that SFM's vbsp can't deal with them.

I might actually whip up a vmf2smd converter as well, mainly for vsscript2smd[www.leeland.net]. It would be nice if propper had an option to envelop func_ brushes to a bone named after their name but not going to happen so I may myself. Would be nice if you could blow up a func_physbox scene, then you could record out the animation, compile your vmf geometry as smd, and have a whole working model without having to envelope a million pieces of debris. I also need to finish porting that to the Beta, unfortunately it's going to be limited to 10fps, unless maybe I can steal HUD_SPECIAL_TIMER0, etc to drive the clock

Wow vsscript2smd looks awesome! Definitely gonna give that one a whirl as well.

What we really need is OnGameFrame(). I updated the VScript suggestions thread asking for something that fires more often.

I was going to reiterate I'd settle for sv_script_think_interval, but looking through the dll, it IS there. So you can have a steady 30 fps, though on existing maps, may cause issues as it's thinking 3 x as much as intended. Oh, the timer hud stuff while it fires faster, it's only like 4-5 fps. I need to finish porting the vscript2smd to the beta

So you can modify the fps, but you need to set that via convar in your mode file. Not possible from the console. I'm working on the port now. I'm adding the ability to record yourself and eyesangles so you can noclip camera intros

May I ask, how does the recording and playback work?

I'm just recording a big array of origins/angles for multiple objects. When you are happy with what you've got, it's exported out to an SMD animation. Playback in the tool is just setting the origin/angles for review purposes

How does the exporting work? Do you just copy the origins/angles to a SMD file via a filesystem class? I'll give the code a look when I get home-- I'm kinda curious :)

I don't export any geometry, just the origins,angles. So you take a bunch of named func_physbox, prop_dynamic, add the RegisterProp() hook to them, Then start recording, cause whatever the physics are, exploding, waking, etc, and export it.

Now take the map, change the script to your newly compiled model, change your physbox, to func_brush, your prop_physics to prop_dynamics and change the RegisterProp() hook to ParentProp().

As far as I know, there is no way in engine to get at mesh data. Ideally, you would be able to take all your func_physbox, etc and make that part of a single model. That's what I was hoping for in Propper. An option to envelope func brushes to a bone named after themself, and have them in ascii order. If that were the case, the animation would mate perfectly with the propper geometry model

I see. So your script basically takes a bunch of origins and angles via a think function and then exports them "frame by frame" to play back a certain animation?

More or less. It's mainly geared towards recording physics stuff. Besides repeatability, physics has a ton of lag. Let's say you wanted to do an airliner crash, you could hold together all your pieces of plane with physics constraints and launch it into your map letting it break apart into the scene, flipping cars and what not as it goes. A lot easier than getting your vmf plus mdls into some 3rd party program and learning how to physically simulate sutff. I plan to add some mdl sound/particle options. So for instance, when a chunk of concrete bounces off a wall, it will generate an impact sound/particle effect in the mdl itself. Ideally though, it would automatically take all those brush based ents and make that one model. I would imagine figuring out the plane/plane intersections to triangulate wouldn't be so bad, but I know from past experience I don't quite grok how to handle the texture mapping of brushsides correctly.

How do you plan on recording dynamically created particles? Not possible without some kind of entity spawn listener.