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

Aug 24, 2003, 1:16pm

Couldn't the desired effect be acheived with one extra command:

event "arbitrary stuff"

It could be used with any trigger, and would send the arbitrary
stuff as an event that could be sensed by bots.

bump event "object 22 was hit"

... would send an SDK event that would 'look like' something like
a chat even from that cits browser so you could tell who bumped
into the thing.

You could also use the new command with the create, activate and
adone triggers as well though, making it a lot more flexible than just
getting an SDK event on bump collisions. If you did all bump
collisions, it would probably be overkill.. you might not want that,
and then you would need a way to turn them on and off selectively.

It's also probably a lot easier for AW to add a new command in the
form of the current ones, than to tinker with the existing command
and triggers. This would be a completely new thing that would exist
apart from anything else that's already in there.

With a little extra thought, it could even be useful without using bots.
Some 'metacommands' could be built into the syntax from the
start that browsers could parse and implement. You might do:

bump event "hey bots object 22 was hit" chat="humans fear not"

which would send the SDK event, and also display a message
in all browsers chat windows.

Continuing along those lines, you might have

activate event sdk="blah" browser="foo" server="bar"

Just a thought.

Throw in a meta language where %C is the cit number, %W is
the world and such, and you're having a lot of fun for very little
extra code on AW part.

[View Quote]

Aug 24, 2003, 8:57pm

There is already something in the browser doing all the trigger
calculations,
including the bump trigger, which is based on collisions. It is already
deciding
if it needs to call the bump command, so adding a new command would not
change anything relating to the current collision code... it could still be
done
exactly as they are now and therefore it would not slow the browser
down in any way.

If the world owner used a lot of them, and many people were in a world
causing them, then it might start to affect performance, but they would only
be used willfully and consciously... not 'under the covers' by a new
mechanism inserted into or cloned off of the current collision detection
code
over which you might have no control.

Apart from the idea of having events going to other browsers or
back to the server, if the events only fire at bots, then the problem is
linearly bounded by the number of bots and cits and will not go geometric
as more citizens come in. A single bot world will be easily handled by
both the bot, and the visitors browsers. If the command could target
a specific bot, then even the penalty of having multiple bots in a world
is eliminated. Perhaps a new world configuration option identifying the
bot or bots you want to get events, or a new SDK function for bots
to register for them.

The events should probably have some hysterisis so they only fire once
until you either stop colliding with whatever it was, collide with something
new or otherwise move away from the thing so you're not flooding
everyone with a stream of events. I think that was what you were trying
to say with your code example.

Whatever they can do would be an improvement, and any limitations it
might have would be worth living with.

[View Quote]

Dec 3, 2003, 6:02pm

Crossposted reply from SDK group

--

Gee.. shouldn't you post this kind of detailed info in the beta group
where the people working on the code are?

[View Quote] Oh.. you're *not* a member of the beta? I'm shocked.

=8O

You should ask for access.. I'm sure they will grant you access.

Why ENZO himself personally asked me if I would like to be on it,
and I've never even released anything to the community.

ENZO? Can Alex have that spot in the beta you offered me?

Pretty please?

>
> Dear AW development team,

<SNIP *extremely detailed feedback that would cost thousands
of dollars to get from professional testers*>

Obviously you would be a great asset for any company to test their
stuff. That assumes of course that they are interested in finding bugs,
and fixing them too. You've led them right to the exact problem, and
provided enough information that surely they can squash this bug
completely without the costly process of actually reproducing it and
capturing the kind of intformation you have there.

Hopefully the oversight with your name not getting pulled out of the
'beta' hat will be corrected. Hopefully you and the half dozen or so
other people who make things everyone relies on in here every day
have the appropriate access to the AWI developers.

This issue will be a good chance for all of us to see how AWI deals
with outside developers and content producers who provide all of the
added value, which is an issue of particular interest to me.

I would also be interested in knowing how they deal with people
trying to make commercial ventures based around AW technology.
As you clearly point out, this issue is a bit of a roadblock. I would
expect to see quick action to resolve this.

Please.. keep us all informed how this situation plays out.

Dec 3, 2003, 8:16pm

PS - I hope they also invite you and a few of the other main third party
developers to participate in the 'alphas' too.

The more time you have to prepare for new things, and the more AW's
coders get to hear your feedback and insight, the better their product
will be as well as yours, and the more it will have to offer people who
have money they want to spend on VR toys.

Alpha, beta .. whatever it is labelled... I hope the top external developers
are asked to be involved :-)

[View Quote]

Dec 20, 2003, 2:09am

May we use it as the key to a one time pad cipher?

> Licence:
>
> You may not decompile this program, you may not eat this program when you
> are hungry, you may not use EXE binders to try and distribute viruses via
> this program.
>
> You may distribute... but be it on your own heads if you end up being
> involved with some form of virus or trojan.

Jan 30, 2004, 12:57pm

Yes.. it's good news indeed!!

I consider both of your bots indispensable.

[View Quote]

Jul 7, 2003, 3:03am

A GZIP compressed stream essentially gives you multi byte tokenization
on *everything* free.

