Feature Request and Questions about the Patcher

[Kitsune44]

Hi 2010kohtep,

First of all, thank you for creating this patcher—great work!

I have a couple of questions and suggestions to share:

Question 1: Removing the Confirmation Prompt

Would it be possible to remove the confirmation prompt when using the patcher?

When compiling large sets of models in Crowbar, the need to confirm the use of the patcher for each individual model becomes very cumbersome. Imagine processing a batch of a thousand models—since I have explicitly set the path to your patcher instead of studiomdl, it's clear that I know what I am doing. Having to confirm each compilation seems unnecessary in this case.

Could you consider an option to disable this prompt entirely?

Question 2: Material Limit

Why is the material limit set to 127?

What is the reason for this specific limit? Could this limit be increased to, for example, 1024 or even 16,777,216? Understanding the constraints behind this limit would help clarify whether higher values are feasible.

I also performed tests which show that the current limit of 127 does not work anyway - above 62 materials in texturegroup studiomdl throws an exception.

Question 3: IsInt24()

Failed to hook IsInt24() I always get this error (it does not terminate the process so it is rather a warning), when compiling models and even when starting the injector without any arguments

Thank you for your time, and I look forward to your response! Best regards, Kitsune

[REDxEYE]

Hello, I'm currently working on a full re-write of this patcher.

Could you please upload couple of files that causes crashes with clean studiomdl?

[Kitsune44]

Hello, I'm currently working on a full re-write of this patcher.

Could you please upload couple of files that causes crashes with clean studiomdl?

Hello REDxEYE,

I don't have any issues with the clean studiomdl. If you're referring to my comment about exceptions being thrown when using more than 63 materials in $texturegroup, those relate specifically to the patcher. The clean studiomdl supports a maximum of 32 materials (in practice, it seems to be 31), while the patcher extends this limit to 127. However, in my tests, the patcher effectively increases the limit to 63 materials (or possibly 62, I can’t recall), beyond which studiomdl throws an exception.

If you'd like to test this, simply add the appropriate number of materials in $texturegroup to a test .qc file.

I also attempted to rewrite the project initially by simply cloning the repository and setting up a workflow with GitHub Actions. While the compilation was successful, the compiled patcher was throwing these exceptions:

DbgTrace("WARNING! Mod '%s' could not be applied - signature not found.\n"); DbgTrace("WARNING! Mod '%s' could not be applied - patch failed.\n"); with %s equal to null

I would be very happy if you could rewrite the project taking my initial feedback into account, especially the removal of the confirmation prompt.

Gretings, Kitsune

[REDxEYE]

Hello, I was talking about cases that require use of stdpatcher. I need such cases to test my own patch

[Kitsune44]

Alright, but what exactly would you like to receive? A package with the model ready for compilation?

[REDxEYE]

Ye, as many sample as you can provide :)

[Kitsune44]

Here is a package containing a single model and all the files necessary for full compilation and testing within the game environment ("Alien Swarm Reactive Drop" BETA version with the PBR shader ported from Strata, with the permission and under the terms of the Strata and Valve developers).

The .qc file includes a total of 123 materials in $texturegroup plus 63 commented-out materials.

The model itself was purchased, so please refrain from redistributing the .smd and .vtf files or using them for purposes other than internal personal testing.

Usage instructions:

1. Configure Crowbar in the 'Set Up Game' tab (remember to set StdInjector.exe in the 'model compiler' field instead of the clean studiomdl).
2. In the 'Compilation' tab, select 'Folder and Subfolders' in the 'QC Input' field and drag the testSMD folder into the field.
3. In the 'Compilation' tab, drag the testASRD folder into the 'Output to' field.
4. Start the compilation and enjoy the errors."

Link to download: removed

[REDxEYE]

I've downloaded the file, you take remove link now

[REDxEYE]

@Kitsune44 Do you happen to have discord? I've created basic patch version that only patches material limit and it's without popup window

[Kitsune44]

@REDxEYE May you create a repo on github anyway?

[kohtep]

Hello,

I'm still not sure whether the project really needs this, but if it's still relevant, I'm willing to allocate time to rework it. Right now, it's clearly dead.

I also don't know the current state of @REDxEYE's version. It's possible that he has already fully rewritten the project and even introduced new features - it's hard to tell from this thread.

Regarding your questions: the IsInt24 error is most likely related to required signature adjustments. The maximum value for Material Limit was set to 127 because - to be honest - I don't really remember. Higher values might have caused instability or required additional, deeper patches (e.g., replacing int8 with int32 checks, etc.).

If this is still truly relevant, feel free to let me know so I can look into it. At the moment, I'm still unsure if this is necessary, and I don't have the broken models or other required data to work with.

[Kitsune44]

Hello @kohtep,

First of all, thanks for your work and the patcher.

@REDxEYE prepared a patcher for me that supports approximately 256 skins, operates without requiring patch confirmation, and works with studiomdl.exe for ASRD.

However, the generation of convex-sub parts for models with more than 32 materials still does not work — this limitation was also present in your patch.

As far as I know, @REDxEYE has not yet published a repository for his version of the patcher. It would be great if you two could collaborate on further developing this patcher, if you’re interested. From my perspective, enabling convex generation and significantly increasing the number of supported materials/skins would be a valuable improvement.

Thanks again for your efforts and contributions.

Gretings, Kitsune

[kohtep]

Hi!

Thank you for bringing me up to speed. I've already reached out to @REDxEYE to ask for example models that could be used to update the patch, but it seems he's currently busy, and I'm concerned I won't be able to get all the necessary information promptly.

Unfortunately, I've lost everything needed for testing and developing patches - including models and .qc scripts for compilation - and I no longer remember how to work with them (it's been several years). If you could provide all the required files to run the compiler (.qc files, models, etc.) and a briefing on how to work with them, I could try to resume work on StdPatch.

The fix won't be quick, as I'm planning to completely rethink the project's architecture, including abandoning the DLL concept, which I now see as an unnecessary complication for the end user. That said, it certainly won't take several months. I can't continue expanding StdPatch's functionality while relying on solutions that once seemed acceptable but now strike me as unnecessary overhead that could be avoided (this includes not only the use of DLLs but other architectural choices in StdPatch that now seem odd to me).

[Kitsune44]

Hi,

Unfortunately, I've lost everything needed for testing and developing patches - including models and .qc scripts for compilation - and I no longer remember how to work with them (it's been several years). If you could provide all the required files to run the compiler (.qc files, models, etc.) and a briefing on how to work with them, I could try to resume work on StdPatch.

In my spare time I will prepare a package for you with everything you need for testing. Until then you can confidently focus on other projects.