Messages

46

Ask a Question / Re: Collisions aren't being detected?

« on: September 03, 2016, 10:47:53 am »

Which physics settings, specifically, are different for the two slimes? Only the "cannot move" part? (Also, have you tried testing for sides that *were* hit instead of sides that weren't hit?)

47

Ask a Question / Re: Collisions aren't being detected?

« on: September 03, 2016, 10:37:09 am »

Use it like this:



(The blue block on the right of the equal side is found under Actors --- Properties ---> Group/Type. It will have the name of a collision group in it and nothing else.)

You can set different collision shapes to different groups on the right side of the collisions screen for your actor. Make sure you have the slime collision shape's group set to collide with the actor's collision shape group. (click on "edit groups" on the screen to check this).

48

Ask a Question / Re: Collisions aren't being detected?

« on: September 03, 2016, 09:50:22 am »

It almost certainly has to do with your collision shapes -- the top/left/bottom/right collision blocks are only guaranteed to work for rectangles. One workaround would be to create a rectangular "hit box" around the slime (set it to be a 'sensor' so it won't collide with tiles/terrains). You would then use the "group for colliding shape" block to only test this sensor's collisions with the player. It would also be wise to use the "group for colliding shape" block to only test for the player's main collision box, otherwise it's testing every one of your player's collision shapes for a collision with the slime. (Unless you wanted that. If you do, make sure to be testing for which side of the *slimes* collision rectangle was hit, otherwise the multiple collision shapes of the player could produce mixed results.)

49

Ask a Question / Re: Collisions aren't being detected?

« on: September 03, 2016, 06:53:07 am »

Is there a reason you are testing for the collision in opposite ways? In the first collision event, you test for "no top collision for the slime" and the second collision event, you test for "no bottom collision for the player" ... ? I realize that seems like it should be "6 of one, 1/2 dozen of the other", but have you tried testing for collision the same way for both slimes? Also, what are your collision shapes for the slimes and the player?

50

Ask a Question / Re: Actor direction locator

« on: August 30, 2016, 11:55:12 am »

Are you saying that you want a marker at the edge of the screen that will point the player in the correct direction to move in order to find the offscreen actor?

If so, you need the following:

 - The X,Y of the offscreen actor
- An imaginary line that connects the player to this actor
- the intersection of that imaginary line and the edge of the screen

I don't know the precise solution, but it seems like raycasting would likely get the job done, and I believe there's an extension for that. Maybe there is a simpler way ... ?

51

Ask a Question / Re: Rotated Rounded Rectangle?

« on: August 30, 2016, 11:45:26 am »

Must it be a draw command? Could you instead use an actor whose animation is a rounded rectangle? Then you have the option of doing all manner of things with that rounded rectangle (effects, tweening, rotation etc ...). Additionally, the actor would be less taxing on the processor, as many draw commands are not good for performance.

52

Ask a Question / Re: Collision Detection: What is value of using "Is a Sensor"?

« on: August 23, 2016, 02:48:25 pm »

Using a sensor means that there will be no "physical" effect from their collision -- in other words, they will not physically "bump into" each other and stop/slow each other down. They will just pass right through each other, but a "collision" will be recognized by the engine for the purpose of game logic.

53

Ask a Question / Re: How can I make a "not colliding" feature?

« on: August 23, 2016, 09:29:15 am »

I think the simplest way is this: In every frame of logic in Stencyl, collisions happen first, then the "when updating", then "when drawing". So, in the collisions event, set the Boolean attribute to TRUE when the two actors collide, and at *the end* of the actor's "when updated" event, set that Boolean back to FALSE. This way, the Boolean is true for exactly 1 frame of logic and always defaults back to FALSE at the end of that frame. If no collision happens at the top of the next frame, it will still be false. No extra calculations for the processor (you already had a collision event), no extra attributes, very little room for bugs to creep in. (Just make sure you don't have a "stop" block in the when updating event, and if you do, set the Boolean back to FALSE before the stop block as well.)

(The touching/touched logic that Bombini showed is good, but is only necessary if you need to discern between the initial contact and the continuous contact.) If all you need to know is whether or not the two actors are touching, this is simpler.

54

Ask a Question / Re: Change Opacity of Tiles

« on: August 23, 2016, 08:02:27 am »

For changing the tiles, you can use "data for collided tile" and tile API (replace tile # with tile #).

For saving the changes ... your could create a  map  for each scene (as a game attribute, so it persists between scenes) to record the tiles that have been changed. Such as:

Game Attribute Map name: "Scene 1 Tile API"

Key   | Value
3,2        275 

(where 3,2 means "column 3, row 2" and 275 represents the tile ID # that should be displayed there.)

Then, when the player returns to scene 1 and the scene is re-created, have a behavior that runs through each key of the map and changes the tiles recorded in the corresponding map. To do it this way, you would need to be proficient with both maps and string parsing (you have to take the 3,2 key and parse those characters out so that the 3 (as number) can be used as separate data from the 2.

If you had different tilesets that you wanted involved, you could do the map like:

Key   | Value
3,2        17, 275 (where 17 is the Tileset ID and 275 is the Tile ID)

It's not simple as it involves a number of different elements (maps, string parsing, data for collided tile and tile API), but that's how it could be done.

55

Ask a Question / Re: Performance: Windows versus Flash

« on: August 14, 2016, 04:48:46 pm »

I find what Stencyl can handle on the desktop platform to be pretty impressive. I have multiple full-screen shaders running, many parallaxing layers (some with semi-transparency), many actors, a fairly robust platformer engine with multiple collision shapes for the MC, particle effects, trig functions (only a few, though) and when the game is exported, I get a solid 60 fps in Windows mode on my i5 laptop with integrated graphics (no separate graphics card). I was in the same position as you a while ago. I thought it was going to be a Flash game and then I realized I wanted to make it so much more than that. It now is, and Stencyl's engine seems to handle all of it. (Just bear in mind that only a few blend modes work in desktop -- I forget which ones, but Stencylpedia can tell you.) Also, certain actor effects are poorer performing, such as "adjust brightness/make negative/sepia" (though "tint" seems to work well.)

As a direct performance comparison, I get about 2 fps in Flash on the same i5 machine with the current version of my game. (and that's 2 fps *without* the shaders, since Flash doesn't support them anyway.)

56

Extensions / Re: [ALPHA] Positioning Utils 1.1

« on: August 13, 2016, 12:10:37 pm »

OH WOW this is incredible ... thank you yoplalala! So many uses ... (!) This has opened up a lot of really nice platformer game mechanics that would have otherwise been a major headache, if they were even possible before at all.

Thanks again. (Do you have a donation button somewhere?)

57

Resolved Questions / Re: [SOLVED] Time block and animation not synched precisely

« on: August 07, 2016, 07:45:00 am »

OK, glad the first one worked, as it's a little simpler. It's good to limit "update" events, but in this case , the 2nd fix wouldn't be significantly more work for the processor than the first fix, since it's only creating the slime 1 time each spit event. Update events only slow things down when things are actually *done* each frame (creation of actors, complex calculations), not when simply checking attribute values to see if it should do something once. Computers are extremely fast at checking variable values, so you shouldn't be afraid of using the "updating" event as I demonstrated above, if it ever comes in handy (it will).

58

Resolved Questions / Re: Time block and animation not synched precisely

« on: August 07, 2016, 07:07:24 am »

Is your spit animation set to loop? If so, the delay is likely caused by the fact that there is actually a very small amount of time in between the end of this event and the beginning of the next spit event, while your spit animation continues to loop seamlessly. If you switch to a looping animation that is already playing, it doesn't start the animation over, it just keeps it playing. So, in other words:

0ms - first spit event, starts the spit animation
1500ms - second spit event is called (but really, a tiny amount of time passes before second spit event happens because while computers are very fast, they're not "instant".), so the second spit event actually happens at about 1510ms. Doing this, after about 20 spit events, your spit animation, which has been looping continuously the whole time, is maybe about .2 secs ahead of the time event that creates the slime.

There are two ways to fix this, I think, is: 1) Always switch the animation to a different animation at the end of the spit event. 2) Set the animation to not loop,  create the slime based on which frame of the animation is playing. (Use the "Get Current Frame For [Actor]" block under Actors ---> Draw.) This takes estimating the time delay irrelevant altogether.  To do this, put the slime creation block in the "updating" or "drawing" event and use a control Boolean to make sure that it only happens the very first moment that the slime frame occurs. (Set the [Create Slime?] Boolean to "true" at the top of the spit event and then to "false" as soon as the slime has been created in the "updating" event.)

For example, in the "updating" event:

If [Get Current Frame for Actor] = 12    (which starts at 1.2 secs after the animation begins)
         If [Create Slime?] = TRUE
                        [Create {Slime} at X, Y at Front]
                         Set [Create Slime?] = FALSE

59

Ask a Question / Re: hide sprite for actor vs. set opacity to 0

« on: August 05, 2016, 06:20:41 am »

I was recently told by someone on the Stencyl team that "hide layer" is the same as setting the layer opacity equal to zero, so I would assume that the same holds true for sprites, but I suppose I can't say that with 100% certainty.

60

Ask a Question / Re: Toggle shaders for HUD layer

« on: August 02, 2016, 08:24:03 am »

My game uses shaders extensively, swapping them out multiple times in each scene, and I found that this was the best way to ensure shaders would never affect the HUD Layer:



The game attribute {SHADERS ON FOR HUD} is set to default to TRUE. (I don't remember why the .1 time delay was necessary, but it didn't work reliably until I added that. You could probably make the delay even smaller, like .01 secs or something.) The entire event is a custom event inside a scene behavior I made called "Shader Manager", but you could stick it wherever, because it uses a Game Attribute. To use this event, I trigger it immediately after any time my code sets a new shader, regardless of what I believe the current state of the toggle is. By using the control Boolean to see if shaders are ON or OFF, it will never allow the shader to be enabled for the HUD Layer.