Messages

1

Ask a Question / Re: StencylForge Quality

« on: March 26, 2017, 06:55:19 pm »

The answer to this problem is community moderation, but then you run into the problem of doing that at sufficient scale to ensure that all the submissions to StencylForge are good quality. So then we might need some way to raise the barrier to submission, such as allowing only submissions by those who have published well-polished games, or those who have a certain reputation on the forums. Some kind of function to auto-detect similar entries to avoid lots of duplication should help too.

2

Ask a Question / Using Git with Stencyl

« on: May 08, 2016, 06:33:45 pm »

Hi everybody,

Is it possible to use Git or any other version control system with Stencyl projects?

3

Ask a Question / Re: Flashing actor doesn't work

« on: May 07, 2016, 08:40:04 pm »

Thanks for your help. I combined noxtudio's and gplar's solutions.

I created a Behavior for flashing:
Do every X seconds
    fade in
    do after y seconds
        fade out

Then I attached this Behavior to the Actor. In a When Created block, I enable that behavior then disable it after a few seconds. I also use  Boolean so it only flashes after a respawn, not the initial spawn. Works well and this way I can easily invoke the Flash behavior from any event. Its timing variables are hard coded for now but I'm sure there's a way any calling code can pass in values for them. This way the flashing behavior can be event-specific.

I wonder if there is a bug lurking here: suppose you aren't careful with your timing and the Flash behavior is disabled during a fade in/out or in between fade out and fade in? Will you be stuck with a half-transparent or invisible Actor?

4

Ask a Question / Flashing actor doesn't work

« on: May 06, 2016, 02:41:26 pm »

Hi,

I almost feel bad asking this since the problem is likely very simple, but I haven't solved it.
I want to make an actor flash when respawned. My code is:

repeat n times
    fade last created Actor to 0% over 0 sec using none
    do after s seconds
        fade last created Actor to 100% over 0 sec using none

I've attached the whole respawn event. It creates the player in the center of the screen, makes it temporarily invulnerable, and is supposed to flash the player.

5

Ask a Question / Re: can't spawn large objects off screen

« on: May 05, 2016, 01:54:11 pm »

I solved the problem (sort of)

The small asteroids had the "wrap around screen" behavior but I had forgotten to give it to the others. Adding it fixed the problem, but I don't understand why. You should be able to create active things offscreen and launch them into the screen without requiring this behavior.

6

Ask a Question / Re: can't spawn large objects off screen

« on: May 05, 2016, 01:38:40 pm »

Thanks for the help.

I tried both suggestions but neither works.
Debug statements for printing the last created actor reveal that the bigger asteroids do indeed get created. So why aren't they arriving from off-screen even with "set always active?"

7

Ask a Question / can't spawn large objects off screen

« on: May 04, 2016, 10:47:05 pm »

Hi,

I'm making an Asteroids clone and I've got small, medium, and large asteroids. I'm working on the spawning behavior now. Small asteroids spawn off-screen just fine but big ones don't even though the logic is exactly the same.  They can all spawn in-screen. The asteroid sizes are about  16x32, 32x64, and 64x128 pixels, if that's relevant.

Any ideas why this is happening?

8

Suggestion Archives / Re: Allow sensors to detect sides

« on: November 17, 2014, 07:25:04 pm »

I thought about the region trick, but the thing is I need some angles when the actor enters/leaves another actor.
Specifically I need the  surface normal of the actor being hit at the point of impact and the collider's angle of incidence with that surface normal. I don't see any way to get these with regions. In fact, i suspect that regions in Stencyl are internally just invisible Box2d sensors.

After reading a bit more on how box2d works and looking at its code, it seems that there is a data structure called a manifold that is generated by colliding objects that contains information like where the collision occurred. Sensors do not create manifolds. This would explain why, for a sensor, in Stencyl you cannot get the x-y normal of collisions or check which side the collision occurred on.
There might be a solution that involves modifying the box2d code so that sensors do create manifolds but nothing is done with them. I'm not sure if this is possible yet; I'll have to study the code some more.

9

Suggestion Archives / Re: Allow sensors to detect sides

« on: November 16, 2014, 03:49:29 pm »

If I understood the engine well enough I could fix it myself, assuming the changes to the sensors doesn't break something else.
The code for the Stencyl engine is available on Github. Does anybody know where to look for sensors and for general collision events?

