Messages

1

Old Questions (from 1.x/2.x) / Re: How do i flip an actor?

« on: March 11, 2013, 09:59:43 am »

Alternatively you can flip actors using the "grow" tweening block by simply growing it to -100% width and 100% height. Create an attribute that changes whenever the player switches directions, and then grow the player using either 100% or -100% width depending on direction.

2

Ask a Question / Re: importing my own drawings

« on: March 10, 2013, 03:40:06 am »

When you import graphics to be used as animations in Stencyl, there is a box on the left hand side of the import window that you can use to specify the "masking color" which will be transparent.

If you click on the white area around your actor's graphics after you choose the file to import, it will set the masking color to white. Keep in mind that this will also render any white areas within your actor transparent. For that reason, most people fill the area around their sprite's graphics with an obscure color that won't be used in the graphic.

3

Old Questions (from 1.x/2.x) / Re: rotate direction of gravity

« on: March 09, 2013, 03:27:51 am »

Thank you very much Hectate for that thorough explanation! The diagrams really help me visualize and comprehend the math behind the solution and for someone who is poor at math that really helps.

4

Ask a Question / Re: How to send value to other actor attribute

« on: March 06, 2013, 10:31:39 pm »

ActorEvents_38 isn't the name or identifier of a specific actor, it's the name of the behavior that contains the attribute _Power.

If you're trying to adjust the attribute _Power within behavior ActorEvents_38 which is attached to the actor "Hero", you will need to replace "Last created actor" with an actor attribute that has been set to the hero actor.

If the behavior containing this event is already attached to the hero actor, simply replace "last created actor" with "self". If not, you can use a game attribute set to "List" to pass the hero actor to all other actors.

Example:
1) Create a list game attribute called "Hero Actor Holder"
2) Within a behavior attached to the hero actor, create a "when created" event which adds [Self] to the list "Hero Actor Holder". The [Self] block can be found under Scene -> Get Actor.
3) Within the event you've posted a screenshot of, create an actor attribute called something like "Hero" and set that attribute to [get item number 0 from "Hero Actor"]. Then replace "last created actor" with "Hero" within the block that modifies _Power

5

Ask a Question / Re: Tile Collisions

« on: March 04, 2013, 08:19:38 pm »

Like twotimingpete said, it's easiest to use invisible actors that you set on top of the tiles for one-way platforms. I would also use an invisible "hit box" actor which acts as your main player actor and responds to all collisions, and then create a collision-less animation actor which is always positioned on top of the hit box player actor.

If you do this, you can make the hit-box actor change between animations/collision frames that react differently with certain collision groups while preserving the continuity of the character's animations.

For example:

- Create an invisible actor which will act as your one way platforms, and create a new collision group for it called "One-Way Platform"

- Create an actor without any physics which will contain all your player-actors animations, and attach a behavior to it that will always move it to the position of the hit-box actor

- Create two animations for your hit-box player actor: Solid, and Pass Through Platforms.

- For the Pass Through Platforms animation, create a new collision group called something like "Pass Through Platforms" and make sure that it cannot collide with the One-Way Platform group. Assign the collision shapes of the Pass Through Platforms animation to this new collision group.

- Make it so that whenever your player's hit-box actor is jumping (aka has a negative Y-speed), it switches to the Pass Through Platforms animation, and whenever it has either a positive y-speed or 0 y-speed, it switches to the regular animation which does collide with 1 way platforms.

If you do this, you can avoid strange things like all other non-player objects falling through one-way platforms whenever the player is passing through one.

6

Resolved Questions / Re: Can you reverse gravity in a specific area within the scene?

« on: March 04, 2013, 07:14:55 pm »

I'd imagine that if you set the mass to a negative value then collisions would be strangely effected, since the mass of an actor determines how collision forces apply to it.

I would simply create a region and then create an "Actor enters or leaves region" event which toggles gravity off and on, and then constantly subtract from the y-speeds of all actors within the region until they either collide with the ceiling or reach "terminal velocity". (ex: always set y-speed to greater of [-30] and [y-speed - 0.5])

If you want the attracting actor to pull actors towards itself rather than simply inverting gravity, then you can use a force block like this:

always
--if not actor and pulling actor are colliding
----push [actor] gently towards (xDir:[x-center of pulling actor] yDir:[y-center of pulling actor]) at [gravity strength] force
----// or
----// push [actor] gently towards [[atan2 y:([y-center of pulling actor] - [y-center of self]) x:([x-center of pulling actor] - [x-center of self])] as degrees] at [gravity strength] force

