jamincollins

That's more or less exactly how I took it. I've been training on Ogre with full steel for a while now, not a single degraded steel item, and no I don't have an NMT. I don't believe this has anything to do with anyone attempting to change the XP/hr that anyone gets. What happens if NMT capes continue to enter the game but never leave? The answer is simple, the NMT cape will eventually become an overly common item. Will this happen in a month, a year, or five years? It's hard to say. The point is if they continue to enter without leaving the game, it will very likely happen. I only say it is likely because it is possible that we will continue to get new players entering (and staying) faster than the NMT capes enter the game, but I don't believe this is probable. I feel it is much more likely that NMT, if dropped at all, will enter the game faster than new permanent players. An alternative would be to limit the number of capes in the game, as has been suggested before in this thread. However, all that would do is create an artificial elite. Those that have the cape already. Since the item is limited and never breaks on its own there is no way anyone in their right mind finding one would sell it. This doesn't seem a very viable solution. So, what does that leave as a solution to eventual saturation of NMT capes via drops? Oddly enough what Entropy suggested, that they rarely break through normal use.

I'd love to see the NMT capes made permanently breakable. Any item that comes into the game without a means to get it out of the game will create saturation. And don't tell me that the branch and mace are the means to get it out of the game. Entropy's already provided stats that contradict this claim.

It isn't the first time that an invasion has dropped right on a populated outside storage.

Please read all of this before voting. I would like to get player opinion for something a few of us have been tossing around for a while. A bot specific market channel. This channel would be monitored by trade bots in much the same way that bots currently handle PMs. That is a player would join the channel and send a command to all listening bots simply by posting in channel. For example a player looking to buy rostogols would type something like the following: @@## inv rostogol where ## is the channel number. The bots in channel would then parse the message just like they would a normal PM. The difference however would be limiting responses to only those that have the item being requested. Likewise a player looking for a bot that buys an item would send something like the following: @@## wanted rostogol This would allow players to query multiple bots at once rather than having to PM tens of bots in succession looking for one that happens to be selling what they are after. It would also lead to a reduction in the advertising spam currently found on market as bots would no longer need to advertise in hopes of being remembered or getting noticed. A new bot need only support the channel command set and carry items players are looking for. Obviously, the exact command set would need to be discussed and documented, but I'd like to get an idea of player opinion on the topic first.

Isn't that simply the channel commands, and their various forms, possibly with examples? If so, isn't this documented on the wiki currently, or am I still missing something?

Here we disagree. Documenting the inputs, their behavior, and the outputs results in defining the human side of it. The human side is the input and output of the development side, or am I missing something? Would you like the page of the wiki for this opened so that any registered user can make changes? I figured limiting the changes to that page until some discussion had occurred would be better, but if you'd rather more people be able to change it, I'm more than willing to give it a shot. The item names are not something specific to the proposed channel. They are the full and actual names of items in the game as provided by the server. If you would like a statement to that effect on the wiki, I'll be glad to add it. The same is true of the maps. In fact the wiki indicates that map names will allow the abbreviations listed in the encyclopedia. Do you really see a need to duplicate this documentation? Now, item abbreviations I can see a need for documenting. If someone would like to undertake this please let me know, otherwise I'll add it to my todo list.

Yes, as the portion you bolded indicates that is nothing more than an assumption. I am not dictating anything there.

My bots won't be participating, so they won't return the required response. Should I expect that you would use that to justify a ban for them? Why would bots not participating in the channel be bound by the channel's requirements? Have I suggested anything like this? Yes, I have contacted Entropy about the idea. His responses thus far seem quite promising. As for other bot owners that you provide hosting for wanting the features, that is between you and them. I don't see documenting a full proposal (with functional proof of concept) as dictating anything, you are however entitled to your opinion.

