R0J0hound's Recent Forum Activity

  • Probably best to read up on picking and the event system works. The manual and tutorials can help. Also what has helped me is experimenting with the events to pin down what specific conditions do and whatnot.

    Generally events work with lists of object instances.

    Conditions, such as comparing instance variables, will filter down the picked instances.

    Actions will then run for each of the picked instances.

    Expressions will reference the currently picked instance, or if more than one is picked it will pick the first picked instance.

    “For each” will pick one instance from the picked instances one by one. That’s why sprite.pickedcount=1 after a “for each sprite”.

    “Pick all” will pick all the instances again. That’s why after a “pick all sprite” the pickedcount=count.

    At least that’s some basics. I’m unable to effectively cover all cases. It also doesn’t help that some conditions do something else entirely.

  • Conditions can do several things. For an object type it filters the list of picked objects. The actions of an object type will run for each instance.

    For example 

    Sprite: big=1
— sprite: set size to 25x25

    Is equivalent to: 

    // fist pick sprites
Var Sprite = list of all sprite instances
Var Picked = [] // empty list
For (var i=0; i<sprite.length; i+=1)
__if(sprite[i].big==1)
____picked.append(sprite[i])
For (var i=0; i<picked.length; i+=1)
__picked[i].setSize(25,25)

    And oddly enough adding a for each after the condition will do the same thing.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Loop over all the keys in the dictionary and create a card for each one?

  • There’s always many ways to do things. One way could be:

    Use an array or json object to store a list of all the cards. In it you could store things like the name of the card, the file name of the image, and if it’s owned.

    Then you could make a second list of owned cards or use find() with the name to filter the list. Basically by looping over the complete list and building the filtered list from that.

    Now to display those cards you’d loop over the filtered list and create the cards and position them like dop suggests.

    If looping over the lists becomes too slow you could only loop over part of the lists per frame.

    You could also possibly not have to create all the cards from the filtered list to display them. Depending how you display them you could calculate what cards would be visible and only create those.

    Finally if video memory becomes an issue with so many unique cards you would need to do some kind of memory management. So instead of adding all the card images to the card sprites animation, you’d add them to the files folder of your project. Then you’d load/remove the images on the fly to the card sprite as needed at runtime. It’s probably more tedious to do than it sounds. You’d want to keep track of what images were loaded to avoid repeated loading.

    Anyways, that’s a fairly low level overview of what might be needed. There are probably many simplifications or shortcuts.

  • If both triangles are about the same size you could just check if their positions are about the same. For example abs(tri1.x-tri2.x)<8, and the same for y. 8 would be how close is ok.

    Another idea is to check if all three corners of one triangle are overlapping the other triangle. You’d do that by adding an image point to all three corners and use the system condition “pick overlapping point”.

  • Hi.

    The “compare: dt>0” is correct. Dt can be 0 in construct but we don’t want that since we divide by dt, and dividing by 0 would give infinity.

    And yes, we are setting diff twice but the second one is using the result of the first. Basically what that’s calculating is the signed angle difference or: singnedAngleDiff(a,b)=angle(0,0,cos(a-b),sin(a-b))

    Or another way to think about it is first we set diff=a-b then we normalize the angle to the range -180,180.

    The third action had a typo. “da” should have been “diff”. My apologies. The formula defines a damped spring.

  • Giving something momentum basically means you give it velocity and instead of changing the position or angle, you’d change the velocity.

    It’s pretty popular to use lerp() to do an ease out but I don’t think that’s suitable to use with momentum.

    So you’d add a angvel variable to the sprite and then one way you can change the angular velocity is with a damped spring. Diff is the signed angle difference which is like the anglediff() expression but it’s negative if ccw. In the expression that sets the angvel you’ll see 0.1. You can change those in the range of 0-1 to adjust the spring stiffness and the amount of damping.

    Var diff=0

    Compare: dt>0

    — set diff to sprite.angle-angle(0,0,gamepad.axis(0,2),gamepad.axis(0,3))

    — set diff to angle(0,0,cos(diff),sin(diff))

    — sprite: add -0.1*diff/dt-0.1*self.angvel to angvel

    — sprite: rotate self.angvel*dt degrees clockwise.

  • Well one way would be to have one sprite type and call it “card”. You’d have all the different looks of the cards as different animation frames, and you’d set the animation speed to 0. Basically you’d create or destroy individual cards to add or remove cards you own.

    You’d then select certain cards from that with conditions to pick them.

  • It’s probably not random.

    You sound like you have a specific behavior you’re after that you have footage of or have seen. You could start by examining the motion of one leaf and trying to break it down into a path that you could replicate somehow. Worst case you could maybe use a timeline to manually plot a path. With two or three varieties you may get enough variation.

    At the other end of complexity you could try some grid based fluid dynamics to model airflows. Then the leaves would move based on where they were within it since you would have velocity at any point. Then you could model the leaves as slightly curved apply the wind to them based on the angle the wind hits them.

    There are probably many options in between. I don’t have any specific examples in mind though.

  • You don’t want to use Sprite.width since it’s changing. Worst case just use a fixed number such as 64 or whatever width you want it to start at when not rotated.

    I guess it’s sprite.ImageWidth not originalWidth.

  • Interesting take to consider the 0-255 range a relic. It’s standard to represent a pixel with a 32bit integer or 8bits (0-255) per component. That’s used in textures, the screen and when you snapshot a drawingCanvas.

  • Probably just: 

    Var rotY=0

Every tick
— add 50*dt to rotY
— sprite: set width to self.originalWidth*cos(rotY)

    Also it’s probably not necessary to post the question twice in both the c2 and c3 sections. The forum is already slow and most just look at new posts so they’ll see the question no matter where you post it.