I've decided to create a new post for my fork of Kyuss' and, jarquafelmu's [Drop-In] Customizable Calendar,Time and Weather addon to have it as a first post resource as well as to put in all the technical information without flooding his thread. I have extended the capabilities of the original token to make it a truly generic calendar mechanism for use in any campaign. With that being said, this token is primarily for GM use. I used 1.b86 to make the modificatios as it didn't have the b87 bug where hitting enter doesn't close an input window.
This started out with the best of intentions in making the drop-in easily extendable should anyone wish to do so. However, as development progressed, my desire for certain (often complex) functionality, along with time constraints, made me break this personal rule in favor of getting this out as quickly as possible. To accomplish my goals, I had to make significant changes to some of the fundamental underpinnings of the original drop-in. I've detailed the deviations on the 1st change log.
Deviations from original token:
Details
2. Removed direct campaign property manipulation from the code. Though ease of coding takes a hit, it allows for all properties to be hidden. I still made them visible as campaign properties, though, for those who want to keep an eye on these properties or do direct manipulation of their values. In any case, deleting the campaign properties will have no effect on the functionality of the drop-in.
3. Moved from execLink to UDFs. I had some weird artifacts using the original token's approach when I started adding new functionality. I'm not sure why but I've found changing the calls to UDF fixed it for me.
4. Hosting control macros as global macros instead of campaign macros.
5. Token need not be on the token layer and may be placed within the Hidden Layer
Included in the attached archive is the token along with all the tables it uses. After dropping the token in and importing the tables, click on the token's onCampaignLoad to setup the calendar for 1st time use. To get the token to this initial state future, use the resetCalendar and initCalendarSettings functions found on the token. As was mentioned in the Deviations section, I made changes based on my preference for hidden properties over visible ones. However, if you prefer to keep track of these properties through the CP, you can create a new entry under Campaign Properties and copy-paste the following:
Campaign Properties
month
monthName
day
dayName
year
year-desc
yearDes
hour (hr)
hourName
minute (min)
dayMod
minuteCount
hourCount
daysInWeekCount
daysInMonthCount
weekCount
monthCount
seasonCount
lunarCycle
moonriseOffset
moonsetOffset
---------[ DEFAULT LISTS ]----------
monthList
monthNamesList
manualDIM
dayList
dayNamesList
hourList
hourNamesList
minuteList
dayModList
seasonList
seasonStartList
seasonSunriseSunset
seasonColorsList
----------[ Toggles ]----------
DayR
Night
Weather
Season
SeasonColor
UserDefined
RandomWeather
TopLevelType
ActiveMonthView
dayColor
GM
AutoRefresh
MultipleAddEvents
LastTriggeredPermanentEvent
SortEvents
VisibleMoon
EventTriggerType
SubmitMethod
----------[ EVENTS ]---------------
yearTempArchives
yearReminderArchives
yearGistArchives
yearColorArchives
permanentEvents
temporaryEvents
reminderEvents
monthGist
Sunrise
Sunset
Moonrise
Moonset
a. The Initial Screen:
Screenshot
1. # of Days in Month - this is an optional entry that will override the result of the # of days in week * the # of weeks in a month. Leave at 0 to use computed value instead.
2. Seasonal division - there is only partial functionality associated with this as of now. Plans for random, seasonal weather will be put on the back burner for now.
3. Lunar Cycle - this affects the phase changes of the moon.
4. Initial Moonrise/Moonset Times and Offsets plus Visible Moon - no functionality associated so these can be skipped. Though the math and logic have been worked out, I haven't thought of a satisfactory way of displaying it using the current sky trail. The Visible Moon toggle is supposed to display the moon at all times during the day. This too is out for now. The sky trail is still useful without these, in any case.
5. Add Event Window Toggle - When disabled, the Add Event windows closes immediately after the form is completed. Enabling this option will keep the window open to add multiple events to the same day.
6. Event List Display Type - entries on the Month Schedule window will be sorted depending on what is set here
7. Selective Broadcast - when the "Tell" functionality is used in the Month Schedule window, this setting will determine whether it broadcasts to all or to a select few chosen through a prompt.
8. Event Trigger Type - This controls the triggering of scheduled reminders and temporary events. "On-time" simply means that the user must trigger the event exactly on the time set for it, whereas "Pass-Through" allows triggering by getting past the scheduled time be it by minutes or hours.
9. Name Hours? and similar entries - RPGs like the one I'm playing have names for each hour. This of course can be tedious to go through so I put this here to skip the entire naming process, defaulting the hour names to the hour value. The other prompts similar to this one does the same. Enabling them all will result in a speedy initialization process but will make a really ugly calendar There are several edit functions I made for this eventuality should there be a need.
10. Manually Set Days in Months - As per request of A.M., this setting will allow the entering of different values for days in months. This will override all other values used for setting this number in the Lib:Token.
a1. Other notes on initialization
1. Season Start - this uses day-in-year values. For example, spring starts at 1, summer at day 85, autumn at day 165, and winter at 225
2. Season Sunrise and Sunset times - dependent on the hour settings put in. For example, a 24 hour clock would need values of 1 to 24
3. Season color - used to prettify the calendar and other functions like the time dialog/frame. We used #88BD1E, #E0D01B, #ED6F1A, #6D9AE8 for the 4 seasons in our campaign.
b. 3 Calendar Views
1. Full Year View
Screenshot
Screenshot
Screenshot
1. Permanent Events - Once set, these events persist through every year until manually removed. Ideal for holidays and other annual events.
2. Temporary Events - These events are removed as soon as they are triggered or "told", and are the only event type that can be set to trigger down to the level of minutes.
3. Reminders - Like temporary events, reminders are removed once triggered, but they are different in the way that they can be made to persist for another day through a prompt (more on this later).
Adding events will color the day button they're on. Red for temporary events, green for permanents, and blue for reminders. Different event types on the same day will color the button with the combination of the color types present.
b.1.1 Event Triggers
1. Permanent Events - triggered when the scheduled day commences
2. Temporary Events - when scheduled, it is triggered when the scheduled time arrives or elapses, depending on the event trigger type set. To schedule, put the equivalent time as the event title. The manner of scheduling is not exhaustive and only accepts values set in military time. In my framework we use 24 hour, 60 minute clock so this converts to hhmm (i.e. 2300 for 11pm, 0100 for 1am). So if your framework has, for example, 24 hours and 100 minutes or 100 hours and 60 minutes, scheduling should use hhmmm or hhhmm respectively; keeping in mind to only put values within the bounds set for your calendar. Failure to do so will result in no triggering. Unfortunately, I haven't tested values of these manner at all, so there will likely be bugs.
3. Reminders- when scheduled, these trigger when the hour set for it arrives or elapses. To schedule, simply put the hour value as title, ranging from 1 to the maximum hour set for your framework (i.e. 1 to 24 for a 24 hour clock). When the time arrives or passes, a prompt asking you to discard or keep the reminder appears. Placing an hour value on the text field will set the reminder to trigger at this hour on the next day. Hitting cancel will erase the reminder from the lists, while hitting ok will schedule it on the next day at the same hour. Again, invalid entries will result in no triggering.
Events need not be schedules for triggering if you don't want to. Simpy using other kinds of titles will set an event up for manual use later.
b2. Calendar Functions
1. Top Level View
1.1 Next and Previous Year - when used, this does not only create a calendar for the new year but also archives the events and settings of the current year before moving. Note that archives of a year will overwrite themselves each time you leave that year so if restoring archived values is what's desired, do so prior to changing years.
1.2 Refresh - this redraws the calendar. most useful when used during Full View and calendar auto-refresh disabled.
1.3 Switch functions- flit between the different calendar views.
2. Add Month Event -
Screenshot
3. Month Schedule
Screenshot
Clicking on a month button displays this dialog. The window contains the ff. functions:
3.1 Remove - removes the entry from all lists. If the event removed is a permanent it also removes the entry from all archives.
3.2 Edit - opens the Add Month Event window to edit an event's details, along with other things mentioned earlier.
3.3 Show - displays the contents of an event
3.4 Tell - broadcasts the event to recipients based on the setting for selective broadcast. Note that if there are no other players connected, broadcasts will be set to "all". Temporary events are removed from all lists once "told", so be careful.
b3. Sky Trail
Screenshot
c. Tables
The token uses the following tables. These are included in the archive for import into campaigns. Tables from the original token are italicized for reference purposes:
List of Tables
2. Sunsets - same as #1
3. Sun - holds sky trail images for the sun. For those who want to get fancy, more images can be added to this table.
4. Moon - holds sky trail images for the moon and all its phases (courtesy of aliasmask )
5. Sun (slices) - more sky trail resources, used when the sun or moon reaches either end of the sky trail
6. Moon (slices) - same as #5
7. weather (Chat inject) - contains text for weather changes.
8. weather (desc) - lists weather types
9. weather 32(day) - contains day weather images
10. weather 32(night) - contains night weather images
11. weatherBG (day) - sky trail backgrounds according to weather. Anyone wanting a complete table must do it themselves as I've run out of time to focus on this, as mentioned in the originating thread. The dimensions I used were 620x115 pixels
12. weatherBG (night) - same as # 11, but for night time
I've grouped useful token functions under groups meant for global/campaign macro and player-side use. Others can save and restore a year's archives as long as they are available and not overwritten by moving away from its year. All other functions are for the token's internal workings and are not advised to be called by themselves else unpredictable behavior occur. I have to admit that it's still a bit cluttered so please bear with it. Lastly, most functions are set for GM-use only. This hasn't been tested thoroughly so it might cause errors on the player side. Should this occur, feel free to remove the assertions I put in the code.
e. Future Plans
1. A listing of all events in a year - though not high on the priority list
2. Random and seasonal weather - I really wanted to get this done as it makes more sense to only be able to set appropriate weather for a season. But following the current design would result in a staggering amount of tedious work where each season would need specific copies of existing tables for its own use. For example, making a 6 ecological season scheme would entail 6 weather desc tables, 6 chat injection tables, 12 weatherBG tables etc., or what amounts to all the needed content. I'm really not up to it right now, sorry
3. Optimize code
Since I can't possibly test this thoroughly enough on my own, I'm putting this out here for for beta testing. Again, my apologies in advance for any bugs encountered . Please provide details and I'll try to tackle it when I can, though I can't guarantee any time in the near future. RL is hammering at the door again Anyway, I hope I haven't missed any important detail with this post. If it works for you, do enjoy the drop-in.
Thanks everyone, especially to Kyuss and friends for providing the initial base for this project