For the gravity strength, you'll just have to play around and see which value emulates default gravity. Keep in mind "do always" events update 100 times a second, so you'll either want the value to be very low or you'll want to use a "do every x seconds" block rather than a "do always" event.

I'm not exactly sure how you would account for terminal velocity using this method though, it would be an equation having to do with current x and y speeds as well as the angle between the center of the falling actor and the center of the attracting actor.

Edit: @Ozygiygas

Honestly I haven't ever noticed anything fundamentally different between "sharply" and "gently" -- other than the fact you have to use values about 100x higher in gently to achieve an equivalent effect with "gently". I would use "gently" because its supposed to apply a force more gradually, whereas constantly applying a sharp force might make things seem jagged (although I've never noticed that).

7

Resolved Questions / Re: How to make sound play once every .5 secs if continuous collision

« on: March 01, 2013, 08:00:59 pm »

Here's one way:
- Create a boolean attribute called something like "Recently Hit"
- Change the first if statement to "if <<self is alive> and <not<Recently Hit>>"
- After the block that plays the sound, add a block that changes "Recently Hit" to true and then a block that changes "Recently Hit" to false after 0.5 seconds. Like this:

Code: [Select]

if <<[Self] is alive> and <not<Recently Hit>>>
--Play [Hit Sound]
--Set <Recently Hit> to <True>
--do after 0.5 seconds
----Set <Recently Hit> to <False>

The "otherwise if" section of your behavior is unnecessary because the event will already stop if the player isn't alive.

8

Ask a Question / Re: Get Width of actor on creation

« on: December 18, 2012, 11:26:05 pm »

^ That wont work if you're trying to use the width within the creation block itself

I've run into this issue when trying to center newly created actors relative to another actor using width and height. Something like "create new actor at x-center of self - half-width of new actor".

My workaround has been to simply use "move x/y" blocks after creation, but this can mess up things if your actor needs to know its starting position in a "when created" event.

9

Completed / Re: "No Physics" Mode

« on: December 09, 2012, 10:41:32 am »

Another thing I noticed was that if I not only best all actors to doodads, but then deleted all collision groups from my game (apart from none locked ones) there seemed to bean increase in performance. I'm not sure if it was caused by that for sure though.

10

Ask a Question / Re: Beginner help on Attributes that confuse the hell out of me

« on: December 06, 2012, 07:10:25 am »

An attribute defined in an actor behavior is only (conventionally) available to the specific actor to whom the behavior is attached. There are ways around this, however.

- In the collision event of actor A, whenever you set 'alarm' to 0 or 1, you can also add a block which changed the attribute 'alarm' within actor B's behavior. The block to do this can be found under Behavior -> Attributes -> For Actor. It's the "for [actor], set [attribute] to [anything] for behavior [behavior]". When using that block, you'll have to type in the internal name of actor B's alarm attribute, which should be "_alarm" by default.

- However, instead of using alarm attributes in the way you have, I typically use actor values to achieve the same effect. The blocks for these are found under Actor -> Properties -> Properties. In the collision event, set the actor value (which you can name "alarm") to 1 for both actor involved in the collision by dragging the two blue blocks for "this actor" and "other actor" into a "set actor value [text] for [actor] to [anything]" block. Then instead of checking if alarm = 1, check if the actor value = 1. Wrap a "get actor value [text] for [actor]" block in an "as number" block to use it exactly like a number attribute.

- Alternatively, you can use a trigger to trigger an event within an actor's behavior which then changes an attribute native to that behavior. To do this, add an custom event to your actor behavior (found under Advanced) and then fill in the "when [text] happens" with a name like "collided". Inside that event, place a setter block which changes the attribute "alarm" to 1.

Then in the collision event of either actor A or B, add a "trigger event [text] in behavior [text] for [actor]" block found under Behavior -> Triggers -> For Actor. Fill it in so that it triggers the event "collided" in the appropriate behavior for both actors involved in the collision, or whichever actor needs to react to the collision.

I'm not sure why the game attribute isn't allowing you to drag it into the block, but I suspect that it is either not set to be a number attribute. In any case, it's best not to use game attributes for situations like this as they are slightly less efficient performance wise and are typically reserved for things like persistent values that need to be saved/loaded, lists that need to be accessed by many different actors, management of sound effects, etc.

11

Completed / Re: "No Physics" Mode

« on: December 06, 2012, 06:34:01 am »

Definitely. Something about the simple collision detection system is slowing down my game, especially when I have many actors using "move x/y position" blocks simultaneously. All I really want the movement blocks to do for disabled physics actors is change the draw position of an actor on the screen.

12

