HentHighSchool Development Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

Site Tools


Events

Events are how the player interacts with NPCs. The bulk of events encountered will be of random events, encountered simply by moving around the game. Native type events are indirectly triggered by an action you took - hire/fire someone, build/upgrade a building, picking something up - rather than random occurrences or deliberately choosing an event. Interaction events are those where the player explicitly chooses to do an action and the event is the result of that decision. There are also some events that occur in the background and are not noticeable as actual events.

Event Execution

Events are separated into two blocks, a Try block and an Execute block. The Try block is checked when the related area is triggered - moving to a location, opening a tab on the Management Panel, etc - and the event manager checks the conditions in the Try block. Failing one of the conditions in the Try block (not reaching an "Accept Event" operation) prevents the event from occurring. The block is used in various ways depending on when/how it is checked.

When moving to a new location, the event manager tries the events for that location. Should the manager successfully make it to an Accept Event action, it adds the event to a list. Once it has determined all events that can run, it sorts the list by descending Priority and randomly picks an event from the highest priority group to actually run. Events can be called from inside an event. When this is done, the event author has the option of checking the remotely called event's Try block (and can have different event paths based on when it was accepted or rejected) or simply executing the event.

In the case of Button events, the Try block is checked to see if that particular event is displayed as an available option. If the player selects a person and picks the Attack or Covert Action buttons, the relevant Attack or Spells events are tried. Any that pass the Try block are displayed as selectable options. Helper events are available in the Management Panel (v 1.07 Alpha, in Smartphone), and their Try block is used to determine if they appear as a selection for the player to choose.

Once an event is selected to run by whatever means, the execute block activates and the event occurs. The visible part of events are images and text, and can include decisions from the player.

More detail on what is involved in an event can be found at the Visual Event Editor. It should be noted that event type and event trigger type are two different things, and should not be confused.

Event Types

Attacks and Spells

Attack events are overt actions taken by the player toward an NPC. This does not necessarily mean literally attacking the person, but includes things like talking to them or any other action that you aren't trying to be stealthy while performing.

Somewhat oddly named, Spell events are covert actions. Want to dose someone with an aerosol drug on the sly? Spell event. Spell events have a chance of failure by the target person noticing the attempt.

Location and Static Events

Location events are the majority of events in a scenario. They occur when you arrive or spend time at a location. Many of these are simply random events, but most event chains are a series of location events.

Static events are almost the opposite of location events. Where location events only have a chance to occur at that location, static events have a chance to occur at any location. Static events are useful for penalties events such as the Principal running out of energy or becoming too aroused.

Location Master events are a special kind of event that is located in the same folder structure as regular location events. It uses a special naming scheme, LOC_name.ve.xml, where name is the internal name of the location (usually the same as the folder name) as its specified in the World Editor. Each event is associated with a location in the game world according to this naming scheme. Whenever you arrive or spend time at a location, all adjacent locations have their associated Location Master event tried. The event gets some parameters passed (which are associated with variables by their comment strings) and is allowed and expected to modify them before they are read back into the game engine. These parameters are:

  • Location (Object): a reference to the Location object that is associated with this event.
  • DisplayName (String): the name of the location that is shown on the button in the game UI. By default this is filled with the DisplayName/Name property that got defined in the World Editor.
  • ToolTip (String): allows you to provide some text that will show up as tooltip for this location button in the UI. Empty by default.
  • CanBeVisited (Boolean): change this to True or False to determine whether or not the button for this location shows up in the UI in the first place. Set to True by default if the location is "known".

Person-Attached Events

Person-Attached events are events that can be associated with any person from the game world population by the use of an Attach Event operation in another event. When you arrive or spend time at a location, all Person-Attached events of all persons who are in the same location are tried in the same way as regular Location events. Attaching an event to the principal has the same effect as using the event as a Static event.

Staff events are Person-Attached events located in a specific character's Events folder (located in Staff\[Character]\Events inside the scenario folder). These events get automatically attached to the respective character at the start of the game.

Helper Events

Management Panel (v 1.07 Alpha, Smartphone) -only events, Helper events come about due to certain characters meeting certain criteria - minimum stats and a certain degree of event chain completion for instance - and allow the player to affect students/staff/adults via the Helper. Helper events can only be done once a day each. Most involve spending a small amount of cash for the helper's expenses.

Native Events

Native Events are Visual Events that get called by gameplay code to react to certain actions of the player. Their Try-block won't be activated and they start right away with the Execute-part. They are associated by their file name with the respective gameplay event, so you need to follow the naming convention precisely if you want them to kick in.