Anything AW can do to make the amount of data needed from the world
server more efficient is OK by me, but I don't really wanna know about it.

For example, the documentation insists that I should supply the .rwx at the
end of model names, so I do it even though it's easy to determine
empirically
that it is not really needed.

It may be however that it's not needed because the browser strips it off
when talking to the world server in order to save bandwidth.

The point being that whatever they do to compress the data stream should
be transparent to me.

[View Quote]

Jul 7, 2003, 3:14am

One of the issues with that would be the eight light source limit. If
everyone
wanted to use that 'lit' avatar... you would soon run out of light sources
and
the world would look funnier than it already does with 'real' lights
blinking
on and off all the time.

[View Quote]

Jul 7, 2003, 2:26am

Better cache management would definitely make me a lot happier.

The per-object reload button is a great idea when you are building, although
it won't help people who visited your world before the object changed and
who come back later. I doubt if AW is going to add a last changed date to
every object in your world on their server and then send that down the pipe
to the browser of everyone who comes to visit.

The 'last modified date' suggestion by TechnoZeus is probably more along the
lines of being doable without major chunks of stuff being rewritten. I would
be happy enough with something like that. Setting the object refresh to one
miunute while your are developing a world is a horrid kluge, and again it
doesn't help when someone came and visited, then comes back later after you
are all done.

I really want a 'last nuked on' date I can set so no matter when someone
comes to visit me, their browser can tell right away that the entire cache
should be flushed.

What I would actually prefer though is that it be a special file that is
loaded from my OP like the avatars.dat file is, since that way server side
cleverness can invalidate some peoples caches and not others.It could even
just be a file that is simply checked for it's date.. not actually read and
interpreted.

This would be useful to implement a content system where a visitor sees a
certain set of textures and objects before they 'sign up' through some
mechanism outisde of AW. A server script can then recognize that they need
to flush these 'non member' objects from their cache and get the 'real
ones'.

Dynamic server side content in AW is possible, and it's a lot of fun to play
with, but with no cache management mechanisms available to developers it is
a complete dead end. It's a shame too because all that is really needed is a
way for the server to completely invalidate it on a per user basis.

[View Quote]

Jul 7, 2003, 3:18am

Being able to specify a sound to play for any event that happens in a world
is a great
idea as long as it's optional.

Another event that might merit attention would be people leaving and
entering the world.

This is all possible with bots, but using a bot to do this is like renting a
bulldozer to
dig a small plot in your yard to plant some flowers.

[View Quote]

Jul 7, 2003, 4:19am

Wouldn't it better be implemted as:

create dark color=????

:-D

[View Quote]

Jul 7, 2003, 4:46am

What about just having the terrain be double sided? Water is...

The first thing I ever did with terrain was create a cavern, but it doesn't
work.

One mans floor is another mans roof.

[View Quote]

Jul 7, 2003, 6:34am

Yes I could, but terrain is already there. I didn't ask
for multi layered terrain.. two sided would suit me fine.

There's always another way to do something, but making terrain
double sided would be pretty easy for AW to do, and it would
make the terrain that much more useful.

This *is* the wishlist newsgroup.

[View Quote]

Jul 7, 2003, 4:59am

There are three rendering engines in there already.. Software,
OpenGL and Direct3D.

Even though these are the same 'engines' used at the lowest level
by other games, it's not the *rendering* engine itself that determines
if stuff like 'mirrors' are possible.

Renderware is more than just a rendering engine, just as the Quake
or Doom or other game engines do more than just 'render'. All game
engines need to do collision detection for example and you won't
find anything like that in a rendering engine.

No game uses raytracing for real time display either. Mirrors in games
are done using techniques such as mentioned earlier.. by rendering
a texture from a given viewpoint and dynamically mapping that to
an object.

Contrary to what somone said in the earlier thread about implementing
cameras, that is how games can and do implement things like
live security cameras and live computer screens in their worlds,
and it is not that big a performance hit. The back of the napkin
math that was cited failed to acount for the fact that the texture
created would only be a very small size versus a full sized browser
view, so cameras need not affect the frame rate much at all.


[View Quote]

Jul 7, 2003, 6:31am

At the expense of performance, the ability to mark a world as uncacheable
would completely remove the ability to obtain a propdump.

No cache... no propdump.

In advance to all the people who will object about how it's impossible to
protect
content, about how performance will suck and all your other objections, we
who
care about protecting content really don't care what you who don't want
anyone
to be able to protect it think. It's Annes choice to try to do something
about
leeches, and I have to wonder why some people are so quick to try to snuff
out any discussion on the topic.

[View Quote]

Jul 7, 2003, 4:16pm

There is a very good description of the packet size issues relating to
an unlimited cell count on the AW Feature vote page.

It is cited as one of the primary reasons for a cap on the object count.

In a nutshell, it is desirable to be able to fit the entire contents of an
AW
'cell' into a single HTTP packet of the maximum size allowed for HTTP
packets.

AW is considering a change to this. Vote on the feature request page if
you want to see them do it.

[View Quote]

Jul 7, 2003, 4:08pm