Suggestion Archives / Re: [Fun] Rotate / Scale the entire game

« on: December 06, 2012, 06:27:19 am »

Thanks cole, the background scaling works perfectly! However, to get them to scale appropriately on my iPhone/iPad, I had to replace all Engine.screenWidth/Height to (Engine.screenWidth/Height * Engine.SCALE).

In the Forge description you said the background scaling doesn't work with gradient backgrounds, but it seems to work as expected for me.

13

Completed / "No Physics" Mode

« on: December 05, 2012, 05:06:22 pm »

In addition to simple physics and Box2D, could we get a mode which doesn't use physics at all? It would be appropriate for grid based games, word games, and all non-game apps like organizers, calculators, education/health apps, etc.

I feel like a whole physics/collision system is a bit overkill for most apps

14

Suggestion Archives / Re: [Fun] Rotate / Scale the entire game

« on: December 04, 2012, 01:09:27 pm »

To anyone else who gets lost when code comes up, I've gotten scaling to work through this method dependably.

Say you want to zoom out your game to 50% scale. You can accomplish this using 2 code blocks, one in a "when created" event within the behavior responsible for zooming, and another to be used where ever the zooming will be triggered (ex. in a "when touched" event)

In the when created event, you'll define two variables that are rectangles. These control how much of the screen is shown at once. The first variable (which I've called _ScaleStandard) is the default size, and the second (which I've called _ScaleSmall) is bigger to accommodate the smaller game scale. You can copy and paste this into a code block.

Code: [Select]

var _ScaleStandard = new nme.geom.Rectangle(0, 0, (scripts.MyAssets.stageWidth * Engine.SCALE), (scripts.MyAssets.stageHeight * Engine.SCALE));
var _ScaleSmall = new nme.geom.Rectangle(0, 0, ((scripts.MyAssets.stageWidth * Engine.SCALE) * 2), ((scripts.MyAssets.stageHeight * Engine.SCALE) * 2));
NOTE: Multiplying stageWidth/stageHeight by Engine.SCALE makes scaling work on different devices with different resolutions. If you don't multiply by Engine.SCALE, this zooming method will not work on iPhone 4/S/5 or new iPads.

Now you can use those two rectangles in the code block used to zoom the game. Say you want the game to zoom in when the player touches the screen. Create a when mouse is pressed event or an always event which acts as a switch to determine if the game should zoom. In that event, place a code block like this:

Code: [Select]

Engine.engine.root.scrollRect = _ScaleSmall;
Engine.engine.root.scaleX = 0.5;
Engine.engine.root.scaleY = 0.5;
Engine.screenScaleX = 0.5;
Engine.screenScaleY = 0.5;
Engine.screenWidth = (2 times whatever your screen width is, for example, the screen width of an iPhone in landscape is normally 480, so put 960);
Engine.screenHeight = (2 x screen height);
This block will shrink all graphics on screen to 50% scale. The screenScaleX and screenScaleY lines are necessary to update things like mouse coordinates to the new scale. Updating the screenWidth and screenHeight makes it so that the tileset is not clipped inappropriately. The dimensions are doubled because when you shrink everything by 50%, twice as much stuff can fit on the screen.

Whenever you want to return the game back to standard scale, use this block:

Code: [Select]

Engine.engine.root.scrollRect = _ScaleStandard;
Engine.engine.root.scaleX = 1.0;
Engine.engine.root.scaleY = 1.0;
Engine.screenScaleX = 1.0;
Engine.screenScaleY = 1.0;
Engine.screenWidth = (whatever the screen width is);
Engine.screenHeight = (whatever the screen height is);

You can modify these blocks to zoom at any scale, not just 50%. Replacing the scaleX/Y and screenScaleX/Y values with 2 and reducing screenWidth/Height to 1/2 will zoom in to 200%, etc.

Hope this helps. One issue I haven't yet been able to resolve is scaling backgrounds to match the zoom amount. If anyone else knows how that can be accomplished please post the solution.

15

Abandoned Bugs / Re: AMDeviceInstallApplication failed: -402653114 [NME bug]

« on: November 26, 2012, 03:56:06 am »

This same issue is happening to me after updating my 4S to iOS 6 and my Xcode to 4.5.2

Exact same "AMDeviceInstallApplication failed: -402653114" until I changed the identifier. And even now that I've gotten it to work on my phone, the game will only go to the splash screen before closing. When this happens the log prints:

Code: [Select]

Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/operand.
0x2fe490cc in __dyld__ZN13dyldbootstrap5startEPK12mach_headeriPPKclS2_

I then have to open it by clicking on its icon.