SillyTavern patch?
It looks like this replaces a file from SillyTavern. Won't that interfere with people's ability to update ST? Have you considered doing a pull request to make this a permanent change in the ST code?
I have already opened a ticket at ST about make this permanent.
Awaiting word on this.
This is definitely the preferred option.
I did also try the extension route - that was no go due to script/function requirements.
At the moment, if there are updates to "core" script.js at ST; I will update the new version with my code in the meantime.
There are 9 internal patches and a code section.
That being said, the patch updates are very fast by design.
Additional Issue:
There are more advanced systems to be added still (tested, running in different versions).
I hope they add this because i can't, everytime i try ST freezes on lauch... but I'm so curious
Hopefully there's a more convenient way to install this. I want to try it, but don't feel like duplicating my ST folder.
You do not need to duplicate your ST install , this is just a suggestion - this way you can have two installs - one modified, the other "normal" and you use
a different icon to access each.
I was curious to give this a try, but noted my current SillyTavern install version is up to 1.13. I considered trying to modify the script; rather I was going to have gemini do it, but apparently 2x 480kB script files was too much to feed it. No way to just insert specific coded word in the system prompt? ...though I suppose that would mean a change in the base models themselves. It would be nice to divorce it from S.T. though, as I was previously using your models, well still do, under comfyui nodes as well. Great work BTW.
Unfortunately the only solution is - at the moment - to install an older ST version separate from current version.
You can get older versions via ST at GITHUB -> Releases.
The main issue with newer versions of ST is the reasoning blocks/handling.
This requires a re-write , but also raises issues like turning "adjustment[s]" to reasoning on/off or allow in part (on/better in part => better option).
I don't have the avail time to do this right now... org patch took 30 days to hack/test and implement into ST.
ST was used for the "patch" due to all the "other parts" of API connections (as well as interface) already developed.
This drastically speed up the testing/implementation.