A VScript function to pack a file or a folder

[Lizard-Of-Oz]

A common problem with large VScript creations (e.g. VS Saxton Hale) is that mappers using them forget to pack in the files. Having to instruct them how to use -includedir is annoying, so is having to juggle multiple such projects. Because the names of resources might be generated in runtime, as well as entities using resources, it's unlikely that automatic resource inclusion will ever work well with vscript.

Proposed solution: add the ability to -includedir from a vscript file.

I imagine it working via scraping for a special line like //#IncludeDir(dirPath) or //#IncludeFile(filePath). Currently I'm using a commented out PrecacheModel function, but it's a hack, and it doesn't support directories.

[Exactol]

How are the resources generated and why does it happen at runtime?

[Lizard-Of-Oz]

Not resources themselves are generated in runtime, but the names of resources to use might be assembled in runtime. Stuff like overlays, PD HUD countdown images, etc.

[Exactol]

Can you send an example?On Jan 7, 2024, at 5:57 PM, Lizard-Of-Oz @.***> wrote: Not resources themselves are generated in runtime, but the names of resources to use might be assembled in runtime. Stuff like overlays, PD HUD countdown images, etc.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

[Lizard-Of-Oz]

Sure, this is how VS Saxton Hale defines which abilities overlay should be displayed to Hale:

        local overlay = "";
        foreach(ability in hudAbilityInstances[player])
        {
            local percentage = ability.MeterAsPercentage();
            //<...>
            if (percentage >= 100)
                overlay += "on_";
            else
                overlay += "off_";
        }
        //<...>
        player.SetScriptOverlayMaterial(API_GetString("ability_hud_folder") + "/" + overlay);    

As you can see, both the folder and the filename are defined by the code. Ideally I'd like to see the ability to include the entire folder, because then I wouldn't have to remember and manually include every options this code can generate.

[Exactol]

I see, yea don’t really want to try to implement a squirrel interpreter so I can look into adding a comment hint to pack a folderOn Jan 8, 2024, at 8:02 PM, Lizard-Of-Oz @.***> wrote: Sure, this is how VS Saxton Hale defines which abilities overlay should be displayed to Hale: local overlay = ""; foreach(ability in hudAbilityInstances[player]) { local percentage = ability.MeterAsPercentage(); //<...> if (percentage >= 100) overlay += "on"; else overlay += "off"; } //<...> player.SetScriptOverlayMaterial(API_GetString("ability_hud_folder") + "/" + overlay);
As you can see, both the folder and the filename are defined by the code. Ideally I'd like to see the ability to include the entire folder, because then I wouldn't have to remember and manually include every options this code can generate.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

[Exactol]

Try this build https://www.dropbox.com/scl/fi/izhbxvjcj6knk27ezl00l/Compile-Pal-028.2.zip?rlkey=iiekwopnn2tpbbwdu98nu0erp&dl=0. You can add !CompilePal::IncludeFile(internalPath) or !CompilePal::IncludeDirectory(internalPath) to any comment to hint which files/directories to include

[Lizard-Of-Oz]

It works, but with bugs: 1)It looks only into the root tf2 directory. So, the parameter needs to be custom/my_map_assets rather than my_map_assets 2)Probably in result, assets in the resulting bsp are located at full path (disc included), rather than being sorted into models, materials, and other folders

[Exactol]

It will look in all search paths defined in the gameinfo.txt, including custom. Because custom is defined as tf/custom/* (by default) in the gameinfo, all subdirectories under tf/custom are added as search paths, which means you can't specify my_map_assets as a directory to pack. It also wouldn't really be portable since people can rename their custom folder or put it directly in their tf folder.

It would probably be best to organize the assets you need within the content paths (materials, models, scripts, etc) under a common name and add an IncludeDirectory hint for each, ex. !CompilePal::IncludeDirectory("materials/my_map_assets"). That way it will still work if people put it directly in the tf folder and not in custom

[Lizard-Of-Oz]

Okay, I see the point. Then I suggest considering point 1 "works as intended".

The desired goal is to give other mappers a folder they can put into custom and have CompilePal automatically include the entire thing, without giving users a detailed explanation that they will very likely fail. The best way to achieve this would be to type //!CompilePal::IncludeDirectory("custom/my_map_assets"), which almost works, but requires a fix of the second bug.

[Exactol]

Thats why I suggest adding IncludeDirectory for each content type, that way people can install it in either the custom folder or the tf folder, and it doesn't assume they won't rename the folder. If your folder contains models, and scripts, you can add //!CompilePal::IncludeDirectory("models/my_map_assets") and //!CompilePal::IncludeDirectory("scripts/my_map_assets") (materials are probably not necessary since they should get included with the models)

It's a little verbose, but I'm hesitant to add special logic to include an entire custom folder since it would be hard to handle conflicts. For example, if someone stored their materials under tf/materials/custom/foo, and also had a tf/custom/foo folder, which one does the user want to include when they have //!CompilePal::IncludeDirectory("custom/foo") ?

[Lizard-Of-Oz]

Okay. It's still immensely valuable as is. Thank you! Done a few tests, seems to function just fine.