[XP] Heretic's Collection of Art and 100% Compatible Scripts

Started by Heretic86, November 26, 2013, 09:22:35 am

Previous topic - Next topic

Heretic86

If it is that important to him, I'll work on fixing it.
Current Scripts:
Heretic's Moving Platforms

Current Demos:
Collection of Art and 100% Compatible Scripts

(Script Demos are all still available in the Collection link above.  I lost some individual demos due to a server crash.)

Jaiden

Awesome stuff Heretic, I've been using a majority of your scripts from this bundle in my project so far and love them.

Just a heads up, it seems there is a bug when trying to position a message window over an enemy, I was getting "can't convert Fixnum into String" on line 1489, since it was checking for "abcd" first. Looks like a line in the def reposition method:
  
def reposition
    if $game_temp.in_battle
      if "abcd".include?(@float_id) # must be between a and d
        @float_id = @float_id[0] - 97 # a = 0, b = 1, c = 2, d = 3
        if $scene.spriteset.actor_sprites[@float_id] == nil
          @tail.visible = false
          return
        end
        sprite = $scene.spriteset.actor_sprites[@float_id]
      else
        @float_id -= 1 # account for, e.g., player entering 1 for index 0
        if $scene.spriteset.enemy_sprites[@float_id] == nil
          @tail.visible = false
          return
        end
        sprite = $scene.spriteset.enemy_sprites[@float_id]
      end
#def reposition continues below...


The fix was to replace the line:
if "abcd".include?(@float_id) # must be between a and d


with:
if "abcd".include?(@float_id.to_s) # must be between a and d

Heretic86

Current Scripts:
Heretic's Moving Platforms

Current Demos:
Collection of Art and 100% Compatible Scripts

(Script Demos are all still available in the Collection link above.  I lost some individual demos due to a server crash.)

mobiusclimber

