1  |   Order by index

Mar 16, 2000, 12:21am

Well you make a door by having it go visible off solid off right? Problem?
Well, when you open the door, it only opens client-side. This means that
everyone else sees it as closed and you glide through a closed door on their
screen. Minor annoyance? Yep. But think of the other option and the
advantages.

EXAMPLE:
pp01.rwx action: activate solid off, visible off

A simple "door" that goes away when clicked on. That's nice. Wouldn't it be
better if the activate trigger could be set up to set some kind of perminant
state for the object? So that it would stay open until closed somehow.

EXAMPLE:
pp01.rwx action: activate state.solid=0, state.visible=0 (note that I made
up an example command structure just to show the idea.... as far as I know
those are not real AW vars)

In this example, clicking on the door actually changes the object itself,
setting these two variables (solid and visible) to 0, or off. So the door is
opened and will remain open for all eternity until someone does whatever is
needed to return it to normal. Or until the builder edits the object which
would probably reset it.

A simple example, but it could be really useful. Especially for games and
the like (Note that I realize bots can be used to do this by removing and
replacing the object or actually putting create solid off commands on the
object when it's clicked - but this is a real waste or resources and efforts
and time and so on).

More variables could exist, even things like pos.x, pos.y, pos.z which could
be used to actually move the object by a click, bump, etc.

Taking that a little farther, the commands like create visible off would be
totally obsolete as the object's state.visible variable could be set while
placing the object (through some modification to the build window)

Adds more to bot interaction too... A bot can then tell if, for example, an
object is solid and if it's okay to walk through it ... thus creating sort
of a collision detection bot (though this would take more work than that)
....... I'm sure there's better examples, I just don't want to think of them
right now.


I know this has been around before... but I like to toss things up anyway.




----------------
You must die! I alone am best!

Mar 26, 2000, 12:00pm

Yes, I know, I know... this whole string has been gone over before, and here's
the gist of why it hasn't been implemented (aside from the fact of Roland being
busy with 3.0). It would take more transfer to and from the server for all the
clients to get the information of the object's changed state. This would,
inevitably, slow down the client... which is a big no no. So, until 3.0 comes
out, we have to worry about framerate quite a bit. (for the uninformed, aw 3.0
is supposed to give a performance boost, even to those with paperweights on
their desk.

[View Quote] > Well you make a door by having it go visible off solid off right? Problem?
> Well, when you open the door, it only opens client-side. This means that
> everyone else sees it as closed and you glide through a closed door on their
> screen. Minor annoyance? Yep. But think of the other option and the
> advantages.
>
> EXAMPLE:
> pp01.rwx action: activate solid off, visible off
>
> A simple "door" that goes away when clicked on. That's nice. Wouldn't it be
> better if the activate trigger could be set up to set some kind of perminant
> state for the object? So that it would stay open until closed somehow.
>
> EXAMPLE:
> pp01.rwx action: activate state.solid=0, state.visible=0 (note that I made
> up an example command structure just to show the idea.... as far as I know
> those are not real AW vars)
>
> In this example, clicking on the door actually changes the object itself,
> setting these two variables (solid and visible) to 0, or off. So the door is
> opened and will remain open for all eternity until someone does whatever is
> needed to return it to normal. Or until the builder edits the object which
> would probably reset it.
>
> A simple example, but it could be really useful. Especially for games and
> the like (Note that I realize bots can be used to do this by removing and
> replacing the object or actually putting create solid off commands on the
> object when it's clicked - but this is a real waste or resources and efforts
> and time and so on).
>
> More variables could exist, even things like pos.x, pos.y, pos.z which could
> be used to actually move the object by a click, bump, etc.
>
> Taking that a little farther, the commands like create visible off would be
> totally obsolete as the object's state.visible variable could be set while
> placing the object (through some modification to the build window)
>
> Adds more to bot interaction too... A bot can then tell if, for example, an
> object is solid and if it's okay to walk through it ... thus creating sort
> of a collision detection bot (though this would take more work than that)
> ...... I'm sure there's better examples, I just don't want to think of them
> right now.
>
> I know this has been around before... but I like to toss things up anyway.
>
> ----------------
> You must die! I alone am best!

1  |   Order by index