Cosmetic

Ashley,

I would like to suggest some comsmetic "changes", mainly for flattening the "learning-curve"

1/

A sprite is the grafical face of an object. At the moment it can be changed by changing the animation. (very powefull). But a sprite is not an object. The basename of an object is "sprite",

and it this "leakes" into the events sheet editor. Thats confusing.

2/

There are 3 kinds of events. And the conditions you use (in practice) with those events are very specific.

There (1) are events that dont pick objects (system events, keyboard events ... ) Lets call them the "flow events" IN practice the conditions paired with those, dont filter in the "picked objects", or should not. Doing so makes no sense.

There (2) are events that "pick objects" and feed them to the actions. Conditions paired to those events filter in the "picked group", or should do so.

There (3) are loops. At the moment u can pair up any condiion with a loop, wich i think makes no sense, less u can show me differend.

I really think this should be reflected in the way the wizzard picks objects and in the way u add events and conditions to the sheet.

An example of a nonsense .cap u find here ..

https://dshop.diino.net/getafile/ANGZIZ ... /onzin.cap

This makes no sense, because u can start every blok events with whatever. I personal thnk every blok of events can only start with a "flow event".

You take this as " lowering the possibiltys". And that is not true. Its like ...

Driving conventions say: drive on the road ! Thats not "lowering of posibiltys" (probaly bad english), because there are roads enough. Just like your concept has roads enough.

Restrict the start of a new bloks of events to "flow events" sure take out some unexpected bugs, and lowers the changes for bugs. The caps will be better readable.

And maybe more importand, they say now: the sheet runs "top down".

Wich would mean that a "On mouseclick" dont work as an interrupted? Thats a question. But if the answer is "yes" then i have my doubts by the whole concept of the sheet. Does a mouse event, a keyboard event, a system-object based collision dedection and all those "interrupts" really have to wait for the next "tick" to be "in account" and to be executed ?

If you think this trough, then the only logical aproach is to start each new event blok with a "flow event" ... where "top down" is the mainway of running it, with exeptions to events that need a inmediatly interrupt, as mouse events do. Those last events can be placed everywhere in the sheet then, but can be executed inmediatly.

Hope you see what i mean.

Ty fro reading.

Please forgive me if I've misunderstood, but let me make an attempt to explain this.

In accordance with the example provided, it appears as though you want Construct to decide which actions are appropriate in a given situation. You have a setup where two values are used to determine which action is to be taken, provided one or the other is true at the time. If VALUE_1 is true, you want to make the Sprite move 10 pixels left or right when the appropriate arrow is pressed. If VALUE_2 is true, you want those controls reversed (left arrow moves right, and vice-versa).

The problem you're claiming to be Construct's design flaw is in reality much simpler. As soon as you set both values true, which you indeed do at application start, you've created your own paradox. Now, one press of the arrow moves your sprite 10 pixels in that direction, and 10 pixels in the opposite direction, with a net gain of zero. The Sprite does not appear to move because this all happens in one frame.

This is not so much a factor of learning curve so much as it is just realizing for the first time you have to be mindful of how you set up your events. In this case, if you're using two separate variables to determine which method of control to use, you have to make sure that the two cannot both be true. You need to have a system of telling Construct which event should be true at what time. Construct itself, nor any other programming platform, can ever determine how to handle this situation without further input from you or the user.

--

To address your first issue... "Sprite" is no more than a default name for that object. It is suggested at the creation of every object that you name it yourself. This can be done by clicking on the new object and going to the Common Properties panel (by default on the left of your screen), and changing the object's name at the top. This change is in fact reflected in the Event Editor, even retroactively (meaning you do not have to also rewrite events when you change an object name).

[ASHLEY: Perhaps a "Please name this object" dialog box at the creation of certain objects is a good idea?]

About starting events with what you call "flow events." In short time you will realize how limiting that will be. Please consider playing with one of the tutorials available on the site to get a feel of how eventing works. In general, it works like this:

IF (this),
AND IF (this),
Then do something.[/code:2lame8jn]

The reason you cannot limit starting events with "flow events" is something you've already pointed out.  It [i]does[/i] limit what can be done with the program.  Allow me to explain.

We have the same road you wish to drive on.  We have cars on the road and some stop lights.  We must tell the drivers of those cars what to do when they encounter a stop light.  The easy thing to do would be:

[code:2lame8jn]IF Car is near Stop Light,
AND IF Stop Light is "Red,"
Then stop Car.[/code:2lame8jn]

