Properties for some behaviors - request

Ashley is there a specific reason why some behaviors do not have action, expressions... for some parameters?

Like for example there is no "Period offset" in Sine behavior.

Now the question, should I modify official behavior to add missing parameters? - probably not, because You may change it yourself or add some optimization to it in the future.

Or should I simply duplicate it with different name and then change in myself? - which is kind of dull to have two almost exactly the same behaviors.

and there's quite few behaviors like that: Sine, Fade, DragDrop...

Never adjust the official plugins or behaviors. Just post a feature request.

I'm aware of that and that's why I'm asking ;P

I was thinking about posting a feature request, but there are already a lot of them asking same thing - mostly for Fade behavior what I've noticed and from long time ago.

But ok then. I request to add all missing properties for all behaviors to be able to accessed them in events.

People often request things that are either already supported (perhaps by some other means), or don't make sense (such as setting the startup properties of the sin behavior, which is already too late to change by the time you can use an action). It would be helpful if you can list exactly the properties you're after so it's clear what you need.

I would rather say startup properties of any behavior be very useful in events.

Let's take Drag & Drop for example. You can only set Axes on instance in layout editor and then you can't dynamically create some objects that can move only horizontally or only vertically while dragging. You can't even have two Drag & Drop behaviors on one object to toggle them to set what you need. So you stuck on this and need to workaround using quite few events.

Would not be better to only set

+Create object Sprite on layer Z at  (50,100)
+Sprite: Set something
+Sprite: Set DragDrop axes to Horizontal
+Create object Sprite on layer Z at  (100,100)
+Sprite: Set something
+Sprite: Set DragDrop axes to Vertical[/code:2y0ez5af]

Same goes to Fade behavior. Fade behavior is very simple and very useful for a lot of different things. But there's only Start and Restart actions and not a single one expression. And same thing with creating objects on runtime, If you set parameters for Fade they are final, and every object you create will have exactly same behavior.

I've always treat behaviors as an option to easily and quickly add some functionality to objects. Obviously You can make most of behaviors using more or less events (which I'm doing every time instead of using Fade, simply because there is no control over it) but what's the point of doing something from scratch if this option is already available to You by few simple clicks?

That's why letting user to control all aspects of used behavior would be extremely useful. Someone with advanced knowledge of C2 will find that more pleasent to work, because there will be no need to add more variables and events to do simple stuff. And for people who just started working with C2 will still have simple options to set in editor without using any events.

Ok then here's the list:
1. Fade
  - Set Fade in action
  - Set Wait action
  - Set Fade out action
  - Set Destroy action
  - On fade in finished condition
  - On wait finished condition
  - Get Fade in time expression
  - Get Wait time expression
  - Get Fade out time expression

2. Drag&Drop
  - Set Axes action

3. Sine
  - Set Period random action
  - Set Period offset action
  - Set Period offset random action
  - Set Magnitude random action

That's all from me. Sine and Fade especially. These two are very powerful and stupidly easy to use, adding more freedom to them on runtime creation will make them have probably  unlimited applications.

I would add a "Pick" (as opposed to the "Drop") action for the Drag&Drop behavior.

Also, I believe that the Fade behavior does not take into account the sprite's current opacity value, that creates abrupt flashes when used on sprites with opacity value less than 100. It would be nice if the default behavior began the fade from (or to) the sprite's current (or set from within an action) opacity.

every attribute of any behavior should have a reflecting action/condition/expresion.

Period.

This should not be requested. It should be there from the beggining.

Whats the point of any behaviours if i don't have full control over it?

Instead of adding more and more new features that no one uses maybe make a step BACK and finish whats unfinished (from months/years)?

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.

— You don't need to explain or show me how to do things like that. But what's the point of making my own sine behavior in event, just to have possibility to have control over period offset? It's like reinventing the wheel. It's not difficult, but it's time consuming. I would rather spend 5 mouse clicks to set behavior then 5 minutes to write my own.

And for my initial questions of this post I'm going to attach an image. I want that what's on the left, now i only have what's on the right.

That's why I've asked those three questions. If no one does not feel like to officially add this I will spare some of my free time and make my own behaviors. But first I need an answer from ASHLEY.

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.

whats your damn problem? i can walk and i can drive a car.

i prefer driving. you prefer walking. what it cost you to let me drive?

I request that and this - you don't? then what are you doing here? huh?

Then lets freaking dump all behaviours - because you can do everything via events.

IF you go that path then the whole Construct 2 is a waste of time and space because you can learn programming and you won't need such game making software.

jesus

Why the hell people on this board are such a pain in the ass.

Irbis

While I agree with your point of view to certain degree, being a douchebag wont help your public image wchich certainly can have effect on if Ashley will take you seriously to change something in c2 you suggest.

Irbis

While I agree with your point of view to certain degree, being a douchebag wont help your public image wchich certainly can have effect on if Ashley will take you seriously to change something in c2 you suggest.

i give what i recive. nothing more, nothing less.

I am crawling this forum from 5 years and, i really em way too old to care about my public image(left alone its totaly not the subject of this thread) or sweet talk when i know i am right.

And i much rather prefer a honest douchbag rather then polite ignorant.

I'm with Shinkan and Irbis on this one. Each property SHOULD have an action/condition/expression to go along with it so it can be manipulated at runtime. It's common sense.

Though honestly I think behaviors should be completely dropped from C2 because

-They can be made with events

-Would be far more customizable

-Would teach the user how to code better

-Would clear up numerous bug reports and beginner topics

-Would save Ashley a lot of time.

buuut I doubt that will ever happen so whatever..back on topic..

— a bit of a mixed message there, although very nicely put never the less!

Although I get the feeling that some of you C2 seasoned guys here in the forums are a bit, as you said it, out of topic. I mean, we ARE talking about improving and needing things on a software that is being advertised and being sold for being able to deliver games with out code (the no programming required is a bit misleading, but you get what I mean). If you strip off behaviors and do all stuff with events (even physics I'd assume), what is stopping you to create your own engine from scratch? No need for middle-ware, just code.

Obviously I am being sarcastic, but more often than I would have thought, people here in the forums assume that everyone is a coder and there is no need for C2 to be easy for people that are coming from different disciplines and try to be creative with out hiring a team of programmers.