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.

*sigh*. No that is exactly what you are trying to avoid doing in the first place. To simplify, what you end up doing is a addition of the difficulty factor for each tile in an anti aliased line and offsetting that with other characteristics such as light, weapon, skill etc.. Pulling rabbits from hats is most assuredly not required. The map format is such that you are probably correct. Objects seemed stored in unordered lists and are not directly relatable from a given tile location which I guess is the key point here. Doing this lookup each iteration could well be expensive. If it is then this should be addressed and then there are ways of getting around it - see below. The system proposed by both of us may still produce obscure artefacts when faced with a series of complex objects. This will occur with any approach (that is not super super complicated) especially when we have to take into account the basic assumptions that we already are. Bare in mind though that this is an MMORPG, people expect to be able to do epic stuff at high levels and this is what makes things memorable. Besides, everything will happen in the blink of an eye anyway. It's not as if they will be following the algorithm to the n'th degree. In fact it will be so fast they won't be able to. The basis of what we've been talking about is utilising a difficulty value for a particular tile on a specific map. This will be achieved through using an already calculated difficulty matrix. This way you do not have to do the expensive 3d object lookup for each tile and you also avoid doing the intersection algorithm. Leaving you with one main algorithm to contend with; generating the anti-aliased line and adding up the specific difficulty values, then applying other modifiers I.e. no complex lookups and no additional complex calculations. This two dimensional difficulty matrix could be produced in a number of ways. 1. Real time Good: No changes to the map format, or no additional files required. Bad: Like you say with the map format as it stands the object lookup for a particular tile is probably expensive. 2. Pre-calculated by server at start-up Bad: Ties up the server at start-up working through task. Limits what choices could be made for the difficulty algorithm due to start-up time constraints. Good: If a very simple algorithm is being used, it removes the need for an offline tool or maybe updates to the map format. 3. Pre-calculated off-line Good: Could use any number of approaches to generate the difficulty map, e.g. predefined/ set difficulty rates to each object, or even ray tracing from each square to each adjacent square. It doesn't matter if it takes five minutes or an hour to do the calculation for each map. Its done offline and only needs re-doing when the map is updated. What comes out will always be a very simple two dimensional array. Bad: Have to write an off-line tool or update the map generator to do this for you.

With trees, bushes and probably quite a few of the other objects as well this will be more likely than you think, especially factoring in the possible difference in heights between the source and target and the different orientation of the objects themselves. Hey calm down I'm the one who’s trying to avoid using a complex algorithm here! There were a couple listed earlier in this thread that imo would do the job equally well and as a bonus should be much simpler to implement and cheaper on the cpu time. I am specifically thinking of the ones where you draw an anti aliased line between the source and target square and each intervening object has a specific opacity/ possibility of getting through value (and maybe even an obejects max height?). Then factor in values such as distance for each object, skill, weapon type, ambient light etc. The result determines a hit or miss and is factoring in the environment through which your firing giving a pretty good difficulty metric. Additionally if your using a cumulative value for each intervening object encountered you could even determine that when you reach a certain value this is where the arrow lands (ie its a miss) and optionally tell the client to put an arrow there (for prettiness or wow factor). I think its been explained pretty well earlier in the thread without me reiterating it again. However if you wanted I’m sure I could come up with a slightly more concrete plan. Just remember, there are valid applications for using a ray tracing algorithm and if another algorithm was chosen for this specific task then it in no way undermines the good work that has already been done, and the validity of including both sets of functionality within the server.

Bows, crossbows, slings, javelins are all ballistic weapons. It just so happens that at the ranges we are talking about they will have a notionally zero level trajectory and can be treated as such in the math. I used ballistic weapons as a term, not as an intention to shoot in arc'ed trajectories. As cool as that would be, like you say it just wouldn't have meaning for these ranges. I should have made a point of saying that I did not intend the calculations to be factored into the server side computation, but was actually addressing some concerns raised earlier about how it would look on the client (I did say "on an unrelated note" but should have made it more clear). You are correct for a server side calculation this should be treated as instantaneous. I have worked in an environment were proper balistic prediction calculations had to be made and it gets madly complicated very quickly! Agreed that bad bows and bad light should affect the final outcome. However you seem to be implying that the small opening is directly in line of the "best case" or the "displacement" ray, which will be statistically unlikely. I'm guessing seen as the best case ray is fixed, for simplicity it would probably have to be set from the central middle point of the source and target. It is therefore not the actual "best case" but in fact an arbitrary case which may or may not be valid and does not really take the environment into consideration. Consider, if you have a small opening on an object or a small route somewhere between source and target then you will need a great deal more rays heading out from the best case in order to "detect" where it actually is, if indeed it does exist. Lets put this in the context of the second stick man drawing. The best case A->B for a good and bad shooter is a fail. The actual ray with the displacement will also be a miss for the "good" archer, but will succeed for the "bad" archer. Archer Best Case Actual Case Final Result Good FAIL FAIL 0 = FAIL Bad FAIL SUCCESS 0>N<1 (Partial Success?) Of course we could say if the best case fails then don't bother with the actual case. But this misses the point of using such an expensive algorithm in the first place. Its aim is to work out if something is really possible in 3d space and to get the best possible to answer to the problem. If that has to be dumbed down to such an extent in order for it to work in this environment, why not use something much simpler (and therefore cheaper in processing terms) that is going to give equally valid answers to start with? I have to admit that I just read your blog entry on this topic and I can see the reasoning and logic behind having a ray tracing algorithm in the server - for certain tasks. But, as cool as it is it doesn't necessarily make it applicable to all tasks. I'm still not convinced that you will only use two rays per arrow to get the system to work with the approach you are talking about. If you do need a more rays to do what you want to do this figure scales down quite rapidly.

