DogBreath
-
Content count
489 -
Joined
-
Last visited
Posts posted by DogBreath
-
-
If I try to put .net 4.0 on my machine it says a higher version already exists...
-
C:\Users\Josista\OneDrive\Desktop\BotCode\CS-ELBot\CS-ELBot>msbuild cs-elbot.csproj
Microsoft (R) Build Engine version 16.10.1 for Mono
Copyright (C) Microsoft Corporation. All rights reserved.Build started 8/15/2023 5:21:23 AM.
Project "C:\Users\Josista\OneDrive\Desktop\BotCode\CS-ELBot\CS-ELBot\cs-elbot.csproj" on node 1 (default targets).
C:\Program Files\Mono\lib\mono\msbuild\15.0\bin\Microsoft.Common.CurrentVersion.targets(1232,5): error MSB3644: The ref
erence assemblies for .NETFramework,Version=v4.0 were not found. To resolve this, install the Developer Pack (SDK/Targe
ting Pack) for this framework version or retarget your application. You can download .NET Framework Developer Packs at
https://aka.ms/msbuild/developerpacks [C:\Users\Josista\OneDrive\Desktop\BotCode\CS-ELBot\CS-ELBot\cs-elbot.csproj]
Done Building Project "C:\Users\Josista\OneDrive\Desktop\BotCode\CS-ELBot\CS-ELBot\cs-elbot.csproj" (default targets) -
- FAILED.
Build FAILED."C:\Users\Josista\OneDrive\Desktop\BotCode\CS-ELBot\CS-ELBot\cs-elbot.csproj" (default target) (1) ->
(GetReferenceAssemblyPaths target) ->
C:\Program Files\Mono\lib\mono\msbuild\15.0\bin\Microsoft.Common.CurrentVersion.targets(1232,5): error MSB3644: The r
eference assemblies for .NETFramework,Version=v4.0 were not found. To resolve this, install the Developer Pack (SDK/Tar
geting Pack) for this framework version or retarget your application. You can download .NET Framework Developer Packs a
t https://aka.ms/msbuild/developerpacks [C:\Users\Josista\OneDrive\Desktop\BotCode\CS-ELBot\CS-ELBot\cs-elbot.csproj]0 Warning(s)
1 Error(s)Time Elapsed 00:00:02.07
I get a similar error trying to compile the game client. As I stated. Not really sure how much more information I can provide.
-
PM from Duck: [Hello, I am a C# bot by DogBreath. ]
[PM from Duck: [Version: 2011.2.17.7 ]
[PM from Duck: [--------------------------------------------------]
Was talking about this bot code, to be specific. Or, an example of compiling the actual game client would suffice as it's raising the same issues.Thanks for the reply,
DB
-
Can someone please make a step by step on how to compile the bot code please? It's been so long since it's been compiled that I'm having issues with Visual Studio 4.0 errors...
Thanks in advance,
DB
P.S. I'm interested in both IX and windows compilations
-
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...)
-
I did a trade with a bot since changes but before I read this thread. When bot did not give me my change I took money out and put in exact amount. Good to know there is a way to find out what is going to pay me or return but still makes me nervous that I will not see amount owed/given to me in window. If a bot calculates wrong or I entered wrong code and object looks identical (i.e. indicators) then it is possible that a mistake can be made.
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.
-
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
-
I'm working on guard-bot code so trading is not applicable.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
-
It appears that the bot gets a HERE_... with a count of zero so the test can't be done. That means that GET_NEW_INVENTORY_ITEM won't know the format.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
-
GET_TRADE_EXIT is sent twice if the trade failed because of insufficient slots or is this intentionally for some reason?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; } -
Since it's end January, could we please get an eta for the protocol change on main?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
-
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?
-
I'm pretty sure the 'Rock Problem' pre-dates the 'Bot Problem' although for me personally all the bots there in their current locations hasn't seemed to be any inconvenience to me. In fact I find it handy as I play the pricing game with more distant bots a lot. Location, location, locationYeah, 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
-
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
-
So.......is this an SDL bug that some of us get to put up with then?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
-
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
-
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
-
once you issue a #item_uid, is it supposed to stay set after logging off?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...)
-
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
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
-
I'm leaving ImageID in to help webservers and old bots that can't handle item ID's yet.ItemID | ImageID | EMU | ItemName
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
-
I'm leaving ImageID in to help webservers and old bots that can't handle item ID's yet.ItemID | ImageID | EMU | ItemName
This looks great, thanks
-
Well actually emu is important for bots.Learner could you please add it to the list, while the image ID is not really needed it comes in same packet as the ID anyway.
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
-
probably itemID, imageID, Name are the minimum pieces of information bot owners would want.Sounds right to me.
TY
Step by Step how to
in Bots
Posted · Report reply
I did. Unfortunately it's still giving the same error. I'm now trying to install ix on a new partition and trying to compile it from that direction. As I understand it there's a converter that will produce a window's exe from the ix build.