• Content Count

  • Joined

  • Last visited

About GiniWren

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. You just helped me fix so many problems with that solution. Thank you so much.
  2. Hello again! I'm having issues with tweening the dimensions of a mask on a group between two versions of Phaser. This was working in the previous version (2.10.6 at time of posting), but looks like it's stopped working in the most recent version (2.11.0). Here is the example of what I'm talking about: Note that the Phaser version in javascript settings on the pen is set to 2.11.0, but when changed to 2.10.6 the pen works. Looking through the release notes, it seems some work was done on masks between the two versions -- regression, or is there a new way to do this? Thanks for any help.
  3. Using group's getBounds makes perfect sense -- thank you!
  4. I see the same behavior in the latest version of Phaser CE, as well as in the Phaser input example ( in the latest versions of both Chrome and Firefox. Seems appropriate to file a bug for investigation ☺️ Here's more information on how to do so: In the meantime, you can use the middle mouse button's onDown and onUp events to set a variable that tracks whether the button is down. Here's an example:
  5. If you define the variable holding your music outside of your state (or even outside of your game/as a global if needed), it continues to play through state transitions. Sorry, disregard my comment and see samme's below. See this codepen for example:
  6. Hey there -- For UI menus in my game, I have created a texture-less button that has a fake 9-patch image (really Phaser Group prototype extension) as a background and a Phaser Text object as its children. This creates buttons where the 9-patch background can be animated to change the button size without changing its scale. I have added instances those buttons as a Phaser Group that aligns them in a vertical column, using the buttons' heights for spacing. The issue is, the children of the button don't affect the button's width/height or bounds, so the grid aligns them by the default texture dimensions: 32x32. This minimal codepen roughly illustrates what I'm seeing/trying to do: I found some old threads that suggest this is expected behavior, and I understand why, but the workarounds discussed are disruptive (e.g., using a group instead of a button means changing how all the events are attached to the button throughout the entire project). Has there been a clean solution since then? Ideally in a way that lets me check dimensions the same way as the any other children added to the alignment group? Thanks for any help on this one!
  7. Thanks @samme -- filed a bug with Phaser CE just so it's documented, but setChildIndex works perfectly for what I need. (Also from now on gonna use that codepen setup from the CE bugs page to make code examples easier to check out ☺️)
  8. Able to work around this by calling the sprite's removeChild and addChild functions -- certainly not the worst work-around, as that's how Phaser Group handles this functionality anyway. Sprite's bringToTop appears to not work because it calls bringToTop on each non-group object's parent, presumably until it reaches the world level (the docs seem to confirm this), but it looks like it leaves the ordering of the sprite's children alone.
  9. Hey there, Having a bit of trouble today with the bringToTop function of the Phaser sprite. I have a sprite, to which I've added two child sprites. However, when I call bringToTop on one of the child sprites, nothing appears to happen. Anyone know why this might be happening? I'm not sure if there's something I'm missing. Thanks for any help! ---------- Using Phaser CE v2.10.5 Seen in browsers: Google Chrome, Version 66.0.3359.170 (Official Build) (64-bit) Firefox Quantum, Version 60.0 (64-bit) Safari, Version 11.1 (13605. Minimum reproducible code: var game = new Phaser.Game(256, 223, Phaser.AUTO, 'game-container', { preload: preload, create: create }); function preload() { // load game images game.load.image('container', 'img/container.png'); game.load.image('star', 'img/star.png'); game.load.image('blueStar', 'img/blue-star.png'); } function create() { // create container sprite var container = game.add.sprite(0, 0, 'container'); // create two additional sprites var yellowStar = game.add.sprite(40, 40, 'star'); var blueStar = game.add.sprite(40, 40, 'blueStar'); // make both sprites children of the container sprite container.addChild(yellowStar); container.addChild(blueStar); // in 2 seconds, bring the first/bottom sprite to the top var timer = game.time.create(); timer.add(2000, function() { yellowStar.bringToTop(); }); timer.start(); }
  10. I don't know enough about the codebase atm to know whether changing the way this works would cause further confusion or unexpected behavior. (This is only the second time I've really had to dig into the source code even after working with it nearly every day for 10 months now. I can't sing Phaser's praises enough, everything just works, and it's the least trouble I've had working with any game engine.) While, I'd expect as a result of startDrag() that the pointer's target (targetObject?) reference would reflect whatever the inputHandler belongs to, in this particular case it would mean you've left the original sprite+inputHandler hanging for its own onInputUp event. Maybe there's a cleaner/easier solution? I'd speak in favor of at least putting a working example out there so people can find it, simply because the behavior and solution aren't immediately apparent. I've found some older threads mentioning the same/a similar concept, so the drag-to-spawn-sprite behavior as a whole seems to be desirable. Here's a few: That said, I haven't seen anyone run into this particular sticking point yet.
  11. Alright, got a workable solution, posting for posterity... The following can be added within the onInputDown code after the spawned sprite is created to ensure proper behavior:, pointer) { newSprite.input.stopDrag(pointer); }); Explanation: From the previous post, I wrongly suspected that the _draggedPointerId was being set to -1, when in reality it was the _releaseHandler calling release for the spawner, not the new sprite; because the pointer wasn't dragging the spawner, it was correct in being -1. So, by adding a one-time event for that release/onInputUp that releases drag on the new sprite, it behaves as expected. After that first time, the event is destroyed, and things can go on normally. Here's the result:
  12. Dug into the Phaser source code, and I think I may be onto an explanation. It looks like InputHandler's stopDrag function (responsible for calling onDragStop) is being called in two different places on first spawn vs normal event. Normally, when a sprite is dragged, the _releaseHandler calls stopDrag, provided the _draggedPointerId on the sprite matches the of the event. However, perhaps because startDrag is called manually, when the sprite is first spawned the _draggedPointerId is -1 (while my pointer is 0), so stopDrag ends up being called by a check in InputHandler's updateDrag. Because updateDrag is only called when the pointer moves, the onDragStop function isn't dispatched until the pointer moves again. I'm stuck figuring out where _draggedPointerId is being set to -1, because when startDrag is called manually, it does get set properly to 0. Something must be changing it along the line...?
  13. I was able to get the hit area working like your post suggested by changing the x, y coordinates of the hit area to be simply offset by half the width/height, since it appears to be positioned with the center of the circle relative placed to your sprite's anchor: bubble.hitArea = new Phaser.Circle(bubble.width/2, bubble.height/2, bubble.width); Note this will make the game.debug.geom shape look incorrectly positioned, because being referenced directly as sprite.hitArea means it won't be drawn relative to the sprite's anchor. To see a debug shape drawn correctly, you'd have to do something like: game.debug.geom(new Phaser.Circle(bubble.hitArea.x + bubble.x, bubble.hitArea.y + bubble.y, bubble.hitArea.diameter), 'rgba(255,0,0,0.3)');
  14. Seen in browsers: Google Chrome, Version 66.0.3359.170 (Official Build) (64-bit) Firefox Quantum, Version 60.0 (64-bit) Safari, Version 11.1 (13605. Here's with the input debug: looks like is Up and duration debugging info is all correct, but the event itself isn't firing until the mouse moves.
  15. I've created a "sprite spawner" that, when the mouse presses down on it, it spawns a new sprite that the mouse is then dragging. I use it for things like menus, where you have an image of something you want to add to the game stage, and by clicking and dragging from the image you create a new instance that can then be placed by the mouse. However, it appears that the onDragStop event isn't being fired until the mouse moves. This only happens on the initial creation of the dragged sprite; behavior works as expected after the first time. Steps to duplicate: Mouse down on sprite spawner. Drag mouse some distance away from the sprite spawner. Keeping the mouse position stationary, release the mouse button. Observe the event hasn't fired yet. Move the mouse in any direction; observe the event is then fired. This also can be reproduced by omitting step 2 (which may be helpful if it's hard to see it happening -- can just click and release the mouse). Here's a gif of the problem: Here's the minimum, runnable game code to see the issue (used to create the above gif): var game = new Phaser.Game(400, 300, Phaser.AUTO, 'game-container', { preload: preload, create: create, render: render }); function preload() { // load game images game.load.image('star', 'img/star.png'); game.load.image('blueStar', 'img/blue-star.png'); } function create() { // text indicating whether a spawned sprite is actively being dragged var dragIndicatorText = game.add.text(10, 10, 'Drag from the yellow star to spawn a new sprite.', {fontSize: 16, fill: '#ffffff'}); // create sprite that spawns blue stars on mouse down that are // immediately dragged by the mouse on spawn var spriteSpawner = game.add.sprite(50, 100, 'star'); // enable input to access events spriteSpawner.inputEnabled = true; // expected behavior is when input is pressed down, a sprite spawns // under the mouse, and mouse is then immediately dragging that new sprite. (spawner, pointer) { // spawn new sprite var newSprite = game.add.sprite(game.input.worldX, game.input.worldY, 'blueStar'); // enable sprite dragging interaction newSprite.inputEnabled = true; newSprite.input.enableDrag(); newSprite.input.bringToTop = true; // recenter sprite on mouse input (taking sprite size into account) newSprite.x = game.input.worldX - newSprite.width / 2; newSprite.y = game.input.worldY - newSprite.height / 2; // hook up sprite drag start/stop events { dragIndicatorText.text = 'Sprite being dragged'; }, this); { dragIndicatorText.text = 'Sprite dropped'; }, this); // start drag on spawned sprite immediately newSprite.input.startDrag(pointer); }, this); } function render() { game.debug.pointer(game.input.activePointer); } I'm not sure whether this is a bug or something simple I'm forgetting to do to ensure the proper events are firing. Let me know if I can clarify or add any other needed information. Edit: Using Phaser CE v2.10.5 Seen in browsers: Google Chrome, Version 66.0.3359.170 (Official Build) (64-bit) Firefox Quantum, Version 60.0 (64-bit) Safari, Version 11.1 (13605. Thanks for any help!