1  |   Order by index

Feb 22, 1999, 10:15pm

Currently, to do a movement animation of the same object one has to have =
multiple copies of the object in different positions coupled with complic=
ated astart/adone, visible, and solid (if you want more realism) commands=
=2E Not only does this fill up a cell against the dreaded cell data limit=
, it also unnecessarily bogs down the frame rate with more polygons from =
all the duplicated objects.

Why not have a way for AW to remember where the object is to go instead? =
Have one (1) object and the "movement path". To do this, one way would be=
to move the object for each "step" (frame) of the movement animation and=
have a way of recording that step/frame. Each step/frame position would =
be added to, say, the object's action field in the first step/frame. A ne=
w movement animation command would probably need to be created (perhaps c=
alled "move"). Positions could be recorded relative to the start position=
, with "a" (altitude), negative (-) numbers designating left/backwards/do=
wn, and "r" (rotation). So if I wanted to make a simple rotate animation,=
the step movements could be something like "create move me 24r" (never d=
id like how that lame "me" is necessary; the current object should be ass=
umed by default) would rotate the object 24 rotations (r) whereas "create=
move me 24" would move the object 24 movements (half-meters), or 12m. Re=
petition would be default; stopping the animation could be done with a "s=
top" argument or something.

OK, well, this system needs more thought but hopefully you get the idea. =
However AW records the steps/frames, it would be a lot easier to just mov=
e the object to each step/frame and hit a record/remember button, similar=
to how a macro recorder works.

Feb 23, 1999, 9:45am

Sounds like an interesting idea except:
Imagine the anarchy if the object moves to your neighbour territory! And =
how about the constant server load?
Or do you imagine it done by the browser only ? Then you have to limit th=
e movement range too.
Andras


[View Quote] > Currently, to do a movement animation of the same object one has to hav=
e multiple copies of the object in different positions coupled with compl=
icated astart/adone, visible, and solid (if you want more realism) comman=
ds. Not only does this fill up a cell against the dreaded cell data limit=
, it also unnecessarily bogs down the frame rate with more polygons from =
all the duplicated objects.
>
> Why not have a way for AW to remember where the object is to go instead=
? Have one (1) object and the "movement path". To do this, one way would =
be to move the object for each "step" (frame) of the movement animation a=
nd have a way of recording that step/frame. Each step/frame position woul=
d be added to, say, the object's action field in the first step/frame. A =
new movement animation command would probably need to be created (perhaps=
called "move"). Positions could be recorded relative to the start positi=
on, with "a" (altitude), negative (-) numbers designating left/backwards/=
down, and "r" (rotation). So if I wanted to make a simple rotate animatio=
n, the step movements could be something like "create move me 24r" (never=
did like how that lame "me" is necessary; the current object should be a=
ssumed by default) would rotate the object 24 rotations (r) whereas "crea=
te move me 24" would move the object 24 movements (half-meters), or 12m. =
Repetition would be default; stopping the animation
> could be done with a "stop" argument or something.
>
> OK, well, this system needs more thought but hopefully you get the idea=
=2E However AW records the steps/frames, it would be a lot easier to just=
move the object to each step/frame and hit a record/remember button, sim=
ilar to how a macro recorder works.

Feb 23, 1999, 10:02am

The evil astart and adone commands are easy to use I have built
a mech like thing you push the button and it fires objects out
of its cannon.


Horizons

Feb 23, 1999, 6:13pm

Well, you could approach this from another direction, when is the EXTRA H=
uge cell limit coming? :o)

