work it

why are you guies still giving atention to this cramp ? he's obviously looking for atention, I wonder if this guy is stupid or just pretending to be stupid, either case he's not funny just making himself look like an asshole.

Now well Ashy,

sorry to disappoint you, sorry to sound disappoint.

But in my eyes, its not a bug, not even an error.

Its a inevitable result of the way the events editor is organised.

Its organised from your perspective, from the inside out.

The constructor (the person who constructs in construct) looks outside in.

I would like the events editor to reflect the following in syntax, work flow and especially in the limiting of combinations.

*events

the detectors of situations. they general start with "on". so i will refer to them as "on's" too.

• keyboard events (on key pressed)
• system events (on object out of view)
• object events (on end of animation)
• step events (on always)
• plug in events (on step - bullet)
• mouse events (on left click)
• timeline events (on start layout)

*conditions

conditions are always paired up with events. They decide to run the actions/loops in the current event or to skip to the next event.

they are the "when's"

• object related (when on layer (x), when visible)
• system related
• plug in related (when gravity is lower the (x) )

Conditions are as general as possible. Because the object is picked in the event already.

Conditions are meant to speed up things by detecting conditons met/not met, before the system looks into the actions/loops.

Another reason why conditions need to be as general as possible and handle as less code as possible.

*comparing

the "if's"

-object related (if objects local variable = true)

-system related (if global variable is true)

• plug in related (if variable x in behavior y is true)

*loops

*and actions the "do's"

At the moment u find if's and when's and on's every where and not organised and overlook able in an easy way.

At the moment u can combine if's with when's, leading not working constructions

At the moment u can when's combine with loops, and the when's pick objects, disturbing the object pickings in the loops

At the moment u can combine if's with events, and the if's disturb the object pickings of the events

really don't sound familiar ?

now to go a little deeper in the concept of an event.

Events you can visualize by:

A fisherman trowing his fish line in the water. Waiting for a snap on the line. As sign that there is something on the hook.

He then pulls the line up, examines whats on the hook, and decided to keep it or not. He will keep a good fish, and trow back a bad fish.

And that's all. To bring this to construct.

In general, an event is meant to detect the situation defined in its event line. It should then record the Info about what happened in an easy accessible way.

Accessible by the conditions (the when's) , the actions (the do's) and the loops

More specific. Lets bring this to the collisions detection events.

""on object collisions detected""

lets assume it returns 'true' and the execution is now passing to the condition ..

but where is the info to feed the condition with ? Especially when its about instances created on run time. They can be anywhere and be anything.

It could be easy though (and not only for conditions).

just let the event make a faceless family object containing all the objects involved at the moment of detection.

Faceless, similar to the keyboard object, the system object ......

Now when constructing the conditions, the actions and the loops all you have to do is what you always do. This object can be read-out as every other object.

It cant be more elegant and construct alike ... especially in dealing with objects created on run time.

Now ashy, give me permission to answer all the nasty kiddie comments. plz ?

ty ?

MikeD, you are also warned: if anything, attack the argument, not the person, and your post was blatant flamebait. There is no need for this.

In regards to the original problem:

For Each Sprite

Sprite is on layer 2

: Rotate sprite

This is now fixed, for what it's worth, but note it has identical effect to this:

Sprite is on layer 2

: Rotate sprite

This event alone will check every Sprite, one by one, and pick the ones on layer 2. You don't need a For Each; Construct does this automatically.

As for your other ideas - some of them don't seem quite right to me. Do you want to force every event to have a trigger (an "on" event) in it? If so, I would see that more as a limitation than an improvement. It'd make it difficult to do something while the left mouse button is down, for example.

In the existing event structure, your fishing analogy could be like so, with subevents:

On line tugged

: Pull up line

: Inspect fish

----> Fish is good

----: Store fish

----> Fish is bad (or ELSE)

----: Throw fish back

Therefore, I think events can easily represent real-world situations and logic as it is. You may also be interested in Condition Aliasing in the function object (read about it here) which would allow you to literally make a condition that says "Fish is good", as opposed to comparing some number or something less obvious.

Also, you mention you have difficulty with instances created at runtime. What specific problem are you having? You can use instances created at runtime in exactly the same way as ones which are created in the layout editor.

[quote:kp5cbi51]

""on object collisions detected""

lets assume it returns 'true' and the execution is now passing to the condition ..

but where is the info to feed the condition with ? Especially when its about instances created on run time. They can be anywhere and be anything.

If you can't keep track of your objects at runtime then you need to learn how. That's all. There's nothing keeping you from it. There is no "make an unknown thing and put it in a random place so I can't do anything with it" action in Construct. So what is your point?

If you're unhappy about certain things not working (like the Else condition) then you just have to realize that CONSTRUCT IS IN BETA. It's actively being created as we speak. The Else bug was a known issue before you made this thread, and if you actually read the forums you would know that.

As for Ashley making pixel shaders and other cosmetic features... that's his prerogative. He's in charge. He works on Construct in his spare time as he sees fit. You have no control over how Construct is made. As an end-user (or rather a tester... remember it's BETA) the most you can do is politely make suggestions. Just because Construct doesn't work exactly the way you want it to doesn't mean you get to be director of the board. It's not called "j0h's Construct."

So yes, I agree with SB. You are being a jerk. You come breezing in like a cocky know-it-all and throw around criticisms when you:

a) Don't seem to really understand how to use Construct

b) Haven't tried making anything in Construct (from what I can see)

c) Haven't put any time or energy into incorporating yourself in the Construct community

d) All of the above

If you really want to see Construct do well, my advice is this:

1. Admit you need help with the stuff you don't understand

2. Help out with bugfixes and make polite suggestions for new features

3. Relax, and quit acting like a jerk

Since I warned j0h about posting inflammatory remarks I cannot find another case where he has done so; and yet it saddens me to find everyone else having a problem with him himself and not his ideas, which any user is entitled to. j0h, I apologise on behalf of all the users here. I will lock this thread now to let things cool down.