DogBreath

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?

Was working on the changes and wondered if changes were going to be made to INVENTORY_ITEM_TEXT, STORAGE_TEXT (and possible LOOK_AT...) This way it'd be much easier to macth up the responses. As it is, there's really no way to know except to assume that you're getting them back in the order you asked for them. Either way, this is a great change, thanks

Just finished restoring my development machine after a nasty virus/windows reinstall... I'll try to get on this ASAP, ty for the advanced notice DB

Hi all, In the spirt of the game (community supported/free) we're now offering free bot hosting service to whomever wants it. We have simple rules to follow (we won't put up with BS.) Here's the URL if you're interested: http://forum.embril.net The code is an enhanced version of artem's bot code, with many fixes/enhancements. Read the forums, register if you want to The public page for the bots currently hosted is: http://dogpound.embril.net/ backup is: http://dogpound.dragoncairn.net/ You must follow all game rules concerning bots before even considering this service. http://www.eternal-lands.com/forum/index.php?showtopic=13063 Which means: you have to have a paid bot before you need anyone to host it for you... Also, the code is available on request for those who want to host themselves. For more information, see the URLs listed above.

Yes, unfortunately there's a 140 total character limit. Thanks for the feedback DB

I was just thinking about how many times I've heard a newbie say "my nexus won't go up" or whatever. Why not have the tutorial npc fill their food up when it heals them? I realize getting food is easy, and at some point they'll want/need to get their own, but for just starting out, why not? Seems like that'd make things 'more friendly' for newbies, and isn't that what we're after?

It might even help the game, if those, who are on IP won't talk too much bullshit to the newbies, but help them instead. Things like "STFU", "This game sux", "go and find a guy named Radu and ask him for free stuff" is not really helpful. Its the decision of the community, of course, if we want more players in game or not. But if someone, who is new to this game, hears only noob talk and no one is really willing to help them, they might *NOT* play and just leave and one day the few remaining players will all sit around the camp fire and call eachothers noobZ. Or talk about the ancient times, when we really had 100 players in game for the first time. That reminds me, that Tumaros still owes me a beer from the 100 players in game party.... Piper Is this something people should be reported (#abuse) for doing? I try to help newbies out and spend some time in IP. I have never seen this type of behavior myself, or I'd report it... I have to agree, if someone doesn't have nice things to say, or nice ways to try and help newbies, they should probably find some place else to hang out

5 11 ms 16 ms 8 ms ge-3-1-0.rlghncpop-rtr1.southeast.rr.com [24.93. 64.178] 6 22 ms 16 ms 16 ms ae-3-0.cr0.dca10.tbone.rr.com [66.109.6.80] 7 44 ms 47 ms 49 ms ae-0-0.cr0.dca20.tbone.rr.com [66.109.6.31] 8 22 ms 22 ms 21 ms ae-3-0.cr0.nyc30.tbone.rr.com [66.109.6.29] 9 * 44 ms 22 ms ae-1-0.pr0.nyc20.tbone.rr.com [66.109.6.163] 10 64 ms 160 ms 118 ms paix.swad.nyc.as8218.eu [198.32.118.95] 11 102 ms 102 ms 104 ms xe1-1-0.tcr1.thn.lon.as8218.eu [83.167.56.144] 12 * * * Request timed out. 13 * 108 ms 113 ms ge1-0-23.esr1.rb.par.as8218.eu [83.167.56.183] 14 110 ms 108 ms 108 ms 213.152.3.5.static.not.updated.as8218.eu [213.15 2.3.5]

http://www.eternal-lands.com/forum/index.p...c=39317&hl=

I've heard from time to time about "people abusing the test server." Is there some place people can look to see what is ok, and what's not, on the test server? I get the feeling people don't really know one way or the other, so maybe there should be a rules page some where for it? If there is one already, I couldn't find it on search although searching for "rules" or "test" or "server" end up with quite a few results but put all three together and I get nothing (I may not be a pr0 at searching...) DB

This is exactly why I mentioned it I'd hate to see people get in trouble, or upset radu, because they didn't understand what the test server is REALLY for. Thanks for clarifying this, Learner. (AFAIK, bot and client coding/testing are aslo acceptable uses, assuming you're not messing up the server and entropy has no issues with what you're coding/testing.) DB

I was working on some bot code and realized that it'd be neat if instead of having to ask for the invasion monsters left if the server would send the number as a protocol/message when it changes. This way the client could have a field on the screen some where it displays the number and changes when it gets the message from the server. I guess on login it could get the message too, so it initializes correctly. Seems like it'd be a fairly straight forward addition to the client. Not to mention that information gathering bots, like gossip, could use this protocol to provide invasion information.

Works for me

