1  ...  2  3  4  5  6  7  ...  13  |   Order by default

Oct 8, 2003, 2:46pm

A tag that would make selected portions of a model insensitive to the
activate command.

Another tag that would make portions of a model insensitive to the
bump command.

These would be similar the collision off feature, but would still allow
the model to support physical collisions.. it would just not create bump
events or cause activate events for some of it's polygons.

Oct 8, 2003, 2:50pm

A new field associated with the ground object where you can put a command.

Among other things, this would allow you to 'create picture blah update=30'
so that you could embed surfaces with picture tags inside your ground model
and change them dynamically.

Oct 9, 2003, 9:43pm

That presupposes an actual developer program.

[View Quote]

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: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, 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, 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: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, 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 21, 2003, 2:36am

The SDK doesn't seem to allow a bot to set the rotation of a
given terrains texture, although the browser seems to have this
capability.

It would be nice if the SDK could specify a rotation value.

Oct 22, 2003, 12:53am

[View Quote] I was very clever. I posted here and someone was nice enough to tell me
real quick.

You didn't spend days scratching your head over it did you? :-P

Oct 21, 2003, 4:26am

The AW_EVENT_WORLD_INFO event in the current release
build of the SDK seems to report when hidden worlds are stopped,
thus providing a mechanism for anyone who can log a bot into a given
universe to discover the names of any hidden worlds they may have.

This will happen even if the bot is not logged in under the PPW of
the hidden worlds owner, and even if the bot is just logged into the
universe and not into any world at all.

So the hidden worlds aren't really hidden that well.

Of course I wish this were fixed.

Oct 21, 2003, 12:45pm

Nope.. just reporting a bug.

CWLab.. look for it... somewhere. It's not in Spiral Matrix.

[View Quote]

Oct 21, 2003, 7:13pm

Oh geez.. you spammed the NG's with advertising!!

:-)

[View Quote]

Oct 21, 2003, 12:49pm

which of course isn't a problem since you can't tell what part of
your av was clicked anyway.

If you could tell what part of your av was clicked, then not getting
clicks for your own av would prevent implementing say a game
feature where you could selectively spend healing points to heal
different amounts of damage to each limb.

Oct 21, 2003, 3:39pm

If an object has a name, it would be useful to have the name returned as
an attribute of the click event.

i.e. "create name info_booth"
"create name info_booth"
"create name info_booth"
..

would let you put 'info_booth' around and not care which one was being
used. They could even all use a different model as long as they share the
same name.

If you care which one is being used, give it a different name. Then you
have a quick way to identify what object was clicked without having
to enumerate all of the objects in the world.

In conjunction with knowing the polygon tags as per the previous
post, this would allow very simple and powerful object oriented
event systems to be made that would be decoupled from the actual
layout, objects, etc. within a given world.

Using the 101 key keyboard example:

create name terminal1
create name terminal2

on two different instances of the same 101 key keyboard model,
and the bot just has to harvest keystrokes from these two objects
without having to do a full query of all the objects.

Oct 22, 2003, 1:47am

<joke>
How about PASSWORD_TOO_HOT and PASSWORD_TOO_COLD to
go with PASSWORD_TOO_SHORT and PASSWORD_TOO_LONG
so you can really zero in on it quicker
</joke>

Oct 26, 2003, 2:35pm

would be nice.

Heck.. it would be nice for sounds too.

If you're worried about abuse, make the number in minutes :-)

Oct 27, 2003, 12:34am

I was thinking more of .wav sounds that repeat.

A babbling brook for example. You have a .wav that repeats, and it's OK for
a few minutes, but it might be good to change it to a different running
water
..wav that repeats after a while.

Same thing for stuff like traffic sounds, muted conversation in a crowd.
Background sounds that would just be a little more interesting if they
could vary a bit.

Sure you can get a bot to do this, but if you can get the browser to do
it for you cheap so much the better.

[View Quote]

Oct 30, 2003, 6:36pm

When you change something, a new object is added with the changed
properties, and if that is succesful, the old object is deleted.

That is why you can't change stuff once an area is full.

[View Quote]

Oct 30, 2003, 6:39pm

It would be nice to see an indicator showing the object density in
your current cell so you know when you are getting close to the
build limit.

The browser should already pretty much know this.

It could even be fancy and show you the cell limit, the number
of objects in the current cell, and then change color as the actual
objects load off the object path (it would look like it was filling
up)

Anything that would help let you know when it's time to
move on and clutter up another cell.

Oct 31, 2003, 9:23pm

seems like a bit of an oversight.

Oct 31, 2003, 10:34pm

It would be cool if the local path feature allowed for a
'default' search path in addition to the specific per-world
mechanism it uses now.

