WackyToaster's Forum Posts

  • So based on the audio scripting example, I have to manually (pre)load the audio myself in order to use it. In the example it's done like so 

    [audioSfx5, audioSfx7, audioEpicArpg] = await Promise.all([
		audioManager.loadSound("sfx5.webm"),
		audioManager.loadSound("sfx7.webm"),
		audioManager.loadMusic("epicArpg.webm")
	]);

    I have many many more sounds. Surely there's a better way to do this. But... no? The best way I found was with a loop but I still have to punch in every single soundfile myself. Is there really no way to just get all the soundfiles to preload like the audio plugin usually does by itself?

    I thought the asset manager would help, but also no...

    construct.net/en/make-games/manuals/construct-3/scripting/scripting-reference/interfaces/iassetmanager

    Am I just overlooking something or is this a case for a feature request?

    And of course I had to do some snooping around... the closed off internal asset manager has the exact function I need. GetAudioToPreload()

    But of course I can't use that :,)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Do you think it's because we didn't provide enough feedback?

    No, I'm pretty sure this topic has been chewed through thoroughly in several very long threads.

    The LTS version is the play here if you crucially NEED 3rd party plugins that CANNOT be ported. That's why it exists, it is this exact case.

    Other than that, the options are what they always are: Deal with it or leave for the other side were the grass is greener. And I'm aware that neither of these options is necessarily appealing.

  • That's what the LTS version is for. Nobody in the community is super happy with this but it is what it is.

  • The illogical design lacks clear official documentation

    Are you sure?

    While I do agree that it's somewhat of an unintuitive design, it has been improved since the last time I encountered it. Because nowadays you can add animations to a sprite dynamically. Meaning you can:

    1. Create your 4 sprites

    2. Create animations on each (A, B, C, D)

    3. Set them to use that animation

    4. Load your image into each animation respectively

    That should do the trick.

  • System -> compare two values

    random(1) < 0.3 = 30%

    random(1) < 0.9 = 90%

    random generates a value between 0 and 1.

    If you want some extra control you can try the advanced random plugin, which supports probability tables.

    construct.net/en/make-games/manuals/construct-3/plugin-reference/advanced-random

  • You could try disabling WebGPU (or enabling it). If you're on the beta branch it is enabled by default iirc and can lead to some pretty weird graphical bugs. For me random pixels are shiftet up or down, it's really weird.

  • You can use the 'Enable/disable collisions' action in the Physics behavior for collision filtering.

    Unfortunately this is absolutely not sufficient, see these requests here for full info :)

    github.com/Scirra/Construct-feature-requests/issues/68

    github.com/Scirra/Construct-feature-requests/issues/467

    I've been hoping/waiting for this for quite a while now.

  • I'm really enjoying working on this, but it's all quite tricky!

    Oh yeah absolutely it's tricky. I've tinkered with all that before. Adding firebase, using my own php scripts and SQL on a server etc. It's extremely tricky to get right. I even went and made my own registration/login before, did a ton of research into the security aspects and all. That was quite some years ago though.

    Cool to see more potential incoming! Global data is also very interesting.

  • Stuff like that is honestly a great add-on service. Although I'm not sure if I can ever utilize it (because if anything I'm bad at actually releasing my games :V)

    But still, I hope to see more in line with this. Another great one would be a service to store data, kinda like firebase.

  • 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()