[Drop-in] Generic Calendar 0.3 (Beta) - Updated 11/1/2012

These are tools and utilities that make it easier to run games. This includes Lib: macro tokens dropped into MapTool to manage the game, a conversion file for CharacterTool to allow use in MapTool, or just about anything else you can think of -- except graphics with macros and anything specific to a particular campaign framework. Those are already covered by the Tilesets subforum and the Links and External Resources forum.

Moderators: dorpond, trevor, Azhrei, giliath, Gamerdude, jay, Mr.Ice

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

[Drop-in] Generic Calendar 0.3 (Beta) - Updated 11/1/2012

Post by Lee »

I don't really have much time to detail everything so I'll do the best I can for now.

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
1. Moved to string lists to JSON (I needed a couple of capabilities String List functions didn't have)
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
DISCLAIMER (2): I haven't been able to test this 2nd build thoroughly so do expect some bugs still :lol:. While I coded in the ability to make months with irregular days, I have no intention of adding the computations for leap years.

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
---------[ DATE AND TIME ]----------
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
Some of these properties, such as VisibleMoon and RandomWeather have no use as of yet and are placed there with future functionality in mind. Lastly, as each game world is different from the next, the user must implement their own fixYearDesc function, which I purposely blanked due to it being too specific to my campaign.

a. The Initial Screen:
Screenshot
Image
Before the calendar can be used, it must first be setup. Most of the prompts are self-explanatory. Here are explanations for what are not:

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 :lol: 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
Image
2. Partial View (or Month View)
Screenshot
Image
3. Month Console
Screenshot
Image
b1. 3 Event Types

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
Image
Clicking on a day button or the edit button under the Month Schedule pops open this dialog. This allows the adding of new events to the day chosen. This is also the window used by the Edit function explained later. Note that you may overwrite a previous event by using the same title. On the flip-side, in Edit mode, changing the title will result in either a new entry or the overwriting of another entry saved.


3. Month Schedule
Screenshot
Image


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
Image
A simple visual aid that displays the actual sky position of the sun during the day and a representation of the moon at night. As noted below, background images matching each weather type must be included by users themselves as I ran out of time to work on it.

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
1. Sunrises - contains text for sunrise events according to current weather conditions
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
d. Usable Functions

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 :lol:
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 :D. 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 :roll: 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 :)
Attachments
Generic Calendar 0.3 (Beta).rar
(325.4 KiB) Downloaded 495 times
Last edited by Lee on Thu Nov 01, 2012 7:01 am, edited 7 times in total.

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: [Drop-in] Generic Calendar 0.2.1 (Beta)

Post by Lee »

[reserved]
Changelog 0.1 to 0.2
1. Fixed a major bug on the remove event function. It should work okay now.
2. Added the ability to manually enter the # of days per month.
3. Provided the option for using links instead of buttons. Still thinking of putting code in for injecting alt/title text for tooltips. I guess I'll leave that for the user to implement himself.
4. Several minor optimizations.
Changelog 0.2 to 0.2.1
1. Fixed minor error in displaying days of week.
Changelog 0.2.1 to 0.3
1. Improved initial setup.
2. Bugs fixed:

a. Initial setup prompted for manual entry for days in a month, even when automatic setting was toggled.
b. Creating the partial view when season colors have not been defined initially
c. Fixed typos for Set Weather macro
d. Reset calendar settings also had some typos

3. Partial code cleanup.
Last edited by Lee on Thu Nov 01, 2012 7:09 am, edited 4 times in total.

User avatar
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: [Drop-in] Generic Calendar 0.1 (Beta)

Post by wolph42 »

Impressive work, its not something Im likely to use (but that happens pretty soon in a sci-fi setting where the players are on a different planet every week...). Nonetheless, I nearly missed this one as it was already buried in a long list of 'newer' posts.

In short: nice work!

User avatar
aliasmask
RPTools Team
Posts: 9023
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: [Drop-in] Generic Calendar 0.1 (Beta)

Post by aliasmask »