I believe this is mostly self explanatory. Either a match will be made and a single line response returned, or a match won't be made and nothing will be returned. I agree that there needs to be some way to get the word out to the users about how to use the channel. However, before attempting to get the word out, we need to define what the word is that we are trying to get out. I never intended to make regular expressions a requirement or even an option. I simply commented that they would be nice. Personally, I love having them, but I know they are well beyond the average user's ability. Only substring matching will be used. Whether there is a penalty or not largely depends on whether the channel is an official channel or not. If the channel is official with a required command/response sent and bots deviate from it, I assume they could be banned from the channel or possibly from the game. However, what real difference does it make if some bots want to try and extend their matching? If their matches are too broad they risk being added to a user's #ignore list. If their matches are more precise/helpful, then the other bots can benefit from them. It may not make his points less valid, but as far as I can tell he's not willing to try and help find a solution. Do I have all the answers? No. That is why I had hoped to discuss the command/response set with other bot owners and find a good fit for everyone willing to participate. There have been a few bot owners that have contributed to the discussions so far. If you would like to contribute and help refine the requirements, you're more than welcome. Perhaps I'm wrong, but I don't see how coding a proof of concept for what we have thus far is hurting anyone. It's only on the test server. If the command/response set changes, the proof of concept will be updated, or if needed rewritten.

A consistent list of aliases could be very useful. If used they should be consulted prior to any pattern matching attempt. All bot responses from channel are limited to a single line. Sure new users may initially use extremely vague patterns. I'm confident that they will learn to use more specific patterns. Additionally, if there is a list of aliases this specific case ('he') would become moot. Doesn't match, silently ignored. Im trying to show nonsense of this. There is no chance to make it works corectly, and many people will have lot of work with implementing this in many bots written in many languages, work for nothing. If you (or they) don't feel it is worth it, don't implement it. The users have clearly indicated that they would like something like this, and I'm willing to add it to the code I maintain. This has been suggested before. Many bots provide different pricing based on who they are taking to. Such as lower sale prices and higher buy prices to members of friendly guilds. Any centralized listing service will not work correctly in such cases. And again we are back to the goodwill of a third party with such services. Nothing stops them from excluding bots or fudging results. Not all of the wiki is read-only. Sure there are sections of it that are, but much of it is modifiable by any registered user. Not having a user modifiable section of the wiki for this discussion was an oversight, and has been corrected now that it's been brought to my attention.

But where ? Your wiki is read only, even for registered users. The wiki (specifically the wishlist sub-page) is the intended place. I'm looking into the permissions currently. However, in lieu of being able to update it, discussion could have taken place here in the forums or via forum PM. NO! We need to decide exact syntax before anyone try to implement anything, if not everyone make it different, and every bot will give differen result, one big mess on the channel. I think perhaps you misunderstood. Simple substring matching for the pattern is the consensus of those that have contributed to the discussions regarding the command set so far. So, it is what the wiki is intended to convey with regard to the pattern and a match. The intent of the wiki is precisely to document the command set and behavior so that we don't have everyone doing it in a different way and responding in a different fashion. I announced the wiki here a while back and my intent. I waited for some time for contributors and received a few. Then began work on the proof of concept. I'm sorry, but I don't get the point of this statement. These are (as far as I know) all capable languages.

This documentation was very unprecise, everybody can implement this in different way and it will be working different with every bot. What does mean "matches" ? 1 pattern is exact same as item name 2 pattern is substring of item name 3 pattern is posix regular expression that gives true on item name 4 pattern has at least N letters same as item name (and N=?) 5 .... Feel free to help document the command set and clear up any areas you feel are too vague. As for the intent and current implementation of "matches", it is a simple substring of the item(s). While regular expressions would be nice, they are far beyond the average user. Perfect example - until the player sends a perfectly formed command there is no way for the player to know what a perfectly formed command actually is. Or maybe you want to stay on the channel 24/7 as a sort of unpaid unqualified moderator telling people exactly what they are doing wrong.. I realize you are dead set against this and nothing I or anyone else says about it will change your mind. However, what makes you assume that this won't be documented in a more straight forward fashion for end users in some way? Right now the implementation is a proof of concept of the bot side of things. The user documentation will follow, assuming we get approval to put this on the production server. Beyond that, the commands in use aren't rocket science. In their most basic supported form, they are: A number of bots already support similar commands.

The command set documented on the wiki has been implemented. Freya is now running under this code on the test server for anyone that is interested, I'll leave her running there for a while. I'm currently using channel #13 on the test server as the bot command channel.

And if family members want to PK each other for whatever reason? Under your suggestion, they can't. Yes, my wife and I have on occasion fought each other. Perhaps there are siblings out there that would like to settle things in PK?

