<sticks head into thread>
Questions/comments for users:
Thanks to new features in liteloader, proper outbound chat filtering in 1.7. Do you want filterablechat left alone or can I remove it?
Should ITEMID be the legacy ID and the new "fully qualified" name be the new return value for ITEM or should I leave ITEM returning the legacy ID and have ITEMID be a new var returning the fqname
I was wondering if Chatfilter (and also macro) could slow down the game in someway if we add a lot of scripts, modify a lot of messages, etc.
Yes, it depends on the complexity of the scripts, and the entire Macros core executive is set up to yield as much possible time to the game engine, but if you make very complex scripts you can slow things down. ChatFilter not so much because the chat filters run in the network thread and run at "full speed", so whilst you can hang the game if you have a "bad" chatfilter script, you can't really slow it down.
Things which *will* slow the game down are running complex scripts with large UNSAFE blocks (that's why the UNSAFE command is called that) or having scripts update GUI components (using bindings is faster for labels) are about the slowest things you can do.
In general, doing something with macros is only marginally less efficient than having a standalone mod do that thing though, due to the architecture of the executive.
Thanks for the fast answer.
Is there a way to put more parameters into the script or do i have to rewrite the script for every word im looking for? And what does the /b mean?
the \b is a special character (regular expression language) that matches word borders
and yes...
For example, this matches diamond, emerald, dslyexci, and either spelling of gray wool
and responds by trying to buy that item
---
$${
;IFMATCHES(%CHAT%,"\b(diamond|emerald|dslyecxi|gr(a|e)y wool)\b",&match,1)
;IF(%&match% = "grey wool");Set(&match,"gray wool");ENDIF
;Echo(/buy %&match%)
;ENDIF
}$$
Quote from Rene_Z »
* Hey! Come back! *
I think you can just remove it and do it the new way. However I liked the feature that you can type as many characters as you want and have a script decide how to "cut it into pieces". That's the main use I had for filterablechat, so that for example "/tell name [some really long text]" would be split into "/tell name [part 1]" and "/tell name [part 2]" (With different procedures for each command).
But adapting to any new syntax/way of triggering shouldn't be a problem.
It would be more logical to use ITEMID for the ID and ITEM for the name, since the name is what you use in commands and everywhere else. It would of course break scripts that use (ITEM = 278) or something, but since Mojang is moving away completely from Item IDs in 1.8 you should use the name from now on as the identifier for item. In the far, far future there will be a finished Plugin API and Plugins that add items, and then the Item ID isn't something unique anymore (at least across servers/worlds). I would go along with Mojang in that matter.
Using ITEM for the ID and ITEMID for the name would be just confusing and I would mess that up every time (though I don't really use it).
Well, you should be consequent and do it the same way for both
Didn't notice there was another page before i posted but i agree with this guy ^ on all points
I think you can just remove it and do it the new way. However I liked the feature that you can type as many characters as you want and have a script decide how to "cut it into pieces". That's the main use I had for filterablechat, so that for example "/tell name [some really long text]" would be split into "/tell name [part 1]" and "/tell name [part 2]" (With different procedures for each command).
But adapting to any new syntax/way of triggering shouldn't be a problem.
It'll be the same, it'll just be an event which fires for all outbound chat packets instead of just those sent using filterablechat gui. In fact if I use the same internal eventId anything which was mapped to the onfilterablechat event will go to the new one
It would be more logical to use ITEMID for the ID and ITEM for the name, since the name is what you use in commands and everywhere else. It would of course break scripts that use (ITEM = 278) or something, but since Mojang is moving away completely from Item IDs in 1.8 you should use the name from now on as the identifier for item. In the far, far future there will be a finished Plugin API and Plugins that add items, and then the Item ID isn't something unique anymore (at least across servers/worlds). I would go along with Mojang in that matter.
Using ITEM for the ID and ITEMID for the name would be just confusing and I would mess that up every time (though I don't really use it).
Well, you should be consequent and do it the same way for both
See this was my thinking. It'll break all scripts which currently use ITEM but as you say, down the line the ID's will lose their meaning anyway so probably best to just adapt to the change now rather than later.
Doesn't it automatically switch configs based on the current IP?
and i think you can access the IP through %SERVER%, possibly
Well, it does switch configs based on the IP but at that time, I want it to switch to other config.
Basically, what I want: if day of the week is sunday and time is between 3 pm and 6 pm, make server1 use config2 and server2 use config1.
If it's too complicated or laggy, I will continue using buttons
Well, it does switch configs based on the IP but at that time, I want it to switch to other config.
Basically, what I want: if day of the week is sunday and time is between 3 pm and 6 pm, make server1 use config2 and server2 use config1.
If it's too complicated or laggy, I will continue using buttons
ooh, okay
Well, you could put it on onJoinGame, but then it will only change when you log on
Or maybe bind it to a commonly used action, like your tab key
have it open the playerlist as normal but ALSO check the time while it's at it
or you could have a constantly running script, which, while it isn't laggy, just seems like something that i personally reallllllllly wouldn't want to do
In either case you would be checking the value of the TIME and DATE variables and then changing Config(name) based on that
If you've decided which one you want, i could write an example =P
Well, you could put it on onJoinGame, but then it will only change when you log on
Or maybe bind it to a commonly used action, like your tab key
have it open the playerlist as normal but ALSO check the time while it's at it
or you could have a constantly running script, which, while it isn't laggy, just seems like something that i personally reallllllllly wouldn't want to do
In either case you would be checking the value of the TIME and DATE variables and then changing Config(name) based on that
If you've decided which one you want, i could write an example =P
OnJoinGame is a great option, I don't see any reason why should it check several times.
OnJoinGame is a great option, I don't see any reason why should it check several times.
Well, it just means if you start playing at 2:45 and play 'till 7:00 or something it won't change until/unless you leave and rejoin the server, hence the other options =P
onJoinGame:
$${$$<configcheck>}$$
in a file called configcheck.txt:
...oh wait, i don't know what DATE and TIME are actually formatted as xD
but something along the lines of
IFMATCHES(%DATE%,<pattern for saturdays and sundays>)
IFMATCHES(%TIME%,<pattern for time range>)
Config(otherconfig)
ENDIF
ENDIF
Well, it just means if you start playing at 2:45 and play 'till 7:00 or something it won't change until/unless you leave and rejoin the server, hence the other options =P
It (obviously) requires a server restart to switch IPs, so yeah, that's not an issue
For the day of the week you can use the TIME(&var,"dateformat") command using java's SimpleDateFormat character "u" to get the day of the week (1-7, 1 being Monday, 7 being Sunday).
TIME(&day,"u");
IFMATCHES(%&day%,"7");
//do things
ENDIF;
For the day of the week you can use the TIME(&var,"dateformat") command using java's SimpleDateFormat character "u" to get the day of the week (1-7, 1 being Monday, 7 being Sunday).
TIME(&day,"u");
IFMATCHES(%&day%,"7");
//do things
ENDIF;
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumQuestions/comments for users:
- Thanks to new features in liteloader, proper outbound chat filtering in 1.7. Do you want filterablechat left alone or can I remove it?
- Should ITEMID be the legacy ID and the new "fully qualified" name be the new return value for ITEM or should I leave ITEM returning the legacy ID and have ITEMID be a new var returning the fqname
- Same question for HITID
<runs away>Yes, it depends on the complexity of the scripts, and the entire Macros core executive is set up to yield as much possible time to the game engine, but if you make very complex scripts you can slow things down. ChatFilter not so much because the chat filters run in the network thread and run at "full speed", so whilst you can hang the game if you have a "bad" chatfilter script, you can't really slow it down.
Things which *will* slow the game down are running complex scripts with large UNSAFE blocks (that's why the UNSAFE command is called that) or having scripts update GUI components (using bindings is faster for labels) are about the slowest things you can do.
In general, doing something with macros is only marginally less efficient than having a standalone mod do that thing though, due to the architecture of the executive.
the \b is a special character (regular expression language) that matches word borders
and yes...
For example, this matches diamond, emerald, dslyexci, and either spelling of gray wool
and responds by trying to buy that item
---
$${
;IFMATCHES(%CHAT%,"\b(diamond|emerald|dslyecxi|gr(a|e)y wool)\b",&match,1)
;IF(%&match% = "grey wool");Set(&match,"gray wool");ENDIF
;Echo(/buy %&match%)
;ENDIF
}$$
Didn't notice there was another page before i posted but i agree with this guy ^ on all points
'Cause tomorrow spring is here
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIt'll be the same, it'll just be an event which fires for all outbound chat packets instead of just those sent using filterablechat gui. In fact if I use the same internal eventId anything which was mapped to the onfilterablechat event will go to the new one
See this was my thinking. It'll break all scripts which currently use ITEM but as you say, down the line the ID's will lose their meaning anyway so probably best to just adapt to the change now rather than later.
Awesome, I value the input from thread regulars like you and Rene so glad that opinions seem to be flowing with what I had planned anyway.
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumyou can use TICKS to access the exact inGame time, and TIME and DATE to read the system clock
'Cause tomorrow spring is here
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWell, 2 servers I play in switch their IPs every Sunday at 3:00pm - 6:00pm. Is there a way to automatically switch configs at that time too?
Doesn't it automatically switch configs based on the current IP?
and i think you can access the IP through %SERVER%, possibly
'Cause tomorrow spring is here
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWell, it does switch configs based on the IP but at that time, I want it to switch to other config.
Basically, what I want: if day of the week is sunday and time is between 3 pm and 6 pm, make server1 use config2 and server2 use config1.
If it's too complicated or laggy, I will continue using buttons
ooh, okay
Well, you could put it on onJoinGame, but then it will only change when you log on
Or maybe bind it to a commonly used action, like your tab key
have it open the playerlist as normal but ALSO check the time while it's at it
or you could have a constantly running script, which, while it isn't laggy, just seems like something that i personally reallllllllly wouldn't want to do
In either case you would be checking the value of the TIME and DATE variables and then changing Config(name) based on that
If you've decided which one you want, i could write an example =P
'Cause tomorrow spring is here
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumOnJoinGame is a great option, I don't see any reason why should it check several times.
Well, it just means if you start playing at 2:45 and play 'till 7:00 or something it won't change until/unless you leave and rejoin the server, hence the other options =P
onJoinGame:
$${$$<configcheck>}$$
in a file called configcheck.txt:
...oh wait, i don't know what DATE and TIME are actually formatted as xD
but something along the lines of
IFMATCHES(%DATE%,<pattern for saturdays and sundays>)
IFMATCHES(%TIME%,<pattern for time range>)
Config(otherconfig)
ENDIF
ENDIF
'Cause tomorrow spring is here
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIt (obviously) requires a server restart to switch IPs, so yeah, that's not an issue
Aaaah, okay, i see what you mean now
Then yeah, just gotta somehow...
i'm sorry, i have no idea what DATE and TIME actually look like.., could you do $${Log(%TIME%);Log(%DATE%)}$$ in the game and see what it shows?
figuring out if a day is a sunday could turn out to be quite difficult though =P
'Cause tomorrow spring is here
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIndeed
For the day of the week you can use the TIME(&var,"dateformat") command using java's SimpleDateFormat character "u" to get the day of the week (1-7, 1 being Monday, 7 being Sunday).
Oh my..., thank you so much
well, uh, in that case..,
TIME(&day,"u");
#day = %&day%
MATCH(%TIME%,"(..):(..):(..)",{&hour,&minute,&second})
#hour = %&hour%
#minute = %&minute%
#second = %&second%
IF((#day = 7) && (15 < #hour < 18));
Config(otherconfig)
ENDIF;
//hopefully you can set a counter with a leading 0, test it with the following script
$${#a = 0;#a = 02;IF(#a = 2);Log(true);Else;Log(False);ENDIF}$$
if it says true, then the script should work (hopefully)
'Cause tomorrow spring is here
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumSo, I tried the 2nd script and it did say "true", but the main script still did nothing (I changed 18 to 22 to test).
Agh, darn emotes..., you replaced those with ColonOpenbraket, right? ( : and ( )
alternatively, maybe it doesn't allow two comparisons together like that, could use
((15 < #hour)&&(#hour < 22))
'Cause tomorrow spring is here
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumEmotes are fine (although that's what code tags are for :D) but it still won't work...