Messages

1

Resolved Questions / Re: Download older builds of Stencyl? SOLVED

« on: September 15, 2015, 03:47:36 am »

Hi Everyone,

Thanks so much for offering to help. I (and the student) really appreciate the efforts of this community. You all are great!!!! I have the file now and all is good. PROBLEM SOLVED AND CRISIS AVERTED!

Best,

Cal

2

Resolved Questions / Re: Download older builds of Stencyl?

« on: September 14, 2015, 01:29:30 pm »

Hello Everyone,

Thanks for responding. I am teaching a class using stencyl using the 8529 build. One of my student's wants to download it at home but only has access to the newest build. For compatibility issues I would like him to be using the same version. He claims to have tested exporting a file from the new build and tried opening it in the older build and was unsuccessful.

We use Macintosh computers in our lab but he has a PC at home, so I cant give him that installer file. I double checked my pc at home and couldn't find the build. 

So, if anybody has a Windows build and would like to share it you would be helping out a kid trying to learn Stencyl.

Thanks.

Cal

3

Resolved Questions / Download older builds of Stencyl? SOLVED

« on: September 14, 2015, 05:12:56 am »

Hello,
Hello,

I was wondering if there was any link to older versions of Stencyl builds. I am particularly interested in getting a copy of the  Build 8529 published on  August 17, 2015.

Thanks for your time.

Cal

4

Bug Archives / Re: Re-install Android SDK hangs

« on: June 08, 2015, 08:25:46 am »

Hello,

I wanted to post in here in case anyone else comes across this problem. I tried to update my Android SDK and got an error message telling me that it could not move a certain folder because of a firewall and or/open borwser, etc. I closed everything and it still gave me the error message. I tried stopping the download manually but couldn't get it to exit. I used the task manager to shut Stencyl, Android Debug Monitor and the Android SDK Manager . After this point the SDK became corrupted and I could no longer test on my device nor download a corrected version.  I also could not reinstall the SDK or open the Device Monitor. It would hang or do absolutely nothing.

After many computer hangs, restarts, unistalls, reinstalls and thread searches I finally found the ".android" folder in my c:/users/YOURCOMPNAME folder. I removed this folder completely. (First I just moved it out of the location but then later deleted it)

I then opened up stencyl and tried to install the Android SDK again. It at first seemingly hung again. After a few minutes (3-5 min) I resized the window and it refreshed showing the download pop up window. It installed the SDK. I was then able to go back into Debug Monitor and SDK Manager and install all the packages. The ".android" folder was reinstalled with the necessary files in the location mentioned above at the time I initiated the download thus confirming it was the folder that Stencyl deals with.

If you are having the same kind of trouble I would first recommend trying to reinstall the SDK through stencyl. Give it time. (As I write this I think I may have been too impatient and should have waited) Resize the window to refresh it. It may become completely black as mine did but give it time and keep trying.  Check the little light on your computer to see if it is flickering to indicate it is indeed working on a task.  If none of this works then I would suggest removing that ".android" folder.

I hope this helps.

~ Cal Arts

5

Resolved Questions / Re: Collision in Simple Physics and Simple Actor Mode - Do they work? [SOLVED]

« on: April 07, 2015, 07:03:15 am »

Hi,

Sorry I missed your message. I haven't been on in a while. Are you still having issues? Can you explain what is going on or share a file?

Thanks
D~

6

Resolved Questions / Re: Possible "Type of Self = Actor Type" issue in 3.2?

« on: December 12, 2014, 09:56:20 am »

Natrium,

Thanks. I figured I overlooked something basic. Have a great day.

D~

[SOLVED]

7

Resolved Questions / Possible "Type of Self = Actor Type" issue in 3.2? [SOLVED]

« on: December 12, 2014, 09:13:05 am »

Hello,

I have two actors on screen that both have the same behavior attached. (scene_buttons.jpg)
When either is clicked the behavior checks to see what actor type it is and runs code dependent on that. (Bhv_Button.png)
Oddly enough BOTH commands are triggered regardless of which button you press. (log_viewerbuttonresponse.jpg)

I am not sure if this is a v3.2 bug or not. I don't recall having this issue with v3.1. Perhaps I am overlooking some basic point here. Anyone have any ideas?

Thank you for your time.

David Calabrese

8

Bug Archives / Re: Recycled Actors in Actor Mode: Simple lose collision.

« on: September 27, 2014, 03:07:14 pm »

MrWagoner,

Thanks for responding. Yes the workaround is not perfect and yes it will lead to a reduction of performance. I too noticed that if you use set xspeed or yspeed the collision will work. In my original thread (I gave the link in my previous post) I was told by rob1221 that set x/ y position blocks do not work with simple physics/simple actor mode but as you can see from my demo they do somewhat work using Box2D and Simple Actor Mode. At least initially they do.

It is just really strange that the set x/y position blocks would work with a newly created actor but not a recycled one. As to where the problem lies I only assumed it was in recycled actors. Perhaps I should have used more caution before blaming that aspect of stencyl.