I found a bug in the demo. On the Cat_To_Player map (the one about followers and orienting characters when moving between maps, and pathfinder), when I talked to the kid who wanted me to help him find his momma, he doesn't follow me and I could go to the map to the left and talk to people (who said things like "I wanna go to the cave, but you already have a follower"). When I went back to the other map and talked to people, they all said and did their stuff. The professor looking person showed the orient caterpillar thing, but I had no one following me so it didn't really make sense ( I mean, it did, I knew what the effect was, but I couldn't see it cuz no one was following me). After that, I could not walk off to other maps bc a message would pop up saying I can't leave without my party. When I tried to talk to the boy again, he didn't say anything. So I was just stuck on that small map.

Helios

Much thanks Heretic86! I appreciate the effort you put into this awesome collection. Definitely going to use the Dynamic Lighting in my game.

One question: is there a way to make Dynamic Lighting work in conjunction with Super Event Sensor?

Namely, standing in the light should make you easier to spot in the dark. I can't make it work with "in_light?" (switching pages will reset move route), nor does SES have options like lit_range.

Heretic86

November 13, 2018, 04:31:17 pm #125 Last Edit: November 13, 2018, 04:36:31 pm by Heretic86
Yes, you can make Dynamic Lighting an Super Event Sensor work together!

Keep in mind that the "magic" behind Super Event Sensor really is only a ultra fancy way of changing Event Pages, there are other scripts that you can use to do that too, to achieve your Sensor Light goal!

The simplest form of a Sensor is this:
Sensor_Config
range=3


To make just the Sensor there work, put a check in Self Switch D (by default).  Keep in mind this is WITHOUT LIGHTING.

Now, to add Light Detection, I wrote another seemingly unrelated script called Unlimited Page Conditions.  This allows you to use SCRIPTS or CODE for ANY CONDITION.  It is mostly intended for those with some familiarity with scripting.  Thus, you are no longer limited to Switches or Variables, but quite literally any code you can write!  So if you wanted a Page Condition to be Player X at exactly one coordinate, you can write it out as this:
Condition: $game_player.x == 12


I did have the foresight to put some Light Detection into the Dynamic Lighting code.  It also appears I lacked the foresight to Document the method I wrote specifically for it!  All Characters (Player and Event) have a method to check to see if they are Illuminated by running the method "in_light?(Event_ID, Tolerance)".

  #--------------------------------------------------------------------------
  # * In Light? - Game_Character
  #  - Returns true when Character's Center is in a Light
  #          arg : can be an Event ID (or 0 for Player), Character, or nil
  #    tolerance : Percent to Add so Light registers as false if in tolerance
  #--------------------------------------------------------------------------


To make the code for "in_light?" work with Super Event Sensor, make sure you also have Unlimited Page Conditions too!  It is in the Collection.  That script was not gone over very heavily, but in hindsight, I probably should have given it more focus as it is Extremely Powerful.  So, the trick here is to add "in_light?" as a Page Condition, as well as Sensor Switches!

Comment: Condition: in_light?(0,0)


The "in_light?(Id, Tolerance)" code can be used either as "Condition: $game_player.in_light?" or "Condition: in_light?(0, 10)".  First argument is an Event ID.  You can use the number 0 for Game Player, since Events start at 1.  The Tolerance is also useful for decreasing the In Light Sensitivity, which is due to the fact we dont use pitch black very often.  The higher the Tolerance, the LESS SENSITIVE the Light Detection will be.

To make this all work, the Page Setup will be that of a standard Sensor.  To keep it simple, lets assume one Non Moving Sensor Guard.  Remember, simple, so just the Range and he can "see" or "hear" anything in his range.  Also remember, Sensor Configs go on Page 1 no matter what, and the Comment Conditions go ONLY on the page you want a New Condition for.

Event Page 1:
Comment: Sensor_Config
range=4


Now, if you recall, the ORDER that pages are checked in is RIGHT TO LEFT.  The pages that should be active when the Player triggers them go all the way to the RIGHT, and default states should be on the LEFT.  Page 1 has Sensor_Config and is the default state that just stands there.  Page 2 is the "Attack the Player" page.  Set Move Route to Approach, so it will approach the player.  Make the Page 2 Condition Self Switch to D, which is the default.  Then make a comment also on Page 2, and say either "Condition: $game_player.in_light?(0,0)" or "Condition: in_light(0,0)".  Only use one, but both code will check to see if the player is illuminated.

=============================

tl;dr

Use this script (check to see if it is already in your scripts tho):

Spoiler: ShowHide
#==============================================================================
#
#           HERETIC'S UNLIMITED EVENT PAGE CONDITIONS [XP]
#           Version - 1.0
#           Monday, August 8th, 2016
#
#==============================================================================
#
#  ---  Overview  ---
#
#  This script will allow you to use Scripts as a Page Condition! 
#
#  This completely unlocks the functionality of Page Conditions, which now have
#  absolutely NO LIMITS!  For example, the Default Page Conditions allow
#  you to check a Game Variable, and the Page is only active if that
#  Game Variable is equal to or greater than what ever number you put there.
#  But, you could not check if the Game Variable was equal to or less than!
#  Now you can easily make Game Variable Less Than a Page Condition!
#
#  ---  Installation  ---
#
#  Place above Main and below Scene Debug.  Place below the SDK if used.
#
#  ---  Instructions  ---
#
#  Add a Comment to an Event says "Condition:" followed by a Script Condition.
#
#  Example 1:
#  @>Comment: Condition: $foo == $bar
#
#  Example 2:
#  @>Comment: Condition: $game_player.direction == 2 and $game_switches[12]
#
#  Example 3:
#  @>Comment: Condition: $game_player.moving? and $game_switches[12] and
#           : (not $game_system.map_interpreter.running? or $foo == $bar)
#
#  Example 4: (Not every line needs to be dedicated to evaluation.)
#  @>Comment: Condition: p = $game_player
#           : p.direction != 2
#
#  Example 5: (Comments within Comments work too, note the # Character)
#  @>Comment: Condition: p = $game_player
#           : # If Player is facing Down
#           : p.direction == 2
#
#  ---  Common Events  ----
#
#  This script does NOT affect Common Events, ONLY Map Events.
#
#  ---  Battle Event Pages  ---
#
#  This script does NOT affect Battle Event Page Conditions.  I wrote another
#  script for Battle Event Pages already. 
#
#  That script is called "Unlimited Battle Page Conditions" and is available
#  as one of my many scripts in Heretic's Collection.
#
#  ---  Multi Line Support  ---
#
#  You can extend your scripts to Multiple Lines of Comment Boxes!  The
#  Comment Box should be plenty big enough to hold your text!  Besides
#  that, you're using Script Calls, so if you can't fit your text into
#  one Box, you can write a Method that returns true or false and plug
#  that into your own script!
#
#  You can have Multiple Conditions also, each in their own Comment Box.
#
#
#  ---  Self Switches  ---
#
#  This script doesn't interfere with the use of Self Switches (ABCD).  Feel
#  free to combine both Self Switches and Script Conditions.
#
#
#  ---  Skipping Evaluation  ---
#
#  There may be certain conditions when you do NOT want a certain Page to
#  evaulate its Script Conditions.  For example, running an Event and you
#  don't want the Page to change until it is done doing its thing.  You
#  can turn Script Evaluation ON or OFF by either a Script Call or with
#  a Comment.  It is intended to use BOTH in conjunction with each other.
#  Basically, it gives you more control over when Scripts are evaluated.
#
#  To temporarily prevent a Page from executing its Script Conditions, simply
#  add a Comment to the Event's Page that reads:
#
#  @>Comment: \skip_eval
#
#  This is intended to be turned OFF with a Script Call or Move Route.
#
#  @>Script: $game_map.events[id].skip_eval = true / false
#  @>Set Move Route: This Event
#                  : $>Script: self.skip_eval = false
#                  : $>Script: skip_eval=(false)
#
#  NOTE: The Page MUST BE ACTIVE to change Skip Eval or else you will set
#        the Skip Eval on the WRONG PAGE.
#
#  NOTE: Once Skip Eval has been changed, it will retain the state you set
#        until the Map has been left entirely and transferred back to.  This
#        includes going into Battle Scenes.  The value of Skip Eval will be
#        remembered even after Battles are exited, but RESET if you leave
#        the Map and come back to this Map.
#
#
#  ---  Performance  ---
#
#  Each Script Condition is evaluated once per frame so don't go crazy using
#  too many Script Conditions, or at least make sure they evaluate quickly.
#  Script Conditions all evaluated on each Map.  Thus, if you have many maps
#  but only a few maps that use Script Conditions, don't worry too much.  You
#  may see performance issues if you use lots and lots of Script Conditions
#  on the same map.  This does end up being tons faster than using multiple
#  Parallel Events for very specific purposes however.
#
#
#  ---  Compatability  ---
#
#  This script may have some compatability issues with other scripts that
#  modify the RPG::Event::Page::Conditions class.  It has been tested with
#  More Self-Switches by Gameus / Game Guy and although only briefly tested
#  appears to work just fine.  This script works by replacing attr_accessor
#  methods with my custom definitions.  Instead of returning a property of
#  an object, it now uses self_switch_valid and self_switch_ch as getter
#  methods which consider if Script Conditions are being used.
#
#  It should also work just fine with Optimization Scripts as evaluation of
#  the Script Conditions is handled outside of Event and Game Map update
#  methods entirely.
#
#
#  ---  Legal  ---
#
#  You may distribute this script on websites in the scripts unaltered form.
#
#  You may use this script in Commercial or Non Commercial projects without
#  compensation as long as you give me credit for the use of my scripts.
#
#
#  ---  Config  ---
#
#  This script has no configurable Options.
#
#
#  ---  Version History  ---
#
#  Version 1.0 - Monday, August 8th, 2016
#  - Initial Release
#
#==============================================================================

#==============================================================================
# ** RPG - Main RPG Module
#==============================================================================
module RPG
  #----------------------------------------------------------------------------
  # ** Event - RPG::Event
  #----------------------------------------------------------------------------
  class Event
    #--------------------------------------------------------------------------
    # ** Page - RPG::Event::Page
    #--------------------------------------------------------------------------
    class Page
      #------------------------------------------------------------------------
      # ** Condition - RPG::Event::Page::Condition
      #------------------------------------------------------------------------
      class Condition
        #----------------------------------------------------------------------
        # * Public Instance Variables - RPG::Event::Page::Condition
        #----------------------------------------------------------------------
        attr_accessor :script_condition
        attr_accessor :map_id
        attr_accessor :event_id
        attr_accessor :skip_eval
        #----------------------------------------------------------------------
        # * Initialize - RPG::Event::Page::Condition
        #  - Adds Default Values for new Properties
        #----------------------------------------------------------------------
        alias script_condition_initialize initialize unless $@
        def initialize
          # Call Original or other Aliases
          script_condition_initialize
          # Container for Script Conditions
          @script_condition = nil
          # New Properties used for generating a Self Switches Hash Key
          @map_id = nil
          @event_id = nil
        end
        #----------------------------------------------------------------------
        # * Self Switch Valid - RPG::Event::Page::Condition
        #  - Replaces attr_reader with reader method
        #----------------------------------------------------------------------
        def self_switch_valid
          # Overrides @self_switch_valid value if a Script Condition exists
          return true if not @script_condition.nil?
          # Return Original Value (Self Switch is Checked in Edit Event)
          @self_switch_valid
        end
        #----------------------------------------------------------------------
        # * Self Switch Ch - RPG::Event::Page::Condition
        #  - Replaces attr_reader with reader method
        #  - Self Switch Channel is usually 'A' unless 'BCD' are specified
        #  - Checks both Self Switch and Script Condition to return Channel
        #----------------------------------------------------------------------
        def self_switch_ch
          # Use Self Switch Ch (ABCD) if Valid and Switch is OFF
          if @self_switch_valid
            # Hash Key for Self Switches
            key = [@map_id, @event_id, @self_switch_ch]
            # Use Self Switch Ch (ABCD) if Valid and Switch is OFF
            return @self_switch_ch if not $game_self_switches[key]
          end
          # If Script Condition Array has any Scripts
          if not @script_condition.nil? and @script_condition.size > 0
            # Iterate each Self Switch Script Condition
            for script in @script_condition
              # Create a Hash Key for Self Switches Hash with Script
              ss_key = [@map_id, @event_id, script]
              # Return the Script if Self Switch Script is OFF
              return script if not $game_self_switches[ss_key]
            end
            # Return Last Script in Array as Self Switch Channel
            return @script_condition.last
          end
          # Default Self Switch Channel (ABCD)
          @self_switch_ch
        end
      end
    end
  end
end

#==============================================================================
# ** Game_Event
#==============================================================================
class Game_Event < Game_Character
  #----------------------------------------------------------------------------
  # * Initialize - Game_Event
  #  - Checks each Page of Event for Script Conditions in Comments
  #        map_id : Map ID
  #         event : Game_Event stored in $data
  #----------------------------------------------------------------------------
  alias script_condition_initialize initialize unless $@
  def initialize(map_id, event)
    # Default value and Shorthand
    script, sc = nil, $game_map.script_conditions
    # Iterate each of the Event's Pages
    event.pages.each {|page|
      # Store values in Condition Object for Self Switch Keys
      page.condition.map_id, page.condition.event_id = map_id, event.id
      # Iterate Each Command
      page.list.each {|command|
        # If Event Command is the first line of a Comment
        if command.code == 108
          # If Script is not nil (two Script Conditions in sequence)
          if not script.nil?
            # Modify Condition Object and Add to Hash for Evaluation
            add_script_condition(page.condition, script, map_id, event.id, sc)
            # Clear the String since it is now stored in the Condition Object
            script = nil
          end
          # Scan the Comment and look for \skip_eval Comments for this Page
          command.parameters[0].gsub(/^\\skip_eval/i) {
            page.condition.skip_eval = true
          }
          # Use Regular Expression to look for "Condition:" and Capture String
          command.parameters[0].gsub(/^Condition:(.*)/){ script = $1.strip }
        # Else if Script and Event Command is a Comment, but not the first line
        elsif not script.nil? and command.code == 408
          # Append Script String with any text from this line of the Comment
          script += "\n" + command.parameters[0]
        # If Script String has contents
        elsif not script.nil?
          # Modify Condition Object and Add to Hash for Evaluation
          add_script_condition(page.condition, script, map_id, event.id, sc)
          # Clear the String since it is now stored in the Condition Object
          script = nil
          # Next Command (One Condition per Comment Box)
          next
        end
      }
    }
    # Call Original or other Aliases
    script_condition_initialize(map_id, event)
  end
  #----------------------------------------------------------------------------
  # * Add Script Condition - Game_Event
  #  - Modifies the Condition Object with New Parameters for Script Evaluation
  #               c : RPG::Event::Page::Condition
  #          map_id : Map ID of Event
  #        event_id : Event ID
  #              sc : Shorthand for $game_map.script_conditions
  #----------------------------------------------------------------------------
  def add_script_condition(c, script, map_id, event_id, sc)
    # Loop to check for Syntax Errors
    begin
      # Evaluate the Script String and remember result
      result = eval(script)
    # Script Evaluated has a Syntax Error
    rescue
      # Display Warning to User
      script_condition_error(script, event_id, map_id)
      # Prevent Storing of Script Condition
      return
    end
    # Create a Boolean Value based on result for proper storage
    value = (result) ? true : false
    # Remember value of Script Evaluation in the Self Switch Hash
    $game_self_switches[[map_id, event_id, script]] = value   
    # Create Array if Nil
    c.script_condition = [] if c.script_condition.nil?
    # Push Script on to Script Condition Array
    c.script_condition << script
    # Add Script to Script Conditions Hash in Game Map with Event ID as Key
    sc[event_id] ? sc[event_id] << script : sc[event_id] = [script]
  end
  #----------------------------------------------------------------------------
  # * Eval Script Condition - Game_Event
  #  - Evaluates Script Conditions
  #       scripts : Array of Scripts for this Event's Conditions
  #----------------------------------------------------------------------------
  def eval_script_condition(scripts)
    # Default
    refresh_event = false
    # Iterate each Script in the Array
    for script in scripts
      # Run the Script and remember the result (Syntax already checked)
      result = eval(script)
      # Create a Boolean Value based on result for proper storage
      value = (result) ? true : false
      # If Stored Self Switch Value is not the same as the result
      if $game_self_switches[[$game_map.map_id, id, script]] != value
        # Store the Result in the Self Switches Hash
        $game_self_switches[[$game_map.map_id, id, script]] = value
        # Flag to Refresh this Event after running all Scripts if more than 1
        refresh_event = true
      end
    end
    # Refresh this Event if the Refresh Flag is set
    refresh if refresh_event
  end
  #----------------------------------------------------------------------------
  # * Script Condition Error - Game_Event
  #  - Prints a Warning and shows Script with a Syntax Error
  #        script : String of Script with Syntax Error
  #            id : Event ID with the Problem
  #        map_id : ID of Map with Event with Syntax Error in Condition
  #----------------------------------------------------------------------------
  def script_condition_error(script, id, map_id)
    # If running game from Editor
    if $DEBUG
      # Explain the Problem
      print "Warning: A Script Condition has a Syntax Error\n",
            "Event ID: ", id, "\nMap ID: ", map_id, "\n\n",
            "Condition: ", script, "\n\n",
            "Conditions should evaluate to true or false\n",
            "Example 1: Condition: $foo == $bar\n",
            "Example 2: Condition: $foo == $bar or $baz"
    end
  end
  #----------------------------------------------------------------------------
  # * Erased? - Game_Event
  #  - Returns true if Event is Erased
  #----------------------------------------------------------------------------
  def erased?
    return @erased
  end
  #----------------------------------------------------------------------------
  # * Skip Eval? - Game_Event
  #  - Getter method, returns Flag set in RPG::Event::Page::Condition
  #----------------------------------------------------------------------------
  def skip_eval?
    @page.condition.skip_eval if @page
  end
  #----------------------------------------------------------------------------
  # * Skip Eval= - Game_Event
  #  - Setter method, sets Flag set in RPG::Event::Page::Condition
  #----------------------------------------------------------------------------
  def skip_eval=(arg)
    @page.condition.skip_eval = (arg) ? true : false
  end
end

#==============================================================================
# ** Game_Map
#==============================================================================
class Game_Map
  #----------------------------------------------------------------------------
  # * Public Instance Variables - Game_Map
  #----------------------------------------------------------------------------
  attr_accessor     :script_conditions    # Holds Event Script Page Conditions
  #----------------------------------------------------------------------------
  # * Setup - Game_Event
  #  - Creates a Hash to hold Script Conditions for constant Evaluation
  #      map_id : Map ID from $data
  #----------------------------------------------------------------------------
  alias script_condition_setup setup unless $@
  def setup(map_id)
    # If Map ID is Valid and does not match current Map ID
    if map_id > 0 and map_id != @map_id
      # Create or Clear Hash
      @script_conditions = {}
    end
    # Call Original or other Aliases
    script_condition_setup(map_id)
  end
  #----------------------------------------------------------------------------
  # * Eval Script Conditions - Game_Map
  #  - Evaluates all Script Conditions in Hash and Refreshes Event if needed
  #----------------------------------------------------------------------------
  def eval_script_conditions
    # Check that Script Conditions exists
    return unless @script_conditions
    # Iterate any Script Condition
    @script_conditions.each {|id, scripts|
      # Get the Event
      event = @events[id]
      # If Event does not exist (typically event removed during game editing)
      if not event
        # Remove the Script Conditions from the Hash
        @script_conditions.delete(id)
        # Next Script
        next
      end
      # Skip this Event if Event has a Skip Eval flag
      next if event.skip_eval?
      # Evaluate Script Conditions (Array of Scripts) from within the Event
      event.eval_script_condition(scripts) unless event.erased?
    }
  end
end

#==============================================================================
# ** Game_Screen
#==============================================================================
class Game_Screen
  #----------------------------------------------------------------------------
  # * Update - Game_Screen
  #  - Calls to eval_script_conditions in the Map, so it will still evaluate
  #    even during Battle Scenes
  #  - Game_Screen is updated after important objects are updated for proper
  #    timing of changing Pages.  Thus, the Map, Events, Interpreter, Player
  #    and System are all updated before evaulating Script Conditions.  If
  #    the evaluations were run, for example, prior to updating either the
  #    Player or Map Interpreter, Page Changes would occur at improper times
  #    and most likely cause you a headache trying to figure out why thinggs
  #    did not work as you expect at the times you expect.
  #----------------------------------------------------------------------------
  alias script_condition_update update unless $@
  def update
    # Call Original or other Aliases
    script_condition_update
    # Update any Event Script Conditions
    $game_map.eval_script_conditions
  end
end


Next, simply edit your Sensor Event, go to the "Attack" page, or what ever page you want or how its labeled, and put a Comment that says "Condition: in_light?(0, 0)" and that page will ONLY come on if the Player is illuminated! 
Current Scripts:
Heretic's Moving Platforms

Current Demos:
Collection of Art and 100% Compatible Scripts

(Script Demos are all still available in the Collection link above.  I lost some individual demos due to a server crash.)

Helios

Thanks for your very detailed reply, Heretic86! I probably should describe my problem in more detail.

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".

Because the guard should be able to see you, in light or not. In light simply makes you easier to be seen. With the method you described ("in_light?" as a second condition), it means unless you are in light, the guard can't see you at all, even if you are hugging him in the face!

Come to think of it, maybe I could use a conical light to mark the vision range of guards, giving player a visual reference of their actual view range, a feature which I believe scripts like SES really should have.

Edit: Ah, I get it. The solution is to make the guard have longer view range than his own light range, so if the player is outside of his own light but in other enviromental lights, they would be seen too. Thanks again Heretic86! You are great! :clap:

Heretic86

Quote from: Helios on November 13, 2018, 08:04:45 pm
Thanks for your very detailed reply, Heretic86! I probably should describe my problem in more detail.

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".

Because the guard should be able to see you, in light or not. In light simply makes you easier to be seen. With the method you described ("in_light?" as a second condition), it means unless you are in light, the guard can't see you at all, even if you are hugging him in the face!

Come to think of it, maybe I could use a conical light to mark the vision range of guards, giving player a visual reference of their actual view range, a feature which I believe scripts like SES really should have.

Edit: Ah, I get it. The solution is to make the guard have longer view range than his own light range, so if the player is outside of his own light but in other enviromental lights, they would be seen too. Thanks again Heretic86! You are great! :clap:


Thanks a ton!  And those ideas are fantastic as well!  The idea that the Player illuminating themselves is a dead giveaway is a suggestion for them to put out their torches / lights, and use the Guard as a Lightsource!  Mostly all it should take is just adjusting some switches, and if you do want to change the view range, you should be able to do that on the fly also!  Scripting, even if its one line of code, can be extremely powerful stuff!

You can also think outside the box.  The Unlimited Page Conditions script has plenty of rooms for YOU to exploit!  I left that wide open as to provide more functionality instead of locking it down.  Thus, you can run Scripts in the Condition.  As long as the final code evaluates to true / false, the code will still run!  Thus, you could run something like "@sensor.range = ($game_player.light.enabled) ? 5 : 4" and change the range on the fly!

Im glad the examples helped!  If you need anything else, feel free to ask!
Current Scripts:
Heretic's Moving Platforms

Current Demos:
Collection of Art and 100% Compatible Scripts

(Script Demos are all still available in the Collection link above.  I lost some individual demos due to a server crash.)

Helios

Sadly, after messing around for about two hours, I still can't get it to work.

I tried putting "Condition: $game_player.in_light?" on page 2 (Guards Trigger Battle). This causes strange behavior, as the guard switch to page 2, his facing (and directional light) is also switched to the default facing of page 2. If page 2 facing is different than page 1, the player would not be lit by the directional light, failing the "in_light" Condition, causing the guard to immediately switch back to page 1, fulfilling the "in_light" Condition again, thus rapidly switching between the two pages without ever approching the player.

Also, with "Condition: $game_player.in_light?" on page 2, if the player approch the guard from behind while not "in_light", the game hangs up, similar to an autorun event that doesn't end.

Btw I'm using a moving guard to test all this. You simply must have some moving guards in a stealth based game, you know, and if a moving guard doesn't cause any problem, so shouldn't a stationary guard.

Quote"@sensor.range = ($game_player.light.enabled) ? 5 : 4"


This seems to be exactly what I needed, changing the guard's range without switching pages or adding conditions. I changed "$game_player.light.enabled" to "$game_player.in_light?", it should work in theory. When I run it, It says stynax error. My comments on page 1 looks like this:


\light[ForwardLight.png]
\light_match_direction
\light_offset_xy[0, -24]
Condition:
@sensor.range=($game_player.in_light?)? 6:4
Sensor_Config
range=4 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


I also tested my idea of having guard's view range longer than his own light, by putting "Condition: $game_player.in_light?" on page 1. This causes the guard to disappear when the player is not in light. Duplicating page 1 (with "Condition: $game_player.in_light?" on the second page 1) to prevent the guard from disappearing also doesn't work, causing the same "switching back and forth" problem described above.

Speak of which, is there a way to maintain previous facing when switching pages?

Heretic86

November 14, 2018, 04:58:10 pm #129 Last Edit: November 14, 2018, 05:27:16 pm by Heretic86
I will have to mess around with this a bit to dig deeper into achieving what you want.  Im sure its possible, but I did end up using a lot of scripts in move routes themselves.

As far as @sensor, there are several ways to do this.  First, basically, anything in the "Condition:" comment must evaluate to true / false, but, you can run other code there before returning the true / false.  Second, the Sensor should be accessible from anywhere, so you can also do stuff like this:

Condition: e = $game_map.events[14]
# l player is in light or not, its a return value also
l = in_light?(0, 0)
# Adjust Range of Sensor Sight
e.sensor.range = (l) ? 5 : 4
# Return stored instead of running code again (faster)
return l


And yes, Comments should work fine in Condition Code also.  I will have to dig into your issue a bit later since it seems I broke something and need to fix that first.  Other thing to note is since you can access $game_map.events[14].sensor from anywhere, one event can change the Range of other events, or anything else inside the Sensor object.

---

EDIT: Lol, ok, apparently all I needed was a reboot. 

Agreed, Guards should not be stationary.  To get the Guard to maintain facing the same direction is quite tricky.  I always had trouble with that also.  So I dont have a definitive solution at this time.  I will see what I can put together when I get some time to dig in deep. 

I tested it for a few minutes, and also got Syntax Error.  It may be necessary to write a custom method to run in the Condition box, which isnt as difficult as it sounds.  Its been a while since Ive played with this, but I'll dig into it.
Current Scripts:
Heretic's Moving Platforms

Current Demos:
Collection of Art and 100% Compatible Scripts

(Script Demos are all still available in the Collection link above.  I lost some individual demos due to a server crash.)

Helios

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. :)