Honeslty, I've never seen so many people resistant to change. The #il command was blasted when it was first suggested. Then, god forbid, someone suggested putting it in the 'login' and it was deemed as spam (even though now that it's in the CVS everyone's ok with it.) Why would anyone ever want this? Because it'd be nice to have... Why have to ask gossip if it can be on my screen? And, as stated over and over, people would want this to be optional, so if you dislike it so much, turn it off. Yes, the game is base on randomness, but not every part of it, and certainly not invasions. If they're so random, why are they announced before hand and why is a point made to direct people to the invasions? This isn't stopping you from playing the game the way you want, if you want to role-play, or pretend you haven't a clue if an invasion is happening or not, that's up to you.

Come to think of it, why couldn't this piggy back on an existing protocol? Say, new_minute, for example.

He would definately want to only send it on a timed basis, not after every kill (as I implied), to avoid the load. Yes, making a bot that polls this isn't an issue. That's really what landed me here in the first place. I've already written this into a 'group' bot and am displaying it on the bot's screen. It was just the next logical step to me, if the bot can see it on the screen, why not the client? Of course you wouldn't want every client polling the server for this (which is really what you have now, maybe not every client, but it can be quite a few I'm guessing...) As far as not seeing it, or seeing it, options ftw.

I suppose how it's implemented doesn't reall matter, as long as it works. I would caution against the idea of "we better get it done fast". A wise advertising firm once said: "Pay me now, or pay me later!" I'd rather see it take a bit longer, and do it right, than rush to a quick and dirty solution, but then that's just me. Whatever change is made, please just give some lead time (I know, I asked before, but it's important) so that we can at least make sure we test this before going live.

Maybe we should split this into two topics, one to discuss either message? @bluap: can't all of what you're suggesting be accomplished by simply adding the item ID to the current protocols as discussed? It also seems you basically just made the new protocols be the old ones with item id, so what's the difference? (unless you're thinking backwards compatability... then I guess I get it, but still seems to be a lot of duplication...) I guess it's a coin toss, add three new ones or change what we have to work the way we need/want them to. @Alberich: your suggestion just makes me dizzy In my experience, building intelligence into IDs (image or otherwise) is probably not a good idea, for a number of reasons... What if one needs to change to a different image, which often happens, seems like this would require recoding/recompiling every time? What happens when you exceed the number of bytes based on your formula? Why should we need to do math to derive two numbers from one number when we could just get the two numbers? Why make unique image ids when they're not unique (and you can accomplish uniqueness by looking at the item id)? I'd have to say that this seems like less work in the short run, but way too many pitfalls and extra work in the future. Also, I think bluap left things out because they're already covered in existing protocols (which wouldn't require changing by his suggestion...) I would, lol Someone has to rewrite/change them Why is this radical? It makes pretty good sense to me. Yes, I was referring to something that wasn't in inventory or storage (hence no position ID to send when asking.) This is only for caching, of course. If I know the itemd ID (however I know it...) then why not a protocol to tell me the rest of the info based on that ID? I'm just thinking bots here, and them wanting stuff that they'ver never actually seen and I can't say I've thought this through totally, so maybe it isn't needed, as you're stating... Yeah, that's what I was thinking, but maybe I've overcooked the thought?

Bots "currently" use image IDs to display the correct image on web pages. Agreed, the bots will break. Surely we'll have a little lead time so we can change/test this before it goes live. (I know, I know, don't call you s(h)urely.) Agreed Agreed, it would be preferred if this stayed 'constant' for the life of the item. Something I didn't notice (it's probably obvious to everyone else and that's why) is that there seems to be a need to be an additional protocol. For caching purposes there'd need to be a "GET_ITEM_NAME" which doesn't require a position, but an item id. Otherwise, there'd be no way to cache names for items not in character/bot's inventory/storage. Or, LOOK_AT_* could be changed to use item id instead of position. On a side note, the client is already kind of a ram/cpu hog, will caching items make it even worse? ... should probably be considered when trying to implement this.

Yeah, it might not fix it totally, but if it makes it more difficult for the farmer, and yet eases the pain for the regular player, isn't that a good thing?

Personally, I think tying it to harvest exp level doesn't solve anything, it just means if a person is persistant enough with their 'gold farmer' that when they get it to a high enough level, then they have an uber gold farmer (a step in the wrong direction, imo.) This also doesn't help the experienceless newbie, which would concern me more when talking about these mini-events. I hate to throw a curve at your suggestion, but here's my what bubbled up for me... Why not just let 'experience' harvests be mini-event free? There's already an event on the server side that indicates max harvest experience for that hour, why can't that be the on/off switch for mini-events? This way people can get their harvesting experience fairly painlessly. Then, the mini-events could be turned up (yes I said up) for the 'farmers' to make it even more difficult to harvest unless it's for experience.... If anything, there should be 'more' mini-events per harvest level, not less as the reward is far greater as your harvest level grows. This would also reduce the number of newbie complaints about harvesting, I think. (The extreme end of this suggestion would be to just limit harvests to 120 per hour and let that be that... Consider this before going 'gah'. It would have some pretty interesting effects on the economy/resources and would make you have work pretty darned hard to get the stuff you needed. It would also make the prices of resources jump through the roof as they would be limited (kinda like piper suggested.)) My 2gc DB