Physics Tools Extension (Beta Release 4)

I think these three blocks would also be very useful:

                       

(In fact, I have needed them.)

I think I could get those added in. The extension is starting to gather a lot of blocks... I thought about splitting the extension into two by grouping the raycasting blocks together, but they're dependent on the other codes.

It'd be nice if the blocks within an extension could be grouped into subcategories (like how the actor blocks have "animation", "layer", and "drawing" subcategories).

It'll be possible to do so pretty soon. The entire palette can already be user-customized with an xml file (as of yesterday), so joining that and the blocks.xml file is the next logical step!

The extension is starting to gather a lot of blocks...

They are interdependent and easy to understand blocks. And I don't think there are many blocks yet.
Indeed, there are other extensions that have more blocks than this extension, and it is not a problem.
Honestly, I don't see the need to split the extension into two.

It'll be possible to do so pretty soon. The entire palette can already be user-customized with an xml file (as of yesterday), so joining that and the blocks.xml file is the next logical step!

Awesome!

That would solve the organization issue much better than splitting the extension.

I can't detect the "first actor on arc" properly, thus I can't stop the trail where I want it to stop.

Here's my behavior in attachment. First of all, how would I go limiting the actors in the arc to type or group?

Second, I'm probably using the block in the wrong way. I have a ball with camera attached to it, that simply bounces around and collides to walls that are actors. I would like to find the wall actor the ball is going to collide with, so I start thinking how to interrupt the trail generation loop (to be honest I still don't quite get how).

What happens is that it only seldom works. Most of the times the "Destiny actor" returns null. I've set 0 to 10 seconds and tried with 100 seconds, most of the time the return is null even though the ball bounces around a stage that is completely surrounded by wall actors.

As for the "Enemy Launcher AI" behavior, I could open it but not test it as it makes my project crash when saving.

Behavior screenshot follows. What am I doing wrong?

how would I go limiting the actors in the arc to type or group?

As shown in the following code.

For a better performance, I use a "fill circle" block to draw the path because it is much faster than creating tens of actors:



The result:

<a href="http://static.stencyl.com/games/32458-0.swf" target="_blank" class="new_win">http://static.stencyl.com/games/32458-0.swf</a>

As for the "Enemy Launcher AI" behavior, I could open it but not test it as it makes my project crash when saving.

That's not good. Is it a particular block that's making it crash?

The "all actors on arc" block was intended to solve the problem of only detecting certain groups or types of actors in the path. The "first actor on arc" appears to be unpredictable in certain cases, but the "all actors" version gives you a list you can filter.

Either way you generate the arc, make sure you're using the right coordinates. I suspect the reason you're getting a lot of "null" results is that you're using the screen coordinates instead of the scene coordinates. Unless your actor is moving very slowly or the scene is very large, 10 seconds ought to be more than enough for most purposes.

Thank you VERY much for that Liberado, I really must have forgotten about the blocks to grab and compare the actor of group or type, I completely forgot about them. Also this is a new usage of a loop for me, never used an if condition inside a loop like that before, so thanks a lot for the programming lesson.

I also didn't know drawing was faster than creating actors, but I suppose you speak from a speed of code execution point of view. From a flash display point of view, I think drawing - which would use flash vectors? - is slower, right?

If that is true I don't know if it's true for mobile and desktop. I know how flash manages vectors and the quality setting, I don't know how Stencyl draws on other platform - are they still vectors, can I still change their quality, and are their slower to display than bitmaps like they should be in Flash? But that's out of topic.

Or maybe drawing does not create vectors in Flash, but some kind of hardware accelerated geometry? I doubt it though, I think it's traditional Flash vectors.

Merrak,

sorry I was mistaken, it does not make Stencyl CRASH - but if I load up that behavior and try to save or test the game, the "Ops! This should have not happened" pop up appears and whatever I do there, Stencyl gets stuck on "saving" and I have to force quit.

The problem seems to be in the last event of the behavior, "EN Projective Collision". It appears like in attachment. The group picking block seems "glitched out"...the "ops!" popup happens even if I just click on it, without testing or saving.

It doesn't crash Stencyl, it simply makes it stuck in "saving..." state. And it does NOT save.

The problem seems to be in the last event of the behavior, "EN Projective Collision". It appears like in attachment. The group picking block seems "glitched out"...the "ops!" popup happens even if I just click on it, without testing or saving.

I think it's just that the behavior was exported with groups you don't have defined. I'll update the behavior so that you won't have to fix it manually--but changing that condition to reference groups you have should fix the problem.

I think these three blocks would also be very useful:

                       

(In fact, I have needed them.)

I got the first two implemented (just need to test them).

That third one though... 
It doesn't look that complicated, but solving for that angle translates to a rather nasty non-linear system of equations. The system below needs to be solved for n (length of time the projectile spends in the air) and T (direction of motion). (All other symbols are constants)

Code: [Select]

0 = x1 - x2 + n*( v * Cos(T) ) + (1/2) * ( n^2 + n ) * gx
0 = y1 - y2 + n*( v * Sin(T) ) + (1/2) * ( n^2 + n ) * gy

I might be able to come up with a more "graceful" solution if I think about it for a while, but for now the best I can come up with is a numerical solution--which will be slow.

I might be able to come up with a more "graceful" solution if I think about it for a while, but for now the best I can come up with is a numerical solution--which will be slow.

I don't think it will be so slow.
I am glad to know that this block will also be implemented.

I don't think it will be so slow.
I am glad to know that this block will also be implemented.

Beta Release 4 adds this block. The angle block is implemented using an approximation. There's no input for the accuracy of the approximation in the blocks, but this number is easy to adjust in the .hx file. The code will approximate the "aspect angle", then return the corresponding angle of motion.

The "aspect angle" should be accurate within about 0.005 degrees.

Ok, thanks a lot. I will test it.

I am really surprised by the accuracy and good performance of this extension when drawing paths.
It is an excellent extension. I only miss the block that I mentioned in my previous post.

<a href="http://static.stencyl.com/games/32401-0.swf" target="_blank" class="new_win">http://static.stencyl.com/games/32401-0.swf</a>

Which block have You used to achieve the trajectory line of the bomb in a sling?

Which block have You used to achieve the trajectory line of the bomb in a sling?

This is a simple way to draw the trajectory. "ax" and "ay" is my actor's position on the screen (emphasis on screen, not scene), and vx, vy the velocity the player will launch the projectile at when fired.