WackyToaster's Recent Forum Activity

  • I haven't tested but you can redefine the function to do nothing with a line of code. It's quite the hack though.

    console.log = function() {}
    
  • If it collides with two at the same time you can add another picking like "pick random" and if there's multiple lvl 1 fruits it will pick just one of the two.

  • It's a short and useful way to write an "if". It kinda translates to:

    	if(Self.AnimationName = "Analyzer") {
    		"List"
    	} else {
    		"Analyzer"
    	}
    

    I always remember it as asking a question like

    is condition true ? If yes : if no

    developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Conditional_operator

  • Yes it does. Especially if you log a lot (inside loops/every tick).

  • Wait... this makes me think the javascript part actually is in fact borked because how do you test for overlap? You HAVE to feed individual instances into testOverlap() meaing if you wanna check 1000 spriteA vs 1000 spriteB you have to use

    const sprite = runtime.objects.Sprite;
    const sprite2 = runtime.objects.Sprite2;
    
    for(const i of sprite.instances()) {
    	for(const i2 of sprite2.instances()) {
    		if(i.testOverlap(i2)) console.log("coll");
    	}
    }

    Or am I mistaken here? Because like this obviously the evenperformance is better by an insane margin

    compared to js

    Am I missing something here?

    EDIT: Lmao nope, even the ghost shooter example has this issue. The event version has like ~6k collision checks at most where the js version quickly balloons to 20k when shooting. I guess this one is actually worth filing a bug for?

    EDIT2: Nevermind I guess github.com/Scirra/Construct-bugs/issues/5665 :V

  • What makes you think that? all the built in behaviors that call it would suffer but they seem performant enough, regardless of how many solids exist.

    Hmm maybe you're right, but it was something I had in the back of my head. I even mention it being performance heavy on the addon page.

    If you tear open the collision engine you'll see that testOverlapSolid() does:

    TestOverlapSolid(inst) {
     const wi = inst.GetWorldInfo();
     this.GetSolidCollisionCandidates(wi.GetLayer(), wi.GetBoundingBox(), tempCandidates);
     for (const s of tempCandidates) {
     if (!this.IsSolidCollisionAllowed(s, inst)) continue;
     if (this.TestOverlap(inst, s)) {
     C3.clearArray(tempCandidates);
     return s;
     }
     }
     C3.clearArray(tempCandidates);
     return null;
     }

    Calling this.GetSolidCollisionCandidates which eventually down the road does a check with collision cells filtering out unneeded collision candidates.

    GetCollisionCandidates(layer, rtype, bbox, candidates) {
     const isParallaxed = layer ? layer.GetParallaxX() !== 1 || layer.GetParallaxY() !== 1 : false;
     if (rtype.IsFamily())
     for (const memberType of rtype.GetFamilyMembers())
     if (isParallaxed || memberType.IsAnyInstanceParallaxed()) C3.appendArray(candidates, memberType.GetInstances());
     else {
     memberType._UpdateAllCollisionCells();
     memberType._GetCollisionCellGrid().QueryRange(bbox, candidates);
     }
     else if (isParallaxed || rtype.IsAnyInstanceParallaxed()) C3.appendArray(candidates, rtype.GetInstances());
     else {
     rtype._UpdateAllCollisionCells();
     rtype._GetCollisionCellGrid().QueryRange(bbox, candidates);
     }
     }

    Before doing testOverlap().

    Since I'm calling testOverlap() directly I'm skipping the step where I'm filtering out based on collision cells. In my case I'm also testing a custom behavior overlap, so I'm testing overlap against all instances that have my behavior attached. This will do an overlap check for all instances regardless of distance.

    Or at least that's what I assume. It appears that the javascript actually also just calls testOverlap(a,b) so that either means it also does not filter out based on collision cells OR it does and I'm simply mistaken.

    Point is I didn't manage to tap into the this.GetSolidCollisionCandidates function from my addon so I sort of assumed it to be not optimal.

  • You ninjad me :)

    It was as I suspected the issue with creating families. The solution is simply to also store the objects name inside the key. And then extract the name using tokenat (the alternative would be using an array) construct.net/en/make-games/manuals/construct-3/system-reference/system-expressions

    and create the object based on the name. You then have to pick the last created family and load the data.

  • Families are a bit tricky. If you tell Construct to create an object "Family" it will randomly pick one of the objects assigned to that family. So if your family contains cirlces and squares, this will randomly create a circle or a square. You probably need to store the name of the object and then "create object by name"

    But without knowing exactly how your project is set up it's hard to give definitive answers on how to solve X, so ideally you could just post an example of your setup.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Man I have sunk a couple of hours into this problem and I still have no idea where to even begin :D It's really not an easy problem depending on how complex you want it. I'd argue the build-in pathfinding behavior is not suited for this type of problem. I've personally never managed to solve it.

    The basic idea is building a nodetree with connections, then use A* to find a path through that tree. But as to how to have the enemy properly traverse along the path... no clue.

    Maybe now that I have a bit more clue about js I could try again but this is rough.

    For a much more basic implementation. A handful of raycasts can do the trick.

    -Move towards the target sprite (either left or right)

    -Shoot one ahead of the enemy, if it hits a wall -> jump

    -Shoot one down from the enemies feet, if it doesn't hit anything there's a pit -> jump.

    This is crude and will not work for anything that requires more complex pathing.

  • Well if you build a nice eventsheet that contains all the players inputs/actions etc. you can just copy that eventsheet into a new project and have it work there too. Only thing is that the new project needs to have all objects used (e.g. the player sprite) already available and with the same name as the old project.

  • You can switch frames with "set frame"

    You can switch animations with "set animation"

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

    You can check if your player is overlapping with "is overlapping"

    construct.net/en/make-games/manuals/construct-3/plugin-reference/common-features/common-conditions

    You can invert conditions by rightclicking -> invert. So you can also check "is not overlapping"

    Put everything together :)

    I recommend switching animations rather than frames btw.

  • You can put dictionary.asJson into yet another dictionary. So you could have one dictionary "savegame" and one dictionary for each type of sprite like "circles", "squares",...

    On save you loop through all sprites and put them into the "circles" dictionary. Then you put "circles.asJson" into the "savegame" dictionary under the "circles" key.

    When you load, you first load the JSON into the "savegame" dictionary, then you take the "circles" key and load it into the "circles" dictionary via savegame.Get("circles")

    Finally you loop through all keys in the "circles" dictionary and create a sprite for each and load the saved data into them.

WackyToaster's avatar

WackyToaster

Member since 18 Feb, 2014

Twitter
WackyToaster has 25 followers

Connect with WackyToaster

Blogs