Irbis

I tend to disagree with you. The purpose of these default behaviors is to create a quick and simple series of actions which follow (what is perceived to be) the most common usage of these actions. It is not to handle EVERY SINGLE possible usage. As such, there are many things these behaviors are not going to do that each individual user may want. In these cases, there are 3 options:

1 - learn to work with the behavior as it is.

2 - create your own behavior that does what you want.

3 - send in an enhancement request to have the behavior changed. If enough people show interest in changing the behavior to change Ashley's perceived idea of the most common way it would be used, and to add enough value to the product, then the change will most likely be made. If not, the change will only take away time for adding features that will add value. Why change something that is working as desired for the majority of users.

Developing new features adds value that makes the product more marketable and brings in income. Changing features that are working just fine for the majority of users, just because a small minority want it, does not. That being said, I believe at least some of the features mentioned by shinkan would be very useful. Especially having the fade behavior take into account the current alpha value of the object when it begins to fade.

BTW shinkan the axes drag and drop feature can be faked easily, and without too many extra events, by setting the x/y value to it's locked position every tick. If the locked axes is the y axes, set a variable to store the start y position and every tick, set the sprite y back to the stored value. If the locked axes is the x, do the same for the x. See the attached capx. You can do a similar work around to fake many of the other things you are requesting as well.

1 - Cut down the number of events to 100 or less

2 - Cut down the number of layars to 4 or less

3 - Cut down the number of effects to 2 or less

4 - Buy the program

These are really the only options you have.

You could use the array "For each element" event. Create a variable to store the value. Then as you loop through the array, compare the current value to the stored value. If it is higher (or lower as the case may be), you would set the variable to the current value.

That all depends on if you want the game to randomly choose the image each time, or if you want it to choose the background in a specific order.

If you want to make sure it specifically cycles through each background in a specific order you will need to store the last bg used in a variable on the computer and update it each time the game runs. If you do this, you would have an event on start of layout to load the information and select the next bg in the sequence.

If you just want a random background (and this is the easier solution) you would just need to create your background objects, and use the random(N) function to decide which to use.

In both scenarios, you would use a global variable contained in an event sheet, which all scenes had access to, to store the background you have currently selected. You would set this variable on the first scene and and all the other scenes would just reference it to properly set their bg.

Instead of using a static value to represent each and every action, use instance variables to represent which version to display.

I am assuming the list above of boy number and direction is what you name each of your animations.

Use a variable to store the selected boy number: BoyNum = 1

Use a variable to store the selected direction: BoyDir = "up"

Then when setting the animation set it to: "boy" & BoyNum & BoyDir

The above will result in the "boy1up" animation being played.

You could do it easily using an array. Use the array to keep track of the position of all the sprites on the board. Then, when the piece is dropped into place, test the array values. See the attached example.

For uploading, You can attach your file to your post here (if it is smaller than 2 MB). If it is larger, most people here seem to prefer dropbox. It is the most common though it isn't the only method.

You are most likely correct that it is a collision between top and bottom. You could test this easily simply by turning off collisions on 1 or the other. It could also have to o with collisions on background items. If your character spawns inside a solid object or gets pushed into one, it will be pushed out. This could lead to being pushed into another causing it to be pushed more.

If you find that it is caused by the 2 separate sprites, you can do a couple things to fix it:

Option 1 - if you can get by with only 1 of the 2 character parts having collision, than remove it from the other. This will stop the glitch and still allow both sprites.

Option 2 - you can create a controller object which handles moving the character around and pin the character sprites to it. In this option, you would remove collisions from the character sprites and allow the controller to handle it.

Of course there are other ways to fix this but these 2 are simple and should resolve your bug. Good luck with your project.

Check the example EgoAnt posted in this other topic:

He has 2 turrets, each with a different allowed angle of rotation.

I found your previous topic and downloaded your file. When I run it, I see both layouts counting up at the same rate. Starting on layout 1, the text begins counting, when I swapped to 2 it takes up the count right where I left off. I don't see the NaN result. I ran it in Chrome, FF and IE11. It ran fine in all 3. What browser are you using?

NaN means Not a Number. You will want to make sure the 0 is not "0". If it's wrapped in quotes, Construct would try to store a text value, not a number value. Hence the NaN result.

If that is not the case, I would have to look at your capx to help further.

Here is something you can do to make your program a little less CPU intensive:

1 - When a target is found, set a couple variables to store the targets X and Y.

2 - If the target is outside the attack distance of the object with the PF behavior, run the PF behavior to get the original path.

3 - Every second (or any time length you feel works best with your setup) check the targets position against the oiginal X and Y to see if a new path needs to be found (set an acceptable margin of error so if the target is say 10 pixels away from the origin, it still counts as in the origin)

4 - If the target has moved far enough, run these steps over again.

This will keep the PF behavior from triggering every tick and allow your characters to each find their own path.

Add a Global variable which stores the time the layout starts. On start store time in it and use the following equation to set the time text:

settext(int(time - LayoutStartTime))

[attachment=0:29slsrju][/attachment:29slsrju]