Example:
initially OnSignal=OnState=false
# Frame 1
Listener A checks OnState: false
Something sets OnSignal = true
OnState = OnSignal = true
OnSignal = false
# Frame 2
OnState = OnSignal = false
OnSignal = false
Listener A checks OnState: false

If Game Maker does not guarantee that an order is kept you might want to think about implementing something more robust.

So you have all this functionality distributed around these “objects”. But they aren’t actual independent entities – you’re actually just doing a single action (aim a gun) and a single blob of logic. So splitting things around the objects is hurting you, and you’re having to add a bunch of book-keeping – stuff that doesn’t make decisions, it just tried to keep all the objects in sync.

I would move all the actual thinking logic into a single place. Doesn’t matter where, but probably PlayerMovementControls(). It will do:

1. Find enemy to point at.
2. Point player at enemy.
3. Tell gun to aim itself that way.
4. Tell reticule to draw itself there.

All the other objects just do what this logic tells them. The information flows one way – from the decision-maker to the children. There’s no back-and-forth or multiple chunks of state. In this case the player object makes the choice, and then the gun and reticle do what they’re told. This will keep things so much simpler, modifiable and debuggable.

I think the cleanest solution is to let it stick around for one frame on from a designated point. Ideally this point occurs just after when it gets turned on, but at least this solution will never fail if it happens to be some time before this point. Then both the draw and the auto aim can happen if the reticle is on, and while they may last for one frame more than is ideal, they will never last for longer than that, and they will always be on for at least one frame.

Anyway, I think what Duncan Wintle and Frans Kasper are saying is the simple solution you can easily use. But I don’t like it.

I think your problem is that you have both the “Several bits of code that can each turn the reticule on”, and the “None of these bits of code know what order they will execute in, on a given step” requirements. I’m guessing this means that if several bits of code want to turn the reticule on in the same step, it will be set to the place where the last bit of code wanted it to go. So even if you solve this problem now, you might run into a problem later, where every step those code paths run in different order, and your reticule will jump around between two places. And you make it a bit hard to set up any priority between the targeting.

So I think long term what would be best would be to have one function which can decide whether to turn the reticle on and where to target it, and this function would run once each step. Of course this probably requires a larger rewrite of your code, so I understand if you don’t do it. But maybe later, when you are introducing some new “state” into the game, you could try doing it in a way where setting the state only happens in one place, generally that makes working with it less complicated.

setVisble(value)
{
if value
{
oReticule.visible = true
oReticule.willDeactivate = false
}
else:
{
if oReticule.willDeactivate:
{
oReticule.visble = false
}
else:
{
oReticule.willDeactivate = true
}
}
}

But could you potentially make a separate script that turns the reticle on, and while it’s on, everytime you call “IsReticleOn()” it checks for a certain condition, in your case: “Mouse no longer on enemy”, before returning the value?

Kinda similar to James Vokes’ suggestion, actually

Or alternatively, make the reticule ALWAYS drawn, but when it’s not autoaimed, make it’s position off-screen, yet still in the same direction as the mouse. Pretty easy vector math, no?

When oReticule.visble is set to true. set oReticule.willDeactivate to false.

When oReticule.visble would be set to true instead check oReticule.willDeactivate.
If oReticule.willDeactivate is false set oReticule.willDeactivate to true
else set oReticule.visble to false.

some sudo code:
setVisble(value)
if value:
oReticule.visible = true
oReticule.willDeactivate = false
else:
if oReticule.willDeactivate:
oReticule.visble = false
else:
oReticule.willDeactivate = true

This will make visible false after one loop in which nothing has called it but will stay visible until that happens

* The reticule should be shown (i.e. you’ve locked onto a target)
* The reticule needs to (re-)paint itself to the screen.

Instead, if you separated these values to something like:

* oReticule.visible
* oReticule.painted

… then you can use .visible as you currently are for the player aiming logic, and use .painted to keep track of whether the object needs to repaint itself.

Does that make sense, or have I misunderstood?

– it feels like separating out the visibility of the reticule object, and whether auto-aim should be engaged, might help you here. Ie: you need to work out what object the player is auto-aiming at, and separately, you need to work out whether to show the thing.

– given that, feels like you need a separate ReticuleManager unattached to a visible object. Basically: anything that can turn the reticule on sends a message to this, such as “I am enemy #248 and I should be auto-aimed at”. That probably gets stored on something like a list, if you want to have many reticules, or just a single field if you want one. (Or: might be worth having a list, so you can re-prioritise later, though I think priority order might just be last on first off). Anyhow, then, when it comes to aiming, you ask the ReticuleManager “which object should I point at” – and separately, when it comes to rendering, you ask the reticule manager “entirely separately, which object do I draw the reticule on?”

And then, at the end of your loop, you need something to tidy up – ie, rather than setting reticuleVisible=false immediately, you clear up after yourself at the end of a game loop.

Is this making sense? It might not be what other people do, but what it feels like is you need something abstract to handle all the possible auto-aims and reticules, that you can message and later ask for canonical answers. That’d also help separate out render and logic.