I have implemented such a feature using the 3.4 referer string and a
server side script.

People can still enter the world, but the server can give them anything
it wants to based on their browser version.. i.e. invisible models that
DL very quickly.. textures that tell them they need to use 3.4

This method has issues with caching though. Some form of cache
control would allow the implementation of a better solution.

[View Quote]

Jul 7, 2003, 4:01pm

I'd like to see them support *any* self masking format.

I believe the GIF patent only applies to software that *creates* GIF files.

[View Quote]

Jul 7, 2003, 3:58pm

What.. you don't want it to produce white noise to go with the
static on the dead TV screen ? :-)

[View Quote]

Jul 7, 2003, 3:50pm

It is quite easy for a server to redirect requests for content to
an entirely diffent server.

It works fine, and it does not 'bog everything down'.

The only people who complain are the people who complain about
eveything anyway, and they only complain when you tell them what
is happening.

If you don't tell them, they don't even notice a difference.

Implementing different passwords for different zip files is another
thing entirely. *That* would be very difficult to do.in the current
framework.

[View Quote]

Jul 7, 2003, 8:07pm

Forgive me if this has already been requested.

I wish there was a way to set the default terrain height in areas
where it is not explicitly set.

This could be done by just having the browser subtract a constant from
all the altitudes that come back from the current algorithm.

This would allow us the get rid of the Z-Fighting that occurs way off in
the distance under various scenarios.

Jan 21, 2004, 12:28am

[View Quote] <SNIP>

None of the theories mentioned so far seem to take into account the effects
of dim lighting or alcohol consumption on attraction, and are therefore all
flawed.

Jul 8, 2003, 8:52am

Would be nice to be able to use DDS textures so that if so inclined
one could completely control the mip-mapping process.

Jul 9, 2003, 6:34pm

There is usually a big difference between the sticker price and
what is actually paid.

I don't think Adobe even *had* 'a bazillion dollars'.

Personally.. I 'smell' them licensing stuff like that from Caligari.
It would be cool to have skinned avatars that use metaballs.

[View Quote]

Jul 11, 2003, 12:35am

It's a cool idea.

More flexibility in dishing out where your cells go in general would
be great.

Even if they don't go for letting you have multiple worlds listed,
maybe they could at least let you have disjoint areas within one
world to use your cell allotment. That would give you a lot more
possibilities, and spreading out your clumps of 'stuff' would give
you another way to combat lag.

So quit calling it a P-10 and call that a C-400 (400 cell world). As
soon as you build in a cell (other than macro terrain) it counts against
your tally. As soon as you destroy everything in a cell, you can now
use a cell somewhere else.

They could even get really clever with the billing and make it work
like a cell phone plan :-)

Hmmm.. it would actually be in fact a cell plan.

[View Quote]

Jul 15, 2003, 11:21am

I would like to be able to specify a minimum browser level on a
per world basis.

I want people who try to enter to get a message telling them they need
a certain minimum browser level, and only let them enter if they have it.

Jul 15, 2003, 8:10pm

Let me clarify..

A per-world minimum browser setting would override the universe setting.
If such a per world setting is implemented, they can make whichever one
they want override the other, and the only way it makes sense is for the
world setting to override the universe setting.

[View Quote]

Jul 16, 2003, 10:42am

This is a very rude and roundabout way of accomplishing a very simple task,
and once they enter the world it is too late. Their browser is already
caching the wrong version of objects, getting the wrong cookies etc.

I already know of a few (unsatisfactory) workarounds.

I'm asking AW if they could put this feature in their browser. It's a pretty
simple request. It is a logical extension of the minumum and maximum
browser levels implemented on a per universe basis. Why not just extend
the mechanism to include a per world setting?

If I have to do it your way, then I would like some better control over
caching, and if everything has to be done by bots, I would like the limit on
the number of bots removed.

[View Quote]

Jul 17, 2003, 5:57am

I don't want people to downgrade at all. I want them to upgrade
to *at least* a certain browser level. This type of minimum version
level is extremely widespread and common throughout the software
business.

You are interpreting this in completely the oppostie way.

[View Quote]

Jul 18, 2003, 2:24am

[View Quote] > hmm ok putting it that way, it could be a good idea.

> But how would you be able to override the universe settings?

> For this idea to work they would have to take it out the universe
> options and add it to the world server options.

I only want to override the minimum. In any case, as long as the world
minimum can only ever be higher than the universe minimum, there will
be no conflict, the current universe minimum and maximum will remain
as they are, and the only thing that would change would be that some
worlds might only work with a higher *minimum* version of the browser
than the universe supports.

In practice, most worlds would support the same browsers the universe
supported. Only worlds that really needed features only available
on newer browsers would set their minimum to a higher level than
their host universe.

> Say your world is set to allow all versions of the browser or just 3.3
and
> up, but the universe only allows 1 version the newest one?

My world would *only* be allowed to set it's minimum browser level
to versions between the universes minimum level and the maximum
(beta) level.

Allowing a world to even set the current beta as a minimum would
also provide a way for worlds that are participating in a beta to
restrict access to people possessing a beta level browser.

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