Re: AW: AW: AW: [Arianne-devel] ObjectID

[Erik K. <kru...@uq...>]

> Eh? What do you mean? Your way of doing it would be promoting the fast
> clickers. If people can eat at 0 time, whoever clicks faster eats
> faster. If its time based like I want it to, you click but got to wait
> til its eaten, so another player who didnt click faster can still click
> in that time.

There's no priority queue. So if you click to eat, presumably any
standing "attack monster until dead or I tell you otherwise" command
gets stopped and has to be restarted with a click.

I can understand the confusion between us if your view is that every
sword stroke requires a separate click (i.e. actions are atomic and
nonpreemptible).  This view is reasonable until you're ready to add
rudimentary task scheduling (which nobody is up to at this point, I
guess).

------------------------------
As to the other points, please don't add float coordinates.
Especially, don't just add float x, y; to objects :-)

The right way (someday) is to attach arbitrarily typed property
maps.  This buys you a lot more than just float coordinates.
(arbitrary graph iteration algorithms, graph iterators "for free",
ability to change the underlying implementation of the generic
graph view of a Zone without too much trouble...)
And it can be done using existing, working C++ headers that have
been carefully crafted and peer reviewed (I like when lazy==better)

This would be a fun task I could do, but I agree that this sort of
stuff should wait until *after* a real game is running and we have
an idea of response/users for the KISS code there is now.  Then
any proposed optimizations get compared to this "standard baseline"
version of server and client code, and this *only* after running
a profiling version of the server under moderate loads.