1st Instance of Object Not Reacting While 2nd Instance Does

0 favourites
  • 3 posts
From the Asset Store
This is a single chapter from the "Construct Starter Kit Collection". It is the Student Workbook for its Workshop.
  • Good day!

    PRIMARY ISSUE: An instance of an object is not reacting to player input specifically after the player interacts with the other instance of the same object.

    Controls:

    Arrow Keys: Move the MrSpy_Move (invisible during gameplay) object.

    On-screen arrow keys: Move the MrSpy_Move object and make the MrSpy_Img rotate accordingly for the angle of movement.

    On-screen green button: Initiate theft of document from Guard when conditions are met.

    DETAILS: The character object, Guard_Steal (hereafter just "Guard") has a meter that appears over its head when the player character, Mr Spy comes within range and has line-of-sight (LOS) to the Guard and the Guard does not have LOS to Mr Spy. Using the on-screen green button, the player presses and holds the button to attempt to "steal" a document the Guard is holding. The meter indicates how long until that process is deemed complete. Any interruption - releasing the button, the Guard seeing Mr Spy, or Mr Spy losing line-of-sight to that Guard - will stop the process and the meter will go down.

    PROBLEM: Go figure, I had this working perfectly before...

    When you load the .c3p file, you'll see two instances of the Guard object. They should both be facing to the right and you can see the faint cone for those Guard's LOS.

    You can try to "steal" the doc from either Guard right away. To do so, make sure you see small green circles spawning around the Guards and shrinking smaller. That will tell you that you are in range and can attempt to steal. If the circles are red, that means you're in range but either you are in the Guard's LOS or you do not have LOS to the Guard, itself.

    The Guard on the left should initially react properly if you attempt to steal from him first. However, once you attempt to steal from the Guard on the right and then go back to the Guard on the left, the Guard on the left will not show any progression of theft. You can be completely out of LOS from the Guard, have the Guard in LOS by Mr Spy, and the green button is pressed down, but the Guard will not show its meter advancing. I've confirmed this through Debug Layout, as well.

    Both Guards start out essentially the same, so there's no reason they should be reacting differently - especially when the Guard on the left initially works the way it should.

    More info: Here is screenshot of the event sheet and a copy of the .c3p file.

    https://drive.google.com/file/d/1TsrqD13V4OapepCLXoKKIYCb07FN5Oir/view?usp=sharing

    Your insight would be much appreciated. Thank you!

  • I told you in another post - stealing has nothing to do with the issue.

    The problem is with LOS behavior, for some reason if you step into guards cone of view, after that it will always have LOS to the player.

    Try removing actions where you add MrSpy sprite as an obstacle for guards. If you want LOS to detect the player, you should not set it as an obstacle!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • dop2000 Oh, I understand that the Stealing mechanic wasn't the actual issue (or part of it) I copied my original post here as is simply because that's how the game is currently set up and how I first detected the problem at all. I wasn't trying to ignore your feedback and I apologize if it came across that way.

    I just did as you suggested - removing MrSpy as an obstacle - and (WOW) that seemed to have solved the problem. There was a reason I added MrSpy as an obstacle but now I can't even remember what that was...or maybe I accidently added him when I intended a different object. Anyway...besides the point. It's working now.

    I also created a simplified .c3p file, however, and made two separate "enemy" objects with LOS and put two instances of each in the layout. I discovered that when two instances of the same object have LOS ranges that overlap, moving into BOTH fields of vision will keep both as TRUE even after you move out of range of one but stay in range of the other.

    So while MY issue is resolved, for now it seems, there is still a problem with LOS, as you said. I did file a bug report for that.

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