Messages

I see...though this would be problematic in certain situations, like a sniper with very long vision, but shouldn't be able to hear that far. Guess the level design has to be changed.

BTW, this problem is still hanging there. I'm willing to wait, but... you know, it's been two years now... :^_^\':
https://forum.chaos-project.com/index.php/topic,13686.20.html

PS:
All I need to know is if this problem can be solved or not.
If yes, then I'll continue to use this type of in levels and wait for the fix.
If not, then I'll use alternatives or even remove them altogether. It's not optimal, but better than bugged guards.

Sorry to bother you again, but I just can't make "listen_range" work.

Let's say range=6, listen_range=4.

Can you make a simple demo where the guard use listen_range instead of (view) range to detect the player? In other words, when player approach the guard from behind, make the guard detect the player from 4 grids away, not 6.

Hmm... yes, I think I understand now. So listen_range is not a separate/independent detection method, it is only used when you are in "range" but outside of "view".

I could roll with that, except maybe the invisible=stealth part... Sadly I'll have to ditch the invis_range etc.

Anyway, thanks for clearing that up!

EDIT: One thing though... what's the point of listen_range then, if every type of view range overrides it? Is it ever used? Because the guard seems to hear me from whatever view range is active at the moment, even if I'm out of view/behind walls etc.

[1]

So, in other words, listen_range must be equal or less than whatever view range is active right now?

So, if you are using invis_range, let's say invis_range=3, then any form of invisibility also automatically give guards listen_range=3 even if you are not "quiet", since the guard's listen_range can not be higher than active "range", right?

This effectively means invisible=stealth since it also "give" you quiet, and it also means the guard can't hear you unless they can see you, which again, doesn't make a lot of sense.

And this still doesn't explain why the third guard on the right with listen_range=1 can hear you from 6 tiles away. As far as I understand, light_range is VIEW range, not listen range.

Two guards at the bottom, that appears to work as designed.

Yes, this appears to be a mistake on my part, sorry! 

https://mega.nz/#!EBdjVQyQ!LqF3_A3EhhPd85i39T7MAJdTenepDegn_T_TjVBZLa0

Here is the updated demo, with the new 1.12 SES script. I also added a few commentary NPC for your convenience.

Yes, like this. You can try editing the script in the demo above.

Final result should look like this:

    # If Sensor responds to the Stealth Game Switches
    cfg.gsub(/stealth=(true|false)/i){$1}
    # <stealth> - Default to CONFIG else use the Value in stealth=true/false
    @stealth=($1.nil?)?SENSOR_STEALTH : ($1.to_s.downcase=="true")? true:false

I'll just wait for the new Collection and grab the updated script, then see how it goes 

I edited the script as you instructed, the line number doesn't match so I just searched the whole line and moved them. The bugs are still there.

No problem.

Unfortunately there are still some other bugs, this time with invisibility and light.

Here's the demo.

https://mega.nz/#!ZQsUlCjT!LUSyC1KLnGIvDgEyT6YECq1YLkv6ukxViv9fKEUYrWA

First, talk to the cat to turn on the invisibility switch.

BUG #1:
Move down to the single plank tile. Both guards have been given invis_range=1, which shouldn't detect you at this range.
However the guard on the left have light=true and light_range=6, which seem to override invisibility and still see you.

BUG #2:
Move left and right on the plank path near the tree trunk. You are "invisible" but not "quiet", so both guards with listen_range=5 should be able to hear you.
However the guard on the middle with invis_range=2 can't hear you when you are invisible, only hearing you when you are right next to the trunk, which indicates he's using invis_range for listen_range.
And the guard on the right with light_range=6, have listen_range=1, shouldn't hear you at all, but still hear you from far away, indicating he might be using light_range for listen_range.

Oops...Try this one.

https://mega.nz/#!5EV3SQob!G4MCS5M3JK4PkcuvyyZK158v1eL-h193VsuCcaj4qXQ

Sure, here:

https://www.mediafire.com/file/1lg580qzt14s4oc/Project_Demo_2.zip/file

I also tested this event in your Collection. The @light.hue -= 20 script only work once when the event is turning. Make sure to test the event multiple times from the same direction.

Found a minor bug:

The @light.hue command only works when the event is facing down.

When the event is triggered from up/left/right, the light won't change hue.

