Cosmetic

New releases and general discussions.

Post » Fri May 09, 2008 11:08 am

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.
B
3
S
2
G
4
Posts: 322
Reputation: 2,119

Post » Sat May 10, 2008 4:07 am

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).

[color=#4040FF:2lame8jn][ASHLEY: Perhaps a "Please name this object" dialog box at the creation of certain objects is a good idea?][/color:2lame8jn]

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:

[code:2lame8jn]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 does 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.

:)
B
3
S
2
G
4
Posts: 310
Reputation: 2,120

Post » Sat May 10, 2008 11:00 pm

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
B
3
S
2
G
4
Posts: 322
Reputation: 2,119

Post » Sat May 10, 2008 11:37 pm

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.

8) :wink:
B
2
S
2
G
5
Posts: 391
Reputation: 2,432

Post » Sun May 11, 2008 2:02 am

@TheInstance
I get an error opening your file.
B
3
S
2
G
4
Posts: 310
Reputation: 2,120

Post » Sun May 11, 2008 2:22 am

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.
B
3
S
2
G
4
Posts: 310
Reputation: 2,120

Post » Sun May 11, 2008 7:58 am

For one,

i do not hide, look in this treath viewtopic.php?f=3&t=939

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
B
3
S
2
G
4
Posts: 322
Reputation: 2,119

Post » Sun May 11, 2008 8:16 am

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...
B
3
S
2
G
4
Posts: 310
Reputation: 2,120

Post » Sun May 11, 2008 3:38 pm

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.[/quote:3vihb7hl]
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?[/quote:3vihb7hl]
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.[/quote:3vihb7hl]
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.
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,600

Post » Sun May 11, 2008 5:48 pm

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 ?
B
3
S
2
G
4
Posts: 322
Reputation: 2,119

Next

Return to Construct Classic Discussion

Who is online

Users browsing this forum: No registered users and 2 guests