I'm not sure if there is a performance benefit but I woke up bored this morning and was playing around with my HUD and decided to read the readme in the tf/custom folder that's always been there.
Mounting a VPK to the filesystem is more efficient than adding a subfolder,
as each time the engine needs to open a file, it will need to make a call to the
operating system to search the folder. VPKs can therefore be searched by the engine
much more efficiently. Each subfolder is a new search path that must be checked each
time the engine tries to open a file. So, for optimal load times, always use VPK files
and don't make any subfolders in this folder!
So then I was like hmm lets make my hud and config into a vpk based mod instead of just a bunch of folders.
Someone should do some tests, not just with huds, but hitsounds, custom shit.
Pretty much you go into tf/custom/ and open another window to common/Team Fortress 2/bin/ and drag your /flamehud/ or whatever other folder onto the file called vpk.exe in the /bin folder.
It will create a vpk of all of the shit in your custom directory, you can then delete or move the subfolders and play.
Idk it could be useful in the future as you could write a hud with this structure in mind and have addons just be 1 file to drag and drop rather than having to tell people to move and replace files.
I figure there has to be a performance benefit if they took the time to explain the efficiency in the readme.
For me, it's annoying because I'm constantly updating and changing stuff but if youre one of the people who just downloads and installs a hud without worrying about it, it might save some frames
I'm not sure if there is a performance benefit but I woke up bored this morning and was playing around with my HUD and decided to read the readme in the tf/custom folder that's always been there.
[quote]Mounting a VPK to the filesystem is more efficient than adding a subfolder,
as each time the engine needs to open a file, it will need to make a call to the
operating system to search the folder. VPKs can therefore be searched by the engine
much more efficiently. Each subfolder is a new search path that must be checked each
time the engine tries to open a file. So, for optimal load times, always use VPK files
and don't make any subfolders in this folder![/quote]
So then I was like hmm lets make my hud and config into a vpk based mod instead of just a bunch of folders.
Someone should do some tests, not just with huds, but hitsounds, custom shit.
Pretty much you go into tf/custom/ and open another window to common/Team Fortress 2/bin/ and drag your /flamehud/ or whatever other folder onto the file called vpk.exe in the /bin folder.
It will create a vpk of all of the shit in your custom directory, you can then delete or move the subfolders and play.
Idk it could be useful in the future as you could write a hud with this structure in mind and have addons just be 1 file to drag and drop rather than having to tell people to move and replace files.
I figure there has to be a performance benefit if they took the time to explain the efficiency in the readme.
For me, it's annoying because I'm constantly updating and changing stuff but if youre one of the people who just downloads and installs a hud without worrying about it, it might save some frames
This would somewhat kill customization as I think the VPK has priority over the separate files in your custom folder.
I will try this by extracting the default hudfiles for #base includes into a new VPK (basically moving them) for faster loading/smaller file size.
This would somewhat kill customization as I think the VPK has priority over the separate files in your custom folder.
I will try this by extracting the default hudfiles for #base includes into a new VPK (basically moving them) for faster loading/smaller file size.
Yeah I wouldn't recommend it from a customization standpoint at all, but from a modification and addon point of view its pretty nice.
If someone wants my damage numbers I can now just make a vpk called damagenumbers and itll just be a single file that goes in /custom instead of having to tell people where to put it and how to maintain it.
I haven't seen much rhyme or reason to the prioritization though. I was able to change my hud files and reloadscheme, and see the changes, even with the vpk there. It might have to do with filename or something or change date but I can't make sense of it yet.
Either way if your hud is done for you personally, and you just want to not think about it, it might be worth it for the end user to package all of their custom addons into one file if it turns out to show some positive performance impacts.
Yeah I wouldn't recommend it from a customization standpoint at all, but from a modification and addon point of view its pretty nice.
If someone wants my damage numbers I can now just make a vpk called damagenumbers and itll just be a single file that goes in /custom instead of having to tell people where to put it and how to maintain it.
I haven't seen much rhyme or reason to the prioritization though. I was able to change my hud files and reloadscheme, and see the changes, even with the vpk there. It might have to do with filename or something or change date but I can't make sense of it yet.
Either way if your hud is done for you personally, and you just want to not think about it, it might be worth it for the end user to package all of their custom addons into one file if it turns out to show some positive performance impacts.
I did some testing before and every time tf2 loads a file, it checks every folder mod for it too. That's what it means by "makes a call to the OS to search the folder." So if you had one folder mod, your load times would be doubled. More folder mods = worse load times. Vpk's solve this by having a manifest of all the files they have, so the worst they get is a bit more overhead memory used but no significant increase in load times.
The issue with huds in vpk's is that font files don't get loaded from within vpk's for some retarded reason. The only way you could get a whole hud (that uses custom fonts like 99% do) into a vpk is if you made the user install all fonts included. This isn't really an issue for all huds, but really limits what you can do and adds another step into installing.
I do believe you could get things like a custom crosshair.res outside of custom and thus not require a folder mod to edit, and load that in through #base, but iit'd be pretty confusing and again would just be another step for installing.
I did some testing before and every time tf2 loads a file, it checks every folder mod for it too. That's what it means by "makes a call to the OS to search the folder." So if you had one folder mod, your load times would be doubled. More folder mods = worse load times. Vpk's solve this by having a manifest of all the files they have, so the worst they get is a bit more overhead memory used but no significant increase in load times.
The issue with huds in vpk's is that font files don't get loaded from within vpk's for some retarded reason. The only way you could get a whole hud (that uses custom fonts like 99% do) into a vpk is if you made the user install all fonts included. This isn't really an issue for all huds, but really limits what you can do and adds another step into installing.
I do believe you could get things like a custom crosshair.res outside of custom and thus not require a folder mod to edit, and load that in through #base, but iit'd be pretty confusing and again would just be another step for installing.