In any case I have used my "workaround" with my blockade game I was working on. For now it works because the game is so short in duration. Perhaps I will increase the time the game is played before the scene is reloaded just to see how long it will last before there is a performance drop.

Hopefully this can be addressed easily for the stencyl 3.2 but I am not holding my breath. I know how fixing one thing breaks another.

Best,

9

Resolved Questions / Re: Collision in Simple Physics and Simple Actor Mode - Do they work?

« on: September 27, 2014, 05:52:46 am »

rob1221,

Yup I thought the same as you. I thought maybe the recycled actor was remembering the attribute "HasCollided" was set to True and that's why it wasn't colliding but unfortunately it is not. I had already tested it by setting the "HasCollided" back to false and got the same exact results.

I tried setting "HasCollided" before the "new" actor is created and when the "new" actor is created. Neither worked, and both together did not work.

I think it is safe to say that Recycled actors in simple actor mode lose their collision boxes. This, I would think, is a pretty big problem especially if you want to create a "bullet-hell" type shooter where you have a tremendous amount of actors on screen at once.

Having those actors set to normal would collide just fine but your frame rate would drop drastically. So the logical conclusion would be simple mode and killing the actor. But as you can see the recycled actors do not retain collision bounds (I think). Using the workaround to offset the "used" actors offscreen would (I think) eventually be costly. That is if you have long lasting levels.

In the Blockade game I made I initially had actors set to normal and the game would slow to a crawl when a certain amount of actors were on screen. Depending upon your computer's hardware/software this can happen sooner or later. My laptop handled it fairly nicely but my office computer and my student's computers could not handle it at all causing me to stop my tutorial mid class.

I eventually found the issues I mentioned above and the workaround and have since finished making the blockade game using simple actor mode. It runs beautifully as long as I move those actors off screen and not kill them. The funny thing I have noticed with all this is that the recycled actors who have code dictating their collision are the ones who lose collision.

For example: In my blockade game my arrow actor(s), whom I must move it off stage, has the collision code. All the other actors that it can collide with can be killed and recreated (recycled) at the start of a new level/round and when the new arrow actor is created (not pulled from the recycled pool, because I did not kill the last one but moved it off stage where it sits suspended) the collision code is functioning when it collides with the other recycled (codeless) actors.

I have posted the actual file and log reports in a thread in the Bug forum if you would like to check it out.
http://community.stencyl.com/index.php/topic,35490.0.html

Thanks for your time.

10

Bug Archives / Recycled Actors in Actor Mode: Simple lose collision.

« on: September 26, 2014, 09:40:36 pm »

Hello,

I believe I have found a bug. It seems recycled actors (That are set to Simple Mode) loose their ability to collide with anything.

The thread were this was initially discussed, evolved, and is explained in detail is located here:

http://community.stencyl.com/index.php/topic,35425.msg201059.html#msg201059

The file attached to this post has two events in the green arrow actor that you should look at. One event  shows the perceived bug and the other shows the potential work-around to it. They are named appropriately and you will have to turn one on and the other off to get the results.

Please let me know if I need to explain further.

Thank you for your time

11

Resolved Questions / Re: Collision in Simple Physics and Simple Actor Mode - Do they work?

« on: September 26, 2014, 09:27:43 pm »

Hello,

To anyone reading this thread I wanted to post again to update on the issue. I dug further and discovered more information about the bug and how potentially to work around it. This is of course my theory. It may not be 100 % correct but this is what I got from my test results.


Game Settings
Physics: Box2D

Actor Information (all actors):
Collision: Sensor-Checked
Physics: Type- Normal, Rotation - No, Gravity - No.
Advanced Physics:  Actor Mode - Simple, Continuous Collision - Yes,

Test

Example 1
Actor 1 collides with actor 2, Actor 1 dies, Actor 1 is recreated, Actor 1 looses collision after being recreated and cannot collide with anything.


Example 2
Actor 1 collides with actor 2, Actor 1 is moved off stage, A new Actor 1 is created, New Actor 1 collides with actor 2, and so on and so forth. If the actor is created from scratch as opposed to created from the recycled actor  pool then it will maintain its collision.

Results
Actors will loose ability to collide when recreated(recycled from pool).
If an actor is created without drawing from the recycled actor pool it has the ability to collide.

12

Resolved Questions / Re: Collision in Simple Physics and Simple Actor Mode - Do they work?

« on: September 26, 2014, 01:31:45 pm »

Rob1221,

I appreciate you getting back to me. I'll put together an example and post the bug in the appropriate discussion board.

For anyone reading this thread in the future the version I was using was 3.1.

Thanks.

13

Resolved Questions / Re: Collision in Simple Physics and Simple Actor Mode - Do they work?

« on: September 25, 2014, 08:26:52 am »

Liberado,
 You are welcome. Continue to check this thread as I explore what we can and cannot do with Simple Physics/Simple actors. If you decide to start playing with them yourself share your feed back please.

I'll share with you some other things I learned:

Using the example I wrote about before, Collision will detect using "set x/y position" blocks on the actor if BOX2D is ENABLED (Settings > Advanced) and the BOTH actors are in SIMPLE MODE (In Advanced Tab). The actors do have to have KIND OF ACTOR TYPE set to NORMAL in the Physics tab (General)

