0.4 Cleaner Signals and DateTime Structure

0.4 is a big overhaul to the system adding better defined internal classes like DateTime to have cleaner representation of how time moves through the game. Signals were cleaned up and moves from global singletons to savable resource files, removing unnecessary ones, and defining better parameters to be used by any other scripts that want to use the system for determining in game events (Game UI, Triggers based on Game Time, Time based Lighting, etc). A lot of documentation has been written up for the README.md file in the plugin that details how to set the plugin systems up for your own game. This post covers most of the major changes to the plugin.

Important

• Signals list have changed. You may need to adjust for parameters and signal names. Check the signal bus scripts.
• Most important signals are emitted on signal buses which are resources rather than global singletons. Anywhere you referenced the singletons, you'll need to replace with a reference to a signal bus resource. I recommend saving the bus from your systems (GameTimeSystem) and using export variables to reference the resource file in your project.
  
  SAVING TIME SIGNAL BUS
  
  ASSIGNING TIME SIGNAL BUS
  

DateTime

Added to the plugin are classes for DateTime, GameDate, and HoursTime which have been integrated with the base systems and included scripts. These objects provide a cleaner way of managing time and conversions of time for your game. The game dates are separate from real world dates, and this applies to the TimeScale and GameCalendar as well. You can customize the number of years (in a cycle, you don't have to define a 2000 year calendar just the 4 years that are different), number of months and days per month, values for seconds per minute, per hour, and per day, and more. Since the scale of these time elements vary between games, you want to use your GameCalendar resource (you'll create one for the GameTimeSystem), in order to handle conversions like date_time_as_seconds(p_date_time). All in all this should be a big improvement over using simple non-object fields for seconds, minutes, days, etc.

Game Calendar

Now a separate resource object that works in GameYears, GameMonths, and DateTime. The go to object for most time conversions like checking how many days into a game year that a given GameDate is. You need to create one for the GameTimeSystem. As a resource, you can save it and reference it anywhere else you need to know about the active game calendar.

GameYear

Defines a number of game months which each layout the number of days on each individual month. A calendar is composed of these and will cycle through the game years when it reaches the end of the defined game_years array.

GameMonth

Arbitrary representation of a month with a name and number of days.

Signals

TimeSignalBus & AgeingSignalBus are now resource objects that shares signals between emitters and subscribers instead of a global singleton. This provides advantages like being able to have multiple time systems that nodes and other objects subscribe to and only receiving signals from the system you want. The in-between resource objects, the TimeSignalBus & AgeingSignalBus, means you can receive those signals without ever directly connecting to the systems (GameTimeSystem, WorldAgeSystem) - all you need to do is save the resource in your project and use as an export field anywhere you need it.

After testing, I've simplified the signals list to the essentials. Less signals to manage hopefully  will make things less confusing.

Similarly, the world age system also has it's own AgeingSignalBus that also works the same way (resource object, save to project, reference it where you need it)