Selberhad

:lol:

Err, I wouldn't. Would you? [Edit] I would macro walking between storage and the mine, re-clickling when I stop harvesting by getting damaged, and walking back when I get teleported. And if I'm at the computer the whole time, is this even cheating? Just saving on clicks.

The fundamental problem is, that as long as macroing is profitable, people will do it. No amount of macroer tests, banning of macroers, etc. will stop it. Usually, the only things macroers can macro are long, repetitive, uncreative, tedious processes. I don't think automation of this is a bad thing, but it should be done on the server side. This makes it so that no one has to do the boring stuff, not just the people who know how to write programs to do it for them. I think that the problem right now is that harvesting is easy but time-consuming, and therefore boring and prone to macroing. Harvesting needs to be made exciting and fast. Imagine if most of the mines were deep inside long tunnels that are infested with strong, aggressive monsters (who ignore monster magnetism). It would take the concerted effort of teams of players to get the ore. Now, if it only took say, 5 seconds per 100 emu of ore to fill up, players would fight their way in, quickly fill up before the monsters respawn in force, and fight their way out. In general, making things difficult but exciting and fast will keep the macroing problem in check. Especially if it requires teamwork; unless someone is controlling an army of bots to help him, there will be no way to macro it. I've seen tons of games with out-of-control macroing problems, but it is always because the mechanics of the game encourage macroing. I certainly haven't been here long enough to have many suggestions on how to change the mechanics, and it might just be too much work at this point. However, macroers will exist as long as macroing gets them something. -S

I am testing my bot using the "Bot_tester" character, on the test server.

First off, I'm new here and this is my first post, so hello . What I'd like to do is write a client in Perl which connects to the Eternal Lands server and allows one (me for now) to play it in text mode; everything that is currently displayed graphically would be described to the player in English, like in a MUD. My primary reason in doing this is self-education; I'm a long time mudder, and I always wanted to write a MUD which would use 3D data to store all of its data, so that it could eventually be played as either a text-based or graphical MMORPG. I never got anywhere with that, but this project seems like a good place to start since half the work - the server - is already done (thanks, btw!). Some questions for the developers here: Am I allowed to do this project under the license/rules? If so, do I have to declare whatever character I use to test it as a bot? Does the license put any restrictions on my client (like copyleft)? Thanks! Selberhad

I'd like to make a summoner bot. My initial thoughts for it are: -automatically harvest and produce essences for summoning -scavenge animal parts from abandoned bags -produce mana potions for personal consumption -wander between known, crowded spawn spots and summon some extra mobs if there are people standing around I am a bit confused as to the rules for bots. If a bot is totally self-sufficient and doesn't benefit specific players, is it then allowed? Is the owner then allowed to play the bot sometimes? Where is the distinction drawn between a bot who is occassionally played by a real person, and a person who illegally macro's most of the time? If the benefits to other players are totally random, and if the bot doesn't interfere with peoples' enjoyment of the game, will it generally be allowed? The ant bots seem to be along the same lines as I am thinking... I think this kind of bot would be very nice; in my brief time here I've seen a number of people complaining about spawn spots being overcrowded. Thanks, Selb

Just the wee animals for now. If people like the bot and want it to summon bigger things, I can modify it to do that. I'd only have it go into scavenging mode when it doesn't see any players around. You'd also be able to ask him to stop summoing and go away, and he'd comply. I don't see what is intrinsically bad about them - they just need to be made more polite, no? I've found the wandering bots very entertaining so far. *nods* I can always make it not summon in certain coordinate ranges (storage,beam), or if there are more than a certain number of visible actors. Thanks for all the feedback.

Great, thanks.

I respect the wishes of the developers - even if I am legally allowed to do something by the license, I'm not going to if the developers don't want me to. That said, I would like an official response from the development team on if I'm allowed to read the binary map data with my client. It would certainly make things easier for me, and I don't really see what would be wrong with it... but I won't if I'm asked not to. -S

Taking this further (and probably too far), I think it would be cool to have embedded Python/Perl/Ruby/<your scripting language of chocie>. Have function hooks for incoming lines from the server, as well as for user input. Then write handlers for these events. Would make bots pretty trivial to program, as well as an alias system. For spammers, what about some sort of flood protection? 10 messages in 2 or 3 seconds gets you muted for 10 seconds, three flood mutes in one hour and you get kicked/banned for a day. 3 kicks in a month = permanent banning. Something along those lines, I'm sure it has been discussed if there have been problems with spammers in the past. I could probably even put together a patch for this, even though I'm not very good at C. -S

The license says: Which means if I do want to use the binary data, I'll need to get approval (does this mean everyone with a walking bot has approval?). I will deal with that issue when I get to it though, unless someone can approve me now. Xilcox, I actually was thinking of having it work as a kind of mud server, though it would still be very different from your idea. You'd connect to the MUD-server with your favorite mud client, and the server acts as a proxy/interpreter and connects to the EL server on your behalf. The problem with this is all people connecting to it would be seen as connecting from the MUD-server's IP address and it would be difficult to find multiplayers. If this project gains official support and the MUD-server is trusted, then it would be possible. Regardless, I'll still have to write all the same code for communicating with the server, and it'll be easier for me to test if it is a stand-alone client for now. I'm glad to see there is some interest here, I can post updates on my progress if anyone wants. So far I've just done the very basics - can connect to the (test) server, log in, and parse incoming requests, but I only have a few simple handlers written. The major obstacle will probably be navigation/perception, as some have noted. I'll definitely be making the source for this available when it is a little more complete, since it could easily be used to write store-bot scripts and such in Perl. -S

Wytter - yes, that's pretty much how my mental image of the thing looked, but with more detail presented. I do realize that it can get complicated. I was initally planning on doing complex pathfinding, but as Cicero pointed out I'd really need to read the map files to do that. I'm not going to give up right away because of that though - I have a few ideas which I don't think would require reading any of the binaries. At worst, I'll have a nice EL bot framework in Perl, which I find a worthy enough goal in itself. -S

Great, thanks. Is there any description of the client/server interface except in the source code for the client?