Heretic86

Quote from: Helios on November 14, 2018, 07:08:30 pm
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. :)


Agreed.  I will set something up as a Template so you can copy and paste.
Current Scripts:
Heretic's Moving Platforms

Current Demos:
Collection of Art and 100% Compatible Scripts

(Script Demos are all still available in the Collection link above.  I lost some individual demos due to a server crash.)

Heretic86

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.
Current Scripts:
Heretic's Moving Platforms

Current Demos:
Collection of Art and 100% Compatible Scripts

(Script Demos are all still available in the Collection link above.  I lost some individual demos due to a server crash.)

Helios

Quote from: Heretic86 on November 20, 2018, 04:45:57 am
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.

Heretic86

Hmm, ok.

I used one of the Forest Bees as a Template, then just edited that to update, and just added the "light" stuff to the Config.  I'll have to experiment with the Guard...
Current Scripts:
Heretic's Moving Platforms

Current Demos:
Collection of Art and 100% Compatible Scripts

(Script Demos are all still available in the Collection link above.  I lost some individual demos due to a server crash.)

Helios

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.

Heretic86

Yes, please post a demo and I can try coding in that to see whats happening.  Sorry, just been rather busy, I will jump on this as soon as I get a chance.
Current Scripts:
Heretic's Moving Platforms

