-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can we avoid storing data in the chat message content? #107
Comments
This needs to be re-opened, I noticed that its not my biography changes that seem to have broken /whisper and /talk, but this PR that replaced how we were storing the data from the message content to flags. since we are storying that data as a flag now it is not properly getting the prefix and inserting it into the message content. I restored the branch from where you previously fixed the /talk prefix to see if i can figure it out. Strangely, I restored your most recent commit before you merged my changes and it seems like it works if you set the /talk flag in the settings but not on the actor sheet itself? |
Ok, no worries, the changes have not yet made it into a release. :) |
Jah, ok. ui.chat.processMessage(response, chatData) The calee is found in async processMessage(message, {speaker}={}) I, with my limited JavaScript knowledge, read this as "Give me the 'speaker' field of ChatData, I do not give a damn about the other fields." I am once again sceptical if we can avoid this ruddy JSON parsing. Now I remember why this topic frustrated me. 😆 |
We are currently placing some chat data directly inside the content, and replacing it at a later point.
This is hacky, and has some side effects. For example, any module working with the chatMessage hook (Talking Actors, for example) sees and processes our flag and json before we can replace it.
The ui.chat.processMessage function returns the message object, but I think only after it has been posted. Can we modify that object afterwards?
I am also not sure if some async functions are called in a fire-and-forget manner, meaning we could be dealing with concurrency issues if we chose this path.
The text was updated successfully, but these errors were encountered: