Zugg Software :: View topic - My first script

Beginner Joined: 02 Jun 2006 Posts: 19

Alright, I’m trying to make a bot to run this zone for me. I have some code worked out, but wanted to run it past you guys first, because its my first real script and I’m sure its sloppy.

Here is the bot’s purpose. To run in a very small zone (about 15 rooms) back and forth, killing any ‘goblins’ I see. (I have simplified room descriptions and creature descriptions for this example).

So, here is how the code is supposed to work. Basically this zone has two floors, and a hallway that runs east and west on each floor. I have a separate trigger for each room description. I have a set of trigger classes made for when I’m going east-west top, west-east top, east-west bottom, and west-east bottom, so 4 trigger classes. This is done because I will (obviously) pass through the same room depending on which direction I’m heading, and the script needs to know which direction I’m heading in. So, GTL1, GTL2, GTL3 and GTH1 are my four trigger classes. (These stand for 'go to lower one', 'go to lower two', etc) I also had to come up with a way for it to not move immediately when it saw the room description, but go in the appropriate direction after it ‘looked’ for monsters. Therefore, I store the correct direction I want to move in in a variable, which changes every room I enter. I also have a trigger class called ‘looking’ which is switched on and off every time I enter a room. The exits for a room all trigger turning this off and turning on a walking class(GTL1, GTL2, or wherever). The reason I have all of the directions listed, is at least one of those will be in the exit list, and as soon as one turns ‘looking’ class off, that’s all I need.

Allow me to show you some of my code before I describe the method its supposed to work:

#class looking {
#trig {north}{#T- looking;#T+@walktype;@godir}
#trig {south}{#T- looking;#T+@walktype;@godir}
#trig {east}{#T- looking;#T+@walktype;@godir}
#trig {west}{#T- looking;#T+@walktype;@godir}
#trig {up}{#T- looking;#T+@walktype;@godir}
#trig {down}{#T- looking;#T+@walktype;@godir}
#trig {a goblin stands here}{kill gob}
#trig {Alas, a goblin is dead!}{look}
}

I also have a class called “GTL1”. This class contains a trigger for EVERY room description from the top room to the first destination (Which happens to be top west room to top east room). The room description triggers look like this:

#TRIG{Room description 2. This is a cool room, blah blah whatever}{#T-@walktype;#T+looking;#VAR godir=e}

In the above example, I know that when I’m on GTL1, and I enter room 2, that I want to travel east. So, here is my method: I enter the room, the description triggers. It turns off @walktype, which was at the beginning of this script defined as “GTL1”. (Whenever I reach the end of the hallway, @walktype will change to GTL2). Looking turns on immediately, which will either see the goblin or not. If it sees it, it will kill it, and in theory initiate combat before the character ‘moves’ out of the room, and when its dead it will ‘look’ showing the room description and running the trigger again. If it doesn’t see anything, one of the exits from the room will trigger an exit trigger under ‘looking’ class, turn off the looking class, turn on the walking class (in this case GTL1), and then move in the pre-determined direction (in this case east). It will hit the next room description, and repeat this. Once it hits a ‘turning point’ (such as the end of a hallway), it will switch to another walking class (like GTL2 or GTL3, these are hard-coded in at specific rooms) and continue.

So, how does this look? Is there a better way to be doing this? I am absolutely ready to reply with clarification or any questions you may have. Thank you for your time (I know it’s a long post!) I would very much appreciate any advice I can get.

Posted: Wed Apr 16, 2008 2:25 am

There're a number of mistakes with your script, chiefly that you're missing spaces between }{s and the #t- and #t+ commands and their parameters. Spaces are very important in zScript syntax and can't be missed out.

There're any number of different ways to do this, and some (perhaps most) of them will be better than what you currently have. However, they'll be much, much more complex. Writing a bot is probably one of the hardest things you can attempt in zScript and most solutions will probably be gobbledegook to you. That'll cause you problems when you try to improve the bot or otherwise edit it, so I suggest you do whatever works for you.

There're many threads on writing bots around. Have a search.

Beginner Joined: 02 Jun 2006 Posts: 19

Thank you for your reply.

I will make sure to make the appropriate fixes to my syntax. However, how is the logic? Does the logic of this code work out? I know it is sloppy and there are better/more complex ways to do it, but will the concept work if I get the syntax correct? I would appreciate any constructive help to get this working. If there is a better way to write this bot, perhaps a foundation of code that I can work from?

Posted: Wed Apr 16, 2008 12:14 pm

Well yeah, it should walk you around fine in theory - it might be difficult to get it to do anything but walk around, though. Since you're always going to use the same route, it'll probably be more efficient to use zMUD's built-in pathing. That just moves in a series of directions one after the other, and you can pause it at any time. That's what's most of the bots mentioned on the forums use.

Seriously, do a search.

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

I would need to see a LOT more to be able to tell you if the specific script you are using would work.

In theory it could work.

However you are hard coding FAR too much.
This in turn will lead to having to rebuild the script from the ground up for each area you attempt to build.

As Fang mentioned there are plenty of bot examples in the forums. Most of which make use of the Zmud/Cmud
mapper and or paths.

I did build one once long ago that didn't use either, but I no longer possess the code and No I didn't post it.

I'm pretty sure from memory that there are a couple of full bot scripts posted in the forums.
And I gave progonoi a lot of advice on one a while back. In a huge thread containing lots of botting advice.
In fact you should find a few threads where he is doing the helping these days...

As a rule we don't like to post too much help for that as the questions never seem to stop.
That and on most muds botting is illegal.

Magician Joined: 28 Jan 2007 Posts: 430

Ohh, I heard my name! Twisted Evil

Yeah, there really is a lot of data lying around what concerns building bots. Just do searches with 'kill bot', 'bot', 'auto kill' etc, etc.

http://forums.zuggsoft.com/forums/search.php

Anyway, there are several ideas which you can use for the movement part.

1) Use built-in Map feature. (Dynamic movement which can be coded to go in circles indefinitely etc)
2) Use paths. (Easy for start definitely, but after a time could end up being too fixed as opposed to dynamical movement, i.e big path from point A to B after each step is confirmed, %pop one direction off list. When list=%null it means path is gone to its end, load the path again (meaning the one from which you %pop from is "temp path" loaded from some general one - temp_path=@general_path) but go reverse from B to A (I think %pathreverse is the command but I have never used Paths myself. I went directly to using Map features).

Whatever you'll use, you have to have msgs from Mud that give you heads up that direction sent is sent successfully, usually Exits line is the best for that. that %pops one direction off. When you kill all the mobs in the room or when there are nothing to kill when you arrive there, next direction is sent. You can do it with #step if you use #path. You can also make a String List with all the directions you're going to. Then you can %pop each direction off after confirmation and then once you end up with nothing in List you'll do %pathreverse(@general_path) or something. You get the gist of it I hope.

I'm posting from school so I may not make any sense at all :P

The point is, there are several ways to skin a cat, its more than true for ZMud (not to speak about CMud if you get yours hands on it)

I hope it helped some.

Prog

Beginner Joined: 06 Mar 2008 Posts: 27

heres the bot im working on at mo to give you an idea of whats involed its fully working but im still iron out bugs at mo

Posted: Wed Apr 16, 2008 5:58 pm

My first thought is "good god, that's an awful lot of code" and a lot of it seems to be repeating itself. If you used aliases and functions rather than repeating the code, you'd save yourself some work making changes. Same if you combine triggers into one.

Also, the only time you need to begin or end a pattern with * is when your trigger is using one of the #sub commands to replace the whole line. Matches can start anywhere on the line and don't need to end at the end of the line, so they're completely superfluous and cause a lot of slowdown. Don't use them.

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

A couple things on first glance.

#IF (@sitting) {#UNTIL (!@sitting) {#WA 5000}} {}
You are not required to actually put the second set of {} if it is blank.
Yes I know that you are up to speed on the fact that (@sitting) is equivalent to (@sitting==1).
It does make code much more readable if you actually spell it out.
It also helps when you do things like (!@sitting).
I know WHY it works but it always scrambles my brain. It would be much easier read as (@sitting!=1).

Next, you have made heavy use of the #until and #wait commands...
While it is the most direct way of thinking about the problem #wait and #until are not the best way to handle a situation when you are waiting.

A better way to handle situations where you have #until (@thing) {#wait}
Is to create a permanent Alarm that contains the remainder of the code within it and an IF statement.

#alarm "waitForStand" .501 {#if (!@sitting) {Go to whatever or do whatever;#T- waitForStand} {}}

Then you would enable the alarm which would check itself every however long and IF @thing is true it then does the rest of the script and disables itself.

#VAR whereami %roomname(,[])
The parser would really prefer you wrote this as below.
#VAR whereami %roomname( )

Just a couple things that I saw but changing them could be a lot of work.

Beginner Joined: 06 Mar 2008 Posts: 27

Thanks for the advice guys, im copying and editing to a new file at mo so i'll incorparate changes as i do it.

I've been adding subclasses 1 at a time so i can check them as i add them but the code does get messy so have to keep re-writting every so often to compact it. just need to add code for horses, torches and when to increase decrease danger and minkillvalue and its finished(plus add enemy triggers just got 4 for while im testing)

where there are 2 triggers detecting the same patern, i have done this to cut down active code, not all classes are on a same time I.E #CLA LetsXP is the biggest so while traveling
and not xp'ing i dont want to be wading through the script everytime i change room, meanwhile the other trigger will still actived all travel needs. there is probably lots of doubling that still that i will remove as editing

hadn't looked at functions before they look like they could save a lot of code i'll see what i can do with them. Thought i might try some #CASE statements to get rid of some of the repaeted #IF statments aswell.

I've been looking at the #ALARM recently, i've seen in the forums a few times that its always better to use #ALARM rather than wait. I'm still not quite sure on the proper way to use this function, i'll have a mess around and see what i can do

Thanks agian for all comments :)

Beginner Joined: 02 Jun 2006 Posts: 19

Indeed, thank you for the replies. I will search and try to re-write my bot using the built in pathing as suggested. Thanks again for the feedback!