I have only examined the latest one.
A few comments on the code:
You have repeat without an until in a few places. These isolated repeat statements do nothing functionally - possibly slow down the code a little if your #LPC setting is low enough.
You should restructure the routines so they have the opportunity to return cleanly. If you need to short cut back to the main loop, then provide a return status to determine the next goto statement instead of directly using a goto out of the sub.
Easyuo has a stack limit (I think it is 1000) for how many blocks it can keep track of. It is possible to get to enough to go over that limit. When that happens, scripts get into a non-responsive state. If you are only collecting for 2 hours with lots of snakes around, you are doing at most 4 per minute (a good cycle has more than 14 seconds of wait time), 240 per hour and 480 in 2 hours - maybe you don't get there. If there is a lack of snakes to charm, then it will take much less time to get to the unresponsive stack overflow state. Without the well structured subs it becomes very hard to read and follow what the script is doing.
Since I do not know the #sysmsg values, I can't figure out what happens after the sub flutechecker is called. I can't tell if it returns cleanly or builds the "gosub charm" on the stack?
I do not know if the remaining subs that process #sysmsg ever happen.
The hard coded click location could be determined using the variables for where the client window is placed (#clileft and #clitop) and even the offset could be calculated using the game window size (#clixres and #cliyres). This would improve the script so no matter the user's screen resolution, it would still target what I have to guess is near their character.
My example here assumes the original was 800x600 game window size. If it was something else then my math will need adjustments.
; At the start of the code create the X and Y offsets
set %ClickXOffset #clixres / 2 + 14
set %ClickYoffset #cliyres / 2 + 18
; later in the Charm subroutine:
...
gosub flutechecker
set %ClickX #clileft + %ClickXoffset
set %Clicky #clitop + %ClickYoffset
click %ClickX %ClickY mc
...
Generally players do not change the game window size while playing, but the game window could be adjusted depending on whether they want the banner menu (I forget what it's called). I have the menu sometimes to swap chat from Help to General when I am looking for something. Other times I want to move my screen layout for arranging icons or whatever - so I could see that changing. That just gives a more resilient way to handle the click locations for a variety of players.
Gaderian