Retrieve Reply information from ExecBodyParams
#52
No reviewers
Labels
No labels
Automated
Backlog
Post_Prototype_1.0
Bot_Code
Core
Bot_Code
Custom
CI/CD
Complexity
Advanced
Complexity
Basic
Complexity
Expert
Complexity
Intermediate
Kind/Breaking
Kind/Bug
Kind/Bug Fix
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Nix
Ownership
Collab
Ownership
Collab with Leads
Ownership
Individual Lead
Ownership
In-Review
Ownership
Needs Owner > May Delegate
Ownership
Workshop with Leads
Phase 1.0
Requirements > Drafting
Phase 1.0
Requirements > Researching
Phase 1.0
Requirements > Review & Planning
Phase 2.0
Design > Research & Analysis
Phase 3.0
Coding > Implementation
Phase 4.0
QA > Unit Testing & Design
Phase 5.0
Resolution > Completed
Phase 5.0
Resolution > Review for Completion
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Blocks
#48 Custom
this
BotCommand}
modulatingforce/forcebot_rs
Reference: modulatingforce/forcebot_rs#52
Loading…
Reference in a new issue
No description provided.
Delete branch "retrieve-reply-details"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Initial Description
Stemming from #48 (comment)
Custom Developers should be able to retrieve reply details from a message, rather than custom build out the logic
The logic already exists here , observed in an experimental module
https://git.flake.sh/modulatingforce/forcebot_rs/src/branch/main/src/custom/experimental/experiment002.rs#L72-L75
Better would be something where the Custom Developer doesn't have to build out the above logic - they can just call a function related to command
Probably would have these methods defined at
ExecBodyParams
objectPlan of Action :
ExecBodyParams
methodget_parent_reply(&self) -> Option<ReplyParent>
Chat
so it can take inimpl ReplyToMessage
this
BotCommandthis
BotCommand #48Does this work how you wanted it?
@mzntori yuppo! fking beautiful . Thanks for the work!
@HaruYuumei - can you review this and see if this would work for you for your PR #48 ? I've decided to push this into
main
branch first as this would benefit active branchesAlso, feel free to use this branch to add in some tests Haru - like if you want to create a module that tests this or look at existing test ones, and just add to them
Example Use Case in a custom
fn
could be something like this pseudocode@ -60,0 +61,4 @@
///
/// If that message replied to message return that information in form of `Some<ReplyParent>`.
/// Otherwise, return `None`.
pub fn get_parent_reply(&self) -> Option<ReplyParent> {
ExecBodyParams
New Method -
pub fn get_parent_reply(&self) -> Option<ReplyParent>
@ -63,0 +116,4 @@
pub message_text: String,
pub channel_login: String,
pub channel_id: String,
}
ExecBodyParams
New Struct -
pub struct ReplyParent
Just to Update :
So far, what tori put in place works.
However, there is an additional desired enhancement so that the bot replies to the original message rather than the message of the
BotCommand
At the moment, when the bot replies some initial tests from Haru, it replies to the
BotCommand
Message rather than the what theBotCommand
was in reply toThis can definitely be done with
twitch-irc
and the code from this PR , but better may be to just go ahead and enhanceChat.say_in_reply_to()
so it can be passed anything that implementsReplyToMessage
similar to underlyingClient.say_in_reply_to()
https://docs.rs/twitch-irc/latest/twitch_irc/client/struct.TwitchIRCClient.html#method.say_in_reply_to
Likely starting in this call onwards
https://git.flake.sh/modulatingforce/forcebot_rs/src/branch/main/src/core/chat.rs#L393
Not extremely difficult to do but I need to double check that this doesn't impact anything business logic related in the downstream
Plan of Action
Chat.say_in_reply_to()
to handleimpl ReplyToMessage
> @modulatingforce - WIPHi @HaruYuumei Feel free to test with the changes I've added. You can pass a tuple : (Destination Channel , Message ID to Reply to) in
say_in_reply_to()
Something like
Feel free to test and create a test listener or button that tests it out
Hi @mzntori can you check my notes? It's not super important but just curious if you could create a simpler version or not
Thanks!
@ -40,0 +41,4 @@
// SayInReplyTo(&'a PrivmsgMessage,String),
// SayInReplyTo(Arc<Box<dyn ReplyToMessage>>,String),
// SayInReplyTo(&'a dyn ReplyToMessage,String), // [ ] 04.03 - Having issues defining it this way?
SayInReplyTo((String,String),String), // ( Destination Channel , Message ID to reply to ) , OutMessage // https://docs.rs/twitch-irc/latest/twitch_irc/client/struct.TwitchIRCClient.html#method.say_in_reply_to
@mzntori can you check this? I want to store in this
BotMsgType::SayInReplyTo
aReplyToMessage
(or aimpl ReplyToMessage
like the function in https://docs.rs/twitch-irc/latest/twitch_irc/client/struct.TwitchIRCClient.html#method.say_in_reply_toBut I keep either getting stuff about it not bounded correctly or it starts getting a bit dank ( I need to define Arc/Boxes, and I'm not sure if that'll be intuitive for custom developers, if that's required to be built by a custom developer )
My Compromise is pass the tuple version
(String,String)
in the downstream - but iftwitch-irc
changesimpl ReplyToMessage
, we would need to change these areas . (though this is likely not an issue if this doesn't happen often)What do you think?
@ -393,1 +409,3 @@
pub async fn say_in_reply_to(&self, msg: &PrivmsgMessage, outmsg: String , params : ExecBodyParams) {
// pub async fn say_in_reply_to(&self, msg: &PrivmsgMessage, outmsg: String , params : ExecBodyParams) {
// pub async fn say_in_reply_to(&self, msg: &PrivmsgMessage, outmsg: String , params : ExecBodyParams) {
pub async fn say_in_reply_to(&self, msg: &impl ReplyToMessage, outmsg: String , params : ExecBodyParams) {
Chat.say_in_reply_to()
now take msg as&impl ReplyToMessage
Similar to the underlying in the following : https://docs.rs/twitch-irc/latest/twitch_irc/client/struct.TwitchIRCClient.html#method.say_in_reply_to
As the above documentation explains, for
ReplyToMessage
we can pass the following&PrivmsgMessage
(&str, &str)
or(String, String)
, where the first member is the login name of the channel the message was sent to, and the second member is the ID of the message to reply to.Everything should be working as intended now, by being able to use the tuple in say_reply_to() I could pass the parent message id and the channel id in wich the message was sent to locate the parent message and reply directly to it 😄
SayInReplyTo((S, S), S)
is very unintuitive, either remove the tuple or make it something likeSayInReplyTo{channel: S, message_id: S, message: S}
.As for the method params for
say_in_reply_to
i dont think you need to pass something complicated like a ReplyToMessage but just channel login and message id seperately. I think that would work fine for the API and users can find their own way to do that.@HaruYuumei how does this look? This is an example of how it looks without the tuple
@ -199,3 +261,4 @@
params.clone().msg.message_id().to_string(),
String::from("16:13 notohh: baby girl"),
params.clone()
).await;
New Usage of
say_in_reply()
Another requested Enhancement . Have 2x fn in chat
sayinreply <-- this doesn't require a msgid . It will respond to the msgid passed in params automatically
sayinreplyto <-- we pass a msgid to reply to
Looking good - approving the merge
WIP: Retrieve Reply information fromto Retrieve Reply information fromExecBodyParams
ExecBodyParams
this
BotCommand #48