That did it! That's exactly what I need!

Thanks a ton, Heretic86!

Basically, what Im thinking is if the Player / Target is being illuminated, then that range is used instead of the default range.

What about something like "light_range"?

That's EXACTLY what I suggested in the first place.

What I envisioned is something like a third "layer" of range for SES, like the listen range which is different fron view range. The "lit range" would be longer than the view range, but only active if "in light".

If only I know how to code...

Anyway, I think I've been bothering you for too long about this, like I said I'm already pretty happy with the last update, so I'll stop here.

Thanks again for helping me out, Heretic86! 

The script itself works, yes, but still have one problem.

Like I said before, the guard should be able to see you, whether lit or not, and being lit only makes you more visible. That's the way it should be.

In the new 1.1 version, if guard has light=true, then being in the dark will render you completely invisible to the guard, which is just absurd. But if a guard's setting does not include light=true, then the "lit makes you more visible" part does not work at all. As the guard's range remain the same regardless of lit or not, lights around the map become pure decoration instead of level design element. Not everyone is running around with a flashlight all the time, you know.

To sum it up, they should able to see you from far away when you are in light, and must still able to see you when you are close enough without light. The current version can only do one or the other. That's the problem.

Although I have to admit, this might be a bit too much to ask. I'm already pretty happy with the current version, so it's okay if you feel there is no need to improve it.

Oops, that's just me being stupid :^_^\':

Usually I run with range=4, changed it to 8 for testing purpose but forgot about the other range settings. After correcting the settings it works smoothly.

And yeah, I started a new project for the demo, so that command_355 bug was left in. In the working version it was fixed.

Thanks again!

Here you go. Just wait for the guard to approch. The warning sign to the right indicates detection.

https://mega.nz/#!pJ1jiQbA!PrYCac1Qr9-g3oIsfIfPMOgtyUzE5Lkn4dJsUrcOf4c

In case you couldn't reproduce the problem, here are some details:

SENSOR_READ_LINES = 12 (with the flashlight code added, the default 10 is not enough)

The guard is standing 10 grids away from player, walking towards the player.

The player is lit by a street light:

\light[Lamp Glow.png]
\light_flicker_opacity[224, 255, 7]
\light_offset_xy[0, -32]

the guard's settings:

\light[ForwardLight.png]
\light_match_direction
\light_offset_xy[0, -24]
Sensor_Config
range=8 listen=3 on_range=6 view=6 on_view=0
listen_range=5 listen_view=5 
listen_switch=listener
wall listen_wall=true on_wall=false inter
Sensor_Config
light=true listen_light=true on_light=true
light_tol=34.5

Upon seeing the player, the guard would appear to be standing still. If you use "guards_can_see?" conditional branch to display 2 different pictures, indicating detection status, you would see the two pictures rapidly flashing. I could provide a demo if you need it.

[SUPER EVENT SENSOR Version 1.1 - LIGHT SENSITIVITY FEATURE ADDED]

Ok, I have a version for you to TEST out.  I believe this is stable.  It didnt take too much work.

SUPER EVENT SENSOR Version 1.1 - LIGHT SENSITIVITY FEATURE ADDED (click me)

I didn't do a template because this should be REALLY EASY to add Light Detection.  Remember, you can have MORE THAN ONE Sensor_Config comment if you need additional room.

Sensor_Config
light=true listen_light=true on_light=true
light_tol=34.5

Please let me know if this does the job for you before I publish a Final Version of it.

Thanks!

I've tested it, with mixed results. Namely, it still suffers from the same "rapidly switching back and forth" problem, when the player is in range but not lit.

And sometimes, if the player is lit and in range, the guard would not rapidly switch pages, but still does not work properly. I have that "guards_can_see?" addon from earlier, and made a UI with that condition, which display a yellow warning sign when not "seen", and switch to a red sign when "seen". Some times when the player is lit, the guard would just sit there watching, while the warning sign rapidly switching between yellow and red. Cause unknown, needs further testing.

Many thanks, Heretic86. I'm not in any hurry, so take your time.

Also, please try to make the guard events self-contained, if possible. Using other events or event number like" $game_map.events[14]" to control guard behavior is rather counter-productive in larger scale, because you have to manually setup every guard. I hope this is not too much to ask.