[View Quote] > Currently, to do a movement animation of the same object one has to hav=
e multiple copies of the object in different positions coupled with compl=
icated astart/adone, visible, and solid (if you want more realism) comman=
ds. Not only does this fill up a cell against the dreaded cell data limit=
, it also unnecessarily bogs down the frame rate with more polygons from =
all the duplicated objects.
>
> Why not have a way for AW to remember where the object is to go instead=
? Have one (1) object and the "movement path". To do this, one way would =
be to move the object for each "step" (frame) of the movement animation a=
nd have a way of recording that step/frame. Each step/frame position woul=
d be added to, say, the object's action field in the first step/frame. A =
new movement animation command would probably need to be created (perhaps=
called "move"). Positions could be recorded relative to the start positi=
on, with "a" (altitude), negative (-) numbers designating left/backwards/=
down, and "r" (rotation). So if I wanted to make a simple rotate animatio=
n, the step movements could be something like "create move me 24r" (never=
did like how that lame "me" is necessary; the current object should be a=
ssumed by default) would rotate the object 24 rotations (r) whereas "crea=
te move me 24" would move the object 24 movements (half-meters), or 12m. =
Repetition would be default; stopping the animation
> could be done with a "stop" argument or something.
>
> OK, well, this system needs more thought but hopefully you get the idea=
=2E However AW records the steps/frames, it would be a lot easier to just=
move the object to each step/frame and hit a record/remember button, sim=
ilar to how a macro recorder works.

Feb 23, 1999, 6:24pm

Of course you could always try using Bots as moving "objects", but it see=
ms that in AW they have already done that. :o(
(Why are people always one step ahead of me?)

But I agree that a "move" command would be very useful. :o)

Charters
Charters World (aurac)


[View Quote] > Well, you could approach this from another direction, when is the EXTRA=
Huge cell limit coming? :o)
>
[View Quote]

Feb 23, 1999, 6:36pm

[View Quote] > Sounds like an interesting idea except:
> Imagine the anarchy if the object moves to your neighbour territory!

Uh, what anarchy? Just with how object movement animation is done now, depending on the name given to objects, it will either work correctly or not.

> And how about the constant server load?

Uh, WHAT "constant server load"? AW already IS a "constant server load" anyway...

> Or do you imagine it done by the browser only ? Then you have to limit the movement range too.

What are you talking about? I already said the step/frame declaration would be in the object's "action" field, so that would mean AW handles everything, just like AW handles current object movement animations using the astart/adone animation commands.

Feb 23, 1999, 6:39pm

Easy is relative. Try doing more complex animations like the ones I have at Hole 25s 10w (or so). It's a bitch.

[View Quote] > The evil astart and adone commands are easy to use I have built a mech like thing you push the button and it fires objects out
> of its cannon.

Feb 23, 1999, 6:44pm

Er, 24s 15e.

[View Quote] > Easy is relative. Try doing more complex animations like the ones I have at Hole 25s 10w (or so). It's a bitch.

Feb 23, 1999, 7:11pm

While this IS another perspective, it is inefficient. The whole POINT of redoing object movement animation is to make it easier and not as much strain in duplicating an object, causing more polygons to have to be rendered (thus reducing frame rate and performance). If AW had a better "action" system (like with checkboxes, pull-down lists, etc that I outlined months ago in another post), cell data wouldn't be as crucial, because the actions would be in binary vs ASCII form and much quicker to process.

So increasing the cell data limit only puts off the growing problem that needs to be fundamentally redesigned.

[View Quote] > Well, you could approach this from another direction, when is the EXTRA Huge cell limit coming? :o)
>
[View Quote]

Feb 23, 1999, 8:00pm

EEP, it is intelligent!!!



[View Quote] So increasing the cell data limit only puts off the growing
problem that needs to be fundamentally redesigned.

[View Quote] > Well, you could approach this from another direction, when is
the EXTRA Huge cell limit coming? :o)
>
[View Quote]

Feb 23, 1999, 9:49pm

This is a multi-part message in MIME format.

------=_NextPart_000_010A_01BE5F44.23B609A0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


There's a thing that's been on my personal AW wishlist for almost 3 =
years. *grin*

