(3.1) Move/Rotate Command enhancement (With examples) (Community)

(3.1) Move/Rotate Command enhancement (With examples) // Community

1  |  

35850 !

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

captain mad mike

Feb 14, 2001, 7:32pm
interesting, it may be hard for AWCOM's team of programmers to do so but
interesting.


[View Quote]

casay

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]

bitmaster

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
: > >
: > >
: >
: >
:

casay

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]

j b e l l

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]

holistic1

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

35850 !

Feb 18, 2001, 1:52pm
It wouldn't. Move and rotate already aren't allowed in public building
worlds.

[View Quote]

e n z o

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]

technozeus

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]

kf

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

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]

sw chris

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]

technozeus

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]

facter

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.

sw chris

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

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]

swe

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]

e n z o

Apr 15, 2003, 3:45pm
CUSTOM AVS IT IS!!!

E

[View Quote]

1  |  
Awportals.com is a privately held community resource website dedicated to Active Worlds.
Copyright (c) Mark Randall 2006 - 2024. All Rights Reserved.
Awportals.com   ·   ProLibraries Live   ·   Twitter   ·   LinkedIn