R0J0hound's Recent Forum Activity

  • Besides being able to convert between rgb to hsv colors you also can get away with just generating the gradients once, and tinting them later with the color property.

    In this c3p the gradient generating code is commented out if you want to use it. Besides that the color conversions are just single line expressions

    dropbox.com/scl/fi/35l84rzbgh45zp467a2ts/color_picker.c3p

    Alternately I was interested in HSL and a circular color picker. Here is that.

    dropbox.com/scl/fi/wfqyelkd0rm3bzgk15h5l/color_picker_HSL.c3p

  • When you create a family instance it just randomly chooses one of the object types in the family and creates an instance from that.

    So to actually duplicate objects in a family you’d probably need to just copy the first two events multiple times and handle each object type in the family specifically. That or just use different animations of one type instead of families.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I’m guessing the speed difference is from the deceleration always being applied in the behavior after you set the velocity.

    So at 60fps the speed after deceleration is applied would be:

    300-5000/60 = 216.66

    And at 144fps:

    300-5000/144 = 265.28

    And at unlimited it could in theory approach much closer to 300.

    Which seems to match with what you’re seeing where 144fps makes it go faster.

    You could try setting the deceleration to 0 when you’re pressing buttons, and set it back to 5000 otherwise. Or maybe you could utilize the simulate control action, since I’m pretty sure deceleration isn’t applied when you tell the behavior a control is pressed.

    I guess we could suggest to have deceleration disabled any frame we set the velocity from the behavior itself, but I don’t think that’s a good idea and would result in many more issues so I’d do one of the other two ideas.

  • Here's one way to do it that's basically what you described:

    dropbox.com/scl/fi/lfmr9x6woehinwv3unnsf/dropshadow_idea.c3p

    The meat of it is the instances are duplicated and placed on the shadow layer. Then to position the shadow you need to access the position (xy) of the instance it was copied from and then you position the shadow with:

    set position to x+(x-light.x)*0.1, y+(y-light.y)*0.1

    The way I handled pairing the instance duplicates is by storing the uid of the shadow instance in the original instance then doing some picking juggling. There are probably other strategies with various pros and cons.

  • You may be able to get a more organic crowd by experimenting with Boids and Steering Behaviors:

    red3d.com/cwr/steer/gdc99

    In practice you have a lot of things you can tweak to get all kinds of different behaviors. Here's one possible result for a jostling crowd that moves around in groups. Left click to have it pursue the mouse.

    dropbox.com/scl/fi/a1mmcm9ty5hpjrz9hgpx9/boids_test.capx

    In some ways it resembles a crowd but it may be more like a living slime kind of thing. But there is a lot of room to tweak to make it behave differently. Anyways, just an idea that could be explored more.

  • If you're not tied to a tilemap you could do the roads with a few crafted overlapping sprites placed in a grid.

    Namely with these 5:

    You could do roads like this. Although making dedicated intersection could look cleaner.

    dropbox.com/scl/fi/eidz69wqyodpz52h2896d/road_pieces.capx

  • Looks like the “start animation” action isn’t functioning, but setting the animation from the current frame does work.

    So instead of

    Start animation from current frame

    Do

    Set animation to self.animationName (play from current frame)

    Looks like it’s a bug even in C2. Probably worth reporting.

  • With just straight and 90 degree turns and intersections I figure you’d need 18 unique tiles (or 6? if you eliminate the mirrored and rotated versions)

    For other angled roads with tile maps you’d usually do something like what asmodean suggested. However you do lose keeping the width of the road staying constant.

    For tiles that can have 45 degree roads with every combination of bend and intersection I figure you’d need 258 tiles before removing the rotated and mirrored versions. It would be way more but as a simplification you’d draw all the tiles within an octagon, and for the corners you’d have a separate tilemap with two tiles for the corners.

    It’d opt to generate all the tiles somehow, and take that opportunity to remove the rotated and mirrored varieties. You probably can get away with less tiles if you limited what intersections were allowed as well. Seems like a bit much to draw them all, and even then it seems like it may be a bit too many tiles to sort through to design levels with manually without some kind of auto tile assistance.

    Here’s a rough template I’d use to draw the tiles. The square is the tile size, and you’d draw the tiles in the octagon within that. The diamonds would be the separate tilemap that would handle connecting diagonals.

  • You do not have permission to view this post

  • Yeah I meant to write variable there

  • Pressing a button to launch a hook and pivoting where it hits an obstacle verses just clicking where to pivot around seems like a minor difference.

    Breaking the problem up into simpler pieces I’d imagine you’re able to see how to launch a hook and see where it hits an obstacle? If not, wouldn’t pressing a button, creating a hook sprite with the bullet behavior from the player, setting the angle of motion up left or up right depending on the direction the player is facing, and finally stopping the hook when it collides with an obstacle work?

    Once you have a hook position you could just use the swing logic from any of the examples you mentioned. I can’t imagine it too hard to just isolate the swinging portion and removing the input method they use.

  • Since it’s vertical you could give the slider called oldy and do an event like: 

    System: pick by comparison: sprite: abs(sprite.y-sprite.oldy)>=10
— play sound
— sprite: set oldy to self.y

    Which means every time the difference between the old and current y position is greater than 10 (the step you’re using for snapping) it plays a sound.

    An alternate way to do the condition would be with an “or” with two y checks, however the abs() lets you handle both at the same time. 

    Sprite: y>=self.oldy+10
Or
Sprite: y<=self.oldy-10
— play sound
— sprite: set oldy to self.y

    Also, you’ll want to set oldy to y at the start of the layout to avoid it making noise when the game starts.

    For a more deluxe version you could handle the case where the slider moved more than one step in a frame so you’d get to hear multiple tick sounds. For that you’d want to mess with the audio action to schedule when a sound will play to offset the sounds from each other. I’d think you’d want to space out the sounds playback time over the next frame which may look something like this: 

    Variable count=0

For each sprite
— set count to int(abs(sprite.y-sprite.oldy)/sprite.step times)
— sprite: oldy to self.y
— repeat count times
— audio: schedule play tick sound at self.currentTime+loopindex*dt/count

    You’d have to look at the manual to verify how to use the schedule playback action.