DogBreath

We now use a single periodic copy of the playersonline for all the bots we host to avoid this, but that's probably not practical/economical unless you're hosting a number of bots... (it also doesn't work real well on test, as there is no "online" page for test) I agree something like this would be nice

I've had good luck with changing the resolution at the login screen (and not logging into the game) then closing the client/reopening it. It seems to not like resolution changes while you're already logged in...

I think it's great this thread even appeared. Just think, this time last year there was no such thing as a mage As with all MMORPGs things will constantly need tuning, it's nearly impossible to balance things perfectly... I think Radu should get kudos for making the magic changes such that this could even occur, so, let's give him a break and let him tune it?

On the top of the screen you'll see several boxes that represent what channels you're in. Click on the server channel first, then click on view all. This should fix it, if I understand the problem correctly.

Just wanted everyone to know we've hit a new milestone. We're now hosting over 100 bots \o/ Thanks everyone for the great support DB

I think you misunderstand the messages, at least how they now work after the off-line buddy change. The byte you are interpreting as "1" to log on and "0" to log off does not have that meaning. A "1" tells the client to add the named buddy to the the list. If the type byte if "0xFE" then the buddy is off-line, otherwise the type byte is the buddy colour in the list. A "0" tells the client to remove the buddy from the list, which will only happen if you remove a buddy "#del_buddy"; not when a buddy goes off-line. The invalid "... has logged on." messages received when you start the client are due to some now redundant code in the client. If you start the client and log in within a few seconds, you do not get these messages. We are very lucky that the original author of the buddy code coded in off-line buddy support as described above; this mostly works well. They also added some comments as to code that would need removing to finish the off-line implementation. I'll update the CVS version soon with these changes. Thanks for the clarification

Hi, Due to the bombing of several bots that have had the one perk, I was hoping to add the bot's perks to our database so that an owner would know what perks the bot has (this really becomes an issue if someone transfers ownership of the bot...) The issue I'm running into is the perks come back to the client/bot as a raw_text message with no identifying tag (like "Perks:") Could you please add a tag, as suggested above? This way I would know that raw_text coming in with that tag is what I'm looking for and can warn the bot owners that they have the perk and should take some kind of action before their bot gets bombed... DB EDIT: typos

Issue #list_perks, watch the color code, and stop watching after a short time that is significantly longer then the servers response time. Thanks, I didn't think of the color code. I'll give it a try.

Seriously, no trade bot should ever take/have One! A bot owner should either know what perks the bots has or log in as the bot and then do #list_perks. It's not worth Ent's effort to add something like into the server for limited usage. Plus, with how the data is being sent currently, the Ants have no problem identifying what perks they have by doing their own #list_perks. I realize no bot should ever have the one perk, but some times people get a bot from someone else and aren't quite educated in the ways of ugly perks. This has already resulted in at least two people no longer owning bots and at least one of them quitting the game outright. I realize the amount of effort needs to be weighed in, but is adding a single word and a colon before sending the text really that much extra work? Could you please explain how you can be assured the raw_text you're decifering as perks is the right raw text? I realize I can look for the raw text, and "hope" that it's the right line, but if some raw text "snuck in" between requests and it had the word "one" in it, it might get really confusing. Best I can tell there's no way to be "sure". If you can show me another way, I'd glady use it. Thanks, DB

I'm not positive about this, but I'm pretty sure that this is due to how the server is sending the information to the client (I looked at the client code for clarity on this.) There are two fields with the message that's sent, the first field was a 1 or a 0 (1 being logged in, 0 not..) and the second field which is a color code (to display the color you'd chosen for that name.) Now, the message is always coming through with a 1 (logged in...) but with the color grey for logged off (and other colors for logged in...) This is why the colors are matching up right but the messages "whomever is logged on" is always being written to the console (because it's always sending a 1...) This is also affecting all of the bots we host. I put a fix in for it until I realized exactly what the bug is, now I'm not so sure if I'll need to back the fix back out (I'm thinking I will need to..) I think if the first field is sending a 0 with logged off that this will be fixed. DB EDIT: the alternative is to fix the client code (and the bot code) to recognize the color code that is sent from the server and key off of it... grey = offline otherwise online... EDIT 2: I obviously didn't see radu's post before I posted this.... sorry for the rehash..

