R0J0hound's Recent Forum Activity

  • Well in the verlet_cloth_paster.capx the distortion is drawn in events 15-17. Those are the only parts dependent on the paster plugin. Remove the paster plugin and the capx should be openable in c3 since only vanilla features are used then.

    I don't use c3 so I won't be making a cp3 example, but as i understand it you can make it work with distortion mesh with one action added to event 16. Somewhere you'll also want to set the x and y divisions of the mesh distort to cloth.resx and cloth.resy.

    for each cloth
    array: for each xy element
    -- set i to array.curx
    -- set j to array.cury
    -- cloth: set distortion point (i,j) to (p(Array.At(i,j)).x, p(Array.At(i,j)).y)
  • Hi,

    What are the issues you’re encountering?

  • Looked around the web for a bit on how electronic simulators typically work. Seems the basis of it is Ohm's law (I=V/R) or in more useful terms: Current=(voltageOut-voltageIn)/resistance. That can be used to see how voltage changes when moving through a component.

    For a simple ring of components with one battery, you should be able to just start with the positive on the battery and loop around till the negative is reached. Just use ohm's law at each component, and if negative can't be reached then stop since there is no complete circuit.

    The general case with branches is a bit more interesting. Found this topic on it that seems to give a good starting point. Looks like it's done by solving a system of linear equations. To do this in construct we could store the system in an array, and implement an algo to solve it.

    electronics.stackexchange.com/questions/91416/how-do-circuit-simulators-actually-work

    I can see it working if everything is connected in loops. Not sure if it handles dead ends and loops without batteries. Might have to do some pruning beforehand.

    Anyways, seems to be a rabbit hole for sure when making a circuit simulator.

  • Well the bulk of it is a vector projection, so reading a tutorial on vector math may be useful.

    This equation sets t to a normalized vector projection of p onto the line between the two centers.

    t = clamp(((p.x-c0.x)*(c1.x-c0.x)+(p.y-c0.y)*(c1.y-c0.y))/((c1.x-c0.x)^2+(c1.y-c0.y)^2),0,1)

    Combined with:

    targetx = lerp(c0.X,c1.X,t)

    targety = lerp(c0.y,c1.y,t)

    you end up with the point closest to object p on the line segment between c0 and c1.

    If you could do vector math directly in construct it could look like this:

    A = p-c0 // vector from c0 to p
    B = c1-c0 // vector from c0 to c1
    t = (A dot B)/length(B)^2 // normalized vector probjection
    t = clamp(t, 0, 1) // limit to the line segment
    closetPoint = c0 + B*t // get point by lerping between c0 and c1 by t

    So anyways, you get a point between c0 and c1 close to p.

    Next it moves p toward that point so it's exactly a 'radius' away.

    Then it turns p left 90 degrees and moves forward at "speed" pixels per second.

    Honestly it's just a bunch of simple things put together. I usually draw a picture as i go coming up with these things. Then i simplify the math as much as possible.

    You could google things like "vector projection" and "point closest to a line segment" to find more info about the math.

    The construct specific stuff:

    clamp(value, low, high) limits a value to be between a low and high value

    lerp(a, b, t) moves a percentage from a to b by t. Where t is between 0 and 1.

  • One idea is to find the closest point on the line segment between the two centers from the car. Then move a radius distance from that point.

    Here's it in one event. Change the radius and speed instance variables as needed. The long formula is just a vector projection in case you were curious where it came from.

    dropbox.com/s/eeuayajvv2lv2l4/orbit_line.capx

    The only issue is the speed around the curve will be different than on the straightaways, but it's not really noticeable.

    A different solution i've tried in the past is to divide up the sections of track into straight and curved sections and moving along them.

    construct.net/en/forum/construct-3/how-do-i-8/keep-object-train-curve-rail-143038

    It didn't consider differing radiuses but the speed is constant even on the curves.

  • I once poked around the C2 source to see where the default instance is pulled from.

    Basically the first layout the object appears, the lowest layer the object appears on that layout, and finally the one with the lowest uid.

    It may be the same in C3, not sure why it would change. The dev’s response indicates they want it to be thought of as arbitrary and could change. It won’t though imo. Most projects rely on the defaults.

    So it seems a good solution would be to create a layout, put one instance of every object, and move that layout to the top of the layout list.

    construct.net/en/forum/construct-3/how-do-i-8/instance-variable-initial-139702

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Here's the way i found to see if a circuit is connected in a particular way. The idea is you give the wires an id and per connection you specify the two wires connected on either side. It looks like this:

    1,2:resistor;
    1,3:resistor;
    2,5:battery;
    3,4:switch;
    4,5:fuse;

    Now, depending on how you connected the stuff together it could give you this instead

    1,2:resistor;
    1,4:resistor;
    2,3:switch;
    3,5:fuse;
    4,5:battery;

    They still represent the same configuration, and there can actually be 5! (5 factorial or 5*4*3*2*1 or 120) different combinations that are correct when there are 5 wires. So to see if they match we check them all.

    The good news is different wires connected to the same nodes are considered the same nodes so that reduces the complexity.

    Also in this example i made it not matter which way you hooked up the components. For most components, like resistors, it doesn't matter, although things like batteries probably do matter.

    dropbox.com/s/4pv5ldu8vkuhzp2/node_idea_2_cleanup.capx

    This is the circuit you're trying to match.

  • Well the first part would be to somehow keep track of what is connected to what.

    One way would be to have the nodes you drag around, and the connections could be indicated by line sprites with two variables that indicate the two uids of the connected nodes.

    Since these are electronic components, I'd suppose each component has two nodes, an in and an out if you will.

    So you'd have components you can drag around, each with two nodes. Then you'd have a way to add a wire between any two nodes. It's doable by referencing stuff by uids, but there are probably other ways.

    To tell if a connection setup matches another should mostly be a matter of checking if the same list of components are used, and they have the same connections. I need to mess with the idea more since there is the issue with the order you added the components. Also most components with maybe the exception of batteries can be connected in reverse. So it would amount to checking all the different combinations.

    You could probably do it easier by checking some other criteria to see if it's a correct setup. Maybe just the same components used and everything is powered. Things like limiting the configurations possible can simplify things too, such as a single loop circuit.

    That leads to how the power is transmitted. For a single battery a simple thought would be to start from the positive and do a astar search along the connected nodes to the negative. For a true simulation it's probably more nuanced dealing with resistance. Probably a flood fill along the connections would work. Flood till you make a circuit. Electricity physics would be your friend here for really good results.

    Anyways, here's a example of how uids could be used to keep track of the connections. It also shows how a basic flood fill can be done. Could be useful for some ideas.

    dropbox.com/s/yh85n6xjtwij2f9/node_idea.capx

  • Here's another idea to add into the mix of clever ideas posted in this topic.

    You can define any path as a bunch of points. Between two consecutive points are lines. Then with a bit of math (vector projection) we can find the spot on a line closest to a point. We can then use that to move along that line, and when we move off the ends of the line we can make it switch to the next or previous lines.

    dropbox.com/s/njck4ai7ebh2ivr/drag_along_path.capx

  • According to this:

    developer.mozilla.org/en-US/docs/Glossary/Origin

    Two pages share the same local storage if their origin is the same.

    So while beta.myawesomegame.com and stable.myawesomegame.com don't work since they are considered different origins, you should be able to do myawesomegame.com and myawesomegame.com/beta or something like that and it should work.

  • Well, according to this:

    javascript.info/localstorage

    localStorage is per domain, but you can't access other site's localStorage.

    So I'd guess that means if the first game was on a website like:

    http://www.myawesomegame.com/game1/main.html

    and the second was on:

    http://www.myawesomegame.com/game2/main.html

    Then they would have the same localStorage. Would have to test, but I never upload games online so I don't know for sure.

    Now, I don't know how construct handles that internally. They could be somehow making it unique per game and not shared.

    You could do it manually with js to cut out the middle man to see what happens:

    // to set value
    localStorage.setItem('key1', 1337);
    
    // to get value
    localStorage.getItem('key1')

    Why can't it be that simple in Construct? They seem to prefer triggers.

  • antigenmx

    Probably better to ask in the topic where I originally posted it. I don’t recall it.

    Also It’s not a relevant question to this topic. Kind of bad form to hijack a topic like that. By tagging someone they well see it no matter where it is.