LOCALMESSAGE BUG
LOCALMESSAGE "[Prison Guard] <$USERNAME> you are now free togo." Hint This command does not support variables, <$USERNAME> Parse failed @Pete107
LOCALMESSAGE "[Prison Guard] <$USERNAME> you are now free togo." Hint This command does not support variables, <$USERNAME> Parse failed @Pete107
I came across this myself and have began the process to correct this oversight of mine. Unfortunately, as there are many commands which make use of variables, it will take time to complete. I won't be able to make much (if any) progress today, rest assured it will be corrected.
LOCALMESSAGE "[Prison Guard] <$USERNAME> you are now free togo." Hint This command does not support variables, <$USERNAME> Parse failed @Pete107
I came across this myself and have began the process to correct this oversight of mine. Unfortunately, as there are many commands which make use of variables, it will take time to complete. I won't be able to make much (if any) progress today, rest assured it will be corrected.
If possible, please fix the problem with the new mobile method as well.
@Pete107 variables should able to be used on absolutely any parameter for any command. That does pose abit of an issue as the new constructors now make the string params strongly typed - so they just need passing through a base call to know if theres a variable placeholder used - and if there is this is called and replaced on demand (instead of using the properties set in each class).
In either case it should be a generic call done on all Check/Act commands
@Pete107 variables should able to be used on absolutely any parameter for any command. That does pose abit of an issue as the new constructors now make the string params strongly typed - so they just need passing through a base call to know if theres a variable placeholder used - and if there is this is called and replaced on demand (instead of using the properties set in each class).
In either case it should be a generic call done on all Check/Act commands
I agree, I hadn't considered variables as mentioned when doing the refactor. I've made a start on correcting the issue (again as mentioned) I have indeed implemented these within the base classes where it'll attempt to get variables and default to the original parameters if the attempt was unsuccessful, it's a case of going through commands and applying the attempt throughout.
Apologies it's taking so long.

Just an update, I've completed the IF commands. Once ACT commands are completed I will have a small test myself to attempt to minimise any other potential issue.
THANKS
发件人: Pete107 @.> 发送时间: 2022年8月7日 20:45 收件人: Suprcode/mir2 @.> 抄送: OuYangPlane @.>; Comment @.> 主题: Re: [Suprcode/mir2] LOCALMESSAGE BUG (Issue #547)
Just an update, I've completed the IF commands. Once ACT commands are completed I will have a small test myself to attempt to minimise any other potential issue.
― Reply to this email directly, view it on GitHubhttps://github.com/Suprcode/mir2/issues/547#issuecomment-1207400443, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AZLXLUIREB4ZTMJCL44LLUDVX6VVTANCNFSM55EC5JYQ. You are receiving this because you commented.Message ID: @.***>
@Pete107 Hello Pete107, have you fixed the new problem?
npc code reverted. should be fixed now.