Here is about the closest version we finished with. It includes validation for the grassy area and should basically keep you there and not target something outside that part.

The previous versions of the script would find snakes and nests that were out of line of sight. This corrects that issue by ignoring both snakes and nests that will lead you down that path.

This also tries to cast invisibility on your character and then hide. This is about the best that can be done to avoid being attacked by a swarm of snakes once revealed. The followup with the hide ('event macro 13 21') could use it's own timer logic since if you were revealed twice inside the time you can execute the hide attempt, it could leave you vulnerable once the magery Invisibility spell runs out (it's duration is based on your magery skill). Basically the idea is that you cast invis on yourself, then use the hiding skill. Now you will not be revealed based on a timeout (like what happens from Invisibility spell), but only from something else revealing you via it's Detect Hidden passive ability.

The versions after this one were about cleaning up the routines to eradicate the 'goto' logic altogether. There was one more concept I had about implementing the ignoreitem logic, but it is wholly untested and there was no logic to support it.

My character template for this was magery, meditation, focus, mysticism, spellweaving, hiding, stealth. Never had bard skills.

The flute is a snake charmer (I think it is carpentry crafted) and IIRC functions like herding on a skill delay.

There are also some gumps on OSI that prevent logout without all that other actions. If you open the gump to a Magincia Broker (I did this with the commodity broker, but likely both pet and commodity function the same) then you will not get kicked for being what it deems idle.

So he is talking about a scripted assist to run the other accounts - and 'army script' of you will.

So in the version you are using, it either needs to keep close enough as the target wanders off or give up on it and move on to a new target.
Easiest solution is to pretend the target died when it wanders off. In the testtarget routine... there is a 'finditem ... G_22' or similar statement. It is looking for the last thing you were attacking and checking if it is more than 10 tiles from you. The 22 is 22 tiles. It will find it and assume it is alive, but doesn't move any closer to it when it is more than 10 tiles away.

Either change the "g_22" to "g_10" or add some kind of movement to get closer to the target. That should help.

I tried to explain. The reason it forces the trash can is that you can mix any BOD types. This way it checks for and sets up the trash can once per full run. That is 1-2seconds. The alternative is add 1 second to each crafted item. That was 20 seconds for a 20 piece bod. Think about how much slower it was getting the trash can when needed…??
This way is much better!

I am not sure if marrying off a child is an appropriate offer... 

The original author went by Snicker7, hence the S7 at the start of the script name. The fact that it is using an outside file to run the crafting was genius, but I suspect it may have come from another script writer's efforts. This allows the code to be easily used for both production and freeshards.

The script does have some not-so perfect elements. Since I revamped it to extend beyond tailoring and blacksmith skills, so I am definitely allowed to critique it. If I could rewrite one part it would be the Freeshard/Production determining code.

If you are just running it from this thread's setup, then you may not realize that it is also callable. So some other's have published scripts that called the original version to fill whole BOD books. Such a project could be adapted to do the same with any of the BOD skills. The major element is determining that the materials to craft the item should exist in the resource containers.

The original script allowed a single resource container. This version allows a primary resource container (where excess goods and materials will be dropped), but can pull resources from any container in reach and opened by the player. This became necessary because having a mixture of BOD types and skills on the character - could overwhelm decent organization in a container.

This version also requires the trash can (or Venus Fly Trap) to be in range at start up. I don't remember if it is only bone armor or if other items require the trash can to dispose of non-exceptional ones. The original would check for the trash can when trying to craft bone armor only. I decided it made more sense to just require the trash can option at the start of the script - before any BOD's have been defined for filling. Otherwise it would significantly slow down the script seeking out the trash can at each crafted item loop.

I personally tested a deed of each possible item. I did not test crafting each item for each material type though. The primary 2 testers covered a lot of testing over about 2-3 months time while the project progressed to expand the BOD types. There were a few things we missed in that project window and I tried to adjust for any of those reported and confirmed. It wouldn't shock me if there are a few corner cases that have been overlooked, because we may not have encountered every BOD possible in that time frame, so if you run into something that doesn't work, please post about it. As I am not actively BOD collecting, it is helpful if you can set aside a problem BOD and allow me to test with it.

The zip file with version 4.0 tests for the target to still be within 8 tiles.
It will continue to cast fireball (That is my guess for event macro 15 17, though I didn't look it up) until the target either dies or wanders outside the 8 tile range.

The version 4.0A actually looks for the target to be up to 22 tiles away. I think most cast ranges are about 10 tiles. It is possible that the creature wanders away outside the target range and you would get stuck in that loop.

This is just reading the code, not actually testing it. You mentioned it works for a while and then fails only occasionally, right? Or do you mean it always fails when trying to cast spells at the target?