A delay=X for most objects.

[GoogleCodeExporter]

Similar to the syntax for sfx after=x, I request a delay=x for most objects. 
Since we already have a wait/nowait argument for bg/fg/obj, I figured we should 
have a differentiated, but essentailly same, argument for those objects. That 
way, authors can fine-tune certain object animations. Also this would 
potentially cut down on the size of the asset required to do certain things, 
like a complete VS screen.

Original issue reported on code.google.com by earlAcda...@gmail.com on 3 Feb 2014 at 5:58

[GoogleCodeExporter]

To clarify, you are wanting it to work like so:

obj SomeAnimation delay=60

and then 60 frames later SomeAnimation begins to display? Or are you meaning to 
have the object stay visible for 60 frames before going away?

Note that it is not well documented, but you can (and probably should) control 
how long each frame in an animation is displayed. You could achieve the same 
effect by setting the delay on a blank frame 0 to 60. An example of how to do 
this in the standard assets is in art/general/evidence/showevl.txt, used for 
the showing evidence macros. The first frame is shown very briefly, while later 
frames are shown longer.

Original comment by saluk64007@gmail.com on 3 Feb 2014 at 9:46

[GoogleCodeExporter]

I suppose that can work. 

But then let's take a more complex example. Let's say one wanted to do a VS 
screen at the same time as the "Cross-Examination" screen. The aim of this is 
to use as few resources as possible and then use the built-in commands to do 
the animating. 

fg white y=192 name=wit
obj general/DefenseVS x=-128 y=244 name=def
obj general/ProsecutorVS x=386 y=304 name=pro
obj general/VSBars y=192 name=bar delay=60
bg VSbg y=192 name=vs nowait
fg CrossExaminationAnim name=ce nowait
scroll name=def x=128 speed=6 delay=69 nowait
scroll name=pro x=-128 speed=6 delay=69
fade in speed=4 name=wit
delete name=def
delete name=wit
delete name=bar
fade out speed=4 name=wit
pause 60
delete name=vs

(probably not the way I'd actually do this, but it's the first thing that came 
to the top of my head)

If you think this is not necessary, then it's fine.

Original comment by earlAcda...@gmail.com on 3 Feb 2014 at 11:46

[GoogleCodeExporter]

I'm not saying it's not necessary, just trying to get a handle on what you want 
and figure out the best way. 

Just to be clear, in your example, which of these scenarios are you expecting:

Scenario A
DefenseVS, ProsecutorVS, and VSBars are displayed
VSbg, and CrossExaminationAnim are added
DefenseVS, ProsecutorVS begin to scroll
while the scrolls happen, the white overlay fades in
60 frames later VSBars is removed

Scenario B
DefenseVS, and ProsecutorVS are displayed
VSbg, and CrossExaminationAnim are added
DefenseVS, ProsecutorVS begin to scroll
while the scrolls happen, the white overlay fades in
60 frames in VSBars is displayed

Original comment by saluk64007@gmail.com on 4 Feb 2014 at 9:10

[GoogleCodeExporter]

Scenario B is closer to what I was thinking.

The thing about the bars is that it's a short animation that runs once so the 
VSBars are displayed a little after both VSbg and CEAnim are added. Then after 
that, the VSes begin to scroll. The white overlay fades in to complete the 
first half of the animation complex. The second part happens when the white 
overlay fades out, where three elements gets removed.

Original comment by earlAcda...@gmail.com on 4 Feb 2014 at 9:46

[GoogleCodeExporter]

Ok that makes sense. How about keeping it "after=" so it is consistent with sfx?

Original comment by saluk64007@gmail.com on 5 Feb 2014 at 12:47

• Changed state: Accepted
• Added labels: Component-Engine

[GoogleCodeExporter]

That is the most logical solution.

Original comment by earlAcda...@gmail.com on 5 Feb 2014 at 2:08