Mini-Suggestion Thread

Any thoughts on one-way collision?

A block that returns an actors scale to a factor of 1 = 100%
Instead of having to use a custom code block in Haxe >> return Actor.Scale.X or Actor.Scale.Y

- When dragging a block into a field, it should always be placed there whenever your mouse is directly over that field. Sometimes it can be a real hassle to put getter blocks into an empty field because it will attempt to go into fields nearby and not the one intended. When dragging blocks, it would be very convenient if they would be placed in the intended field 100% of the time.

+1

- I'd like the option in the scene editor to snap actors to the tile grid.

You can do this by holding the shift key.

You can also use the magnet in the top right corner

Improved image scalling, or maybe more scaling options? I import my images at 2x using the bicubic method and when scaled down, they don't look that good with stencyl. I have to import them in photoshop and manually scale them using bicubic automatic and replace the stencyl scaled ones. When you have a lot of images it's kinda time consuming if you're not using pixel art.

Some set of block that work with video player
Don't know why this block not include in stencyl[basically adobe flash doing with video clip as default work]
simple game that use video asset work
 Block that make user like me that don't understand how to code can manage it
in some case user that is video editor want to put his cut scene in or some trailer
and can't find the way or a thread of tutorial about it

ps. I know that in 2.x there are some behavior niccow work with but yes that in code mode
and in the worst way 3.x not supported it
Code is just hard enough then 3.x want user to port that to haxe...
It's make user that got hope from stencyl that present it self as easy block tool so sad 

As discussed in my thread http://community.stencyl.com/index.php/topic,36481.0.html
people get confused about the "direction of actor" block, thinking it returns the direction it is moving in, when it actually returns the direction it is facing.
Currently the way to get the former is:
atan2(yspeed of self, xspeed of self) as degrees
If you use this on a Last Collided Actor, you will get its post-collision velocity direction, not the pre-collision direction.
To get the latter, you need to make an attribute that takes this value and is updated every frame (via an "always" event) and use that attribute (in the frame at which collision occurs, this attribute has the pre-collision data).
However, since the physics engine already knows this information (or else it would not work!) it is inefficient to compute it ourselves.
I suggest removing this inefficiency by creating a block that gets this information from the physics engine. To distinguish between the facing direction and velocity direction, the two types of directions should be named that way in their blocks.
Furthermore, when using Last Collided Actor in a block, it should allow choosing whether you want that actor's pre-collision velocity or post-collision velocity.
Then, instead of the convoluted, counter-intuitive, and inefficient solution I used, one could simply say
"set vector direction of last created actor to pre-collision vector direction of last collided actor"

When you're setting an attribute in a Behaviour to {GAME ATTRIBUTE}, it would be nice that the games attributes are listed by categories and that you see the name of the category.

Another mini suggestion.

In the dashboard, when you see all the games, it would be great to see when it was  last modified. Because I have a few copies of my game and I always  have to check in the folder.

Please add a sprite size editor option for Actors that allow them to stay a certain size upon setting it.

It would be great if the dialog extension would be pre - installed I'm sure it could save a lot of time and effort .   

I don't know how to describe this so here goes...

Instead of making a whole custom block for something like this, I wish I could trigger a  custom event with an attribute. Instead of only calling it by name, have it be called by its name and send an attribute to use for it. Similar to a custom block but without stuffing up the palette or requiring the behavior to be present.

For example, one could "Trigger [WhereAreYou] with [xycoords]"
I've had to come up with a lot of weird ways to get my behaviors and actors to communicate. Mostly just make game attributes and after a while, they get really bloated and not ALL of it really needs to be saved.

If anyone actually has a alternative solution that's already possible, by all means share please.

Also, maybe a "Run Previously Tested Game" that runs the game from the testing sandbox again without having to rebuild it. I know I can fish it out of the folders but most times it doesn't work that way.

I also find setting up custom blocks to be annoying, because you have to get it right the first time and it bloats the palette. These are both issues that will be fixed in the future.

For now, when I don't want to make a custom block, but I still require the ability to call a function and pass arguments, it's fairly easy to do so with a "Custom Code" event.

code: public function functionName(arg1:Int, arg2:Float, arg3:String, arg4:Bool):Void {
===
In between these two code blocks, you can use design mode blocks as normal. To refer to one of your arguments, use an inline code block.
===
code: }

Great Tip Justin !

I have a mini sugestion : when you export game, being able to export it with the extensions.

I'd like to see the code blocks used in the demos in the Stencylpedia so we can see how they did what they did.

Example: http://www.stencyl.com/help/view/effects/

How did they make the buttons effect the actors in the scene? Things like that.

Suggestion : Stencyl users should have a choice to lock their  "Shout Box" and even delete messages from it if
they want .

Reason : because sometimes it could get annoying to have tons of silly messages that are lying around in
your shout box , if they really have a question they should PM you , but just to say a comment over and over again could annoy a user .