oosyrag's Forum Posts

  • You're doing something wrong. Pathfinding reaches max speed just fine in a minimal project. No idea what you're doing wrong with the information you've provided though.

  • The simplest way is to use the layout bounds with the scroll to behavior, it already does everything you want by default.

    Otherwise, you'll need to define your own bounds and margins. You'll need four bounds, top, right, bottom, and left. You'll also want two margins, horizontal and vertical, or you can simply use half the viewport height and width as your margins. You can use the clamp() expression to keep the final value within a minimum and maximum value.

    + System: Every tick

    -> System: Set scroll X to clamp(Target.X,LeftBound+(LayoutWidth÷2),RightBound-(LayoutWidth÷2))

    -> System: Set scroll Y to clamp(Target.Y,TopBound+(LayoutWidth÷2),BottomBound-(LayoutWidth÷2))

  • There is not enough information to even begin to guess what your problem is.

  • Your question is incomprehensible.

  • Use the system scroll to action.

  • Try adjusting your cell size and cell border lower.

  • First thing, don't use the tap gesture, it is unreliable. Use on tap instead.

    Secondly, for a toggle, you should use sub events under a single trigger, and use the else condition. Otherwise the second event will run at the same time as the first event. The event sheet runs top to bottom, so the first event results in the condition for the second to be true and the second event cancels out the first.

  • + System: Every tick

    -> Sprite: Set Bullet angle of motion to Self.Angle degrees

    Use a group to enable and disable.

  • You probably didn't set it up correctly. Without seeing what you did, I have no idea why you failed either.

  • You might have a CORS issue. My understanding is that access control allow origin is set on the server, not in a request. That's like going to a door that is locked to keep out strangers and a stranger walking up and asking to have the door unlocked.

    Or slight possibility your text object is not large enough to fit the text as a single line so it doesn't show it.

  • You can use a common data helper object that is synced, there is a sync instance variable action in the multiplayer object.

    You can also have the host broadcast the message with the relevant information whenever it changes or when a new player joins, which is what I would recommend, as this variable is not something that needs to be updated 30 times a second.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Don't use the wait action. Use the timer behavior instead.

  • This is an interesting problem. I'm sure there are already algorithms out there, but I'm going to take a shot in the dark.

    Taking cover is only applicable from the player's point of view. So when triggered, I would cast line of sight rays from the player towards the enemy, starting from a direct line, and then gradually getting wider to the sides. When an obstacle in range is hit, create helper "movement targets" along the path of the ray away from the player starting from the intersection point, deleting ones that overlap, until the first free space is "hit". That will give you a bunch (or just 2, or only first valid one, really up to you how long to search) of valid points that are behind cover from the player. Then we'll want to pick the one to path find to, either the closest one to the player, closest to the center line, closest to the enemy, ect. We can add additional conditions to invalidate movement targets, like too close to the enemy, too high pathfinding cost, ect.

    Upon reaching cover, I'd imagine the enemy would need to pop out to get los to shoot, which would simply be pathfinding to the player location until line of sight is acquired, stop, and shoot.

    Flanking is similar, except target the rays to the side of the player instead. Build a list of potential movement targets, and use the one that makes most sense, probably the closest one to the enemy unit. You can use additional invisible helper sprites on either side of the player to check for valid "flanking spots", if the movement target overlaps these helper sprites, then it is a valid target. Otherwise, not.

  • Oh I misunderstood. That sounds like a bug and probably one that would be addressed within a release cycle if it was properly reported on the bugtracker on GitHub.