Currently, you have to manually set up a directory tree that
contains the name of your domain server and any subfolders
you may need in the URL (mangled of course).

Then you need to populate that folder with another copy of
the megapath, or as I mentioned in another post, you can create
a shortcut to the same megapath from multiple places, but you
have to do this manually, and it's a little ugly for the average person
to figure out a pathname after the fact from a cache folder entry
and go set it all up. By then you've already wasted the bandwidth
anyway.

It would be useful if you could tell the feature to *always*
consult a specific folder on your local machine regardless of
the domain you were attempting to access, in addition to doing
what it does now (a per world mapping). This would allow
people to dump a copy of the megapath locally onto their hard
drives, and surf a great many worlds without having to download
a single 'stock' object.

Enabling this feature dramatically reduces bandwidth consumption
even if you just spend a lot of time working in your own world.

People who fiddle with stock objects without changing the names
shouldn't do that anyway :-)

Nov 1, 2003, 11:23am

[View Quote] I don't see how it could be used to automatically supply
all megapath content for all worlds you visit without having
to manually edit the multipath script.

What I describe below is real easy for the non techie to
set up. It would just work out of the box with no extra
stuff to set up other than one copy of the megapath on
a locally accessable drive, and the AW installer or a new
browser feature could make that painless too.

Not only would doing this save a lot of bandwidth, it also
*could* mean that the cache directory you already have
would not need to store those redundant copies of all the
megapath models over and over again in each persons
world.

Assuming this was implemented, the browser could decide
that if it got a local copy of something, it didn't need to
put another version of it in the given worlds cache directory.

If you current cache did not have cached versions of any
of the megapath stuff in any of the directories, how much
filesystem space and bandwidth would you save?

Multiply it by the number of universes you might visit.

Multiply it by the number of visitors to your world.

It could add up.

If I was paying AW's OP path bill... installation of a local
tarball of default objects would be mandatory before
you ever came in the door. By design... it would cut the
monthly bandwidth for all AW megapath driven worlds
by... ummm.. gee.. let's see... carry the four... add the
six... 100%! (assuming they sent you everything and
neglecting the initial download)

If it was done really nicely, they could send you big chunks
as you need them. Go into a 'standard' world, and a dialog
says "Would you like to add the MARS content to your local
hard drive for faster loading?".

If a set of stock objects was mandatory, world owners could
have much smaller FTP spaces with only the models they have
that are unique on them. This could make it cheaper and more
accessable to people to have their own OP path, and they
would certainly be easier to manage without the megapath on
them.

It takes a gnarly server to deal with the entire megapath anyway.
You probably have enough room for it all, but you will probably
hit a limit on the number of files you may have, and Apache
is sorely stressed in dealing with directories that have many
many thousands of files in them as well.

It just seems like something that would make a huge difference,
would not take AW much effort to implement (90% of the
mechanism is already there), and it would save both AW and
all their customers a whack of real money in bandwidth costs.

Plus it would make everyones browsers go much faster.

What's the downside to this one again?

>
[View Quote]

Nov 1, 2003, 6:37pm

A mechanism to change the set of .seq an avatar can play
(i.e. the row of buttons along the top of the panel) depending
on if they are walking, running, flying, swimming etc

Nov 2, 2003, 6:50pm

bump url yoursite.net/event.php?TriggerName=thisobject
target="_yourhiddenframe"

If you don't do PHP, sorry for the false alarm.

[View Quote]

Nov 7, 2003, 12:34pm

Given that for example you need to have a bot to seed if
you somehow wipe out your world (backing up your world
is another example) it would make sense that AW have a
very basic 'official' bot that you can get as a world owner.

Another good reason for that is that some people may not
trust bots made by third parties, especially if they are new
and have not had time to develop a trust in any of the existing
bots.

Seeding an object, and doing a save/restore of your world
are arguably key features without which owning a world is
'incomplete'.

While this can be done using the administration utility, that
utility is overkill for what most people (especially new world
owners) would need. Most of them do not host their own
world, but simply need a friendly way to back up and
restore, and possibly to wipe everything, and then seed a
starter object.

Nov 7, 2003, 2:55pm

Sure.

They might add the source to the 'basic bot' into the SDK as an
example as well.

[View Quote]

Nov 7, 2003, 5:17pm

The 'world admin' utility is an SDK app I think. It just has too much stuff
in it for most new world owners.

I suggested this because getting a new world can be a bit overwhelming.
There are a lot of different 'pieces' you need to all work together. It
would
take most people a while before they got around to locating a bot.

If AW just supplied one, they would be introduced to that stuff right away,
and with a simple bot it would be an easy learning curve.

[View Quote]

1  ...  2  3  4  5  6  7  ...  13  |   Order by default