Lunksnark

One my windows PC running: MB: ASUS P7P55D PRO RAM: Corsair 4GB PC3-12800 Dominator CPU: Intel Core i5 750 VGA: Sapphire Radeon HD 4870 1GB DDR5 I see a fairly massive memory leak with the EL client. Don't know if its caused by EL or the drivers though as I haven't had time to try different things and see what happens. As I'm at work I also cant see which version of the drivers, but I did a clean Windows 7 install not that long ago and I picked up the latest set then. Its strange as you can sit there and watch the memory usage in task manager going up by 250kB-270kB every second or so. Is that the sort of thing you were seeing in Linux?

and me: http://magicfish.mybrute.com

Ok, seen as everyone is using different measurements i thought I would give it a try: Height 1.78 meters or 12.714 linguine or 0.1930 double decker bus's (lengthways) or 0.008848 Furlongs / 1.94663 Yqrds Weight 85 Kg or 425000 Carats or 0.085 Metric Tons or 227.734 Troy Pounds / 227 Troy Pounds and 8.81345 Troy Ounces For more useful measurements see here

I saw this M.C. Escher drawing and it reminded me of just spending a bit longer on getting that next level

Bot name: Richery Owner: Lunksnark TirunCollimdus Any other contacts: Any other RICH member can pass on messages Purpose of this bot: Trade inv wanted loc help Thanks