Available events:

  • Hire/fire a staff member: "BethManili_Hired.ve.xml" or "SamanthaKeller_Fired.ve.xml"
  • Buying a school upgrade: "Swimming Pool_Bought.ve.xml". The prefix is the name of the SchoolUpgradeLevel, including whitespaces.
  • PTSA proposal is passed: "AnatomyClass_ProposalPassed.ve.xml". (This event no longer fires in 1.07, as PTA functionality has been moved to an event)
  • Opened a club: first triggers an event for the entire club chain whenever a club of that chain is opened, e.g. "CookingClubChain_ClubOpened.ve.xml". Afterwards it triggers an event according to the current club level, e.g. "Restaurant_ClubOpened.ve.xml".
  • Closed a club: first triggers an event for the entire club chain whenever a club of that chain is closed, e.g. "CookingClubChain_ClubClosed.ve.xml". Afterwards it triggers an event according to the current club level, e.g. "Restaurant_ClubClosed.ve.xml".
  • Upgrading a club: first triggers an event for the entire club chain after a club of that chain was upgraded, e.g. "CookingClubChain_ClubUpgraded.ve.xml". Afterwards it triggers an event according to the new club level after the club was upgraded, e.g. "ToplessRestaurant_ClubUpgradedTo2.ve.xml". The 0-based index is needed because some clubs use the same name throughout multiple club levels.
  • Downgrading a club: first triggers an event for the entire club chain after a club of that chain was downgraded, e.g. "CookingClubChain_ClubDowngraded.ve.xml". Afterwards it triggers an event according to the new club level after the club was downgraded, e.g. "CookingClub_ClubDowngradedTo0.ve.xml". The 0-based index is needed because some clubs use the same name throughout multiple club levels.
  • Minigame failed: "BreakInFail.ve.xml"
  • Initialization event: "Initialize.ve.xml" (after loading all files but before updating the UI or advancing time)
  • Start of game event: "Start.ve.xml" (the name of this file is defined by the respective scenario)
  • Event that triggers once every day: "Daily.ve.xml" (executed after Initialize.ve.xml and then every day at midnight)

Item Events

Item Events are pretty much the same as Native Events: they get called by gameplay code to give event developers a way to react on that action. They are in a separate folder than the Native Events for performance reasons. Another difference to Native Events is that Item Events do get their Try-phase activated as well.

The Try-phase is used whenever the Item is used by someone - either actively through the menu or passively via automated daily consumption by NPCs. It gets the Person passed as Argument that is attempting to use the Item. You should activate an "Accept Event" action if the item should lose one of its "charges" from being used. (So this also allows you to make some simple AI scripts that decide whether or not an NPC should actually use the Item or not - it doesn't make sense to drink an Energy Drink if you are at maximum Energy, or does it?)

The Execute-phase is activated after the Try-phase, but only if the Item got used by the player from the menu with the "Use Item" button.

Item Events are associated by their file name with the respective Item, so you need to follow the naming convention precisely if you want them to kick in.

File Name Convention:

  • NameOfTheItem + "_ItemEvent.ve.xml", for instance "Energy Drink_ItemEvent.ve.xml"
  • NameOfTheItem is what is specified as <Name>…</Name> in the XML file, not the actual file name of that file!

Other Events

Paper Doll Handlers are events that determine what paper doll images are shown on the screen. There are Handlers for students, adults, and unique characters. These Handlers check various information to determine what clothing should be worn before calling the appropriate Paper Doll Function to set the paper doll.

Schedule Handlers are events that change the default schedule of a specified person or group if active. This is useful if an event author wants a character to have a different schedule for a brief time, or if the default schedule would have them going places they shouldn't be going at that time (like to work when unemployed).

Function Library

The Function Library is a location for generic event code chunks that can be reused by multiple events. Events can simply remote call the function instead of reinventing the wheel each time. This also means that changes to that code can be done in a central location rather than having to hunt down the code across hundreds of events in order to make the changes. The function library only sees one level of subfolders (so FunctionLibrary\PaperDoll\ works, but FunctionLibrary\Club\ExhibitionClub\ would not work).

Extension Library

The Extension Library shares some similarities with the Function Library in the fact that any events that are stored here don't get called by the game engine on its own but by other events instead. However, the major difference between the two is that calling events are supposed to request all events from a specific subfolder of the Extension Library instead of explicitly referencing a single specific event. There are some internal optimizations to make this particular task more efficient for all events in the ExtensionLibrary folder.

As the name suggests, this is meant to open the game up for external extensions ("mods") by letting events give control to other events without having to know any details about them by the time they were written. One of this system's goals in particular is to enable additions to the existing content without having to modify and override files from the official game release when creating custom mod packs, which may cause issues if more than one mod pack wants to change the same file.

Events usually use the Extension Library with three operations:

  • "Get EventList by Directory" returns an ObjectList that contains all events from a specific subfolder of the Extension Library. Only events in exactly the specific folder path are considered, ignoring events in subfolders of that folder.
  • "Iterator" goes over the ObjectList and picks each event individually to put it into an Object variable.
  • "Remote Event (Dynamic)" tries/executes the event that is passed in the Object variable and may supply parameters by comment-based matching.

Variables can still be passed as parameters to the events, but the comments of the passed variables need to match the comments of the argument variables in any of the called events that wants to make use of them. It is recommended to place a simple txt-file in an ExtensionLibrary subfolder that explains when and how the events of that subfolder are triggered and what variables are passed to them, so other event creators can add matching events later on.

game/events.txt · Last modified: 2016/01/05 06:07 by dougthec