I thought about this for a day or so, and tbh, I don't think I'd use it. However, I can see it being useful for others. I already make things at a loss, and at least need to sell what I get to try to cover as much of the cost as possible. I do see 'rich' people being able to take advantage of this though, so I think it's a good idea.

Have you run windows update to make sure all of your drivers are up to date? Is there anything in your log files that might indicate what the problem is?

I'm a little confused by which your ingame name is. I went looking for you once or twice so far and couldn't find hellzinchick or Jennie. Also, it might be helpful to indicate what your normal playing time is, so someone with similar hours could try to meet up with you.

Doesn't matter who writes this, if there's a bug in the programming, it's going to mess up. Well then, if people you host the bots for don't mind the possibility of having everything on their bot scammed, then it's OK to me. They already take this risk every day. If I screw up, they have the distinct chance of losing everything. AFAIK in the year+ we've been hosting, not one bot has been scammed due to anything other than operator error (sell price lower than buy price, etc...) While I can't claim perfection (by no means...) I can say that having so many eyes watching the same pool of bots gives us a huge advantage over the scammers. As soon as something is found, we have the ability to shut the entire thing down and fix it and we have a team of admins (that can shut it down) spread across different time zones so there's usually someone watching. We also have forums, in game contacts, and the admins have my phone number to call me if the roof caves in. That being said, it seems to me that it'd be best for a single bot (like perhaps walkincloset, that's being used to hold the quests prizes already, or a similar storage bot) to hand out the prizes, so, the tradebots would just be handling the quest events and logging who's completed what. This way these bots don't have to worry about actually trading anything (cancelled trades could be used to verify items, or the 'ending' bot could be the one that collects the item(s) and hands out the prizes, depending on how the quests were planned...) All of these bots are on a centralized database as well, so there's no timing issues between them, they all know (or could know) 'everything' from each other bot at the same time. You asked for a network of bots, that's what we have We're just trying to offer that network to do what you're asking (assuming you can trust us enough to handle things well.) It's your call

Doesn't matter who writes this, if there's a bug in the programming, it's going to mess up. Our tradebots can move, assuming you don't have an issue with them moving for a quest and then returning when they're done. (They don't perform as a normal trade bot when they're not at their home position, already...) This is why I suggested having more than one bot listed - a back up bot for each step (with as many as have volunteered from our service already, this would be very possible.) The owners wouldn't have access to the higher privilege commands, just the code base on events. And, if you have these bots tagged as having special privleges (or the IP) then even if someone had the code it wouldn't do them any good, would just be another person trying to scam and they'd get banned for attempting it. All of our bots are hosted on a single machine, while no one can gaurentee 100% up time, we're around 98% or better. And with 70 bots spread across the 'world' I'm not sure you can find a better spread without doing what bkc suggested, making a new bot for every map.... If the interface is nice enough, I'm not sure why it matters if some programmer understands it or not. If the person that's setting up the quest understands it, what's the difference?

Why not let the those that you trust to do this have examples of how you program the npcs, then let them submit back to you modified versions for new npcs/quests? These could be submitted to you to run on the test server and be tested until you're satisfied that they're working correctly and then moved to live. This way all the work isn't on you, but the quests could still be fully integrated into the server and then there'd be no reason to worry about "if the bot isn't up" or it being written in a language that's not "clear" etc... It also means if the person drops off the map some day, that the quest system doesn't disappear with them. These 'quest writers' could also be the ones responsible for taking the player ideas for quests and implementing them as time permits (assuming you approve of the ideas.) I'm sure you could ask them to 'sign' some non-disclosure agreement if you felt that was necessary.

So far the response to this by the bot owners on our service has been overwhelmingly positive (and had actually been suggested by several of them in the past already.) I guess all we'd need now is more details on how this interface should work and if you'd like us to proceed.

If there are enough bots availble to do this, there could be a secondary bot chosen during the quest set up (for each step) this way if one of the bots was missing, chances are the other wouldn't be. The quest could then just defer to the secondary bot for that step.

