R0J0hound's Forum Posts

  • Before settling on a way to tackle this I'd try to better define what I want to do. Go full hog at first and then whittle down features till it's more reasonable and doable.

    Will I want all the roads to be the same or would I like variations like driveways, multi-lane highways, country roads, etc...

    From the above I'd want to try to think up how I'd want the intersections and transitions between the roads to look. Probably make lots of diagrams as examples.

    Would you want different road heights? Bridges and tunnels?

    To define the roads you could just make up a bunch of building block images of road pieces. They don't have to be grid based but in practice it's hard to have them match up otherwise, although I'd imagine it's possible.

    For full analog with roads going every which way I'd go with generating the road graphics with code. The intersections would be trickier but then again I'm not really sure how I'd want them to look. Roughly off the top of my head a straight road would be a solid color rectangle with two fog lines on the side, and a dashed yellow line in the middle. Curved roads are just multiple straight roads, and intersections could be done by drawing a solid color polygon over the intersecting part. Again I'd need to figure out the different looks for intersections and maybe make it so you could choose form different styles.

    To define the roads I'd want to keep the tedium to a minimum. You could probably simplify defining roads to just drawing lines and have the intersections figured out with code. The constuct editor isn't suitable for defining a bunch of lines like that, so I'd either make an in game editor or utilize some vector drawing app and pick a save format that I can pull the lines from with minimal coding effort.

    For in game you'd want to be able to draw all that reasonably fast, and since you would usually be pretty low you'd only need to draw the roads with all their details around the player. You wouldn't want to have to check every road so you could just have large squares that roads are part of, and if the square is in view just draw all the roads in them.

    Anyways just some ideas. I'd do a lot of mini tests with the different aspects to see if they are achievable. I'd probably simplify things down a lot to make everything more doable in a reasonable amount of time.

  • Here's another example. With it you can either define the path with the order you create the nodes, or set the node.order variable to define the order and event 4 with recreate them in that order. They don't have to be sequential numbers, just as long as the next one is higher than the previous.

    dropbox.com/s/c2a2xy1yn78i0ql/path_follow_3.capx

    The con with this method is it only allows one path.

  • The nodes have an instance variable “links”, which is a comma separated list of the Uids of the connected nodes.

    So say you wanted a path through four nodes with uids 2,5,3,6 you’d do this:

    Node 2 links = “5”

    Node 5 links = “2,3”

    Node 3 links = “5,6”

    Node 6 links = “3”

    If that makes sense.

    Since you just want to be able to move forward and backward on the path my capx isn’t quite suited for it. It can be made simpler but I’ll have to look at that later.

  • The upside down T sounded interesting, which is basically a path that has branches. Here's what I came up with. Defining the paths is pretty tedious since you have to place a list of the uids of all the connected nodes in each node, but the events are fairly simple albeit dense.

    dropbox.com/s/maef5spnv5olc07/path_follow_2.capx

    The motion is driven by the the input angle. If the object is between nodes the object will move forward or backwards depending if the input direction is pointing more in one way or another. Also when a node is hit it will look at all the connecting nodes and pick the one with the lowest anglediff with the input angle to move towards.

    The events a mostly easy enough to follow I think. The exception is probably the formula in event 13:

    obj: add (cos(inputDir-self.ang)>0?1:-1)*speed*dt to d

    inputDir is the angle from the keyboard input

    self.ang is the angle between the current pair of nodes.

    cos(inputDir-self.ang) is the dot product between two unit vectors made from those angles. It just simplifies to that. If the dot product is positive then the inputDir is mostly in the same direction as the angle between the nodes. And if it's negative then it should go backwards.

    The conditional ...cos(inputDir-self.ang)>0?1:-1 is to make it only positive or negative 1. That is to keep the speed constant.

    The remainder is to apply the speed in that direction with dt.

  • Normally you can read and write text files and send text over a network. Binary is useful to be able to deal with nontext files or to send data more compactly over the network.

    Reading non text files is more niche but can be useful. Typically you’d be fine with just using text based files.

    Binary data can be more compact than text. Especially with numbers. For example look at the number

    123456789.0123

    As text it will take 1 byte per character or 14 bytes, or you can store it as a 64bit float and only take up 8 bytes. So in that simple example you’d save 6 bytes for one number. Anyways, that’s just one example.

  • Ah. Guess I never got around to fixing it.

    Here’s a list with what should be working links.

    construct.net/en/forum/extending-construct-2/addons-29/r0j0hound-plugin-list-135781

  • It should be the one in the first post.

  • I think he may mean that when moving along a rotated wall the motion isn’t smooth or sliding.

    Maybe in the same vein as this:

    construct.net/en/forum/construct-2/how-do-i-18/8-direction-behavior-slide-95148

  • I usually do it with one condition. Pick the relaxant instance and then the following will run if they are in the mountfamily. It may be more or less what you ended up doing. I didn’t read too carefully.

    Mountfamily: pick by uid playerfamily.uid

  • I’m guessing from what I can find that the text is drawn with a html5 canvas, so css isn’t used at all. The size limit is likely arbitrary though.

  • I’d just scrap the whole effect and start from scratch. The way the effect works is it draws 8 copies of the image at offsets and sets all the pixels to a color.

    Transparency sounds like just another number to adjust that. The issue is blending the 8 images together. It’s the same issue as multiple sprites with 50% transparency vs the same sprites with 100% and the layer with 50% transparency. In my non flu thinking I’d do that in two steps. Not sure how that would be done in a shader.

    An inset outline could possibly be done by doing a Boolean blending with the offsets together in some way. Then simplifying it if possible.

    I don’t really want to mess with GLSL or JavaScript within construct. If I have to do that I’d rather do it elsewhere.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Set array size to (tokencount/4,4,1)

    Repeat tokencount/4 times

    — set array at (loopindex, 0) to tokenat(loopindex*4+0)

    — set array at (loopindex,1) to tokenat(loopindex*4+1)

    — ... and so on for 2 and 3

    Alternatively you can simplify it further

    Set array size to (tokencount/4,4,1)

    Repeat tokencount times

    — set at (int(loopindex/4), loopindex%4) to tokenat(loopindex)

  • I re-shared the images in that link. They are ways to approximate the collision point once the balls are overlapping.

    You still need the point when the balls collide. The two ways are either to use a loop to move the one ball forward by steps till they collide, or you could raycast from the white ball to the red.

    the loop way could be something like this:

    every tick:

    -- testBall: set position to whiteball

    -- testball: set angle to whiteball.angleofmotion

    repeat 1000 times

    testball: isn't overlapping redball

    -- testball: move forward 1 pixel

    The ray cast method it more complex but more percise. Basically a ray from the whiteball against a circle at the redball's position with a radius of whiteball.radius+redball.radius. I couldn't find where I've done that before, but it's a formula you can find online.

    Anyways after that you can calculate the bounce. This is pool so we could do perfectly elastic bounces. You really only need the normal (angle from one ball to another) and the velocity. The formula is pretty standard in physics. Here is a possible example, and a link to an article about it.

    construct.net/en/forum/construct-2/general-discussion-17/approaching-pool-ball-movement-56649

    construct.net/en/forum/construct-2/how-do-i-18/fake-physics-collision-123031

    In the end though it may not precisely match the path the balls will move with the physics behavior due to differences in frame time causing the collision to be at slightly different times.

  • I'd imagine it's not possible for most though. I'd recommend doing a bunch of simple projects to try out various ideas related to what you want to do, and see if you have the ability to do them. Then if you find you're able to do that you can try working all the ideas together. You should to be able to quickly see how much is involved and if it's something worthwhile to work at till completion.