SkriptLang
Remove command senders from load/start/stop events
Description
Removes the console command sender from load/unload/start/stop events to prevent things like event-player and cow from being valid syntax in those events.
Target Minecraft Versions: any Requirements: none Related Issues: none
Are there any cases where those syntax would actually work in some way? I can't think of any, so I don't think this is a breaking change (because there's nothing that works that would be broken).
Actually, thinking about it, isn't this value registered so that you can do something like send "my message" and it'll take the console as the default expression for that?
Actually, thinking about it, isn't this value registered so that you can do something like
send "my message"and it'll take the console as the default expression for that?
yes!
This PR makes me sad 😢
I remember adding this a few years ago so we wouldn't always have to type send ... to console in load events.
RIP command senders.
Food for thought...
might be messy, but...
What if in the send effect, if there is no to %sender% and its one of the three Load/Unload events, we default to sending to console?!?!?
I'd rather not write in such hardcoded functionality, I don't think it's worth it. Honestly, I don't think the change should have been made in the first place. Why shouldn't send "test" send to console in functions? in block physics events? I don't see what makes the load events special compared to those. You should be explicit in who/what you're sending to
Honestly, I don't think the change should have been made in the first place. Why shouldn't
send "test"send to console in functions? in block physics events? I don't see what makes the load events special compared to those. You should be explicit in who/what you're sending to
respectfully, I disagree.
-
this was added to make debugging/logging to console easier in load/unload events. These events had those default command senders as they're not player driven events. As for functions, well.. because functions aren't limited to a specific event. Load/unload events are essentially server driven events.
-
In my opinion (along with dozens in the help channels) this whole command sender thing has become a massive mess since the previous change. For example
on break:
send "you broke something"
This now saying there are multiple command senders in the event??!?! Why? there's only a player. As previously discussed it was most likely due to command blocks being a command sender. I personally find this change to just be hurting Skripters over actually providing anything good.
Again, just my opinion (and the opinion of dozens of other users)
Yeah, I can see how there are cases where it's annoying and confusing, but it was a much needed change. There was someone asking why send wasn't working in a click event almost every other day, because the event-values were colliding. We still need to do more work with this concept (see event-dropped item in the on drop event, for one), but it was definitely a necessary change.
I see your point with the 'server-driven event' argument, and I think that's fair. For now I'd rather have this removed until we can get a proper fix for event-value conversion (ideally this would work fine and only allow event-commandsender and not event-player/cow).
Yeah, I can see how there are cases where it's annoying and confusing, but it was a much needed change. There was someone asking why
sendwasn't working in a click event almost every other day, because the event-values were colliding. We still need to do more work with this concept (see event-dropped item in the on drop event, for one), but it was definitely a necessary change.I see your point with the 'server-driven event' argument, and I think that's fair. For now I'd rather have this removed until we can get a proper fix for event-value conversion (ideally this would work fine and only allow event-commandsender and not event-player/cow).
sounds fair :) thank you for understanding!
Are there any cases where those syntax would actually work in some way? I can't think of any, so I don't think this is a breaking change (because there's nothing that works that would be broken).
Actually, thinking about it, isn't this value registered so that you can do something like
send "my message"and it'll take the console as the default expression for that?
what happens if a cow executes the command (via /execute and such)
closing since it doesn't seem to be a big issue and we should be fixing it properly anyway