Roland told me in Dec 96 that he really hates the whole action concept =
as he wrote it... however reimplimenting a whole new action system is =
going to require some careful thought. Hopefully it'll eventually =
involve server-side action of some sort, ala quake2. That involves the =
use of a lot more bandwidth per user, however. Not to mention a =
substantial amount of complexity in design and implementation... so in =
short don't hold your breath on this. I think there are a lot more =
important time-consuming issues, such as 3d card support, that require =
immediate attention.

Rjinswand

[View Quote] Why not have a way for AW to remember where the object is to go instead? =
Have one (1) object and the "movement path". To do this, one way would =
be to move the object for each "step" (frame) of the movement animation =
and have a way of recording that step/frame. Each step/frame position =
would be added to, say, the object's action field in the first =
step/frame. A new movement animation command would probably need to be =
created (perhaps called "move"). Positions could be recorded relative to =
the start position, with "a" (altitude), negative (-) numbers =
designating left/backwards/down, and "r" (rotation). So if I wanted to =
make a simple rotate animation, the step movements could be something =
like "create move me 24r" (never did like how that lame "me" is =
necessary; the current object should be assumed by default) would rotate =
the object 24 rotations (r) whereas "create move me 24" would move the =
object 24 movements (half-meters), or 12m. Repetition would be default; =
stopping the animation could be done with a "stop" argument or =
something.

OK, well, this system needs more thought but hopefully you get the idea. =
However AW records the steps/frames, it would be a lot easier to just =
move the object to each step/frame and hit a record/remember button, =
similar to how a macro recorder works.


------=_NextPart_000_010A_01BE5F44.23B609A0
Content-Type: text/x-vcard;
name="Rjinswand.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Rjinswand.vcf"

BEGIN:VCARD
VERSION:2.1
N:;Rjinswand
FN:Rjinswand
ORG:Rjeneration
URL:
URL:http://table.jps.net/~rjins/rjeneration
EMAIL;PREF;INTERNET:bcnu at psicorps.com
REV:19990223T234946Z
END:VCARD

------=_NextPart_000_010A_01BE5F44.23B609A0--

Feb 23, 1999, 10:01pm

This is a multi-part message in MIME format.

------=_NextPart_000_0139_01BE5F45.B7885560
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Oh just another note here Eep... when objects are "visible off" they =
are removed from the scene... therefore you do not spend cpu time =
rendering them. Actual object animation would not improve on this. It =
would probably improve on the pauses and certainly the limit of what you =
can do.

Rjinswand

[View Quote] ------=_NextPart_000_0139_01BE5F45.B7885560
Content-Type: text/x-vcard;
name="Rjinswand.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Rjinswand.vcf"

BEGIN:VCARD
VERSION:2.1
N:;Rjinswand
FN:Rjinswand
ORG:Rjeneration
URL:
URL:http://table.jps.net/~rjins/rjeneration
EMAIL;PREF;INTERNET:bcnu at psicorps.com
REV:19990224T000102Z
END:VCARD

------=_NextPart_000_0139_01BE5F45.B7885560--

Feb 24, 1999, 4:54am

Define "it".

[View Quote] > EEP, it is intelligent!!!

Feb 24, 1999, 4:58am

But when right-clicking on one object, they ALL become visible (and rendered), not to mention a bitch to select and edit, especially if a lot of objects are in a small area. Having the SINGLE object step through its movements (or maybe even use wireframe versions of the original object to show the animation path, would speed things up a bit.

[View Quote] > Oh just another note here Eep... when objects are "visible off" they are removed from the scene... therefore you do not spend cpu time rendering them. Actual object animation would not improve on this. It would probably improve on the pauses and certainly the limit of what you can do.

Feb 24, 1999, 4:59am

Duh. I, of all people, KNOW what needs more immediate attention in AW...

[View Quote] > so in short don't hold your breath on this. I think there are a lot more important time-consuming issues, such as 3d card support, that require immediate attention.

1  |   Order by index