Actually, I'm not sure if this is a Stencyl issue or a Box2d issue. I'm reading up on Box2d now. If I don't find an answer after a while, I'll ask on the Box2D forums.

update: It appears that sensors in Box2d do not call the pre-collision and post-collision callback functions. In other words,  certain information about the collision or derivable from it is not available.
However, sensors do have the BeginContact and EndContact functions (or else they couldn't sense!) and these do have some physics info.
One difference between Begin/EndContact and Pre/Post solve is that there can be multiple physics events in a single collision, so multiple pairs of begin/end contact callbacks can be called between one pair of begin/end contact.
See here for some more info about how collisions work in Box2d.

So basically, if the info I want is in pre/post solve but not begin/end contact, I am screwed (not really, but the solution would involve modifying the Box2d sensors or else creating a new type of sensor).

10

Ask a Question / Re: Surface normals vs x/y normals

« on: November 15, 2014, 10:43:11 pm »

Hmm. There is a big problem with implementing refraction from inside to outside.
First, the photon must pass through the prism. We can use the workaround of changing the photon's animation to one without a bounding box, but then we must know when to change it back.
Worse, it must be changed back in order to collide with the inner boundary. However, if it gets changed back while the photon is still inside the prism, the prism attempts to eject it.

You might think that making the prism into a sensor would solve this problem, but it doesn't. If the prism is made into a sensor, then the photons can pass through but the x and y normals do not work correctly. In other words, sensors aren't simply physics-less collisions. Some of the collision functionality does not work at all with sensors, such as detecting which side of an actor was hit. This really makes no sense, and I have a thread in the Suggestions sub-forum about this.

11

Suggestion Archives / Re: Allow sensors to detect sides

« on: November 15, 2014, 10:11:46 pm »

Ok. The thing is, this wouldn't work for complex shapes, or would at least be really complicated.

Worse, x/y normals don't work for sensors. I know this because I implemented refraction of a photon (only outside-to-in) using the surface normal and Snell's law. The surface normal is arctan2(y-normal of collision, x-normal or collision).
Even though the x and y normals in Stencyl are actually the impulse normals, not surface normals, it seems that this formula does in fact give the surface normal, at least for a ball colliding with a plane.
When trying to implement inside-to-out refraction, i decided to make my prism into a sensor, so that the photons can pass through. But this one change broke the refraction code because the x/y normals of the collision are no longer correct. This is similar to the sensor not being able to detect which side a collision occurred in.

This really baffles me. Sensors should be exactly the same in every respect as ordinary collision except that they do not automatically apply any physics. If this were the case, then my refraction problem, and lots of other use cases, would be easily solved. It seems from the description that sensors are supposed to be this way, but they actually are not. This ought to be fixed.

12

Ask a Question / Re: Surface normals vs x/y normals

« on: November 15, 2014, 08:27:57 pm »

Thanks.

arctan2(y-normal / x-normal) of Last Collided Actor as degrees

appears to give a surface normal, at least for the case of a round object colliding with a flat surface.
I now have working outside-to-in refraction. Now i need inside-to-out refraction. Can an object collide with the internal of another object's bounding box?

13

Journals / Re: Introducing Hollow Knight

« on: November 15, 2014, 04:38:29 pm »

The visuals are about all there is to see right now, but they are great! Are you guys artists?

14

Suggestion Archives / Re: Allow sensors to detect sides

« on: November 15, 2014, 04:34:03 pm »

This would help some.

Does this involve Haxe coding? I'm not afraid of programming, I just don't know how to do it with Stencyl yet.

15

Ask a Question / Surface normals vs x/y normals

« on: November 14, 2014, 12:53:53 am »

In physics, a surface normal is simply a vector that is perpendicular to the surface.
Stencyl includes "x-normal" and "y-normal" blocks under Collision -> Collision Points, which need to be used with the "For Each collision point" loop.
However, I doubt these are surface normals. Have a look here: http://www.iforce2d.net/b2dtut/collision-anatomy
This seems to say that these normals in box2D are not surface normals but are rather vectors indicating where and in which direction impulse should be applied to most efficiently  separate objects in contact. This may not necessarily be a surface normal.
So if the x/y normals in Stencyl are the same as these box2D normals, they are NOT surface normals!

So then, how do I find out the surface normal? I need to know this to implement beam refraction.