oosyrag's Forum Posts

  • Update 2: Applied for visual line of sight dropbox.com/s/m6x32uzqcjlf8sk/VisualLOS.c3p

    Canvas' poly outline looks good but the fill doesn't work half the time. Am I doing it wrong?

    Edit: Fixed, it had to do with the order of adding poly points and the resulting intersection of poly points.

  • Update: Debugger shows 0 collision and poly checks/sec?

  • Project file: dropbox.com/s/iwy8ckiozyp604z/Raycast.c3p

    Method 1: By Angle

    Store angle and position of each corner of each solid object in an array.

    Create a blue line from sprite, angled towards stored angle, width (length) of LOS.Range.

    Cast ray towards each angle by x=origin+LOS.Range*cos(angle), y=origin+LOS.Range*sin(angle)

    Subevent if ray intersected, set line width to LOS.HitDistance, change color to green (truncate the line if it hits a solid).

    Result/Issues:

    A and D - Rounding errors, line can either collide or not at corners. Expected behavior.

    B - Works as expected

    C - No collision/ray intersection detected (until trying to exit out the other edge). Can confirm when moving around the origin sprite, if the max range for that particular line terminates within the solid, the line stays blue. So the first corner does not trigger the ray intersected event at all (sometimes). Possible bug?

    Method 2: By coordinates

    Same as above, except casting the ray at each corner's stored coordinates. Normally I wouldn't do it this way, except by default there is no way to cast a ray by angle/range and I am experimenting anyways.

    Result/Issues:

    Some lines don't show up at all, some lines work, and some lines shoot all the way through the solid.

    For the lines that don't show up, debug shows that the line is spawned, but with width 0 and set to green. So the intersection event fires, but LOS.HitDistance returns 0. No idea what is going on here.

    For the lines that shoot through the solid, simply no collision was detected (I draw the lines at full length first, then resize if a collision occurs). Can be reasonable due to rounding errors. Either the ray doesn't completely reach the nearest corner to collided, or same as problem C above.

    Further testing reveals that when putting the solids out of LOS range (300), the cast ray action still works. The farthest corner will trigger the intersection event and extend the line as expected, but the nearer 3 corners either don't trigger the intersection event, or they trigger it and LOS.HitDistance is 0.

    There were a few issues and I wasn't sure if I was doing anything wrong/behaving as intended, so I figure I'd make a post and ask for input before making a bug report.

    Also feature request: cast ray by angle, to LOS range? Not a huge deal and I'm out of suggestion votes. Workaround is simple enough, but "x=origin+LOS.Range*cos(angle), y=origin+LOS.Range*sin(angle)" might not be immediately obvious to some people. Also I don't know if there might be a performance benefit to not using sin and cos to calculate out the coordinates when casting a significant amount of rays.

    PS: Thanks for developing this, it was a nice surprise! With canvas, all the tools are finally available to do visualizations for line of sight! redblobgames.com/articles/visibility (Edit: Also really fancy lights and shadows!)

  • Two ways

    A: Use the sync action - Create the object on the host, and the object will be created and updated for all peers. Peers do not create or otherwise manipulate these objects. Peers should instead tell the host what they want to do, and the host will do it for them (either via messages or send input state action).

    B: Don't use the sync action - Use messages to tell the host (and have the host relay to all other peers) what has been done. Each peer creates/makes changes the objects on their own locally, based on direct input and received messages.

  • Sync object

    Automatically sync an object. The host sends information about synced objects to peers. This is one-way transmission; peers sync with what is happening on the host.

    If you are using sync with an authoritative host, peers will only send their inputs to the host. Have your peers tell the host what they are doing or want to do by sending a message. The host will move all synced objects based on these messages/inputs, and thus update the object for itself and all the peers.

    Local input prediction, lag compensation, and interpolation will be not applicable to your game, since it is turn based.

    Alternatively, if you don't need an authoritative host, simply have each peer and host relay their actions to each other via messages, and update the game state on each peer/host individually. Make sure messages are set to reliable ordered, and make sure host and peers utilize the same set of events to update the game state to keep everyone synced. Do not use the built in sync object feature in this case.

  • Basically there is no built in functionality to get the current window size. The intention is use best practice scaling modes to support different aspect ratios, since you have no control over the window size of the end user. There shouldn't be any case where resizing your visible viewport to whatever the window size is is superior (this would basically be like using a huge viewport, and no scale mode.

    This article may help, in case you haven't seen it yet. construct.net/en/tutorials/supporting-multiple-screen-17

  • I can't open your capx with plugins.

    Probably just a timing issue, you can adjust the lerp parameters.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Will need to see your project to troubleshoot. I'm guessing you have some event running every tick that shouldn't be.

  • Try looking up the GitHub API.

    You might be able to do something with iframes as well.

  • softwareengineering.stackexchange.com/questions/86863/how-are-minimum-system-requirements-determined

    Alternatively, find a game similar to yours and copy their requirements.

  • dropbox.com/s/utr7vnkx9ldzzdx/dramaticzoomexample.capx

    When doing actions over time, use a timer behavior. For smooth motion, you want to use lerp.

    Construct 3 has a new Tween plugin that makes this sort of action easier to accomplish.

    What I'm doing here is using lerp between two points, using the time elapsed over total time as my progress amount.

    If you want the effect to happen before the object actually collides, you can use an invisible helper object that is pinned ahead of the bullet to trigger the effect instead.

  • You set the animation to the message contents, but then immediately change it back to whatever Self.Ani is.

  • The end trigger does work. Did you check the example?

  • Works as you expect. See example dropbox.com/s/o6zzm9z5hmhfez2/elseexample.c3p

    Check each set of your actions to see if they behave as you want them to.

  • Thanks, didn't know there was a bug tracker for the website. The issue seems to have resolved itself though.