Lets break this down: I assume what are you saying is that when you shoot from A->B, you will apply a random offset to the destination point? For example if you go from A->B+d, where d is a (Gaussian) random offset, determined by the parameter set (distance, skill, visibility, arrow, bow). However what d does not depend on, is the degree of clutter on the path, which would give the difficulty we would want to model. Meaning that a hit is possible (or guaranteed?) if there is an open path A->B+d. The most obvious flaw in this model is that it does not allow skill to overcome path difficulty. Referring back to the diagram I drew earlier, this approach would still not solve the difficulty problem in hand. Consider also a situation where the path for the exact line A->B+0 is blocked, but A->B+d (where d!=0) is open; as skill increases, d->0, so a shot which may be made by an unskilled character (blue arc) is not possible for a highly skilled one (red arc). (Apologies for the stick men drawings. I am graphically challenged, but it seemed to be the best way of explaining things without the aid of whiteboard) Is this related to the ambient light level or the quantity of clutter between the source and the target? If its light level then this can be grouped with the items listed next. If its clutter then that its a different problem altogether. All valid modifiers that could/should be included in the final calculation, but unfortunately they are not the actual base difficulty of the intended shot. I think ballistic weapons will be a great addition to the game, and could really change the whole makeup of combat and teamwork. But if some of those algorithm performance figures listed earlier in the thread hold true, you will have a set hard limit on how many players can fire a bow before the server suffers some serious performance issues. And all this before we know exactly how players will react to this exciting new feature. I really do know where you are coming from though. Working in this industry for a long time it is always tempting to use an algorithm because its cool, new and interesting to write. At the end of the day though you have to look at it with your head rather than your heart. If we are taking the view that the calculation should be achieved though rough approximations using only the above factors then there really is no need to go with such a complex and expensive ray tracing approach. We end up cracking a walnut with the proverbial sledge hammer. On an slightly unrelated note, there is good site on the physics of bows here Looking at some of the values this gives: 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 Based on this it would be *meaningful* to animate a few frames for the arrow, but it would have to look like an indescrete blur. There is really no point in getting fussed over whether it appears to go through a tree with that level of approximation.

The problem with the ray tracing approach is that it is only ever going to give you an absolute 'yes' or 'no' answer to whether you can hit an object or not. How do you plan on refining this to give a measure of difficulty? The only way I can see it working is to apply an order of magnitude more processing power to the ray tracing algorithm, or use an additional statistical approach such as those shown earlier in the thread. If you are going for the former then there is a reason that fps style games are limited to 10's of players rather than 100's. And if we end up adding constraints and compromises in order to get the ray tracing approach to work at a sensible speed, then does this mean that we could have just as validly used a statistical approach right from the beginning? If you want to get something up and running really quickly then why don't you define a basic api which takes the two actors and returns the difficulty. In the short term this just looks at the tiles between the two actors and computes the difficulty. Et voila missile support in short order and running in the test server for people to try out. Having the standard api also means this could be ripped out and replaced whole by the much more complicated ray tracing approach at a later date. The reason I am bringing this up is that I have been responsible for coding on very large mission critical military and civilian real time systems for many years and learnt very early on that its worth spending time working a problem right the way through at the start because bad choices there cost serious time (and money) later on.

Basic missile support for a first person shooter (fps) and basic missile support an MMORPG are fundamentally different things. For example, in a FPS the "difficulty" concept is down to the mouse control and reactions of the RL player and what we really need to know is when they click the mouse button is that specific shot is possible. In an MMORPG such as EL the real driver would be, based on my character's skill how hard would this shot be. The skill of the RL player should have absolutely no bearing on the final result. What I am trying to say (in a roundabout way) is that Basic missile support in an MMORPG IS the difficulty rating of a particular shot.

I've been following this thread for a while and there is something bothering me about this ray approach and that is that in this system there is no concept of "difficulty" for a shot. If there is no concept of difficulty then applying a player skill modifier is near impossible. Take for example the following illustration. Using the ray approach A can see B and B can see A and therefore a shot can take place, but the reality is that B hitting A will be much more difficult that A hitting B. How is it envisaged to take this into account?

Not really a comic per say, but if happen to work in a tech environment Dilbert is very funny.

<name> has recorded a verdict of death by misadventure

I am in RICH and look after Richery. I think the idea of a separate area to discuss bot issues is a good idea. Can you please add me to the list? Many thanks. By the way my in-game name is the same as this forum name.