However this led me to another issue connected with collision which now I will direct to rob1221...

rob1221,

Thanks for replying. It is noted, and if you have any comments on the results I wrote about above I would love to hear it. Interestingly enough I continued to muddle with my project and wanted to share a result with you that really perplexed me and ask maybe if you have any thoughts on the situation. I think it has something to do with how Stencyl handles recycled actors.

So in the simplest explanation of my problem:

 If I place actor 1(simple mode) in the scene, move it towards actor2(simple mode) using the "set x/y"position blocks, which then DOES collide with actor2 (print "collision" in log viewer), then kill actor 1, and use the create block to dynamically create actor 1 again at its original position,  set it to move towards actor 2 again,  then when they touch/overlap it DOES NOT produce a collision and the actor1 continues to move straight through.

So the first pass they touch it produces a collision, but after being killed, and restarted the collision is not detected on the second pass.

The above left me really perplexed because the movement code still works but the collision which was working has vanished.

Now to twist your brain further.

If I repeat the process but do not kill actor 1 and wait until actor 1 has moved OFF SCENE (screen and scene are same size) and then recreate actor 1 it will move and collide with actor 2. This can be repeated endlessly and it will always produce a collision (print "collision" in log viewer).

It is my understanding that actors that leave the scene are killed and put into a pool of recycled actors. The kill block should do the same. Theoretically killing an actor through code or by letting stencyl do it should not have any affect on the collision bounds or be any different.

So my questions are:

1.)Does Stencyl Kill actors differently when they leave the scene as opposed when killed though code?
2.) Why would an actor who has been killed while on screen inside the scene NOT be able to be recreated with collision bounds working?
3.) Why would an actor who has been killed by stencyl off screen/out of scene be able to be recreated with collision bounds working?

Thanks for your time

14

Resolved Questions / Re: Collision in Simple Physics and Simple Actor Mode - Do they work?

« on: September 24, 2014, 03:08:24 pm »

Hello,

I have solved my issue and I wanted to share with anyone who cares to know what I discovered. Firstly, the question at hand was do collisions work with Simple Physics and Simple Actors.

The Answer is YES.

There is conflicting documentation that suggests otherwise and there are certain situations that render the answer to be NO.
Of the situations I have read about none have been exactly like mine. I would like to explain my situation so that it might help someone else.

Here is a simplified example: You have two actors (Actor 1 and Actor 2) both are 32px by 32px. They both have square collision boxes. They are both aligned in the same row with a short bit of distance between them. Lets say 64 pixels. Actor 1 will move right towards Actor 2. When Actor 1 collides with Actor 2 it will print "Collision" in the Log Viewer.

Simple Physics Turned on (Actor Mode = Normal):
This WILL work:
In Actor 1 there is a "when created" event that sets the xspeed. The value does not matter as long as it moves to the right. When tested Actor 1 moves and eventually collides with Actor 2 and stops it dead in its tracks. Collision is detected and "collision" is printed to the log viewer.

This WILL NOT work:
In Actor 1 there is an "Every N Seconds" event that sets x position to x of self + value. For example "set X to (X of self + 10) for self". When tested Actor 1 moves and does not collide with Actor 2. It simply moves through it.

In conclusion it seems that using set X or set Y (positioning blocks) will negate the collision bounds and not produce a result. Which is very very very strange because you can actually place Actor 1 on top of Actor 2 in the scene, test it, and get a collision. Partial overlap, total overlap, collision box inside of a collision box all produce a collision if manually placed or if using motion blocks like x speed.

If anyone has any comments on why it doesn't work when you use the positioning blocks then I am all ears.

Thanks for your time.

15

Resolved Questions / Re: Collision in Simple Physics and Simple Actor Mode - Do they work?

« on: September 24, 2014, 05:19:13 am »

Liberado,

Thank you for your response. Yes I understand that it would be better to build this style of game using the method you mentioned. However, I am a teacher and I am currently introducing stencyl by walking them through a series of small arcade games. As we progress forward I am introducing new concepts with every game.  Because there is so much to learn about stencyl I am introducing a few concepts/functionality at a time. We currently have not explored tiles.

My essential plan is to move the students through making games inefficiently with  exposure to few concepts to making games efficiently with exposure to many concepts.

Currently the Blockade game we are working on does function using actors as sensors and box2d collisions with limited physics. It works fine until a certain point until too many actors are on the screen. I want them to see the lag and understand that this is limitation that they need to work around/overcome.

In the Blockade game the goal is to cause your opponent to crash into a block and the game will end. If the player is efficient enough they will cause the opponent to crash before too many actors are on the screen which will prevent them from seeing any lag. So ultimately the game is functioning (although not via the proper method).

So with that cleared up I was just wondering if it is possible to detect collision between two actors using  Simple Physics/Simple Actor Mode? If so, would any one mind sharing how they do it?

Once again thank you for your time and consideration.

Liberado, a special thank you for your response. I appreciate you sharing your knowledge.