Animations Totally Bugged?

Theinstance is right. And you are wrong. Fix that bug.

http://www.savefile.com/files/1664634

User "_/\./\_" has been deleted for being an additional account of TheInstance, and TheInstance has been issued with a warning. If this thread does not continue solely for the purposes of pursuing the animations bug, it will be locked.

So let's get back on topic

There is a bug in the latest .cap, now that Only Trigger Once has been added. The Bounce only plays once. Rest assured that this will be looked into.

This thread confuses me. So I'll have to ask a few questions.

I haven't got around to animations quite yet, but I looked at TheInstances' cap and it looked like it has "trigger once" in the events, yet you guys are saying it doesn't? You guys are talking about "always" events, but I don't quite understand the problem here. Unless you mean starting an event with always is so bad it negates the trigger once, but that doesn't make any sense and that's different than what I was lead to believe from the start of looking at this forum and using Construct. I thought the always event didn't really mean much and was just what the program does by default every tick, because when I delete the "always" condition and leave the field blank, it doesn't do anything to the event, and when I run it, it works exactly the same either way. Strange.

<img src="http://img377.imageshack.us/img377/5241/triggersj0.png">

<img src="http://img241.imageshack.us/img241/3999/triggerblankij8.png">

when I delete the "always" condition and leave the field blank, it doesn't do anything to the event, and when I run it, it works exactly the same either way.

From Conditions on the Wiki:

[quote:3ifawsp1]Blank events

It is possible to remove all conditions from an event so it has an empty condition area. In this case, it means the same as Always: whenever this event is evaluated, it immediately runs the actions and tests the subevents. This can be useful if you have an event with lots of subevents, and you want actions to be run after all the subevents have been tested.

It's worth mentioning putting an event as a subevent to an empty Always (or blank) event has no effect, because the parent event does nothing.

Putting an event as a subevent to a blank event gives you the ability to minimize the event, and that might be handy some times if it's an ugly event

[quote:2akow67p]

It's worth mentioning putting an event as a subevent to an empty Always (or blank) event has no effect, because the parent event does nothing.

Yeah i dont know what logic he used, you could say that instead of:

-Always
      -Condition 1
      -Condition 2[/code:2akow67p]

You could do:
[code:2akow67p]-Always
      -Always
            -Condition 1
            -Condition 2[/code:2akow67p]

Same thing that wont do anything different.

[b]Edit:[/b] Karnaugh Map Optimalization!

You could do:

-Always
      -Always
            -Condition 1
            -Condition 2[/code:2ysxil0x]

Same thing that wont do anything different.

That's obvious, because it's not feeding from the first level of the sheet anymore. The first level is an always event just like I thought it was. Why would someone make two levels of blank conditions anyway? I barely even see two levels of always events used. It is worth mentioning though.

<img src="http://img377.imageshack.us/img377/5241/triggersj0.png">

The reason this isn't working with multiple instances of the sprite is the 'trigger once' condition means the event only runs once while the conditions above it are true. Whereas in fact what you want to happen is the event to only trigger once per instance.

The set animation action has been changed now so you can use it in an always condition. If the animation is made to play which is already playing, nothing happens.

Umpphhh,

well i knew that already, and its exactly what i showed you in the first example.

Oh well, we have a saying...

" Wat baten kaars en bril als de uil niet zien wil ? "

I can freely expect the same bug to be gone in the '8 directions" �-aligning ?