However, we only have system events to help us here.  Unfortunately for us, this method of picking objects does not classify in your definition as a flow event.  The System Object, one of the flow objects you describe, can give us true or false comparisons between two variables to potentially work around this.  However that method is clunky, and our situation is better resolved by using "pick object events."

Does this mean you have to be careful about making a conflict to this Stop Light event?  Yes.  That's just part of the puzzle you have to overcome.

Regarding loops, I do not believe you're ready for them yet.  You correctly point out that they can be mirrored by standard events, but that is not the point.  Loops are designed to run in between ticks to perform actions that must be computed in advance.  I or any of the other people here can help you with those when you need to use one for the first time.

--

I hope this has helped you understand the process a little better.  Just keep practicing with the event sheets, and be mindful that Construct cannot read your mind to know what it needs to do and when.  You just have to take that extra step or two to let it know what you are thinking.

captain ?

do we agree that the cap you can download here ...

http://www.mediafire.com/?tmdltuje2n1

is "flow" driven ?

and would you be so nice to point out the limitations ?

besides the two that i know allready ..

1/ i can not interrupt the mouse down event ..

2/ i can not interrupt the balls behaviour to read out accurate collision dedection

well maybe you are so nice to teach me how,

your help is apriciated

j0h?

Since this is a "cosmetic" thread, Ashley, can you please fix the 48px Construct icon? It has missing pixels along the bottom of the C.

TheInstance

I get an error opening your file.

You know, I more than figured this was j0h posting again.. But just in case we had a new person trying to learn construct, here I went taking the post seriously and actually trying to help. Shows what happens when I try to be a good little forum-goer.

For one,

i do not hide, look in this treath

For two,

judge me on what i do with Construct.

and here it is .. uploaded again .. be so nice to read opening post to place the .cap in the right context.

ty

http://www.mediafire.com/?tnymthxlmlj

I believe I see better what you mean now. But I ask you, what is it that you have accomplished that Construct does not already do through layouts? If anything, you are adding an extra couple of steps to achieve what is, in your mind, a better means of organization.

Which is fine, don't get me wrong.

Now if we were to remove your starting "flow" checks (a global variable dictating what code to use), we're back to square one. Expanding your flow events out reveals that you are doing no different than the rest of us as far as picking objects via their criteria. In this I will admit you have not limited the scope of the program - if you will also admit you have added nothing but an organizational element to your event sheet.

It's 0400 my time, and I am about to pass out. I will give your .cap a more in-depth look in the morning to see if I can help you with the mouse and behavior stuff. In the mean time I suggest you play around with the Ball Behavior's "Set Activated" function.

To be continued...

Firstly, j0h, please stick to one username only. Looking at the IPs of new registrations you seem to have at least 3 accounts here now, and possibly more. That is confusing for me and the users, please do not sign up any more and stick to your current account.

[quote:3vihb7hl]The basename of an object is "sprite", and it this "leakes" into the events sheet editor. Thats confusing.

It's good practice to rename it as soon as you insert it - Construct can't second guess what you're going to use it for. Although:

[quote:3vihb7hl]Perhaps a "Please name this object" dialog box at the creation of certain objects is a good idea?

This is a good idea and something I had planned.

[quote:3vihb7hl]If you think this trough, then the only logical aproach is to start each new event blok with a "flow event" ... where "top down" is the mainway of running it, with exeptions to events that need a inmediatly interrupt, as mouse events do.

This part of the event sheet editor was designed a long time ago; originally, it was coded by another developer, and at the time I disagreed with him and wanted to make sure triggers must be the first condition of a top-level event, and never be allowed in subevents, since this clarifies how the runtime runs the events. With triggers in subevents, it does obscure the top-down approach, since logically it goes upwards to read above conditions in parent events, then downwards to run actions and other subevents. I don't like this, so I'll see if I can change it.

THX u so mutch Ashley,

As you can see in the included cap,

the behaviour of the ball runs out off sync with the events.

This way a lot of the collissions escape.

There are 2 ways to solve this.

Use (1) a bullet behaviour and calculate the bounces in events yourself. Easy for the walls. Since they are BIG BIG cirkels we can assume the objects go trough the middlepoint when they aproach the walls. And bounce back mirrord arround the normals.

Thats (180 - .angle), (360 - . angle) and (0 - .angle) .

Must be not that difficult to do with the collisions with the cirkels. I know the size of the cirkel. I know the dx and dy between x1,y1 cirkel and x2,y2 aproaching object.

I think it bounces around the tangent.

