WackyToaster's Forum Posts

  • Hmm now that I think about it, this is probably a bit more complicated. The physics plugin uses more variables that will affect the trajectory. Like mass/density and dampening. Since construct uses box2D under the hood I searched if there's something on that and found this answer but the math is beyond me and I don't have time right now to read into it.

    stackoverflow.com/questions/20208642/draw-dynamic-projectile-curve-in-box2d

    Maybe R0J0hound can help here.

  • You will have to cook up a system that checks for that. Something like: Go through all keys that should be there and if it isn't, add it.

  • It's hard to make any guesses based on that. If a crash happens, you can maybe check the developer console (F12 in chrome) and see if there are any errors showing up.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Perhaps this can help you, although it's not directly made with the physics behavior in mind. The math should probably be roughly the same I think.

    howtoconstructdemos.com/trajectory-calculation-two-methods

  • Ashley wrote somewhere that collisions are something we have to handle ourselves in javascript. He also wrote that internally a collision is "is overlapping & wasn't overlapping previous frame" but that doesn't appear to be the entire story.

    Example: The platform behavior lands on solid ground. With events this correctly triggers a collision, makes sense. But in javascript with just a testOverlapSolid() it never triggers. So without tearing open the platform behavior again, I have to assume that there is a piece of code that roughly does:

    1. Execute the movement

    2. testOverlapSolid() -> if true trigger collision

    3. Push out solid

    So when my scripts are executed, the platformer object will just never be overlapping the solid. So I came up with this, which sort of works 

    const sprites = runtime.objects.Sprite;

for(const i of sprites.instances()) {
	const vec = {
		"x": i.behaviors.Platform.vectorX,
		"y": i.behaviors.Platform.vectorY
	}
	const prev = {
		"x": i.x,
		"y": i.y
	}
	
	i.offsetPosition(vec.x*runtime.dt, vec.y*runtime.dt);
	if(i.testOverlapSolid()) i.setAnimation("Animation 2");
	i.setPosition(prev.x, prev.y);
}

    At least I think it does what I want it to. I have to be cautious to only execute this code after any potential changes to the vectors (e.g. jumping, knockback) which is fine.

    The main issue I'm having is that this technically triggers the collision a frame to early. So I kinda need to only register the collision first, and then handle what it should do the next frame. Is this the right approach? My gut feeling tells me this might be prone to a bunch of edgecases but maybe I'm mistaken...

    Of course I could possibly also just handle this in events, but that's not the point :V

  • Oh absolutely. I just wanna make sure that I'm not making something more complex than it needs to be. I hate being in the middle of a project and realizing that I could have done some things much easier + my code tends to spaghettify anyway and it's harder to maintain. So I kinda started to look for the most simple and effective solutions I could possibly think of so I don't get frustrated when the code is a maintenance nightmare. It's hard enough as is :)

  • One way I find myself doing "picking" in js only is using array.filter 

    	const instances = runtime.objects.Sprite.getAllInstances(); // get an array of instances
	const picked = instances.filter(obj => obj.instVars.foobar); // filter based on instance Variable

    which in events would be basically just this

    Here's some more info on it

    developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/filter

  • Hmm interesting. I'd suspect it's an oversight, I think it should be ok to post it in the issue tracker github.com/Scirra/Construct-bugs/issues

  • Maybe something like:

    1. On drag start

    2. Add all cards you want to drag within the hierarchy with "Add child" construct.net/en/make-games/manuals/construct-3/plugin-reference/common-features/common-actions

    3. On drop, remove all cards from the hierarchy

  • Heh, I just had an epiphany. See, I'd have argued that this can be also quite annoying to deal with. It does work well with hierarchies/templates, but what if I don't need a rectangular hitbox. What if it's a single big spike and I need it triangle-shaped? My first thought was I'd need to create specific collision polygons for every differently shaped object... but there's a feature that I tend to overlook a bit. Meshes! Meshes solve that quite elegantly. And one obvious benefit is that I can also make an enemy only partially spiky simply by adjusting that sprite, which I would have to solve this way anyway even with javascript.

    Only downside I see with this approach is the lack of a simple catch-all. I don't think spawing in the spiky sprites via events is ideal and hierarchies can be a little bit annoying to deal with (although it's gotten better over time), and some objects (let's say a static sprite) would be so simple to solve by just saying "you're spiky now" as opposed to creating hierarchy, template, placing replicas, having to remember to update the replicas across all layouts when I make changes,... And the mesh could also be somewhat annoying to set up in some cases at least, for example with a round sprite it's quite easy to just press "guess collision polygon" and be done with it, but adjusting the mesh nicely to that...

    Tilemaps are also a bit tricky in that regard I think. I can't really just create the spiky sprites if I have differently shaped spikes, at least not without some extra work to make a specific template for the specific tiles. Or I make an extra tilemap that is only spikes, but that then again would require me to do an extra "or on collision with tilemap" which kinda defeats the purpose.

    But I suppose this is still the ideal solution.

  • Just wanna do a little thought experiment. I have roughly an idea on how I'd do this myself, mostly using javascript. But the point is to do this via events only, because that's one of the main things in Construct. So here's the task:

    1. Have an object

    2. This object should get destroyed whenever it overlaps with something that's "spiky"

    3. "Spiky" objects can be pretty much anything, be it Sprites, 9-patch, tiled backgrounds, maybe even a specific tile in a tilemap

    Seems deceptively simple, but how do you actually define "spiky" objects? Instance variable perhaps? That means I will need an "on collision with familyA OR familyB OR familyC OR..." for each type of family. Super annoying to work with, should be easier imo.

    In javascript I'd subclass all my objects, so it's pretty easy to just add a property "this.spiky = true", then gather all relevant instances and execute a testOverlap() on them. Done, maybe I need some extra handling for the tilemap part at worst. 

    	const instances = [array of instances I wanna check for overlap];
	const spiky = instances.filter(obj => obj.spiky === true);

	for(const i of spiky) {
		if(this.testOverlap(i)) {
			this.destroy();
			break;
		} 
	}

    I think the key here is the fact that the collection of instances can simply be a wild mix of any type of instances. The filter function doesn't care, neither does testOverlap().

    Any idea on how or even if it's possible to replicate that in events with the same effectiveness?

  • Well if it's an option it should probably be supported. You should post such requests to the suggestions platform too construct.net/en/forum/construct-3/general-discussion-7/announcing-new-construct-161682

    But also... you could just not show an interstitial ad the second the app is opened :V Surely there is a better way to monetize than that.

  • I couldn'see anything wrong with the project, this does actually look like a bug. You probably should post it in the issue tracker

    github.com/Scirra/Construct-bugs/issues

    I thought that maybe a ray shoots off randomly somewhere or that the order of polygon points gets messed up somehow, but since drawing the outline works perfectly that can't be it.

  • Congrats, a lot of people don't even get this far in the first place.

    I am being inundated with spam emails asking for free steam keys.

    Lmao yeah, those are pretty much all key resellers trying to nab a free key. Most of them might look legit at first glance but they don't pass a closer look. Thankfully this dies off somewhat after a while.

  • You also have to set the lvl variable of the object. And also there's no check in place where and how quickly you can create the objects.

    I'll let you figure out the rest. ;)