Yes, nice work. What is an "event"? Is it just a popup and how is that different from a reminder. I'm guessing a reminder is tied to an event like if you have a meeting at 12, you may want a reminder at 11. I like all the form submit buttons, but you could also use links or image links and that will give you added functionality of a tooltip. Unfortunately, tooltips don't work for buttons and other html elements like radio and checkboxes.

The one thing I would want to use the calendar system for is for Greyhawk, but they have a funky system where they have festival "months" that are only 7 days long. I didn't notice in your screenshots, but are you able to customize each month's number of days. I see there is a field, but if I put 31, does that make all the months 31, or do you enter a list of values?


Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: [Drop-in] Generic Calendar 0.1 (Beta)

Post by Lee »

Thanks guys. It feels good to finally give something back to the MT community :)

@aliasmask, I just used the word event as a catch-all term for holidays, special occasions etc. The 3 types all sport distinct functionality to make my work a little easier and provide tools for people looking for a specific fit a situation without overlapping design. Permanent events happen on the date every year until removed, temporary events expire as soon as they happen or are fired manually, and reminders either are removed or stay for one more day depending on what the user desires when prompted. I did start out with using links and thought that I should provide a variety of views and wait for feedback as to what's the popular choice; which is why I've delegated the links to one view and buttons to the other 2. It shouldn't be too hard, I guess, to put a new toggle in for users to choose whether they want stuff in buttons or links :)

:lol: I didn't quite expect my disclaimer on months to meet a challenge right away. I was certain there was no need for differing month lengths. I owe you, A.M., for a lot of things, especially RPEdit; so when I have time again, I'll put in a process to specify month lengths on an individual basis. I did have an idea to go about it but it got pushed back to the point that I ran out of time when I released it.

Thanks again for the feedback. Having 2 of the best weigh in on my work means a lot to me :)

User avatar
kyuss11
Giant
Posts: 175
Joined: Thu Dec 23, 2010 1:12 am

Re: [Drop-in] Generic Calendar 0.1 (Beta)

Post by kyuss11 »

Lee will you be my friend,lol. I'm seeing a very motivated person with great potential,I also see someone who will be a great asset in the future of coding projects. I would like to talk with you in skype if possible,my email is [email protected] if you wanted to post your skype name,or any other means to chat.I must say that I never thought the calendar addon could get so intricate and interesting.I do like the idea of weather backgrounds for seasons or maybe a border,I have to confess though my skills at coding are improving but Jarquafelmu gets all the credit.I like to give him ideas to keep him coding,since that's what he wants to do for a living.Well anyways,my point here is I would love to chat and maybe come up with a plan for future 5e framework,and or if your interested 2e.Jarquafelmu is finishing a disease tracker atm for 4e and maybe all 3 of us can share ideas and learn stuff.Awesome job by the way 8)

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: [Drop-in] Generic Calendar 0.1 (Beta)

Post by Lee »

Edit: Double posted sorry. Couldn't find the delete post button XD
Last edited by Lee on Thu Jun 07, 2012 5:19 am, edited 1 time in total.

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: [Drop-in] Generic Calendar 0.1 (Beta)

Post by Lee »

@aliasMask I got it done A.M. I had a day free and thought I'd put in what you asked. Let me know what you think :)
kyuss11 wrote:Lee will you be my friend,lol. I'm seeing a very motivated person with great potential,I also see someone who will be a great asset in the future of coding projects. I would like to talk with you in skype if possible,my email is [email protected] if you wanted to post your skype name,or any other means to chat.I must say that I never thought the calendar addon could get so intricate and interesting.I do like the idea of weather backgrounds for seasons or maybe a border,I have to confess though my skills at coding are improving but Jarquafelmu gets all the credit.I like to give him ideas to keep him coding,since that's what he wants to do for a living.Well anyways,my point here is I would love to chat and maybe come up with a plan for future 5e framework,and or if your interested 2e.Jarquafelmu is finishing a disease tracker atm for 4e and maybe all 3 of us can share ideas and learn stuff.Awesome job by the way 8)
:lol: Sure, friends it us. I do have to say I'm hardly OL as I hardly get to sit at home in front of my PC for my hobbies. I'm sure most will notice that I'm in and out of this forum for months at length. Also, my players are near mutiny over my inattention to the framework I built for our campaign. It was open revolt actually when I did this side project :lol:, so I don't think I can work on anything much at the moment. I do think your friend has sound skills in this and should you guys ever post something in need of assistance (and I'm around), I'll be sure to help then. Sorry, if I can't offer more, RL being deadly as it is.

Thank you for all the kind words, I do appreciate the appreciation :)