I've sent a system message to the bot owners asking their thoughts on this, so I'll let you know how they feel about it in the next day or two. I assume this wouldn't interfere with the normal operation of the bots (and indicated such on the post.)

As you're probably aware of, we currently host 70 trade bots, and serveral storage bots on our service. I assume that means people trust us (we have a small team of very trusted players as administrators on our service.) We also have a web interface (that has several layers of security.) If what we're talking about is adding a new protocol or two to the bot's code and then allowing this 'trusted player' (or players) to upload the quest information into the database some how (via a web page that they can upload some script with, or just fill some out some web page with quest information,) I think this could be done in a fairly short amount of time. This would, of course, require the bot owners' consent (but at least one of the owners has already indicated on this post that he's willing.) I can ask them if they'd be willing and have an indicator on bot configuration screen that would allow them to 'opt in' with their bot(s). I'd certainly be willing to add Josi as a 'willing' bot, as well. If I understand it right, these messages would only come from the server while the quest was running or would the bot also need to check if the quest was running befor it tried to interpret these new messages? The bots already have the ability to recognize people as they walk into range (as they have the ability to greet them - which has been the subject of a bit of contraversy...) I assume that when they approach the bot it'd be told by the server that this person 'qualifies' for the 'action' you'd like the bot to perform. It all sounds possible/doable. With such a coverage of bots on both continents, if I can get their consent, the quests could cover most maps in the game. If you'd like us to persue this further, please let me know and how you'd like us proceed. I'd need to know what the new protocols were so I could modify the bot code to handle them and what the web page should look like (and who could should be able to access it.) I'd guesstimate that this would take about two weeks to develop and test. We're in between releases right now, so this would be the perfect time to do this.

I guess that's up to the person writing it. There are many possibilities but the simple GUI I use on Linux could not simply be ported to Windows AFAIK. It is basically a shell script that uses a generic app called Zenity for the GUI. Using OpenGL would allow the app to be written using the same graphic style as the client which might be nice. Why not another c or c++ application, like the application is in already? That seems the easiest way, using the same drivers/includes, this way the compile process would be the same as well... Porting to multiple OSs should be exactly the same then.

I concur with XenaMT on this. One of the best ways is indicators (especially the frist couple indicators that take the least amount of ings.) That being said, I think some small adjustment on the vendor prices for indicators/predictors could stimulate the market for them. People want them, they just don't want to pay what they're worth when they can go to the NPC and pay less than anyone can make them for (espeically for the ones that cost way more to make than the vendor is selling them for -- like the ones that use gems on top of everything else.) With the changes to invasions, and suggestions radu's made about using mines/caltrops as a good method of dealing with them, there might be a growing demand for those items (I haven't researched it enough to know for sure but I suspect so.) My experience with arrows is that only the 'advanced' archers want player made arrows as until they get to that point, it's not worth the gc cost of wasting arrows (with all the missing...) when you can just buy training arrows for 10gc each and pluck away knowing you're saving nearly 30gc an arrow. A slightly off-topic footnote on this: it might be nice if these were listed under engineering as well as archery (in the encyclopedia,) since it requires engineering to make them... In my opinion, engineering certainly has wonderful uses and some demand. I think some minor changes (that radu appears to be addressing as time permits) will stimulate the demands for these items. There are also uses for the items you make, for yourself, if you can't find someone to buy them right away I wouldn't even consider making "stoof" with expensive tools without checking my breakage astro first...

I know this is kinda off topic, but how about bot hubs? Are they ok to post in channels? For example: http://labby.co.uk, or http://dogpound.embril.net, etc...

Thinking about this a bit more, most MMOs I can think of use this type of procedure. A server select screen, choose server, then it launches client... Upon exit of client, you go back to the server select screen... (Everquest, WoW, and several others come to mind...)

Sounds like back to square one then, as you pointed out, test and live might not be close enough to keep the client 'alive', especially if there's some change in graphics engine... Hrm... EDIT: if exiting the client puts you back to the menu each time, would that be that bad? considering the issue listed above, I'm not sure how that could be avoided... *brainstorming, yeah, I know, it's possbile anything in my brain must be a storm...*