R0J0hound's Forum Posts

  • Changing the playback rate changes the pitch. For example I have used the sound for one piano note and got any other note by changing the playback rate.

    On the JavaScript side in addition to playbackRate there’s a PreservePitch setting which controls whether the pitch will change with the rate or not. In construct at least it’s off so changing rate changes pitch.

  • Cool stuff

    Programming makes math way more fun since it’s a way to apply it.

  • What kind of ideas are you after?

    To draw stuff use the drawing canvas.

    To mask stuff use a blending mode. Blending modes can be used while drawing and you could use multiple canvases. Draw to one then paste it with a blend mode onto another one I guess.

    Freehand drawing tool? Just draw to the mouse location when the button is down every tick. To fill the gaps when moving fast you’d also draw a line or rotated rectangle from the previous mouse location to the current one.

  • That sounds messy to have all the possible enemy attributes as family instance variables. You probably just want attributes common to all enemies to be in the family and the attributes specific to certain enemies as instance variables of that type. Instance variables overall are the cleanest way to store values per instance.

    When you add a dictionary you only get one. To be interchangeable with instance variables you’d want a dictionary per instance, but that’s not super straightforward to do and can make events look more busy.

    You can put an object type and a dictionary in a container to have one per instance, but you can’t create a container with a family. Containers let events automatically pick the paired dictionary when you pick a sprite.

    Another more manual way is to create a dictionary whenever you create a sprite and store the dictionary’s uid in an instance variable of the sprite. Then you’ll need to pick the dictionary whenever you want to access it in events. You’ll probably want to pick and destroy the dictionary when you destroy the sprite too. This is useful in some situations but generally it makes events harder to read.

    So apart from having values per instance.

    Variables are nice since they are named and let you catch typos as you write them. They are also cleaner looking to use over dictionary keys.

    Dictionaries are accessed by a text string so it’s up to you to avoid typos. Accessing a value with a name you didn’t add to the dictionary will just silently give you a zero which can be a tricky to notice. With a dictionary you can also add things on the fly but that has limited usefulness. It also lets you access values by name if that’s important.

    Overall using variables or instance variables are the way to go, especially if you have values per instance.

  • Here's an example of it. It corrects the position and the velocity. Seems to work alright with collisions if you add them. In C3 at least if you enable wall sliding.

    dropbox.com/scl/fi/sflsjyje1eqwgtxhk9qjb/tetherObjects.capx

  • Here are some ideas.

    You can start the array with all 50 numbers in order. Repeat 50 times->set at (loopindex) to loopindex+1. The you can repeatedly swap values at two different locations. The shuffling would be done like this. 

    vars i0,i1,tmp
repeat 100 times
— set i0 to int(random(50))
— set i1 to int(random(50))
— set tmp to array.at(i0)
— array: set at i0 to array.at(i1)
— array: set at i1 to tmp

    Another idea would be to take advantage of the arrays sort action to do the shuffling. You’d set the array size to 50x2, and the first column would be a random value and the second column the number. You’d populate it with: 

    repeat 50 times
— array: set at (loopindex, 0) to random(1)
— array: set at (loopindex, 1) to loopindex+1

    Then you’d use the sort action. Then you can probably remove the random column with a delete action on the y axis.

    A third option could be to use 50 instances of a sprite as an array instead of the array object. You’d create 50 instances and you’d be able to access it like an array with sprite(n).value. To populate it you can do: for each sprite ordered by random(1) -> sprite: set value to loopindex+1.

    You also could look at the advanced random plugin since it may be designed for that sort of thing.

    To limit the value 25 to be after index 20 you’d probably want to check where that value was with the array.indexof expression, then either just re generate the array again to see if it’s better or just swap it with a value elsewhere with basically the swap idea above.

  • Try it without the wait. Loopindex isn’t preserved when using a wait.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Just use loopindex not loopindex(“”)

  • Yeah I was thinking collisions could be an issue but it should mostly work. But yeah the velocity bit is probably problematic. You could also cancel the part of the velocity of the objects moving away from each other.

    Here’s one way to do that. You’d do this in addition to correcting the position in my other post. Relv is the velocity of the objects moving toward or away from each other. Then you’d subtract that from the velocity’s so it just keeps the rest of the velocity.

    Ang=angle(a.x,a.y,b.x,b.y)

    Relv= (a.vx-b.vx)*cos(ang)+(a.vy-b.vy)*sin(ang)

    A: set vx to a.vx-relv*cos(ang)

    A: set vy to a.vy-relv*sin(ang)

    … same for b

    Overall setting the position is nice in that it provides a hard limit to how far objects can move apart. Adding a velocity correction to that helps.

    Just changing the velocity to limit the positions indirectly is another idea for sure. It’s actually what the physics behavior does to resolve collisions and joints. In practice it can be a bit spongier though. A quick way is to apply an acceleration to the objects toward each other if too far apart which is a bit spongy. Another idea is to just do the velocity correction above. Probably only if the relv>0 or moving apart. However you’ll still need to add a bit more velocity to move the objects back toward each other otherwise they will drift apart

  • You could move them toward each other if the distance is greater than 300.

    Roughly this. Distance-300 would be the extra distance beyond 300, and you’d divide it be two so each object goes half that. 

    Var dist=0
Every tick 
— set dist to distance(a.x,a.y,b.x,b.y)

Dist>300
— a: move (dist-300)/2 pixels at angle angle(a.x,a.y,b.x,b.y)
— b: move (dist-300)/2 pixels at angle angle(b.x,b.y,a.x,a.y)

  • It should be the same.

  • Well in construct the red dot is at angle 0 from the center of the needle. You can then use the anglediff() expression to get the difference between two angles. And to make it -20 at five just multiply by -4

    Volume =-4* anglediff(0, needle.angle)

    Or if you just want to use the position of the red dot instead of an angle

    Volume = -4*anglediff(angle(needle.x,needle.y,red.x,red.y), needle.angle)

  • Here's another iteration that puts the anchor points at the corners instead of the sides. It also keeps track of where anchors are in a dictionary so it avoids putting markers on attached objects and avoids duplicate markers. Still only 10 events, but I'm sure it's possible to simplify further so you have more than 15 events to use if you use the free version.

    Anyways some more ideas maybe.

    dropbox.com/scl/fi/g7fcdn16o3z7e4flss33y/dynamic_attaching2.capx

  • This was made before you posted your last few posts but maybe you can get some ideas from it.

    Roughly it just creates attachment points around all the attached objects, and then deletes invalid points that overlap other attached objects.

    It keeps track of what's attached with a boolean variable and doesn't let moving objects get attached so you can throw them. Also it keeps track of the order the objects are added with a number variable.

    dropbox.com/scl/fi/7vf4eia7vzvmnzd8hoi6g/dynamic_attaching.capx

  • An image illustrating what you’re after often helps if you can’t describe it enough to get the idea across.

    I get that you want to be able to attach multiple instances to each point now but you probably need to be more specific about what you want to happen when there are multiple on one point. Should they stack? Should they all not overlap but be close to the point, like in a circle? Or since you said bigger maybe you want them to overlap and scale up based on how many are attached?

    As to the statements about confusion and weird with how your attempts are running I’d recommend sharing a c3p or a screenshot of your events. Typically there is no way to debug things based on descriptions otherwise. But if you meant them as just vents in frustration I can understand that too.