User avatar
Xalcairn
Cave Troll
Posts: 27
Joined: Sat Dec 05, 2009 4:53 pm
Location: Boise, Idaho

Re: [Drop-in] Generic Calendar 0.2.1 (Beta)

Post by Xalcairn »

Thanks for all the hard work on this! One issue I am having however is this. When I attempt to change the weather with the macro button I get this error.

  Error in body of roll.       Statement options (if any): h, code       Statement Body (first 200 characters): { [assert(isGM(), "This is a GM only function...", 0)] [tableName = if(getLibProperty("DayR") == 1,"weather32(day)","weather32(night)")] [weatherlist = table("weather(desc)",1) + " " + tableIm

What could be causing this? I appreciate the help.
-This roll of 1 brought to you by.... your very own random number generator, and the letter F for Fail-
RPGA#:9214000284 Skype:xalcairn

User avatar
kyuss11
Giant
Posts: 175
Joined: Thu Dec 23, 2010 1:12 am

Re: [Drop-in] Generic Calendar 0.2.1 (Beta)

Post by kyuss11 »

Well considering this has been modified quite extensively from my post on a calendar drop-in,I'm not sure if the tables are included.The first question is did you add this to your campaign,and if so did you import tables?The other suggestion would be with the original drop-in,you had to have the Lib:Calendar token on the map you were going to run the macros from,but since this has been changed I'm not sure if thit still applies.

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: [Drop-in] Generic Calendar 0.2.1 (Beta)

Post by Lee »

@Xalcairn which specific macro would that be? I haven't touched that in 3-4 months so it's already hazy to me. Also, did you move that macro anywhere else other than the lib:token?

@kyuss I tried to adhere as close as possible to your original work, but I believe one of the major changes was to use library properties. I did keep the Campaign properties intact, but only for viewing and editing on the fly. Everything else is done in the background accessible across all maps.

User avatar
Xalcairn
Cave Troll
Posts: 27
Joined: Sat Dec 05, 2009 4:53 pm
Location: Boise, Idaho

Re: [Drop-in] Generic Calendar 0.2.1 (Beta)

Post by Xalcairn »

Wow thanks for the fast response. It is the set Weather macro button located in the group time controls. I also get the same error when attempting to use the other set weather button located in drag to global. The two look somewhat different though in the edit screen. Below is the macro for each
Spoiler
[h, code:{
[assert(isGM(), "<b>This is a GM only function...</b>", 0)]
[tableName = if(getLibProperty("DayR") == 1,"weather32(day)","weather32(night)")]
[weatherlist = table("weather(desc)",1) + " " + tableImage(tableName, 1)]]
[currWeather = getLibProperty("Weather") - 1]
}]

[h,for(i,2,11),CODE:
{
[weatherlist = weatherlist + ", " + table("weather(desc)",i) + " " + tableImage(tableName, i)]
}]

[h:status=input(
"selectWeather|"+weatherlist+"|Select Weather|LIST|SELECT=" + currWeather + " ICON=TRUE ICONSIZE=30"
)]

[h, code:{
[abort(status)]
[setLibProperty("Weather",selectWeather + 1)]
[currTime()]
[h,, if(getLibProperty("DayR") == 1), code:{
[broadcast("<img src=" + tblImage("weather32(day)", getLibProperty("Weather")) + "</img><br><i>" + table("weather(Chat Inject)", getLibProperty("Weather")) + "</i><br>")]
};
{
[broadcast("<img src=" + tblImage("weather32(night)", getLibProperty("Weather")) + "</img><br><i>" + table("weather(Chat Inject)", getLibProperty("Weather")) + "</i><br>")]
}]
Spoiler
[h: assert(isGM(), "<b>This is a GM only function...</b>", 0)]
[h: setWeather()]
Other than that is a great tool I would love to use it in my homebrew. Thanks again for all of your hard work.
-This roll of 1 brought to you by.... your very own random number generator, and the letter F for Fail-
RPGA#:9214000284 Skype:xalcairn

User avatar
Xalcairn
Cave Troll
Posts: 27
Joined: Sat Dec 05, 2009 4:53 pm
Location: Boise, Idaho

Re: [Drop-in] Generic Calendar 0.2.1 (Beta)

Post by Xalcairn »

kyuss11 wrote:Well considering this has been modified quite extensively from my post on a calendar drop-in,I'm not sure if the tables are included.The first question is did you add this to your campaign,and if so did you import tables?The other suggestion would be with the original drop-in,you had to have the Lib:Calendar token on the map you were going to run the macros from,but since this has been changed I'm not sure if thit still applies.

I did drop it into my existing campaign that uses the hybrid dn5 and veggiesama framework by Zalarian.

I did indeed import tables however I did notice that there were no images for the different weather patterns in the sky trail in the weather table, but it had all of the originals for the current time dock window.

I was indeed running it on the same map I had it loaded on, it was visible to players and had no ownership restrictions.

I copied in the campaign props from this forums parent post as well.

All of the other macros including the sky trail work great.

I am using maptool b87

Also tried dropping in the original you had posted kyuss11 and it works great including weather although of course it has been heavily modified to now.
-This roll of 1 brought to you by.... your very own random number generator, and the letter F for Fail-
RPGA#:9214000284 Skype:xalcairn

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: [Drop-in] Generic Calendar 0.2.1 (Beta)

Post by Lee »

Edit: scrap that last post. Overwrite the Set Weather macro on the library token with this:

Code: Select all

[h, code:{
[assert(isGM(), "<b>This is a GM only function...</b>", 0)]
[tableName = if(getLibProperty("DayR") == 1,"weather32(day)","weather32(night)")]
[weatherlist = strformat("%s %s", table("weather(desc)",1), tableImage(tableName, 1))]
[currWeather = getLibProperty("Weather") - 1]
}]

[h,for(i,2,11), code:{
  [weatherlist = strformat("%s, %s %s", weatherlist, table("weather(desc)",i), tableImage(tableName, i))]
}]

[h:status=input(strformat("selectWeather|%s|Select Weather|LIST|SELECT=%s ICON=TRUE ICONSIZE=30", weatherlist, currWeather))]

[h, code:{
[abort(status)]
[setLibProperty("Weather",selectWeather + 1)]
[currTime()]
}]

[h, if(getLibProperty("DayR") == 1), code:{
[broadcast(strformat("<img src=%s</img><br><i>%s</i<br>", tblImage("weather32(day)", getLibProperty("Weather")), table("weather(Chat Inject)", getLibProperty("Weather"))))]
};
{
[broadcast(strformat("<img src=%s</img><br><i>%s</i><br>" , tblImage("weather32(night)", getLibProperty("Weather")), table("weather(Chat Inject)", getLibProperty("Weather"))))]
}]
Do keep using it and let me know if there're any more bugs. Oh, and I really don't have images for those tables. I made the tables as placeholders for people to put images in themselves since I ran out of time to work on this. If you can, you can fill in whatever blanks there; better yet, you can share these images and I'll put them in in the future for everyone's use.

Edit # 2: I checked on the drop-in and found several bugs I didn't catch the last time (such is my luck around 3 in the morning). Fixed these as well as the Set Weather typos. Uploaded 0.3 as a result. I may have broken some other things, but what the heck, Happy Halloween.

Post Reply

Return to “Drop-In Macro Resources”