1  |   Order by index

Oct 20, 2003, 7:58pm

It would be useful if click events in the SDK returned more info
about which polygons of the object were clicked on.

Oct 20, 2003, 8:00pm

[View Quote] That would be nice, but how would you want it to work? :)

--
--Bowen--
http://bowen.homelinux.com
I know you want to join my army.

Oct 20, 2003, 8:55pm

Reliably would be nice :-)

I would want it to reflect what 'tag' value the polygon that you actually
clicked on had in the original object.

Both objects and avatars can initiate click events in the SDK. In the
context
of an avatar click, knowing the tag value tells you which of the avatars
limbs
was clicked, and this information is not currently available. That is the
main
purpose of my wish.

In the context of other objects, a lot more information is returned already,
but being able to create an object that had it's "ON" switch polygons tagged
with a number (123 for arguments sake) and it's "OFF" switch polygons
tagged with a different number (i.e. 321) would allow for easy construction
of a lot of useful things that a bot could sense. If there were enough tags,
you could make a working keyboard model as a single object, and have
a bot sense your typing.

Some of the tags are already in use, and that's OK. Knowing someone
clicked in the active picture part of a picture object, or on the text part
of a sign object would be good enough for most purposes, and as
mentioned above the avatars are already tagged according to which
limb.

[View Quote]

Oct 20, 2003, 9:11pm

What'd be nice is if it returned the X Y and Z values of where you clicked
(I mean X Y and Z of the object.. not of its position). Then you could make
mini keypads etc.

~John

[View Quote]

Oct 20, 2003, 9:55pm

[View Quote] > What'd be nice is if it returned the X Y and Z values of where you clicked
> (I mean X Y and Z of the object.. not of its position). Then you could make
> mini keypads etc.

That would be hot.

--
--Bowen--
http://bowen.homelinux.com
I know you want to join my army.

Oct 20, 2003, 10:43pm

That would make dart games possible too, as well as many other things. In
paintball games, if you wanted to be more realistic, and a user shot a wall,
then it could add a paint thing to that spot where clicked, same with bullet
holes, etc.

[View Quote]

Oct 20, 2003, 11:55pm

When you click on something, they have done a whack of math to figure out
that you clicked on a polygon, and they know which one it was. They would
have to do more math to turn it into an XYZ coordinate in object space for
you and you would have to turn around in your bot program and do some kind
of math to figure out if that XYZ coordinate on that specific object means
something.

What would an XYZ coordinate on an avatar that may be performing a gesture
mean anyway if you did not also know which 'limb' (in other words the
polygon
tag) was being clicked?

If they return a polygon tag, then anyone can make an object that has on/off
switches, or numeric keypad keys, or any number of other useful functions
without anyones bot having to know anything about the object the person
clicked on other than that it had an on off switch or a numeric keypad
insert
key on it somewhere.

You can make SDK bots that can tell when you click on an avatars head or
limbs and it would work on any avatar without the bot having to know a thing
about the avatar other than it has a head, or a right arm.

It is definitely useful to know the XYZ of the object being clicked on, but
since they already know which polygon you clicked on, and in all likelihood
if it has a tag or not, why not return that info?

[View Quote]

Oct 21, 2003, 1:58pm

[View Quote] <snip>

> It is definitely useful to know the XYZ of the object being clicked on, but
> since they already know which polygon you clicked on, and in all likelihood
> if it has a tag or not, why not return that info?
>

