Schmurk

I think it's a good idea and you can even add a random rotation and a random scale to add more variety.

Just a quick idea: The wanderer - The person who is walking the most during his online time (number of steps / online time)

I've written such an algorithm during my thesis and yes, you should not forget the intersections with the corners which lead in several particular cases. This is why I said earlier that this algorithm is not so trivial. An other version of this algorithm is to search for the intersection point that is the closest to the searched point. Then, when you have this point, if you know the orientation of the polygon, you can deduce the position of the point by checking on which side of the crossed segment/corner is the point. This version can be faster if you cross a lot of corners because you'll have to deal with particular cases only once rather than several times with the original version...

The simple methods I found work for convex and non-convex polygons. I just don't know how the loading compares or how much you can pre-compute during initialisation. Is it the method that computes intersections between the polygon edges and a line? If it's the case, yes it works fine but there are some particular cases to handle which are not that trivial. BTW, if you want to implement such an algorithm, tell me which version you know because I might have a solution to optimize it a bit. I've checked the code again and I'm pretty sure it is OK for both convex and non-convex polygons. The work is done in validate_boundary(). The first stage is to find the maximum and minimum x and y which define the minimum rectangle that can enclose the polygon. This bit does not assume anything about which points to use or the order they are defined. Only if the corners of that rectangle match exactly the points of the polygon is the boundary reduced to two points using the first and third points as the bottom left and top right; a valid thing to do as we know its a rectangle. Ok, I don't remember the validate_boundary() function so at least it uses the good point. However, with the current system, you still can't represent such shapes:

It's an interesting idea but concerning for example creature food we can also see things in a different way. Imagine for example that to make creature food you need a big recipient where you put all the ingreds. Then when the mixture is ready, you put it in several vials. So, if you fail the mixture, then you should lose all the ingreds, no?

I hope this means we do NOT have to redo all the sound areas-if so forget it Of course not. What I'm speaking about is completely transparent from the XML point of view...

Totally agree with you. However, handling non convex polygon might be harder. The bounding box is calculated correctly if we consider that the first and third points always correspond to the bottom left and top right corners but if the region is not defined this way, then it becomes wrong. I don't really understand the need for such a limitation so I think it would be nice to compute the bounding box the usual way and store the result in 4 new variables. With this small change, we could already allow every kind of convex shapes...

I had a quick look at the code that is handling those regions and I've found that the code is more complex than it should be. The related function is sound_bounds_check() in sound.c and all the other functions that are called from this one. From what I've seen, the function works like this: First, it checks if the given point is in the bounding box of the region. However, here it supposes that the first and third points of the region correspond respectively to the bottom left and top right corners of the bounding box. This greatly limits the shape of the regions you can define which is quite bad IMO. Then, if the point is in the bounding box, it checks if only 2 points have been defined for the region and if it is the case, it doesn't go further because it assumes that the 2 points correspond to the corners of the bounding box (see first point). If the region is defined by more than 2 points, it then checks the point against the lines of the region to see if it's inside. Here, it does several tests to decide if it's ok or not and it even computes angles between each adjacent lines of the region to see if the point is in these angles. Well, I've checked the coords you've put in your file Roja and it seems to pass the 2 first tests so I suspect there's a bug in the last tests but it's hard to find where exactly. Anyway, IMHO all the tests are not done properly and I would do them this way: First, if we want to allow pure rectangles to have fast tests, then it has to be coded explicitly in the data structure and in the XML file. Second, the bounding box of the region should not be linked to the corners of the region, it's way too restrictive IMO and may be source of bugs. Third, there are easier ways to test if a point is inside a convex polygon. A simple solution is to give an orientation to the polygon and then compute the Z coordinate of the cross product between the vectors made by each segment and the point. I mean, if a polygon is defined by 3 points A, B, C and we have a point P, then we have to test the sign of the following cross products: AB ^ AP, BC ^ BP, CA ^ CP. There are maybe better solutions out there but this one is at least better and cleaner than the current one. I think we should also allow to handle convex polygons with less or more than 4 points which could add more flexibilty to the definition of these regions. Anyway, I just give my opinion about the code I've seen but I actually don't have time at all to work on it. So if someone else is interested to work on it, then just do it! (I can still give a few tips if needed...)

