Line-of-sight Behavior problem

0 favourites
  • 12 posts
  • Problem Description

    Line-of-sight behavior behaves differently from what stated in Official C2 Manual.

    In short: if you have a “Target” sprite in the LOS of your “Shooter” sprite (i.e. it is “within range, within the cone of view, and with no obstacles in the way of a straight line between the two objects”), and then you simply add the Solid behavior to the Target without changing anything else, the Target results no longer to be in Shooter’s LOS.

    Attach a Capx

    The attached capx tries to show a simple case in which this maybe a not negligible issue.

    Description of Capx

    The player's sprite (grey tank) must shoot at incoming enemy vehicles (green tanks & halftracks – only the tanks have Solid behavior). To aim at a given vehicle the player must turn its sprite towards it moving the mouse; the capx then checks if that vehicle is in Player’s LOS and therefore eligible as a target. If yes, the target itself is highlighted.

    Steps to Reproduce Bug

    • Step 1 Try to select every enemy vehicle as a target pointing the player’s tank towards it.

    Observed Result

    Only the halftracks are eligible as target (i.e. highlighted when aimed at); the tanks, despite the fact are exactly in the same visibility conditions than halftracks, are not.

    Expected Result

    Since the conditions to have a clear LOS between two sprites (Player and enemy) are fulfilled by all the enemy vehicles *, any vehicle should be eligible as a target * and highlighted when aimed at (i.e., any vehicle should be in player’s LOS).

    *: Exception: the halftrack behind the tank

    Affected Browsers

    • Chrome (v. 48.0.2564.116 m (64 bit)): YES
    • FireFox: don’t know
    • Internet Explorer (v. 11.0.9600): YES

    Operating System and Service Pack

    Windows 7 Pro, 64 bit – SP 1

    Construct 2 Version ID

    v.224, 64 bit

  • Somehow it looks very logical to me.

    LOS will see all objects in sight, unless blocked by a solid (or a custom object)

    In your CAP it sees all Incorporeals except the one blocked by the solid vehicle.

    It also dont see the vehicles that block theirselfs by beeing solid.

    You need a second condition to see those.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • So, an object may (but only sometimes) block the LOS to itself...? sound quite odd to me...

  • I must be missing something, i dont see a 'sometimes' happen. Plz explain ?

  • Sorry, I mis-explained, I intended for "sometimes" that the object may change its status switching Solid on or off, the times he switches off is visible and the times he switches on it's no longer.

  • Ok, anyway, no problem, really - I try to explain my needs, maybe someone can help (see my example capx):

    1. My player must have a clear LOS to every object he is actually spotting (i.e. to any vehicle of the first row), as happens in the real world. To achieve this, no object can be Solid or defined as “Obstacle” by events. Strange, but... ok.

    2. Objects hiding behind the “big cats” in the first row must be out of player’s LOS, as they are covered (think of infantry hiding behind tanks). Again, nothing strange here, this happens in real world too. But if the green tanks are neither Solid nor defined as Obstacles they are (correctly) “transparent” to player’s LOS.

    It's perfectly possible there is a simple workaround, but at the moment I’m not able to see it….

  • I would do it this way:


    Not pretending that this is the best solution.

  • Very kind of you, thank you so much. So was necessary to write a couple lines of code, to run every tick, to have the Behavior perform in a logical way in this case.

    Problem solved. Thanks again.

  • Well. Imagine you have some walls, floors and enemys hiding behind them. The walls and floors are solid and are needed that way for, by instance, a platform behaviour.

    Would you like the walls and floors to be included in the picklist generated by a LOS condition ?

  • You're right if the game is a "not-so-realistic" platformer. But if (as in my case) the game is "realistic", the answer is yes - since I can perfectly see the wall, I want the possibility to elige it as my target, and perhaps smash it with a cannonball...

    Of course I understand these are just my needs, and for dozens of developers they are different... this is ok, but again (and for the last time ) the manual does not mewntion at alla the targets properties, and one may assume that ANY type of object is ekligible at target.


  • It's very unusual to add the Solid behavior to any interactive or moving object. Why have you done that? If you just delete the solid behavior from the tanks it works fine.

    I think it's ambiguous to ask for whether you have LOS to an object that blocks LOS, so I don't think you should expect it to work either way. Combining that with the fact I can't see any reason to have the solid behavior on those objects, closing as won't fix.

  • Why? my idea was to have - with a minimum effort - objects able to grant cover to those hiding behind it *and* reachable/damageable by heavier fire.

    Anyway I understand your point.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)