The following structural changes should be made to remedy this:
stat_puller.rs should be under src/mir/
mir.rs should be moved to src/mir/mod.rs
character.rs should be created, containing a struct, and all logic relevant to characters to clean up the rest of the codebase and allow changing just the character relevant logic without having to make changes elsewhere
The single message character sheet system needs to be reworked also, as there are now two messages that need reading and potentially will be more in future, at the moment this is not scalable as the message has to be indicated manually by the user
There are a number of ways this could be resolved
Upon character creation, all other messages in the channel should be read also, and automatically classified by a language model (by giving it an example and asking it to pattern match I believe GPT could discern which message contains the stat block and which contains the spell list fairly accurately)
Allow the user to manually set their various messages, which is likely more reliable than a language model however will bloat the context menu options created by Ordis
Pattern match using keywords, for example detect messages with the strings "str", "dex" etc and set that as the stat block message (this could be combined with option 1 for error checking purposes)
Read all messages in the same channel, combine them into one big string and feed that into a language model instead of handling them seperately - This is probably the easiest solution, however it gives more room for the language model to get things wrong
flashgnash
commented
1 day ago
Once https://github.com/flashgnash/ordis/issues/ is completed, the stat_puller module will have lots of duplication of code, and generally is a bit of a mess.
The following structural changes should be made to remedy this:
The single message character sheet system needs to be reworked also, as there are now two messages that need reading and potentially will be more in future, at the moment this is not scalable as the message has to be indicated manually by the user
There are a number of ways this could be resolved
Upon character creation, all other messages in the channel should be read also, and automatically classified by a language model (by giving it an example and asking it to pattern match I believe GPT could discern which message contains the stat block and which contains the spell list fairly accurately)
Allow the user to manually set their various messages, which is likely more reliable than a language model however will bloat the context menu options created by Ordis
Pattern match using keywords, for example detect messages with the strings "str", "dex" etc and set that as the stat block message (this could be combined with option 1 for error checking purposes)
Read all messages in the same channel, combine them into one big string and feed that into a language model instead of handling them seperately - This is probably the easiest solution, however it gives more room for the language model to get things wrong