I know it'd piss some people off, but this sounds like a decent idea imo I've proposed something like that a long time ago and I've even proposed to have a limit depending on related skills. For example someone with a good a/d could store more rostos than someone with a low a/d. Almost everybody was against this idea and some people even said that it was against freedom. The funny thing is that in only a few days similar ideas have came up in this thread. I still think that it would be a really good idea and would solve some problems...

Treating the problem of performance by increasing the speed of the memory allocation is not the way to go. If the memory allocations take too much time, then we have to simply limit them. For the code like the eye candy system that needs a lot of objects, it can be done with object pools that keep the objects in memory and reuse them without destroying/creating them each time. I don't remember how it is done in it though, maybe it already works like that.

I can make you a patch to not display it if you want. I would be interested to see how you're able to flee a bear in RL. Want to try?

Works fine here on Ubuntu 8.04 32 bits.

We've just finished the instance on the main server and I think there was a small bug at the 4th wave because we didn't have any monsters. The counter said that there were 0 monsters left for a few moment after the 3rd wave and then it said that there were 2 monsters left which were the 2 orcs of the end. We also had a lot of resyncs because of monsters that were having too much actions to handle. Out of that, all went pretty well, we lost a few rostos but we had great fun! A big thanks to all my teammates: CaTHuga, Cyberwulf, LightLan, Me_Ow, rauch and WolfWitch.

I'll not be here for Christmas so I'm auctioning my Santa hat. Starting bid: 50Kgc Increments: 2Kgc Buy it now price: 100Kgc Happy bidding! Edit: forgot to say that it'll end on Thursday 18 at 20:00 GMT.

Gratz to all of you! Too bad I was not here tonight to participate to it. When I came online, you already had finished it...

Arf.... I would have preferred to do it on thursday but if I can achieve all I want to do before tonight, I would be interested in joining. However, I would not be here before 9:00-9:30 pm GMT.

Hello all, I've updated my market site a few days ago in order to change some stuff and I had to move all the members data elsewhere. So for the people who are using this service and has put a market preview in their signature, you'll have to update the link to the new image location (this one can be found in your settings). The old data has been kept and will be available until the end of the year. After that, I'll remove it. As usual, if you encounter any problem while using the service, please tell me. Schmurk

The problem is that when you disable the extended camera the camera rotation is brought back to the default angle range so you don't see the horizon anymore and so the number of visible objects is reduced. Then you can enable it again but as long as you don't rotate the camera, it doesn't change anything, you still see as many objects. You can simply try that: when you notice a frame rate decrease while in extended camera mode, rotate the camera in order you see you char from the top and you should see your frame rate increase again. If this doesn't work, then ok, there's a problem. Anyway, maybe I'm misunderstanding what you said so to be sure, please post screenshots of situations where you think there's a problem...

Activating the extended camera allows you to see further so more objects are displayed so more cpu usage, it's normal. However, you can reduce the number of objects displayed by reducing the maximum viewing distance in the options, it'll maybe resolve your problem.

Wow! The orcs and gargs are amazing! Great work Roja! Can't wait to see them ingame with clops, ogres and trolls too...

20Kgc

I think the idea of queuing the emotes until the actor gets in idle state is good. Instead of using a timeout of 1 sec which is generally low for big lags, you can maybe also decide if you have to queue an emote by testing the last action in the queue of the concerned actor. This way, you can see if the actor is fighting, moving or something else... BTW, if only arms are going to move, we can also maybe authorize the emotes when an actor is walking?

17Kgc

18Kgc

I think this corresponds to the pain animation (which is not executed with weaker monsters because fedora was not hit) so it's maybe the pain animation that has a problem...