Tool auto generated Invoke reflection names are too long

[StephenHodgson]

          @StephenHodgson I've found that Assistant v2 doesn't always understand well when type.FullName is included, because the namespaces I use are long and not relevant/confusing to the AI context.

I found that removing this and only including the method.Name solved it.

I realize it isn't the ideal scenario in case two types contain the same method name, but it would still be helpful with an omit namespace option if possible. For now I've been removing it manually here in each update :)

Originally posted by @Bodekaer in RageAgainstThePixel/com.openai.unity#235 (comment)

Proposed fix:

Converting long namespace names to hash file string guid.

[sagos95]

I faced the same issue.

I found that removing this and only including the method.Name solved it.

But how did you do that? I didn't see any accessible ways to specify function name by myself.
By the way that could be a fix too - to allow users manually specify function names. As for me it will be not the best solution to use hashes or guids.

[StephenHodgson]

Using hashes or guids would make it a bit more difficult to debug.

Part of the reason I haven't implemented it yet

[StephenHodgson]

By the way that could be a fix too - to allow users manually specify function names.

Needs to be unique, and ideally not something that is super configurable, also the cache uses the names as keys on the backend.

[sagos95]

also the cache uses the names as keys on the backend

Maybe it makes sense to separate Tools for different chats. For example, we could create a kind of Tool pool or Tool container. Making this class static provides a simpler way to interact with it, but this approach limits the flexibility of using Tools in scaled production apps.

[StephenHodgson]

You don't have to use the built-in tool serialization convince methods. You can always serialize and pass your own. That is off topic from the issue and not productive to solving the original problem defined in the title. Open a discussion about it if you'd like to talk about proposals like this.

The reason it is done this way is to provide convenient way to invoke those same tools if they happen to have locally defined methods you can execute in known libraries. Without mapping these things correctly it'd never work.