I got to google this to be sure.

But.. oh man, not using all those nice behaviours ? Thats a shame eh ?

The other (2) solution is to start each block events with "flow" events. They are interruptable.

And to give the plugins (behaviours) events that can interrupt the other events (in a later stage of the developping)

Also, there is another advantage. Its important to make the dissicion to run a certain event or not, as early as possible in the event and with the fastes tools available. Only this way u build speed in big caps.

The fastest tools are the hardcoded system events, and as far as i can see, u did a great job on them.

I am sorry that i made the wrong statement about "global variables" beeing slower. I ofcourse had to test this out. And i was wrong.

About using more "tags", tags as in usernames.

Several times i gave up on this. Each time i gave the username a non existing e-mail and a random password. Thats for me as user the only way i can find to delete a username.

I was't gonna come back, each time.

But then a few days later, i took it up again. Made a .cap illustrating the things that i missed. And i knew its worth it all.

So ty for lookin into what i suggested.

I stil have this need in my veins to make this .cap that shows events combined in a way that should not be allowed by the wizzard. You gonna hate me (again) for it ? or is it um ok to do so ?

We don't hate people for showing if something's wrong with Construct - that's what beta is for, to find possible problems and try to fix them.

I for one would be interested in seeing said .cap, for insight on what others think is the 'wrong' way to combine events.

Let me state (again) that i am not here to demolish Construct.

I fully realise that the render engine is in beta, and the control engine is probaly in alfa.

I stated several times that i think the Whole is a great concept.

I know that i use rough english, i dont even speak it !!

And on top, i did't drink from the Holy Grale. I overlook things. There are things that i dont understand yet.

Althaught i produced some .caps, i still feel Newbie. And as long as Construct is not announced by Ashley as "close to finished", no one can be "expert".

All i do is drop "situations", point out "quirks", and show ways to "alternatives". I think its very cheap to critize and dont bring alternatives yourself. That is not how i am.

So look into this .cap, think a minute about what u see/read. Plz dont give me solutions. There are work arrounds, Construct is flexible. Look at it from the point of "should the wizzard allow this" .. and if yes, why ?

Ty

http://www.mediafire.com/?nhm5g1tym1j

Well, what you're doing is fine, but it comes off wrong. Instead of making a challenge to the community (which IS here to offer solutions and workarounds), make an request directly for a change or addition. I can't speak for the others, but to me the way you've been making points about construct comes off as more combative than constructive (forgive the pun).

If you can do this, not only will we all get along better but we might get things done more efficiently. Got a bug report? Supply a small .cap to display it. Have a feature request? Keep it to a couple of clean paragraphs and encourage further discussion. These things help you help us help Rich and Ashley.

I'll start by apologizing for my bit of snideness earlier. I should have stuck to trying to help out instead of complaining.

Captain i have no problem with you, never had.

You produce the most .caps that have a something to learn from. You been most helpfull.

And i love the flow in your english. I also learn from that.

But as i said before. The "makers" of construct got to "review" the "control engine".

Thats not a command.

Thats an on facts based statement with no strings attached.

Its not judging.

I think i produced enough facts now. Dry and clean.

But considering my position, and the stranger i get taken for,

the statement is just a wish and wishfull thinking.

Do i have to express that ? In attitude and in a language thats not mine ?

I am not able to.

I am not able to take "sensibilty" in account when i write english.

I read it 50 times faster then Dutch, because my brains do not pronounce the words, they are soundless. And i dont get the nuances too.

I write it 20 times faster then dutch because, there is no mental spellchecker reading with me, my brain is not bizzy with "ethics' not whith "beaty of the words", not with ritme, sound and "sensibility"

But when i get comments, like i had, what do you expect me to answer ?

I had a quick look over the example with the 10 example events. Here's a very quick review:

1 - triggers as subevents to triggers shouldn't be allowed, i'll try to fix

2 - as above

3 - nothing wrong with this: when global value = 0, pick a random object. That makes perfect sense.

4 - it's up to you to order your conditions correctly. It doesn't actually matter which way round they are, but as you say, it might be clearer to say 'Global value = 5, pick objects with height < 6'. However, I don't think the IDE should enforce the order of your conditions here, since different ordering might make more sense in different situations, for readability.

5 - triggers should be first condition, i'll try to fix

6 - Makes perfect sense, will loop until y >= 400

7/8 - Not sure whats wrong here?

9 - string literals shouldn't be able to be passed to value parameters, i'll try to fix

10 - What's wrong with this one?