WackyToaster's Forum Posts

  • Pretty sure your code does not work unless I mucked it up.

    this.tween.finished will run before this.attacking = null. So the following check for if(this.attacking) will always be true.

    But I do get the gist, I just need an extra variable to track.

    I don't wanna implement it though if you plan on changing how this works anyway. :^) So if you plan on changing it I will post it to the tracker for tracking purposes. I'm really not acutely worried about a memory leak that happens if I spend an hour attacking.

  • Ah pause... duh. Yeah that appears to work SORT OF with some adjustments.

    There's just one thing that worries me though... I do in fact want the tween to end there, no need to resume. If I pause it, isn't it just floating around in memory indefinitely? And the async call is also kept waiting for the tween to end?

    Some context, I'm using it for an attack animation. Here's how it looks in short 

    async attack() {
	if(this.attacking) return;
	this.attacking = tween;
	tween.finished.then(
		//do whatever
	)
}

cancelAttack() {
	this.attacking.pause();
	this.attacking = null;
}

    If I cancel the attack during it's animation and just pause the tween... I can literally never actually stop the tween because as soon as I do that, the async will resume its tween.finished.then() which I don't want. Something doesn't add up, perhaps a skill issue on my part?

  • I hope Ashley can chime in here I don't wanna put it as a bugreport because it could be by design.

    In Events:

    If I start a tween (2seconds) that I then stop after 1 seconds. The tween just stops.

    On Tween "Tag" finished does NOT trigger.

    In Script: 

    class MySprite extends ISpriteInstance {
	constructor() {
		super();
	}

	async start() {
		this.tween = this.behaviors.Tween.startTween("x", this.x+200, 2, "linear");
		this.tween.finished.then(() => {
			this.setAnimation("Animation 2")
		})
	}

	cancel() {
		if(this.tween.stop) this.tween.stop();
	}
}

    I do essentially the same. However, this.tween.finished.then() still runs anyway (right when the tween is stopped). My thinking was that if the Tween is stopped, I would not consider it finished. It's stopped.

    I guess the solution would be to track an extra variable that shows that the tween was stopped and not simply finished. It would be much more convenient though if at least I could get "was the tween stopped" from the ITweenState somehow, however, ITweenState becomes effectively unusable after stop.

    So is this by design, a bug, a feature?

  • Hmm that's actually a tough issue given that the default of sorting at the Y position is not gonna cut it.

    Perhaps the easiest solution for the fences specifically would be to split it up into individual sprites (and use hierarchies to stich them back together), so that sorting by Y position would approximate more closely to what you'd expect.

    I can imagine there could be a more involved solution where you figure out the draw order based on some hidden top-down representation of the scene.

    Or it's possible that you utilze the 3D capabilities of Construct. If you imagine the scene as isometric 3D, the fence would be on the side of the cube object, and the sorting is handled by the 3D magic.

  • Yeah it is missing. For the time being, you will have to make a function with the events and use runtime.callFunction()

  • Would be good if you can post your project in the bugtracker.

    github.com/Scirra/Construct-bugs

    You can probably remove everything except the bugged layer that's causing the problem.

  • ive never used flowcharts-are there for java script only or can u use it with events?

    They are currently event-only. Whether you should use them depends on what you want to do. If you do a text-adventure or something, they are great.

  • Yes, we have plans for leaderboards to work independently of the Construct Arcade.

    Interesting. Does that mean you plan on hosting a server/service for the leaderboards? And potentially more?

  • Load and save what?

    For me I was talking about the data of the flowchart and/or individual nodes. I don't think that that the feature is abandoned but this thread was just kind of fitting to me since I recently tinkered with them a little. And I thought about submitting a feature request but I just didn't have the urge to do so yet, it's not a pressing issue for me.

  • I'm personally still waiting for the scripting API. I kind of expected that to come sooner rather than later, but it seems to be later... Save and load from JSON would also be great. Right now when I tinker with it I basically write a parser in the eventsheet that outputs the node as a JSON. :V

  • The settings going away is probably a browser thing, like if you delete browser history. But I did notice that you will be logged out every time if you log in on another device like a Laptop or something.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Use hierarchies instead of pin.

  • Oh yeah, I'm on the beta branch. You can just open it in the newest beta if you want to take a look.

  • You are WAY overcomplicating things. All you need to do is...

    wackytoaster.at/parachute/cardflip.c3p

    At least that's roughly how I'd do it. But there's obviously more than one way to get to the goal. I've used something similar to your method before for something else, where I stored the UID in a tag.

  • Alright final update for now. I've updated the project (same link)

    wackytoaster.at/parachute/ceilingSlopes.c3p

    I did add a velocity-based pushout that solves issue #2 mentioned above, but adds some other issues in that it sporadically does not work. So it's disabled in the project. It's kinda fun though.

    Issue #1 cannot be solved as easily as expected, the issue is not that the jump isn't executed by the behavior, but rather that the pushout actually pushes the player into the floor and thus the pushout fails. I tried changing the players height slightly during the pushout to compensate but that also did weird things. I feel like this should work though, maybe I made an error somewhere.

    Issue #3 is a bit more complex than expected, probably another can of worms that I don't wanna open at this moment. I had a solution that kind of worked but was framerate dependent, so... nah.

    For now I'm actually fine with all these 3 issues being present (for my project). It's not make or break for me. But of course, if someone happens to find a solution for them, let me know.