gibs models & assets referenced in I/O events won't be packed.

[agaertner]

I have a point_servercommand entity that has an input that fires the source command "play path/To/Sound.wav" Since no actual entity parameter like ambient_generic is using it it won't be detected by PakRat or VIDE. Luckily, both VIDE and PakRat have a manual adding button, but VIDE has a bug with the fixation of the file path and PakRat corruptly packs the materials.

I am now compiling with CompilePal, but I am pretty sure it won't detect the sound file either.

I think adding an entity like ambient_generic and link it to the sound is enough for a work-around. ~But I dislike the idea of having an entity in my map that won't be used ever.~ EDIT: I am just using ambient_generic with the 'Play everywhere' flag now. I forgot about that.

But the more important issue are gibs models (broken pieces of destroyed physic models) not being detected and packed. I had to manual add these using PakRat.

The only solution would be manual parsing as I am unsure if you want to just search for a gibs/ folder and add everything in there. Names could vary from the original model.

So, here I would like to request a manual adding button.

[maxdup]

Not parsing server I/O is deliberate. Otherwise we'd have to deal with all the commands like prop_dynamic_create and prop_physics_create. Server commands are usually a bad practice as far as mapping is concerned. Server operators can disable point_server command and usually do so that's a battle we choose not to fight. It wouldn't be impossible to do but parsing this stuff is going to be a mess.

Having dummy entities with start_disabled is the approach I would suggest for compilepal detection. You can even send a kill input at runtime if you're a little short on entities.

A manual packing feature is unlikely but I'll consider adding a feature for users to provide a list of assets to be packed additionally, much like bspzip would. https://developer.valvesoftware.com/wiki/BSPZIP

As for gib support, I'll look into it. surely it can be automated by looking inside mdl files.

[agaertner]

Thanks for your work.

It is not about parsing the asset path as server command in point_servercommand (It can be disabled with sv_allow_point_servercommand), but rather any asset parsed inside any entities I/O parameters.

As for the gib models. I didn't know you could look inside the mdl. That's crazy. Isn't it compiled as crypted? You gonna read byte for byte? I wanna know how you wanna approach this.

[ruarai]

maxdup's packing code already reads the model byte by byte so that shouldn't be too much of an issue.

As for the custom asset list, that does sound like it could be useful, maybe just a little hard to fit into the current UI.

[agaertner]

As for gib support, I'll look into it. surely it can be automated by looking inside mdl files. -- maxdup

If you need an example model with alot of gibs for testing purposes. My friend 'n colleague made one on request for me:

• A breakable buddha statue compiled for ep2 (latest) - (direct)

I am very interested on how you read the *.mdl. Why is the long value here hardcoded? I read something about it at the valve wiki page of the bsp file format which states that it is the gamelump ID of static props ('sprp' ASCII which is 1936749168 decimal). Could you educate me about this quickly?

My guess is it has something do to with the maximum index size of a BSP.

[maxdup]

Now that you mention it, I suppose sprp simply means static_prop. I won't go into details here but essentially, 1936749168 marks where the array of static_props is in the bsp. I'm obviously too lazy to compare it against 'sprp' so I'm going off the integer value. I think the location for the list of prop_static can change from one game to the other so I have to look for that identifier.

but yeah, if you want to see the code that actually digs into mdls, this method is what gets materials out of mdls and I just got reminded that I have a lot of unfinished business here. Mdl is pretty complex and can store particle effects and ropes so I'll be looking into that while I'm looking for gibs.

Thanks for the model btw, that'll come in handy

The main problem with digging for assets in entities I/O is that source is very inconsistent. Suppose you have two commands that expect a path to a material, one command will expect a path formated as "materials/decal/blood.vmt" and the other will expect "decal/blood.vmt" since it assumes it's in materials/. it's really is a mess. On top of that, source often has trouble caching assets that are only referenced in I/O so I simply don't bother (altho gmod is not as crippled by this). And on top of that, I'd have to parse addOutput inputs. That's a nightmare you don't wake up from.

[agaertner]

Don't forget that gibs can have materials that vary from the base model. So you'd need to search in every gib model that was detected for materials. (You can find a bonsai tree model or a vase on that same page that has separate gib materials. Buddha statue is the exception.)

As for the find materials function. Cool stuff.

[maxdup]

Alright so here we go, I've added support for gibs and ragdolls. e99654b1986d25e75660a061b9f89d58956469a5 These features will be shipped with version v25.

Turns out they were both referenced in .phy files.

so yeah I/O assets are a definitive no from me, we will consider pull requests if someone wants to implement it tho. Closing issue.