This is the intent of having a specific set of commands and responses for the channel. If you check the wiki link, you will see that the inventory and wanted commands have this as a requirement so far. I've added an optional multi-match single line response format that bots could use or they can opt to send only one of the matched items in the normal format.

Following Aislinn's suggestion, I am currently working on documenting the base set of commands for this channel. I invite anyone interested to participate. I've setup a page on my guild wiki for documenting the supported commands and a sub-page (wishlist) for discussion of desired features. The wiki pages can be found here.

This has been proposed before. The only way I see the external site working is if it's provided as part of the game site. Anything else relies on the goodwill and neutrality of the individual hosting it. What is to stop the host from excluding or fudging a bots reported information? With a channel, the middle man (and the reliance on his/her goodwill and neutrality) is removed.

I'm ready to make the change to the bot code I provide, which is available to everyone. I can't speak about the code provided by others. There would be no need for the bots to advertise in this channel, it is intended as a means to check which bot has or wants the good(s) in question.

Entropy has asked that I bring the discussion for this to the programming forum. As many of you probably know, several people have various scripts that monitor the chat_log.txt for changes and play different audible alerts based on the different text entries. Not all events are written to the chat_log.txt, and most really shouldn't. I'm looking to go beyond what is possible with simply following the chat_log.txt by passively monitoring and parsing the network traffic between the client and server. The external script would sniff the packets between the client and server, parse the data structure, and be able to trigger audible alerts based on any event sent by the client or server. This script wouldn't have any information/knowledge that the client doesn't already have. What do you think?

There's an existing poll on this subject? If so, I apologize for the redundancy. However, I don't recall one. And this means that each player needs to PM each bot one by one to see if they do or don't buy or sell the item(s) in question. That can lead to a fair amount of wasted time and bandwidth. Monitor? Who would want to sit in a channel that only receives bot commands? I guess you could if you like, but I see most players logging into the channel, sending their command and leaving as they get their responses. I knew I saw you say this somewhere - your idea would only increase your bot's exposure at the expense of all the others. And surprisingly (not) this was posted in a thread from over a month ago that discussed pretty much exactly the same thing. Do you really think we have such short memories? What point are you trying to make? That I'm generally against bot advertisements on market? Absolutely, they are little more than a waste of bandwidth as far as I'm concerned. How would this increase my bot's exposure at the expense of others? I'm not stopping you from placing your ads, if you wish to continue sending them do so. In fact, what I'm proposing would increase the exposure of all participating bots (not just mine) without trying to bombard players with advertisements. No, you're not wrong on it at all.

Using latest CVS (updated minutes ago). It appears that the drop message sent by the client to the server differs based on the source of the drop. Items dropped from the main inventory window are sent as [pos:1][qty:4] where number after the colon is the number of bytes for the filed in the data stream. However, if the drop is done from the quick bar it is sent as [pos:1][qty:2]. I'm guessing that at some point the quantity was a 2 byte field and this was increased to 4 but not all spots got the update.

Where does it say that we are proposing to stop your bots (or others) from using channel 3? The question of the poll is entitled "Would you use a bot specific market channel?". For those that want a market channel free of bots there is channel 33. This is a proposal to make interacting with the bots easier for the players and give them control. So, how is the poll biased? Nope, it was only a question of when the response would appear.

This would only happen if all 200+ bots had the item you're looking for. The idea is you will only get responses from bot(s) that are either buying or selling (depending on the command) what you requested.

That is exactly what I'm proposing, a standard uniform feature set on an official channel. Interactions with the bots directly can still use whatever feature set or command set the bot owners want. However, I propose that interactions through the channel have a documented and uniform set of commands and responses.

Difference here is that the player requested the reading by sending the command, it wasn't spammed at them unrequested as the current market channel announcements are. These would be targeted responses, not shotgun advertising. I'm not convinced that this will consume anymore bandwidth than the bots spamming each other and players with their ads. Even if it does, you're now dealing with a case of requested responses. Typos would simply be ignored by the bots as non-match, no problem there. As for substring matches or aliases, this is a question of command set implementation. That is something I clearly indicated in my first post would need to be discussed and agreed upon.