Most likely to conserve bandwidth. There is already too much info sent on a click event :(

--
Andras
"It's MY computer" (tm Steve Gibson)

Oct 21, 2003, 2:30pm

Hmmm...

Is it possible that the amount of bandwidth needed for a bot to enumerate
all of the objects in the world so that a click has any meaning swamps the
actual click events that get sent around? I'm not seeing millions of click
events. They only get generated when a user actually clicks, so compared
to all the traffic for basic moving around, it seems pretty low on the list
of
high bandwidth consuming events.

I also suggested allowing polygons to be tagged so they don't generate
clicks, which would allow you to drastically cut down on the number of
click events that don't mean anything if you were inclined to use it.

Basically, if the events had a little more info, a bot would not have to
enumerate all of the objects in the world or know anything about what
(or where) they were in order to do useful things.

A polygon tag is just one extra number in the packet. Compared
to the latencies and overhead of sending the packet, one more number
isn't going to make that big a difference.

[View Quote]

Oct 21, 2003, 2:37pm

I forgot to mention that the ability to make a single object that could
have three or four different functions would save some bandwidth
over downloading four seperate objects so you could assign a single
function to each one.

A single object 101 key keyboard versus 101 single keys each with
a different letter mapped to it...

Oct 21, 2003, 5:21pm

[View Quote] > I forgot to mention that the ability to make a single object that could
> have three or four different functions would save some bandwidth
> over downloading four seperate objects so you could assign a single
> function to each one.
>
> A single object 101 key keyboard versus 101 single keys each with
> a different letter mapped to it...
>
>

I see a flaw in your justification: The enumeration is a one time only event but the click could be very heavy. I know it from experience (several, actually) that my bot can receive around a millions of click in a two days time frame, which is significant.
What is really missing from the SDK that you can't tell the world server what info do you need at a particular event. I understand your point and can imagine a good use of it but it could ruin an absolutely different kind of bot which needs only the plain old info about the click.

--
Andras
"It's MY computer" (tm Steve Gibson)

Oct 21, 2003, 5:42pm

How about a new event then that only fires for objects you specifically
ask for it on.

They only send for objects with a name= on them or along the lines of
that in my other post. 'create botevent send="keyboard_1"'. Default it
to not send a bot event.

I grant you that some worlds would have heavy click traffic. I'm surprised
it's that high in some worlds, but I believe it could be for a global mode
bot in a very big world.

Your suggestion of an event mask or something so you could ask for only
what you're interested in would help a lot.

Any mechanism that could provide better info on specifically what it was
you clicked on would be a great help for doing complex bots using a simple
app.

[View Quote]

Oct 22, 2003, 4:33pm

Would take up royal s**tloads of processing power server side checking each
time, or changing db's depending on sets etc...

But Andras' idea is great... why not allow a bit mask for the attributes to
recieve...
8 bytes should sort it?

- Mark

[View Quote]

Oct 22, 2003, 6:14pm

[View Quote] > Would take up royal s**tloads of processing power server side checking each
> time, or changing db's depending on sets etc...
>

All triggers/messages relating to the click (and some others) are initiated by the browser, not by the server, so the workload is on the browser side from the person actually did the click.
I don't see THAT one as a server overload but I see some programmers who would overload the system without any merit. (No - it is not you, Mark:)

--
Andras
"It's MY computer" (tm Steve Gibson)

Oct 22, 2003, 6:23pm

[View Quote] LoL... ;)

--
--Bowen--
http://bowen.homelinux.com
Give me ideas.

Oct 22, 2003, 7:09pm

I don't think the server is deciding when my browser clicked on
something.

I think it's my browser doing that.

When I click on an avatar that is playing a .seq, the clicks only happen
when they are actually *on* the avatar. If I click on a hollow part of an
avatar, it does not generate an event.

If I use an avatar and a .seq that are only on my local hard drive and are
not even on my OP, I still get reliable click events when I click on avatars
or objects.

The whole point of my request was that the browser generating the event
is about the only thing that could provide any additional information
easily.
In order for a bot to decide what a click meant, it has to have an inventory
of all the objects in the world.

To really do a proper job, it even needs to take into account differences
between it's inventory at the time it receives the event, and it's inventory
at the time the event was generated, and what's worse.. the bots idea of
the worlds inventory and the person who is doing the clickings idea of
the inventory may not have even matched at that time.

The only piece of software that can really tell anything about click
events is the browser of the person who is doing the clicking. A bot
can't even really do it *in theory* although in practice it can just assume
it's inventory matched the person who clicked's view of the world, and
be right about it 99.99999 % of the time.

Andras's idea is definitely good, and I would happily use an event mask
filter mechanism if it meant I could get the extra info I was looking for.
Even just to get object names would simplify a more event triggered
approach to bots. Polygon tag numbers would make me ecstatic (being
a lazy programmer things that save time make me very happy).

But as Andras says later, such a mechanism might end up causing
it's own problems. It would probably work well if you set it once
at the start and left it alone, but if you tried to constantly change your
event filter, you would need to send out messages to all browsers
every time you changed it so they would know what to send you,
and you'd have to worry about when they got your filter message
and deal with some browsers sending you the extra info even
after you think you told everyone not to.

In the end, it's probably best that if something like this is done,
the info is just sent all the time, or it is done using a new mechanism
wherein you tell specific objects to send a detailed event report
using a new SDK event type and a new 'create' command. That
would likely be the best route anyway, since of all the objects in a
world there are likely only going to be a handful that have detailed
working functionality. Most objects will just be 'background' and
you probably don't even want to get a click for those.

[View Quote]

Oct 22, 2003, 7:25pm

There is the single biggest problem you face...


[View Quote]

Oct 22, 2003, 7:25pm

[View Quote] <snip>


> But as Andras says later, such a mechanism might end up causing
> it's own problems. It would probably work well if you set it once
> at the start and left it alone, but if you tried to constantly change your
> event filter, you would need to send out messages to all browsers
> every time you changed it so they would know what to send you,
> and you'd have to worry about when they got your filter message
> and deal with some browsers sending you the extra info even
> after you think you told everyone not to.

I guess - this mask should stay within the server but the browser has to send ALL relevant info about the click to the server. With this method, the net traffic can be minimized - only those info relayed to bots which is relevant to them. The click from the browser won't bring the net to it's knees :)
The more we discuss it the more I like your idea !

--
Andras
"It's MY computer" (tm Steve Gibson)

1  |   Order by index