It may well be higher as there seem to be a lot of factors that need to be taken into account. I found quite a few conflicting sources when I was looking last time. The site I chose gives a pretty good account of the physics involved in medieval archery which is why I used it. It just happened to put it closer to 60m/s. To be honest though, choosing 60 or 80m/s is pretty mute when you looking at the result over the nine meters or so we are talking about. I was merely showing the numbers so that whoever comes to do the animation doesn’t attempt to render the arrow in detail at every step of the path. Incidentally, the site you chose is talking about a modern (circa 1960's) compound bow which is an entirely different beast to the medieval long bow.

A quick note about the animation of the arrow heading to the target. I did some calculations on longbow arrow velocities when the server-side implementation was being discussed here and it showed that the time taken for an arrow to hit a target at the maximum range (for this game) should be about 0.15 seconds. If there is to be an animation of the arrow heading from the source to the target (in addition to the animation of the bow on the player) then realistically it should only be present for a handful of frames and resemble a fairly indiscrete blur. Calculation Detail: Speed of arrow = 60m/s (ish) Time for arrow to travel 1m = 1 / 60 = ~0.0166 seconds Maximum Range of arrow = 9 meters Time to target = 9 * 0.0166 = 0.15 seconds Human perception rate = 25 fps (frames per second) Time for single frame = 1 / 25 = 0.04 seconds # Frames for distance covered by arrow = 0.15 / 0.04 = 3.75 frames

So your saying if you are using someone elses bot code (and its already functional), then you should just throw it away and tinker around with some other open source project? Lets be a little realistic.. Ill be intrigued to see the post about open source'edness if you can dig it out. I did a quick search but nothing obvious popped up. It doesnt help that you cant use the word "bot" in the search due to the number of characters! I cant believe that its true though. There are quite a number of bots out there where the source code is not available. Getting back slightly on topic. I think if you want to do this and run it through a website, the communication should be taken outside of EL. Im not so keen on the "pull" idea of having the site check each bots page everytime it has a connection and instead much prefer the standard "push" idea of ttlanhil.

Seriously bad idea due to the bandwidth being used. I doubt you would earn any friends with that sort of frequency. In the real world this wont happen especially for those owers who dont have access to their bots source code.

This discussion seems to be going back and forth and to be honest I'm kind of losing the plot. However it seems to me that a lot of the replies are focussing on the symptoms of the problem and not the root cause. The underlying issues seem to be: 1. There are more and more bots being added and the percentage of bots to players is getting skewed. 2. Bot spam on the sales channel is becoming and issue 3. Bandwidth issues with bots is becoming common place - especially if everyone gets involved with this new channel idea. Ideas: 1. Cap the number of bots allowed in the game. ie. If we are at 96 paid bots now, then say when we reach 100 there will be no more new submissions allowed. Bots have a yearly fee so if this isn't paid it is removed and the next on list is made active. This figure could be readdressed when the average number of real players increases to a certain point. 2. Moving bots to inside locations or away from highly populated areas. This would remove a fair amount of work from the server, but more than likely would really hack off a number of existing bot owners. 3. Fragment the client server comms. The majority of trade bots do not need to see every single message sent by the server and this could be made a lot more lightweight. Some features could also be made pay per use. ie rather than just paying to have the bot buffed up, additional api's could be purchased, such as ones involving storage. 4. Mandate a higher minimum advertisement time. I, like a number of the other bot owners have voluntarily set it at around 40-45 minutes but I'm guessing from some of the posts here that there are a number who haven't? 5. Make the new channel another yearly pay for service which can be used in addition to channel 3. Not everyone will take up the offer, but those who do will get some additional benefit. I like the fundamental idea idea of this new channel and applaud the idea of making it voluntary, but I can see some real drawbacks in how it would be used. I think ttlanhil and LabRat have a good handle on those issues so wont reiterate here. Caveats: I do run a bot, and I do not specifically advocate any of the ideas listed above, I'm just throwing a few out there.

A somewhat related thread can be found here

Its a shame because the lack of opposable thumbs is going to make them suck at manufacturing and crafting right?

Oops, I just updated my post while you were replying to my original one.. Looks like we got out of sync a little there. No comment

Firing only two rays from one point to the next could just as easily hit any one of the obstructions shown on the diagram as with the simple difficulty methodology. Only if you were are iring many rays from multiple points within the source bounding box to multiple points within the target box could you guarantee to get an actual metric of whether this shot would be possible or not. The difficulty metric in this instance would be a percentage of how many of the the rays could hit the target out of the many that were fired. But as has already been said firing a great many rays for every single shot would be a bad move from a server performance perspective. The simpler difficulty calculation would still return a value, it just might be that that value would be very hard to achieve without some sort of epic level archer. It certainly is an interesting example and one that can be overcome. Id forgotten that the "real" ground level does not necessarily equate to the height map for every single instance and I guess that's the crux of the problem. Your saying there seem to be valid routes "underneath" the existing height map. Well it must be possible to find these cases and put them into a slightly more extended difficulty/ height matrix. I can think of a couple of ways of doing this, but right now its home time for me and I'm going to head off. I will readdress this later this evening or if I don't have time tonight, tomorrow morning. BTW, what was the supposition you made? Wow, thinking about this is so much more fun than doing real work

At the point where you are adding an object to a specific tile you do know its parameters because it will be part of an object tool kit. Keep the algorithm to generate difficulty simple and this issue goes away. As you say if you also maintained some height information for the tiles difficulty you could ignore the wall for range2.jpg. You know the difference between the respective heights of the source and target and could add a simple comparison for the specified tile to this difference. For the tree example if you maintained a height you would still have an obstruction in the way that is true (Trees do tend to be a taller than the possible difference in heights between source and target). Bear in mind though the assumptions we are making just to get to this point. e.g that the source and target players could be anywhere if their respective tiles. Would it not be fair to say that the chance of shooting around a solid trunk and the chance of shooting through a set of tree limbs could be validly classified with the same difficulty? Yes some effort up front will have to be applied to the tool kit of objects already available in the game. This will be a one off hit though and not done in real time. I just thought of another situation based on your drawing above. I dont know if it could ever happen based on the macro scales we are talking about, but consider: Option 1 would be to ignore it. At the distances we are talking about, getting a significant amount of terrain in the way is unlikely, and even if you do could be explained away in RP terms as someone arc'ing the shot slightly. Option 2 would be to deal with it and this could be solved because we would know the height of the ground at that point the the height diff between source and target as discussed before. If the estimated difference for that tile turns out to be below ground level then set the difficulty to the maximum and it becomes an automatic fail.