|
(3.1) Move/Rotate Command enhancement (With examples) (Community)
(3.1) Move/Rotate Command enhancement (With examples) // Community
Feb 14, 2001, 4:31pm
Well, I've been playing around with the new commands - expecially
move/rotate, which is the topic of most of this message, really.
While the commands in their current form have applications, and, with the
help of some other commands (astart/adone, mostly - as you can see in
objectd', or even the little looping truck animation I have in proxima right
now) can be quite useful, I'm hoping that future additions to them can be
made.
Basically, I'm looking for a way to chain together move/rotate commands more
efficiently than the current method of astart/adone and multiple instances
of the same object. Perhaps some sort of 'wait' or 'then' command which
would cause the parser to wait before continuing execution combined with
more move/rotate options (like a 'stop' command which makes the object halt
at the end of a move before returning - basically infinate wait).
I'm sure there's a better way to implement that if I really thought about
it, but there needs to be a way to chain move and rotates. Motion path is
also an EXCELLENT idea, which, I'm sure, could be implemented without too
much difficulty (even if simply as a new command, perhaps with its own set
of dividers). In fact, I think I like that idea so much I'm going to write
up a detailed explaination of how it would work.
Example: create mpath (move 10 time=2, rotate 10; move 0 0 -10 time=4;
rotate 10 time=4)
Allow me to explain.
The first part, create mpath, is a simple command (on create, start a motion
path). Inside parenthesis are the details of the mpath - we do this since
it's easier to use the dividers we know and love, comma and semicolon. The
first part in there, "move10 time=2, rotate 10" causes two things to happen
starting at the same time - the object moves 10 meters while rotating at 10
rpms. It stops moving AND rotating after two seconds. Next we have "move 0
0 -10 time=4".... which we should all understand. The object moves 10
meters, but in a different direction (NOTE: This is the critical part... the
object starts moving from where the first movement/rotation left it! It does
not return to its built origin!). Finally, "rotate 10 time=4", which is also
self-explainatory. Note how things that happen at the same time are comma'd,
while each event it separated by a semicolon.
Basically, that command makes the object move while rotating, then just
move, then rotate. It might not be the BEST way possible - but I'll bet
Roland could do it in under an hour, and it'd still be rather easy for
everyone to use.
One last piece -- it wouldn't be a terrible idea for the mpath command to
have a "use orientation" switch. That is to say, a simple on/off option
telling the client if it should move the object just on the world coords, or
relative to the actual ANGLE of the object - so that rotating it effects
what direction it travels in.
35850
Feb 14, 2001, 7:32pm
interesting, it may be hard for AWCOM's team of programmers to do so but
interesting.
[View Quote]35850 <!> wrote in message news:3a8acefd$1 at server1.Activeworlds.com...
> Well, I've been playing around with the new commands - expecially
> move/rotate, which is the topic of most of this message, really.
> While the commands in their current form have applications, and, with the
> help of some other commands (astart/adone, mostly - as you can see in
> objectd', or even the little looping truck animation I have in proxima
right
> now) can be quite useful, I'm hoping that future additions to them can be
> made.
>
> Basically, I'm looking for a way to chain together move/rotate commands
more
> efficiently than the current method of astart/adone and multiple instances
> of the same object. Perhaps some sort of 'wait' or 'then' command which
> would cause the parser to wait before continuing execution combined with
> more move/rotate options (like a 'stop' command which makes the object
halt
> at the end of a move before returning - basically infinate wait).
>
> I'm sure there's a better way to implement that if I really thought about
> it, but there needs to be a way to chain move and rotates. Motion path is
> also an EXCELLENT idea, which, I'm sure, could be implemented without too
> much difficulty (even if simply as a new command, perhaps with its own set
> of dividers). In fact, I think I like that idea so much I'm going to write
> up a detailed explaination of how it would work.
>
> Example: create mpath (move 10 time=2, rotate 10; move 0 0 -10 time=4;
> rotate 10 time=4)
> Allow me to explain.
> The first part, create mpath, is a simple command (on create, start a
motion
> path). Inside parenthesis are the details of the mpath - we do this since
> it's easier to use the dividers we know and love, comma and semicolon.
The
> first part in there, "move10 time=2, rotate 10" causes two things to
happen
> starting at the same time - the object moves 10 meters while rotating at
10
> rpms. It stops moving AND rotating after two seconds. Next we have "move 0
> 0 -10 time=4".... which we should all understand. The object moves 10
> meters, but in a different direction (NOTE: This is the critical part...
the
> object starts moving from where the first movement/rotation left it! It
does
> not return to its built origin!). Finally, "rotate 10 time=4", which is
also
> self-explainatory. Note how things that happen at the same time are
comma'd,
> while each event it separated by a semicolon.
>
> Basically, that command makes the object move while rotating, then just
> move, then rotate. It might not be the BEST way possible - but I'll bet
> Roland could do it in under an hour, and it'd still be rather easy for
> everyone to use.
>
> One last piece -- it wouldn't be a terrible idea for the mpath command to
> have a "use orientation" switch. That is to say, a simple on/off option
> telling the client if it should move the object just on the world coords,
or
> relative to the actual ANGLE of the object - so that rotating it effects
> what direction it travels in.
>
> 35850
>
>
|
Feb 14, 2001, 8:51pm
After ByteMe did the complex actions on the jack in the box in Objectd' we
decided that there would be a use for rotate- rdone/rstop/rstart and same
for moves. Then it was pointed out to me why not an overall generic stop,
start, done. I did post it in the beta NG when we thought of it but it's
something for the wish list.
Casay
[View Quote]"captain mad mike" <cmadmike at crosswinds.net> wrote in message
news:3a8af951 at server1.Activeworlds.com...
> interesting, it may be hard for AWCOM's team of programmers to do so but
> interesting.
>
>
> 35850 <!> wrote in message news:3a8acefd$1 at server1.Activeworlds.com...
the
> right
be
> more
instances
> halt
about
is
too
set
write
> motion
since
> The
> happen
> 10
0
> the
> does
> also
> comma'd,
to
coords,
> or
>
>
|
Feb 14, 2001, 9:19pm
Well, I wasn't going to mention this until I tested it out more, but
be it a bug or a feature, if you use in combination with the astop
astart commands with a move 0 0 0 name=objectname, on an already in
motion object, it will stop that object at the position it is currently
at during the move when the command is issued. If you leave the area and
lose render of the initial objects starting position it will reappear at
starting position. Or if you restart it with a new move with a value, it
will start from it's starting point. Oh well. :\
I have an example of this in Forbiden in my test area.
Bits
"casay" <casay2 at home.com> wrote ...
: After ByteMe did the complex actions on the jack in the box in
Objectd' we
: decided that there would be a use for rotate- rdone/rstop/rstart and
same
: for moves. Then it was pointed out to me why not an overall generic
stop,
: start, done. I did post it in the beta NG when we thought of it but
it's
: something for the wish list.
: Casay
: "captain mad mike" <cmadmike at crosswinds.net> wrote ...
: > interesting, it may be hard for AWCOM's team of programmers to do so
but
: > interesting.
: >
: >
: > 35850 <!> wrote ...
: > > Well, I've been playing around with the new commands - expecially
: > > move/rotate, which is the topic of most of this message, really.
: > > While the commands in their current form have applications, and,
with
: the
: > > help of some other commands (astart/adone, mostly - as you can see
in
: > > objectd', or even the little looping truck animation I have in
proxima
: > right
: > > now) can be quite useful, I'm hoping that future additions to them
can
: be
: > > made.
: > >
: > > Basically, I'm looking for a way to chain together move/rotate
commands
: > more
: > > efficiently than the current method of astart/adone and multiple
: instances
: > > of the same object. Perhaps some sort of 'wait' or 'then' command
which
: > > would cause the parser to wait before continuing execution
combined with
: > > more move/rotate options (like a 'stop' command which makes the
object
: > halt
: > > at the end of a move before returning - basically infinate wait).
: > >
: > > I'm sure there's a better way to implement that if I really
thought
: about
: > > it, but there needs to be a way to chain move and rotates. Motion
path
: is
: > > also an EXCELLENT idea, which, I'm sure, could be implemented
without
: too
: > > much difficulty (even if simply as a new command, perhaps with its
own
: set
: > > of dividers). In fact, I think I like that idea so much I'm going
to
: write
: > > up a detailed explaination of how it would work.
: > >
: > > Example: create mpath (move 10 time=2, rotate 10; move 0 0 -10
time=4;
: > > rotate 10 time=4)
: > > Allow me to explain.
: > > The first part, create mpath, is a simple command (on create,
start a
: > motion
: > > path). Inside parenthesis are the details of the mpath - we do
this
: since
: > > it's easier to use the dividers we know and love, comma and
semicolon.
: > The
: > > first part in there, "move10 time=2, rotate 10" causes two things
to
: > happen
: > > starting at the same time - the object moves 10 meters while
rotating at
: > 10
: > > rpms. It stops moving AND rotating after two seconds. Next we have
"move
: 0
: > > 0 -10 time=4".... which we should all understand. The object moves
10
: > > meters, but in a different direction (NOTE: This is the critical
part...
: > the
: > > object starts moving from where the first movement/rotation left
it! It
: > does
: > > not return to its built origin!). Finally, "rotate 10 time=4",
which is
: > also
: > > self-explainatory. Note how things that happen at the same time
are
: > comma'd,
: > > while each event it separated by a semicolon.
: > >
: > > Basically, that command makes the object move while rotating, then
just
: > > move, then rotate. It might not be the BEST way possible - but
I'll bet
: > > Roland could do it in under an hour, and it'd still be rather easy
for
: > > everyone to use.
: > >
: > > One last piece -- it wouldn't be a terrible idea for the mpath
command
: to
: > > have a "use orientation" switch. That is to say, a simple on/off
option
: > > telling the client if it should move the object just on the world
: coords,
: > or
: > > relative to the actual ANGLE of the object - so that rotating it
effects
: > > what direction it travels in.
: > >
: > > 35850
: > >
: > >
: >
: >
:
Feb 14, 2001, 9:40pm
Hmm interesting. I sure hope Byte huriies up and teaches the class on the
astop/start stuff, I could sure use it. That and more examples on the help
page. lol
Casay
[View Quote]"bitmaster" <bitmeister at i2k.com> wrote in message
news:3a8b1283 at server1.Activeworlds.com...
> Well, I wasn't going to mention this until I tested it out more, but
> be it a bug or a feature, if you use in combination with the astop
> astart commands with a move 0 0 0 name=objectname, on an already in
> motion object, it will stop that object at the position it is currently
> at during the move when the command is issued. If you leave the area and
> lose render of the initial objects starting position it will reappear at
> starting position. Or if you restart it with a new move with a value, it
> will start from it's starting point. Oh well. :\
> I have an example of this in Forbiden in my test area.
>
> Bits
>
> "casay" <casay2 at home.com> wrote ...
> : After ByteMe did the complex actions on the jack in the box in
> Objectd' we
> : decided that there would be a use for rotate- rdone/rstop/rstart and
> same
> : for moves. Then it was pointed out to me why not an overall generic
> stop,
> : start, done. I did post it in the beta NG when we thought of it but
> it's
> : something for the wish list.
> : Casay
> : "captain mad mike" <cmadmike at crosswinds.net> wrote ...
> : > interesting, it may be hard for AWCOM's team of programmers to do so
> but
> : > interesting.
> : >
> : >
> : > 35850 <!> wrote ...
> : > > Well, I've been playing around with the new commands - expecially
> : > > move/rotate, which is the topic of most of this message, really.
> : > > While the commands in their current form have applications, and,
> with
> : the
> : > > help of some other commands (astart/adone, mostly - as you can see
> in
> : > > objectd', or even the little looping truck animation I have in
> proxima
> : > right
> : > > now) can be quite useful, I'm hoping that future additions to them
> can
> : be
> : > > made.
> : > >
> : > > Basically, I'm looking for a way to chain together move/rotate
> commands
> : > more
> : > > efficiently than the current method of astart/adone and multiple
> : instances
> : > > of the same object. Perhaps some sort of 'wait' or 'then' command
> which
> : > > would cause the parser to wait before continuing execution
> combined with
> : > > more move/rotate options (like a 'stop' command which makes the
> object
> : > halt
> : > > at the end of a move before returning - basically infinate wait).
> : > >
> : > > I'm sure there's a better way to implement that if I really
> thought
> : about
> : > > it, but there needs to be a way to chain move and rotates. Motion
> path
> : is
> : > > also an EXCELLENT idea, which, I'm sure, could be implemented
> without
> : too
> : > > much difficulty (even if simply as a new command, perhaps with its
> own
> : set
> : > > of dividers). In fact, I think I like that idea so much I'm going
> to
> : write
> : > > up a detailed explaination of how it would work.
> : > >
> : > > Example: create mpath (move 10 time=2, rotate 10; move 0 0 -10
> time=4;
> : > > rotate 10 time=4)
> : > > Allow me to explain.
> : > > The first part, create mpath, is a simple command (on create,
> start a
> : > motion
> : > > path). Inside parenthesis are the details of the mpath - we do
> this
> : since
> : > > it's easier to use the dividers we know and love, comma and
> semicolon.
> : > The
> : > > first part in there, "move10 time=2, rotate 10" causes two things
> to
> : > happen
> : > > starting at the same time - the object moves 10 meters while
> rotating at
> : > 10
> : > > rpms. It stops moving AND rotating after two seconds. Next we have
> "move
> : 0
> : > > 0 -10 time=4".... which we should all understand. The object moves
> 10
> : > > meters, but in a different direction (NOTE: This is the critical
> part...
> : > the
> : > > object starts moving from where the first movement/rotation left
> it! It
> : > does
> : > > not return to its built origin!). Finally, "rotate 10 time=4",
> which is
> : > also
> : > > self-explainatory. Note how things that happen at the same time
> are
> : > comma'd,
> : > > while each event it separated by a semicolon.
> : > >
> : > > Basically, that command makes the object move while rotating, then
> just
> : > > move, then rotate. It might not be the BEST way possible - but
> I'll bet
> : > > Roland could do it in under an hour, and it'd still be rather easy
> for
> : > > everyone to use.
> : > >
> : > > One last piece -- it wouldn't be a terrible idea for the mpath
> command
> : to
> : > > have a "use orientation" switch. That is to say, a simple on/off
> option
> : > > telling the client if it should move the object just on the world
> : coords,
> : > or
> : > > relative to the actual ANGLE of the object - so that rotating it
> effects
> : > > what direction it travels in.
> : > >
> : > > 35850
> : > >
> : > >
> : >
> : >
> :
>
>
|
Feb 15, 2001, 1:35am
it's always gone back to the starting point if it does the things you
mentioned... that's part of how astart works...
--
J B E L L
http://platinum.awjbell.com
G O I N G P L A T I N U M
[View Quote]"bitmaster" <bitmeister at i2k.com> wrote in message
news:3a8b1283 at server1.Activeworlds.com...
: Well, I wasn't going to mention this until I tested it out more, but
: be it a bug or a feature, if you use in combination with the astop
: astart commands with a move 0 0 0 name=objectname, on an already in
: motion object, it will stop that object at the position it is currently
: at during the move when the command is issued. If you leave the area and
: lose render of the initial objects starting position it will reappear at
: starting position. Or if you restart it with a new move with a value, it
: will start from it's starting point. Oh well. :\
: I have an example of this in Forbiden in my test area.
:
: Bits
:
: "casay" <casay2 at home.com> wrote ...
: : After ByteMe did the complex actions on the jack in the box in
: Objectd' we
: : decided that there would be a use for rotate- rdone/rstop/rstart and
: same
: : for moves. Then it was pointed out to me why not an overall generic
: stop,
: : start, done. I did post it in the beta NG when we thought of it but
: it's
: : something for the wish list.
: : Casay
: : "captain mad mike" <cmadmike at crosswinds.net> wrote ...
: : > interesting, it may be hard for AWCOM's team of programmers to do so
: but
: : > interesting.
: : >
: : >
: : > 35850 <!> wrote ...
: : > > Well, I've been playing around with the new commands - expecially
: : > > move/rotate, which is the topic of most of this message, really.
: : > > While the commands in their current form have applications, and,
: with
: : the
: : > > help of some other commands (astart/adone, mostly - as you can see
: in
: : > > objectd', or even the little looping truck animation I have in
: proxima
: : > right
: : > > now) can be quite useful, I'm hoping that future additions to them
: can
: : be
: : > > made.
: : > >
: : > > Basically, I'm looking for a way to chain together move/rotate
: commands
: : > more
: : > > efficiently than the current method of astart/adone and multiple
: : instances
: : > > of the same object. Perhaps some sort of 'wait' or 'then' command
: which
: : > > would cause the parser to wait before continuing execution
: combined with
: : > > more move/rotate options (like a 'stop' command which makes the
: object
: : > halt
: : > > at the end of a move before returning - basically infinate wait).
: : > >
: : > > I'm sure there's a better way to implement that if I really
: thought
: : about
: : > > it, but there needs to be a way to chain move and rotates. Motion
: path
: : is
: : > > also an EXCELLENT idea, which, I'm sure, could be implemented
: without
: : too
: : > > much difficulty (even if simply as a new command, perhaps with its
: own
: : set
: : > > of dividers). In fact, I think I like that idea so much I'm going
: to
: : write
: : > > up a detailed explaination of how it would work.
: : > >
: : > > Example: create mpath (move 10 time=2, rotate 10; move 0 0 -10
: time=4;
: : > > rotate 10 time=4)
: : > > Allow me to explain.
: : > > The first part, create mpath, is a simple command (on create,
: start a
: : > motion
: : > > path). Inside parenthesis are the details of the mpath - we do
: this
: : since
: : > > it's easier to use the dividers we know and love, comma and
: semicolon.
: : > The
: : > > first part in there, "move10 time=2, rotate 10" causes two things
: to
: : > happen
: : > > starting at the same time - the object moves 10 meters while
: rotating at
: : > 10
: : > > rpms. It stops moving AND rotating after two seconds. Next we have
: "move
: : 0
: : > > 0 -10 time=4".... which we should all understand. The object moves
: 10
: : > > meters, but in a different direction (NOTE: This is the critical
: part...
: : > the
: : > > object starts moving from where the first movement/rotation left
: it! It
: : > does
: : > > not return to its built origin!). Finally, "rotate 10 time=4",
: which is
: : > also
: : > > self-explainatory. Note how things that happen at the same time
: are
: : > comma'd,
: : > > while each event it separated by a semicolon.
: : > >
: : > > Basically, that command makes the object move while rotating, then
: just
: : > > move, then rotate. It might not be the BEST way possible - but
: I'll bet
: : > > Roland could do it in under an hour, and it'd still be rather easy
: for
: : > > everyone to use.
: : > >
: : > > One last piece -- it wouldn't be a terrible idea for the mpath
: command
: : to
: : > > have a "use orientation" switch. That is to say, a simple on/off
: option
: : > > telling the client if it should move the object just on the world
: : coords,
: : > or
: : > > relative to the actual ANGLE of the object - so that rotating it
: effects
: : > > what direction it travels in.
: : > >
: : > > 35850
: : > >
: : > >
: : >
: : >
: :
:
:
|
Feb 17, 2001, 10:39am
How would handle encroachment? I can just see an object come flying through my
house on its way to the pizza shop...:)
[View Quote]
> Well, I've been playing around with the new commands - expecially
> move/rotate, which is the topic of most of this message, really.
> While the commands in their current form have applications, and, with the
> help of some other commands (astart/adone, mostly - as you can see in
> objectd', or even the little looping truck animation I have in proxima right
> now) can be quite useful, I'm hoping that future additions to them can be
> made.
>
> Basically, I'm looking for a way to chain together move/rotate commands more
> efficiently than the current method of astart/adone and multiple instances
> of the same object. Perhaps some sort of 'wait' or 'then' command which
> would cause the parser to wait before continuing execution combined with
> more move/rotate options (like a 'stop' command which makes the object halt
> at the end of a move before returning - basically infinate wait).
>
> I'm sure there's a better way to implement that if I really thought about
> it, but there needs to be a way to chain move and rotates. Motion path is
> also an EXCELLENT idea, which, I'm sure, could be implemented without too
> much difficulty (even if simply as a new command, perhaps with its own set
> of dividers). In fact, I think I like that idea so much I'm going to write
> up a detailed explaination of how it would work.
>
> Example: create mpath (move 10 time=2, rotate 10; move 0 0 -10 time=4;
> rotate 10 time=4)
> Allow me to explain.
> The first part, create mpath, is a simple command (on create, start a motion
> path). Inside parenthesis are the details of the mpath - we do this since
> it's easier to use the dividers we know and love, comma and semicolon. The
> first part in there, "move10 time=2, rotate 10" causes two things to happen
> starting at the same time - the object moves 10 meters while rotating at 10
> rpms. It stops moving AND rotating after two seconds. Next we have "move 0
> 0 -10 time=4".... which we should all understand. The object moves 10
> meters, but in a different direction (NOTE: This is the critical part... the
> object starts moving from where the first movement/rotation left it! It does
> not return to its built origin!). Finally, "rotate 10 time=4", which is also
> self-explainatory. Note how things that happen at the same time are comma'd,
> while each event it separated by a semicolon.
>
> Basically, that command makes the object move while rotating, then just
> move, then rotate. It might not be the BEST way possible - but I'll bet
> Roland could do it in under an hour, and it'd still be rather easy for
> everyone to use.
>
> One last piece -- it wouldn't be a terrible idea for the mpath command to
> have a "use orientation" switch. That is to say, a simple on/off option
> telling the client if it should move the object just on the world coords, or
> relative to the actual ANGLE of the object - so that rotating it effects
> what direction it travels in.
>
> 35850
Feb 18, 2001, 1:52pm
It wouldn't. Move and rotate already aren't allowed in public building
worlds.
[View Quote]"holistic1" <tkafader at ptdprolog.net> wrote in message
news:3A8E6E21.AA392B7B at ptdprolog.net...
> How would handle encroachment? I can just see an object come flying
through my
> house on its way to the pizza shop...:)
|
Apr 3, 2003, 4:49pm
Wellllllll....
3.4 is obviously not released yet but we have already started considering
features for 3.5 or 4.0
One feature that is near the top of the list is "movers".
While "move" and "rotate" are great little commands there is a need for a
higher level of scripting to do the things you describe.
One existing problem is the shared state of the veiwer and the object is not
shared with others. Aside from the ability to "sync" an event with the
clock you really have no control as to what everyone else sees. A door
appears to open (bump rotate 0, 0, 1) for you, but everyone else sees you
walking through it. Currently only by using a bot can you fix this problem.
Another example, if I start a move on a train.rwx it will only go to my
visible range and then disappear, this distance is differnent for everyone -
and once the train.rwx disappears... so does the command. Your command
suggestion would work for you but anyone else who walked in after it had
started would not see it, or they would see it in a different position. And
if the numbers were larger than the visible distance the animation would
stop.
A solution for these problems is "movers". Movers would probably be a
seperate class of objects which the server could recognize as a shared event
object. This would allow the server to track events that started either by a
script or an action in world. If this is done train.rwx is seen by everyone
in the same place (no matter when the entered the world... or what there
visible range is) A mover should be able to follow waypoints you could set
from coords. A mover might also allow people to "ride" it (elevators-
buses-merrygorounds- rollercoasters)
Anyways... it is on the list but not simple
E
A "mover" could travel in a specified area and be a shared event throughout.
[View Quote]"35850" <!> wrote in message news:3a8acefd$1 at server1.Activeworlds.com...
> Well, I've been playing around with the new commands - expecially
> move/rotate, which is the topic of most of this message, really.
> While the commands in their current form have applications, and, with the
> help of some other commands (astart/adone, mostly - as you can see in
> objectd', or even the little looping truck animation I have in proxima
right
> now) can be quite useful, I'm hoping that future additions to them can be
> made.
>
> Basically, I'm looking for a way to chain together move/rotate commands
more
> efficiently than the current method of astart/adone and multiple instances
> of the same object. Perhaps some sort of 'wait' or 'then' command which
> would cause the parser to wait before continuing execution combined with
> more move/rotate options (like a 'stop' command which makes the object
halt
> at the end of a move before returning - basically infinate wait).
>
> I'm sure there's a better way to implement that if I really thought about
> it, but there needs to be a way to chain move and rotates. Motion path is
> also an EXCELLENT idea, which, I'm sure, could be implemented without too
> much difficulty (even if simply as a new command, perhaps with its own set
> of dividers). In fact, I think I like that idea so much I'm going to write
> up a detailed explaination of how it would work.
>
> Example: create mpath (move 10 time=2, rotate 10; move 0 0 -10 time=4;
> rotate 10 time=4)
> Allow me to explain.
> The first part, create mpath, is a simple command (on create, start a
motion
> path). Inside parenthesis are the details of the mpath - we do this since
> it's easier to use the dividers we know and love, comma and semicolon.
The
> first part in there, "move10 time=2, rotate 10" causes two things to
happen
> starting at the same time - the object moves 10 meters while rotating at
10
> rpms. It stops moving AND rotating after two seconds. Next we have "move 0
> 0 -10 time=4".... which we should all understand. The object moves 10
> meters, but in a different direction (NOTE: This is the critical part...
the
> object starts moving from where the first movement/rotation left it! It
does
> not return to its built origin!). Finally, "rotate 10 time=4", which is
also
> self-explainatory. Note how things that happen at the same time are
comma'd,
> while each event it separated by a semicolon.
>
> Basically, that command makes the object move while rotating, then just
> move, then rotate. It might not be the BEST way possible - but I'll bet
> Roland could do it in under an hour, and it'd still be rather easy for
> everyone to use.
>
> One last piece -- it wouldn't be a terrible idea for the mpath command to
> have a "use orientation" switch. That is to say, a simple on/off option
> telling the client if it should move the object just on the world coords,
or
> relative to the actual ANGLE of the object - so that rotating it effects
> what direction it travels in.
>
> 35850
>
>
|
Apr 3, 2003, 5:23pm
Actually, the enhancements I have suggested for the move and rotate commands would cover almost all of those possibilities exactly as I have outlined them, and I'm pretty sure they would be much easier to implement. The only thing you've mentioned which my proposed enhancements wouldn't cover is the idea of being able to see the object's current shared position even if you entered the world out of visibility range and had not moved into visibility range of where the object was originally placed. A small modification could cover that possibility as well, by periodically updating a temporary object entry in the world object database, as outlined in my earlier suggestion for temporary objects. Also, the enhancements I have suggested would allow a choice between shared or unique experience with the same command, and using the same types of objects, rather than having to force a person to use one or the other.
One small correction to your example of how the move command currently works. If the move command moves an object out of visibility range, you still see the object and the command attached to it is still in effect. It's only if you move out of visibility range of the object's origin that the object is removed from the scene. I have also outlined suggestions to improve this situation.
TechnoZeus
[View Quote]"e n z o" <enzo at activeworlds.com> wrote in message news:3e8c8249$1 at server1.Activeworlds.com...
> Wellllllll....
>
> 3.4 is obviously not released yet but we have already started considering
> features for 3.5 or 4.0
>
> One feature that is near the top of the list is "movers".
>
> While "move" and "rotate" are great little commands there is a need for a
> higher level of scripting to do the things you describe.
> One existing problem is the shared state of the veiwer and the object is not
> shared with others. Aside from the ability to "sync" an event with the
> clock you really have no control as to what everyone else sees. A door
> appears to open (bump rotate 0, 0, 1) for you, but everyone else sees you
> walking through it. Currently only by using a bot can you fix this problem.
>
> Another example, if I start a move on a train.rwx it will only go to my
> visible range and then disappear, this distance is differnent for everyone -
> and once the train.rwx disappears... so does the command. Your command
> suggestion would work for you but anyone else who walked in after it had
> started would not see it, or they would see it in a different position. And
> if the numbers were larger than the visible distance the animation would
> stop.
>
> A solution for these problems is "movers". Movers would probably be a
> seperate class of objects which the server could recognize as a shared event
> object. This would allow the server to track events that started either by a
> script or an action in world. If this is done train.rwx is seen by everyone
> in the same place (no matter when the entered the world... or what there
> visible range is) A mover should be able to follow waypoints you could set
> from coords. A mover might also allow people to "ride" it (elevators-
> buses-merrygorounds- rollercoasters)
>
> Anyways... it is on the list but not simple
>
> E
>
>
>
>
>
> A "mover" could travel in a specified area and be a shared event throughout.
> "35850" <!> wrote in message news:3a8acefd$1 at server1.Activeworlds.com...
> right
> more
> halt
> motion
> The
> happen
> 10
> the
> does
> also
> comma'd,
> or
>
>
|
Apr 3, 2003, 7:17pm
Such a scripting engine as Enzo suggests exists already in some other
VRs, I think, in fact that something like that would be needed.
However, the question is if it should be implemented with a command, on
a seperate "scripting" engine or via an enhanced sdk (personally, I
favour the last option and at the same time revise and improve some of
the existing commmands).
The most important thing is IMHO a dedicated rights administration, eg.
to be able to give certain citizens certain rights (eg. fly, enhanced
commands, etc.) rather than rights depending on global flags.
[View Quote]technozeus wrote:
>
>
>
> One small correction to your example of how the move command currently works. If the move command moves an object out of visibility range, you still see the object and the command attached to it is still in effect. It's only if you move out of visibility range of the object's origin that the object is removed from the scene. I have also outlined suggestions to improve this situation.
>
> TechnoZeus
>
> "e n z o" <enzo at activeworlds.com> wrote in message news:3e8c8249$1 at server1.Activeworlds.com...
|
Apr 3, 2003, 9:49pm
With the suggestions I've given for enhancing the commands, neither of the two choices you mentioned would be needed. On the other hand, if either of them were to be added it would make sense to me not to choose one or the other but rather to choose implement scripting, and then give both builders and SDK developers access to it.
TechnoZeus
[View Quote]"kf" <none at junk.mail> wrote in message news:3E8CA50A.9A0 at junk.mail...
> Such a scripting engine as Enzo suggests exists already in some other
> VRs, I think, in fact that something like that would be needed.
>
> However, the question is if it should be implemented with a command, on
> a seperate "scripting" engine or via an enhanced sdk (personally, I
> favour the last option and at the same time revise and improve some of
> the existing commmands).
>
> The most important thing is IMHO a dedicated rights administration, eg.
> to be able to give certain citizens certain rights (eg. fly, enhanced
> commands, etc.) rather than rights depending on global flags.
>
>
>
> technozeus wrote:
|
Apr 3, 2003, 10:50pm
Just so long as those enhanced command rights are enabled for us who build
in the public build worlds would rights administration for movers be
acceptable. :P
SW Chris
[View Quote]"kf" <none at junk.mail> wrote in message news:3E8CA50A.9A0 at junk.mail...
> Such a scripting engine as Enzo suggests exists already in some other
> VRs, I think, in fact that something like that would be needed.
>
> However, the question is if it should be implemented with a command, on
> a seperate "scripting" engine or via an enhanced sdk (personally, I
> favour the last option and at the same time revise and improve some of
> the existing commmands).
>
> The most important thing is IMHO a dedicated rights administration, eg.
> to be able to give certain citizens certain rights (eg. fly, enhanced
> commands, etc.) rather than rights depending on global flags.
>
>
>
> technozeus wrote:
works. If the move command moves an object out of visibility range, you
still see the object and the command attached to it is still in effect.
It's only if you move out of visibility range of the object's origin that
the object is removed from the scene. I have also outlined suggestions to
improve this situation.
news:3e8c8249$1 at server1.Activeworlds.com...
considering
for a
is not
the
you
problem.
my
everyone -
had
position. And
would
event
either by a
everyone
there
set
throughout.
news:3a8acefd$1 at server1.Activeworlds.com...
with the
in
proxima
can be
commands
instances
which
with
object
about
path is
without too
own set
write
time=4;
a
since
semicolon.
rotating at
"move 0
10
part...
It
is
just
bet
for
command to
option
coords,
effects
|
Apr 4, 2003, 1:27am
The way KF was recommending (through SDK commands) would not add anything at all for builders directly in any world, but would instead allow bot designers to produce bots which would control such things. Technically, that could be done now with a bot, but would require a more complex bot program than if special SDK enhancements were made. Of course, those SDK enhancements would also require programming to add, so one way or another it's a lot of programming. In short, the answer is no... adding such commands to the SDK would add nothing to public building worlds for builders to take advantage of, and they would not directly add anything to private worlds either, nor would they add anything even indirectly to any worlds at all unless someone wrote a bot to indirectly add functionality and that particular world's caretaker allowed someone to run that bot in that world, and the additional functionality would only be available while the bot is running.
Of course, if the same functionality were to be added in commands designed to work from inside of an object's Action line, many existing bots could take advantage of them without having to modify the bot at all, and newer bots could still be written specifically to take advantage of the new functionality.
TechnoZeus
[View Quote]"sw chris" <chrisw10 at skywalkeronline.net> wrote in message news:3e8cd6d1 at server1.Activeworlds.com...
> Just so long as those enhanced command rights are enabled for us who build
> in the public build worlds would rights administration for movers be
> acceptable. :P
>
> SW Chris
>
> "kf" <none at junk.mail> wrote in message news:3E8CA50A.9A0 at junk.mail...
> works. If the move command moves an object out of visibility range, you
> still see the object and the command attached to it is still in effect.
> It's only if you move out of visibility range of the object's origin that
> the object is removed from the scene. I have also outlined suggestions to
> improve this situation.
> news:3e8c8249$1 at server1.Activeworlds.com...
> considering
> for a
> is not
> the
> you
> problem.
> my
> everyone -
> had
> position. And
> would
> event
> either by a
> everyone
> there
> set
> throughout.
> news:3a8acefd$1 at server1.Activeworlds.com...
> with the
> in
> proxima
> can be
> commands
> instances
> which
> with
> object
> about
> path is
> without too
> own set
> write
> time=4;
> a
> since
> semicolon.
> rotating at
> "move 0
> 10
> part...
> It
> is
> just
> bet
> for
> command to
> option
> coords,
> effects
>
>
|
Apr 4, 2003, 2:47am
>
> Anyways... it is on the list but not simple
>
*whispers into Ricks ear - psst, custom avatars...psst.. The
List...psst...curtom avatars....psst..been waiting for
years...psst...psst...psst*
hehehehehe
F.
Apr 4, 2003, 10:32pm
..... sounds like the long way around to reinvent the wheel.
Do it like Enzo says. Ditch the bots. They're not cost effective to keep
online 24 hours anyways for the "normal" users who aren't bot-savvy and/or
can't afford the time or money to keep their bots on a 24-hour broadband
connection. :P AW's common features are supposed to be accessable to
everyone. That's how you build a userbase, by implementing features that
people want. But I suppose I'm preaching to the choir.
Simple in explaination, tough in execution, but it pays off in spades.
Chris
[View Quote]"technozeus" <TechnoZeus at usa.net> wrote in message
news:3e8cfb90 at server1.Activeworlds.com...
> The way KF was recommending (through SDK commands) would not add anything
at all for builders directly in any world, but would instead allow bot
designers to produce bots which would control such things. Technically,
that could be done now with a bot, but would require a more complex bot
program than if special SDK enhancements were made. Of course, those SDK
enhancements would also require programming to add, so one way or another
it's a lot of programming. In short, the answer is no... adding such
commands to the SDK would add nothing to public building worlds for builders
to take advantage of, and they would not directly add anything to private
worlds either, nor would they add anything even indirectly to any worlds at
all unless someone wrote a bot to indirectly add functionality and that
particular world's caretaker allowed someone to run that bot in that world,
and the additional functionality would only be available while the bot is
running.
>
> Of course, if the same functionality were to be added in commands designed
to work from inside of an object's Action line, many existing bots could
take advantage of them without having to modify the bot at all, and newer
bots could still be written specifically to take advantage of the new
functionality.
>
> TechnoZeus
>
> "sw chris" <chrisw10 at skywalkeronline.net> wrote in message
news:3e8cd6d1 at server1.Activeworlds.com...
build
on
eg.
currently
that
to
need
object
with
door
sees
to
command
it
be a
shared
could
(elevators-
expecially
see
them
command
combined
wait).
thought
Motion
its
going to
start
this
things to
have
moves
it!
which
are
then
I'll
easy
world
>
>
|
Apr 4, 2003, 11:26pm
Exactly. That's why I recommended something that would benefit everyone who can build, whether they use a bot to do their building or not.
TechnoZeus
[View Quote]"sw chris" <chrisw10 at skywalkeronline.net> wrote in message news:3e8e2435$1 at server1.Activeworlds.com...
> .... sounds like the long way around to reinvent the wheel.
>
> Do it like Enzo says. Ditch the bots. They're not cost effective to keep
> online 24 hours anyways for the "normal" users who aren't bot-savvy and/or
> can't afford the time or money to keep their bots on a 24-hour broadband
> connection. :P AW's common features are supposed to be accessable to
> everyone. That's how you build a userbase, by implementing features that
> people want. But I suppose I'm preaching to the choir.
>
> Simple in explaination, tough in execution, but it pays off in spades.
>
> Chris
>
> "technozeus" <TechnoZeus at usa.net> wrote in message
> news:3e8cfb90 at server1.Activeworlds.com...
> at all for builders directly in any world, but would instead allow bot
> designers to produce bots which would control such things. Technically,
> that could be done now with a bot, but would require a more complex bot
> program than if special SDK enhancements were made. Of course, those SDK
> enhancements would also require programming to add, so one way or another
> it's a lot of programming. In short, the answer is no... adding such
> commands to the SDK would add nothing to public building worlds for builders
> to take advantage of, and they would not directly add anything to private
> worlds either, nor would they add anything even indirectly to any worlds at
> all unless someone wrote a bot to indirectly add functionality and that
> particular world's caretaker allowed someone to run that bot in that world,
> and the additional functionality would only be available while the bot is
> running.
> to work from inside of an object's Action line, many existing bots could
> take advantage of them without having to modify the bot at all, and newer
> bots could still be written specifically to take advantage of the new
> functionality.
> news:3e8cd6d1 at server1.Activeworlds.com...
> build
> on
> eg.
> currently
> that
> to
> need
> object
> with
> door
> sees
> to
> command
> it
> be a
> shared
> could
> (elevators-
> expecially
> see
> them
> command
> combined
> wait).
> thought
> Motion
> its
> going to
> start
> this
> things to
> have
> moves
> it!
> which
> are
> then
> I'll
> easy
> world
>
>
|
Apr 5, 2003, 8:36am
i agree! custom avs are needed, otherwise most people will have no reason to
make avs! :)
oh, and the post you are replying to is over 2 years old!!!!
[View Quote]"facter" <invurt at hotmail.com> wrote in message
news:3e8d0e51 at server1.Activeworlds.com...
>
>
>
> *whispers into Ricks ear - psst, custom avatars...psst.. The
> List...psst...curtom avatars....psst..been waiting for
> years...psst...psst...psst*
>
> hehehehehe
>
> F.
>
>
|
Apr 15, 2003, 3:45pm
CUSTOM AVS IT IS!!!
E
[View Quote]"swe" <swe at swe-e.com> wrote in message
news:3e8eb1a3 at server1.Activeworlds.com...
> i agree! custom avs are needed, otherwise most people will have no reason
to
> make avs! :)
> oh, and the post you are replying to is over 2 years old!!!!
> "facter" <invurt at hotmail.com> wrote in message
> news:3e8d0e51 at server1.Activeworlds.com...
>
>
|
|