Jump to content
Eternal Lands Official Forums


  • Content count

  • Joined

  • Last visited

Everything posted by DogBreath

  1. #Lottery command

    I think adding a #Lottery command that provides the current amount, drawing date/time (and maybe the last winner/amount) could help the lottery. This would allow people to check it when then have time (or just logged on) and might be useful for some bots to publish it in some heavy traffic web pages/game channels some where... The more 'publicity' this gets, the more people will use it, I'd assume (and the more that use it, the higher the amount, enticing even more...)
  2. bugged storage

    Oddly enough, I ran into this same exact problem, today I think there's another possible solution to leaving it on. It'd work if it would take a parameter, instead of being a toggle. E.G.. "#item_uid 1". This way it wouldn't break bots on _old_ code and would allow you to assure it's on by setting it (if indeed you want it on...)
  3. Changes to EL-Services bots

    The bots hosted by el-services will be working a bit differently in the near future... The biggest difference you'll notice is the bots will not put coins into the trade until the last 'step' in the trade (so basically when you indicate to the bot you're "done" it will put its coins in...) The bots will also provide more information about the trade using a new command: #total, that may be entered at any time during the trade. The #total command will provide you with complete details of the trade (what you've put in, what the bot's put in and how much is owed and to whom it's owed...) The #total command will execute automatically when you click accept, if you don't want to enter it yourself. It's really not a "huge" change, just some minor re-ordering of how it trades but we figured it best to let people know ahead of time. DogBreath
  4. Changes to EL-Services bots

    The bot will tell you what you owe (or are owed) and provide you a way to get a detailed listing of the transaction. The biggest change is that it won't put coins into the window until you've 'commited' to your side of the transaction by clicking trade once (and it won't EVER take coins out of the window, it would cancel first...) This doesn't mean the trade is final, until you click accept a second time (and you can always cancel before the second "accept".) It's simply a change to how the bots used to do it that we wanted you to know about.
  5. Would be great to see some tailored (colored) boots/gloves to go with these great looking outfits
  6. Teh_Master

    Hi, I wanted everyone to know about Teh_Master. He's a bot designed to help the community. Currently, he doesn't have a lot of features, but one of his best might be that he posts announcements on twitter. You can find the information here: http://twitter.com/Teh_Master Now, before you say, "I don't use twitter", consider this: You don't have to be getting tweets to find this useful; You can refer to the page to see annoucements you might have missed while you were away from the game. If you do find the page useful, please register/follow, so we can tell how many people are folllowing (It helps to know that people are making use of it...) If any mod needs to remove a tweet, they should contact radu/asgnny/Aislinn, as they have the ability to remove tweets posted. DISCLAIMER: the code is new, so it may have a few bugs still (that we're working to eliminate as quickly as possible.) There's a chance that an annoucment might not get tweeted if the bot runs into a bug (until the bugs are all worked out.) The bot doesn't go AWOL that often, but it has happened. Please stop by and take a look at the information on Teh_Master's page. Hopefully you'll find it useful DB

    If you need to give the bot items, or take items off the bot, you'll still be needing the trade_item protocols, no? I realize you won't need it for buying and selling, but trading isn't exclusive to buying and selling... I guess if you're logging it on by hand to trade items then it's a mute point Just didn't wanna see ya miss something DB

    You're right but then you don't need to know the length until you're actually dealing with an item. I realize it might be easier to calculate the size, remember it, and reuse it, but it's not really that difficult to keep recalculating the size as you need it (and probably safer...) This is also a good way to test, as you can flip the switch on the bot (#item_uid) to be sure it doesn't have a problem either way... The other place(s) you need to check are GET_TRADE_OBJECT and GET_NEW_INVENTORY_ITEM (if you use this last one, many bots don't as best as I can tell...) Check to see if there are the extra bytes at the end (if not, then the assumption is there's no item id provided by the server...) private static void newItem(Bot Bot, byte[] itemInfo) { uint pos = itemInfo[9]; uint flags = itemInfo[10]; int image_id = BitConverter.ToInt16(itemInfo, 3); int quantity = BitConverter.ToInt32(itemInfo, 5); int serverItemID = 0; try { serverItemID = BitConverter.ToInt16(itemInfo, 11); } catch { serverItemID = -1; } public static void GET_TRADE_OBJECT(Bot Bot, byte[] buffer) { Bot.tradeItem myTradeItem = new Bot.tradeItem(); myTradeItem.pos = buffer[10]; myTradeItem.imageID = BitConverter.ToInt16(buffer, 3); myTradeItem.quantity = BitConverter.ToInt32(buffer, 5); myTradeItem.toInventoryInd = buffer[9]; myTradeItem.playerName = Bot.tradePartner; myTradeItem.fromMe = ((buffer[11] == 1) ? false : true); bool alreadyInList = false; try { myTradeItem.serverItemID = BitConverter.ToInt16(buffer, 12); } catch { myTradeItem.serverItemID = -1; } Coded like this, you don't have to know the length before you need it (and don't need to remember it as you're really only after the server item id.) This works, as I have a bot on the main server using it and it was first used on test with both lengths (it just doesn't care what the length is, mosly...) Hope this helps DB

    I can confirm this. I don't think it's new though. I have my code checking to see if they're trading before I process this command. The first time it processes it and sets trading to false so it just ignores the second time. EDIT: it doesn't seem to do much more with this anyways except setting the trade partner to ""... case Constants.GET_TRADE_EXIT: { Bot.addText("GET_TRADE_EXIT(" + protocolType + ")!"); if (Bot.trading) { Bot.addText("Trade complete!" + Environment.NewLine, System.Drawing.Color.Gold); Bot.tradePartner = ""; Bot.trading = false; } break; }

    It'd be nice if we'd switch over on test first (completely, so that it's a more true test...) Right now, we have to issue a command to make sure it's working correctly. It'd be a good idea to have a full test first, for maybe a week. If there are client changes associate with this, they could be fully tested as well... But yes, an ETA on the final switch would be good too. I have some code swapping/database changes that I'll have to do on "switching day" and would like to ensure I can be around in case anything goes wrong. Thanks, DB
  11. Prefered database for a bot

    I like mysql, but whatever works tbh.... "If it's for free, it's for me!" I've used oracle, db2, progress, mysql, mssql, and some others I can't even remember the names of... Each has their advantages/drawbacks. I'd have to say orcale is on the top of the heap, but it ain't free and it ain't cheap... I agree with piper, if you're only going to have a single bot (or two) then, a database probably isn't necessary... However, if you're going to host a large number of bots, it can be quite handy. Databases can also be nice if they support triggers and stored procedures. These allow you to share the processing load with the database where it makes sense. Often you can do some work on the database and save a lot of I/O by providing the answer instead of the raw data. Being able to do adhoc queries is also a nice advantage to using a database. My rule of thumb is: "best tool for the job". Whatever is the best fit for what you're doing...

    Is there going to be only one list of items for all three servers?
  13. Traffic in NC Near Storage

    Yeah, no disagreement there... But since the bots were brought into this idea, I thought why not kill two birds with on stone I agree, the rock is painful
  14. Traffic in NC Near Storage

    Sounds good to me... I still kinda like the idea of a central market place... I realize people think tha bot placement is a huge deat, but let's think about this... If you can get a deal, you'd walk for it, no? It's really more about price than location, isn't it? It's be so much easier if all the bots were on one map (and there was an easy way for anyone to get to that map...) imo... It'd be so much easier for newbies too, finding a bot wouldn't be hard. Maybe a command, similar to #beam me (and some central return point, or portals back out to several locations...) would make it sweet (once again, imo...) Then no bots would ever be in the way (I realize this is about the rock, but it's also about the bots, if I'm interpreting right...) and there would always be a place for new bots (right beside the last one...) Just my 2gc, I'm sure some won't like the idea, but please, don't kneejerk, think it out before you flame me DB
  15. EL Gamma

    From what I've heard, the new client won't even use SDL, which I consider a sort of boat anchor anyways. Most of the .net programming languages (afaik) already have the bit conversion functions built in (and many of the graphics functions) so SDL isn't really needed any more (I've had this conversation with the person writing the new code and he concurred.) With any luck, this problem will be a non-issue with the new client DB
  16. Teh_Master

    We're trying not to duplicate gossip's job. We certainly appreciate all she's done for the game and wouldn't like to give the impression that we're trying to step on her toes
  17. EL Gamma

    Can't say I know a ton about this, but I think there are different layers of gamma in windows (desktop, application, and fullscreen application.) I suspect the client is affecting the wrong one, some how.... I too have had this issue and agree there's probably a way to clean it up in the code as other programs/games don't leave a permenant change after closing them... Wish I knew more about it =\ On an odd note, when I had to reinstall vista recently I got version 191.07 of nvidia's driver and this problem seems to have vanished (this driver was from MS, not downloaded from nvidia's site.) The other odd part is, with all previous versions of the driver there were "runndll" processes in task manager, these seem to be not needed as they're not present with this driver and yet I still get the nvidia control panel and all seems to be working (if not better than before....) This driver also seems to have eliminated the random crashes I used to have with previous nvidia drivers. So, I suppose it's possible there's a driver issue included in this. It might be worth investigating the driver above (assuming you're using nvidia...) I would also suggest looking on nvidia's sight for a driver removal tool, to be sure the old driver is completely removed before installing the new one. I can't say for sure that this will help, but it might be worth trying DB

    IMHO from a client point of view, it is certainly better in the short term (until its permanent) for it to reset each time you login. Well, maybe... Though Entropy seemed to imply that the setting was kept between logins (hence the 20$ reset fee) Only problem with #item_uid being reset on logout is that the first inventory is send directly after login, so that would always be the old format, until the new format becomes definitive... Would sending #item_uid immediately after login get me the inventory in new format? Yes, for my testing I had to issue the command, then refetch the inventory and check other commands with the new lengths (I agree, I got the impression that once you issued the command it would stay that way until you toggled it off...)

    You're using C# if I'm not mistaken. Just use .NET properties System.Net.HttpWebResponse.LastModified to get the date and use System.Net.HttpWebRequest.IfLastModified for the request to prevent downloading an old file. Ok, I'll check that out, thanks

    Was working on this change and realized it might be nice to have an "effective" date on the item_info.txt file (just a date at the top or bottom of the file/page.) This would keep the recepients of the file from having to process it, in its entirety, each time its aquired. Once simple check (is the effective date on the file > the last time I updated?) and one would know if they needed to process the file or if they already had an update to date list. Just a thought DB

    This looks great, thanks

    You're right, ID is the used protocols, but weight is not. Currently we're deriving weight from the description (as you're eluding to.) So, as long as the description is the entire text returned to the client (which includes weight) we should be ok. Good catch

    Sounds right to me. TY

    Anyways, I made this code change so it detects the size of the packet. This way it works either way... If its size is 10, I have an item id, otherwise I don't. This works well with with the switch on or off. Just my approach if anyone was looking for an idea how The changes seem to work great, ty radu DB Done properly, bots may no longer need to be looking at the items at all or parse their text descriptions, because they will have the full ID for unique items. I've got what should be a full list of ID's. Once I get the go ahead from Entropy, I'm willing to share that information with everyone. Yes, but what about when a new item shows up? Or a text change to a current item? If the change happens "before" the list is available (which is how it has to happen, it seems...) then there would still need to be a way to ask the server, right? My list is made from the server definition files by an script, so any delay would be fairly short. So, just to clarify for everyone, after this change we should stop using the "INVENTORY_ITEM_TEXT and STORAGE_TEXT" protocols? Can I assume the list will be on some web page some where so we can check it in an automated fashion?

    Done properly, bots may no longer need to be looking at the items at all or parse their text descriptions, because they will have the full ID for unique items. I've got what should be a full list of ID's. Once I get the go ahead from Entropy, I'm willing to share that information with everyone. Yes, but what about when a new item shows up? Or a text change to a current item? If the change happens "before" the list is available (which is how it has to happen, it seems...) then there would still need to be a way to ask the server, right?