Current Demos:
Collection of Art and 100% Compatible Scripts

(Script Demos are all still available in the Collection link above.  I lost some individual demos due to a server crash.)

Helios


Heretic86

December 01, 2018, 06:53:58 pm #138 Last Edit: December 01, 2018, 06:55:20 pm by Heretic86
Ok, I think I figured it out.

Sensor_Config
range=8 listen=3 on_range=6 view=6 on_view=0

Take a look at the bold parts.

What appears to be happening is the ON Range is Less than the Range.  Each time the Sensor gets triggered, ON takes over and ON Range is used.  Since the ON range is less than the Range, it says "nope, the target is out of range so cant see it" then it disables and changes Event Pages, then the next frame it says "yep, the target is in range so yep I can see it", changes Event Pages again, and it just goes back and forth.

Basically, with any Range, it should increase as awareness increases also.

For example

range=5
listen_range=6
on_range=7

If the Increased "Awareness" is less than default awareness, you'll end up with that toggling like you are seeing.  That was my intent anyway...  When I changed that one setting in your Sensor_Config, it looks like it was working as intended without any script changes.  Its definitely an easy thing to miss, so dont blame yourself!  And now we have a better idea of where to look if things start doing that back and forth page triggering!

Try using this:

Sensor_Config
range=6 listen=4 on_range=8 view=6 on_view=0
listen_range=7 listen_view=5
listen_switch=listener
wall listen_wall=true on_wall=false inter

NOTE: Bolded numbers are what I changed.

---

Also, and Im figuring this is just for the Demo, but I saw that the command_355 bug was also present.

    # Evaluation
    result = eval(script)
    # If return value is false
    if result == false
      # End
      return false
    end
    # Continue
    return true

Need to get rid of the "return false" line.  If the bug still exists, if you make a Script Call like $game_player.light.enabled = false, then the game will just hang.  It wasnt your script that broke it, it was a bug in command_355.
Current Scripts:
Heretic's Moving Platforms

Current Demos:
Collection of Art and 100% Compatible Scripts

(Script Demos are all still available in the Collection link above.  I lost some individual demos due to a server crash.)

Helios

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!