Need help on a script since I don't know programming.

I got an idea based on a few scripts that I saw but I don't know how to do it off hand. I saw Brian's old time/torch tracker that has the shrinking radius on !round x command which made me think about using the End of Turn script to reduce the light. How would you go about getting the tracker script to work with the EoT script for tracking the time? I use the light function seeable to all players on a player's token to represent a torch instead of a actually torch token and would need that token to reduce it's radius specifically. I'm not a programmer so I have no idea where to start or what to do when I start and how to incorporate any new commands or codes if there is any. End of turn time/torch tracker

Are you trying to make it automatically switch turns when the timer hits 0 (aka no radius)? Edit: after checking out the reducing light script, it shrinks the light based on the number of rounds lit. Are you trying to make it so that ending your turn effectively reduces the light on that specific token? Or are you trying to make a continually shrinking aura/light on a token to indicate a timer for how long a player has to take their turn?

I was trying to figure out how to make the end of turn reduce the torch light based on the length of it's burn time. A torch lights up 50 ft light but the dimness starts at 30 ft. Now the torch burns 1d4+4 turns so if I or the torch bearer does a end of turn the radius is reduced by either a % or just by footage. I just wonder if it should be movement based instead of end of turn so that after so much movement the light radius is reduced and continues till there is no light until it is reset to represent a new torch.

It really should be turn based the might hang round in a room for a minute fighting monsters, the torch burning down all the while

right now I've been manually counting it through the turn tracker but would love to automate it somewhat.

aye, I was looking at making it do something similar, I just never got around to it. Thing is dissecting the code and pulling out the bits you want included in your version. to make it go round by round you have it check to see if the id of the turn tracker = that of the end of round counter you have on it - each time it is, you have to pull 1 from the timer of the torch (bar2 on my setup.) unfortunately I never got the time to really make it work and since then my players haven't been in a dungeon situation where it would matter, so I kinda left it. the other way of doing it is writing a time script that you can use to keep track of time over the whole game, not just round by round. then use that to keep track of torches. more accurate to be honest, and thats where I was getting caught. I couldn't make it work, not being a programmer and all. mostly because it would need to be able to keep track of time in three different ways - what minute it was, (and what round in combat situations), which hour of the day it was, and what day of the month it was. you would also have to be able to add to the time in such a way that you could enter in an amount of hours to be passed over, (ie, three hours later), enter a time to advance to (the party beds down for the night and awakens at 6 in the morning - regardless of what time it is when they go to sleep) and a way of entering a date and having the game leap forward to that date - and with all of that, you need a way of removing time from the game in the same way - by the minute/hour, to a certain time of day, and to a certain day in the past. I got a headache thinking about how to implement it.

you gave me headache just trying to understand what you were meaning.

Hey Metroknight, I haven't spent much time on my scripts since my game actually started (though I keep meaning to), but with today's Rugged Reroll announcement I've gone back to blow the dust off my scripts and add some new features I've been thinking about. I actually have implemented some of the stuff Michael suggests -- I have a running timer that keeps track of how much time has passed, but only during the current session (my campaign is based around a nearby dungeon and the group makes short forays before returning to town), but I've been thinking of making it persistent and adding some automation for healing, etc. I forget if I updated the version of the script on the forums to reflect some of my small changes since I originally wrote it, but I'll be taking a look at it this weekend. I'll check out the End of Turn script -- I just glanced at the post (I'm still technically at work ;-) but it seems like it would be useful, since I too often accidentally skip player's turns. I don't think it would be hard to integrate it into my torch timer.

Cool.

@Brian H - A persistent script that lets you hook healing and regeneration effects into it (along with everything else) that actually works would be awesome! I never managed to get it running (i'm learning Javascript as I code it for roll20, so I don't know much at all about how to get it to do what I want). best I managed was a script that let you heal up overnight and regenerate spellpoints (3.5 variant), but never got it hooked into a time keeping script, just macros to activate. I'd be happy to test/help out with/break anything you put together, I can usually follow a code once its written, and I am pretty good at breaking them (at least, I always seem to manage to break em). PS: just thought I'd add this little bit - Your torch time tracker was the first script I used, and I found that it was a simple thing to code the stats for that light into the tokens bars - I used the green circle for the torches 'HP' ( but with the time in minutes that a torch was active - and used fractions to keep up with round by round combat situations), blue for an automatic on/off switch, (on = on, off = off, though I fixed off so it left the token with a 0 light rad so that players could see it in the dark and interact with it) and the red circle for the tokens light radius (max rad and dim rad set to the bars current and max levels). players had access to a tokens on/off state, (they had to remember to turn it off in lit areas themselves or their torch/lantern/candle was wasting away.) and i used the carry token script to bind a torch/lantern to a players token when players wanted it set that way I did find that if you have the light source growing dim, it really gave that feel of it running out by reducing the dim rad more than the max rad; for example, strong torch = 20ft max rad, 15 ft dim. torch just starting to burn out = 20ft max rad, 10ft dim. torch that was nearly burnt out = 15ft max rad, 5ft dim rad, and a torch on its last legs = 10ft max rad, and 0ft dim rad. (though I used fractions in the actual code not hard numbers) I experimented with having the torches flicker, as well as grow dimmer (every second the light rad changed by +/- 10% its max rad) but it wasn't the smoothest, although thinking about it now I never tried adjusting the dim rad to see what that looked like) but I wasn't impressed with the testing I did.

oh, and Metroknight? I get a headache just thinking about it myself too.

Using bar3 for the bright and dim radii is brilliant! I've updated the torchTracker script to use those, it's simplified things nicely. And I like your idea for reducing the dim radius faster than the bright radius, so I implemented that too. I like it much better than the arbitrary percentages I chose. I also updated it to work better with the carry token script. I was having issues with all the torch and lantern tokens having the same name -- the !carry command would always pick up the first one. But my script depended on the tokens all being named either "Torch" or "Lantern," and wouldn't work with "Frank's torch." So I've changed it to select all the tokens on the current player page that have light_otherplayers set to true, and bar2 value/max value set to 1. This works for me to filter out anything but torches and lanterns, because I don't set up any tokens to emit light visible to all players that aren't torches or lanterns. Checking that bar2_max="1" isn't really necessary for my game, but if I ever want glowing monsters or non-fuel-based lights, I don't want to rely solely on the light_otherplayers property. And since I currently only use bar2 for armor class, it's unlikely to ever be 1. I took a look at the End Of Turn script, and it's pretty easy to update it to work with the torch time tracker, with the only real complication being that one round in combat is usually not equal to one minute, which is currently what I've called a round in the script. I mostly meant it for keeping track of how many minutes/hours the party has spent exploring, and assumed combat and the aftermath (cleaning off blood, bandaging wounds) takes one turn total. It wouldn't be too tricky to seconds to the tracker, and then to advance the total 10 seconds for every turn. I think I might prefer to keep it to minutes/hours and only increment every 6 turns in combat, though. That'll take some more thinking, though, and it's late tonight. ;-) Anyway, to get the !eot command to advance the torch tracker one round, you can add the following line at the end of the on("chat:message" function the End Of Turn script: moveTimer(1); which will call the moveTimer function from the torch tracker & advance the timer 1 round. To make the turn tracker "advance turn" button also advance the time tracker, add this callback function to the torch tracker: // Listen for change of the turn order, and advance one round on("change:campaign:turnorder", function() { moveTimer(1); }); I'm working on making the time tracking persistent, which I need to do before implementing any kind of rest/healing tracking, but I'm still in the "how can I do that" stage, but I'll happily share when I get something that's in some kind of testable form. Right now, I'm planning to use a character with attributes to store total days, hours, and minutes. I think I'll get something working for resting and healing, and then refactor the torch tracker to use the persistent time instead of the state property. Anyway, that's all for tonight. I've updated the code in gist, so hopefully it'll update in the original post. That topic has been automatically closed, though, and I don't want to post it in a new topic until I've made some more significant changes to it.

I believe the easiest way would be for a api command that adds minutes, hours or days at a click of a button. actually tracking time in real time isn't that essential, so a simple click of a button for every minute of wandering around a dungeon (or ten) by the DM is probably enough, and that will let spells that have durations be tracked and automatically whisper the DM that the spell being tracked has run out of time. also, might I suggest a form of calendar? at least have it break down the days and weeks into a player definable format (ie tendays for forgotten realms, etc) set in configerable options.

Tried to post twice and each time I got a blank post. :( Short version: I'm working on something that will work like the torch tracker but include commands for hours/days/months/years in addition to minutes, and will be configurable to use custom month names and weekday names (as well as length of week, i.e. tendays). Haven't started on the event handling yet, but I'll post some code when I get the basics working. Right now I can add days and hours, and display the time in "October 8, 2013, 3:00pm" format.

cool. That sounds awesome.

sounds like we are on the same wave length :P

I probably won't have much time to tweak this before the weekend, but here's the code so far if you guys want to play around &amp; see what you can do with it. It's pretty rough, but the basic calendar is working. Commands are !year, !month, !day, !hour, !minute in the form "!year x" (currently needs a number, otherwise script stops), and !addTime, which can add them all at once and looks like "!addtime 1,2,3,4,5" with 1-5 being year through minute. Requires a character names "Chronos" with attributes named Year, Month, Day, Hour, and Minute. Also, assumes that Month, Day, and Hour have max values to indicate when to flip over to the next year/month/day -- i.e., Month has a max value of 12. In case a day has 27 hours in your campaign. Variable month lengths are trickier. There are two arrays defined at the top for storing calendar information, but at the moment the only thing being pulled from there is the name of the month -- right now it assumes all months are 30 days long because I haven't worked through the math to calculate days properly when months have varying lengths. That and working out the day of the week name are the next steps when I have some more free time. Suggestions for improvements or bug fixes welcome. ;-) <a href="https://gist.github.com/bripod/6902575" rel="nofollow">https://gist.github.com/bripod/6902575</a>

my only complaint is that this has come in at the start of my work week... And I need sleep!!! will play with it though, just won't have time to really try and break it till monday.

I'm still in shock how my little question has blossomed into this script.

I've had the idea for doing something like this for a while, you guys have given me some motivation to work on it. ;-) I fixed a few minor issues I discovered while messing around, and tried to clean up the script &amp; make it a little more readable, hopefully. The gist file is updated. Also added some more handling for the configurable calendars; the script should now take the second value from ["January",31] to determine when to rollover a new month when adding more days than are in the current month. (This doesn't work right if you add enough days to move the timer forward by two or more months, though, it assumes the second month has the same number of days as the first.) Also, added some handling for day of the week, which currently assumes that the a each year starts on the first day of the week (i.e., the first value in the week array). Alright, I seriously have to get back to work now.

Awww, I was looking at rollover too. :P first thing I noticed lol.

List of fixes needed: Need to fix the timing of midnight/midday - 12.30pm lists as midnight and 12.30 am lists as midday. timer doesn't quite track right (copy of text below). This was using !minute 60 to advance an hour at a time, and it skips midday altogether. (From Chronos): Updating. (From Chronos):Wednesday, November 21, 10:32am. (From Chronos): Updating. (From Chronos):Wednesday, November 21, 11:32am. (From Chronos): Updating. (From Chronos):Wednesday, November 21, 1:32pm. and again at the other end of the scale, it doesnt quite do the math right. from 12.32 to 0.32. (From Chronos):Wednesday, November 21, 11:32pm. (From Chronos): Updating. (From Chronos):Wednesday, November 21, 12:32pm. (From Chronos): Updating. (From Chronos): Thursday, November 22, 0:32am. (From Chronos): Updating. (From Chronos): Thursday, November 22, 1:32am. (From Chronos): Updating. (From Chronos): Thursday, November 22, 2:32am.

Thanks -- my math was, um, not very accurate for determining am/pm. ;-) Fixed in gist.

all good, its the only thing I found that wasn't right (so far)

I didn't actually have much time to tinker over the weekend (and I keep getting the weird API bug where the editing window constantly scrolls back to the top, making working in the API annoying, to say the least), but I did get the basics for healing and burning torches integrated. I think this might be where it starts to get tricky, because I think that neither of you are using DCC rules, which differ enough from 3/3.5E (and a lot from 4E) that I'm still trying to figure out how to get the script to support both. 3.5 will be easier, as I think it's just a difference of how much healing happens with rest, although it's been long enough that I'm fuzzy on the exact mechanics. Right now, when the !day command is executed, the script grabs all the tokens on the player page, and then goes through their attributes, adding 1 for each day to every attribute that's both on the list (HP, Strength, Agility, Stamina etc. for DCC) if that attribute value is less than the max value. It's pretty crude -- I'd like to add some parameters for different types of resting -- i.e., in DCC 8 hours' sleep heals 1 point of HP/ability damage, while 24 hours bed rest heals 2 hp. So, I need to figure out how to make the type of healing configurable. Probably some combination of another array to be set -- [["NormalRest",1],["BedRest",2]] or something. Perhaps more useful to me, though, would be getting some kind of alarm or timer set. My game last night had several characters infected with disease and other effects that last for x turns, it would be really nice to be able to set a countdown timer and get a message when the time has elapsed. I'm kicking around a few ideas as to how to do this, but so far they all feel pretty clumsy. The copy in gist has my latest changes, feel free to throw ideas/suggestions/bugs my way, I'll be tinkering some more this week.

I use a game system that is very simplistic. It is a D&amp;D retroclone called bfrpg.

Ah, cool -- I just grabbed the PDF, healing is basically the same as in DCC, so it should more or less work without too much trouble. That'll give me a good test case.

cool.

ok, the bug? just reset your zoom level to 100%, it will fix itself. best way I can think of to make configurable timesets for healing is to actually have it pull functions for each systems methods of healing naturally, rather than trying to fix it so that it works out what healing is needed beforehand. Its a lot of coding back and forth, but it is probably the cleanest way I can think of to make it work, and it leaves you open to editing your scripts very easily, and of course, able to update and add new variations every time you want to expand your script. the thing with d20 healing is that you heal 1 hp/lvl and 1 ability score penalty if you are resting (only light activities and at least 8 hours of sleep) and 2 hp/level and 2 ability score penalties if you are on complete bedrest (doing NOTHING during the day beyond light reading and sleeping). Both of these are doubled if under the competent care of a trained healer. thats a few variables to factor in: charLVL = [*level of character*] heal.rest = 1*charLVL heal.restFull = 2*charLVL with another modifier set in the API command to double those figures if under care. then you would need to work both HP and possible Ability Score damage into the equations for healing (one reason I'd like to see if done with functions - easier to code in variations as we go that way), factoring in whether they are on bedrest and/or treated for the day, or if they have been properly treated during the time your timer ticks over. Possible, I know, but very difficult to manage in game. I propose an api command that cycles through the selected tokens and applies healing to it based on the DM's input, which then moves the timer along, rather than tracking the other way around (especially if you have been in a fight or been wounded at all you get no healing for that day, and thats even MORE things to keep track of on each character - again, still possible, but the micromanagement involved boggles even me, and I like Micromanagement, specially when its automated). Something along the lines of !rest [number of hours] [level of care; leave empty for none]; ie !rest 8 would give the selected tokens 8 hours of normal rest based on their level, and !rest 24 would give the 24 hour rest. !rest 8 -care and !rest 24 -care would would apply the relevant healing as if they had been under the care of a healer. (and - of course - turn your campaign timer down by the relevant amount of time specified of course.... EDIT: thinking about it an option to apply the rested time to the campaigns timer would be good - that way you could apply healing for time spent outside the main stream of time - I occasionally have the group separate and each doing their own thing, so forcing the time update wouldn't be the best way of doing that. Easier to put in an option on the API command like !rest 8 -care -notime so that your command searches for the tag -notime to see if Chronos needs to update (still love that btw, nice touch) I would also like to point out that I use mana points in my game and one hours rest gets you from under 3/4 your SP back up to 2/3rds total SP or from 1/2 your SP back up to 2/3rds, which would be nice, (ie !rest 1 would regenerate SP to its relevant level), and sometimes it would be good to have that not be added (caster uses magic, and then they declare they are stopping for lunch which takes an hour and you update the timer. then the wizard says, 'oh shit my spellpoints I forgot to regen them but its been two hours could you fix that please?' at the next encounter after that, and you click the rest button for him. I'd rather it not add another 2 hours for the 'rest' he got (travel time counts as rest, so long as its non-strenuous) in situations like that. for the countdown timer, have a look at <a href="https://app.roll20.net/forum/post/197725/script-conditions-and-status-tracker#post-389254" rel="nofollow">https://app.roll20.net/forum/post/197725/script-conditions-and-status-tracker#post-389254</a> it works - or it did - and it is easy to follow. With a bit of recoding it should be easy to take the basic code there and apply it to work with your time script, using your rounds and minutes to keep track of combat and if you contact him you could perhaps work out a way to integrate each others scripts with each other as they would synergise very well, so long as neither requires the other to work.

Great ideas, Michael. I'll definitely separate the commands to move the clock from the command to rest, and put a flag in for whether or not the resting/healing should move the clock. So, something like: !hour 8 = simply move the clock ahead 8 hours !rest 8h = move the clock 8 hours and apply system-specific healing rules !rest 8h -notime = apply 8 hours of healing but do not move the clock I'm still thinking about whether it will be better/easier to have the "care" flag as a parameter or another call (i.e. "!rest 8 -care" or "!care 8"), I'll see when I start refactoring. The countdown timer looks good, and shouldn't be too hard to modify to work with Chronos ... the main issue is that I haven't decided what to do about the round vs. minute issue, since combat rounds are usually some number of seconds, and Chronos doesn't keep track of anything less than a minute (and I'm not sure I want to add another layer of complexity just to keep track of seconds). I have something in mind but haven't tried it out yet. I'll post an update when I've had a chance to do some more work, maybe later tonight.

Depending on the specific game, the round is usually 6 or 10 seconds. Could you not set it up to divide the minute by that amount in the code? Just tossing out ideas. It sounds like a very good script.

Thats what I was thinking Metroknight. If you have the capability to measure rounds in a combat situation, (in 3.5 its 6 seconds for ten rounds in a minute, and in gurps each round is one second flat) then you can hook spell durations into it in a combat situation, but there is no need to actually record seconds into Chronos. Just keep track of rounds based on a end of round tracker in the init list and add a minute for every 10 (or sixty, or whatever the system uses) 'ticks' that it puts in for combat turns. Spells are kept track of in rounds, minutes or hours, so I don't see that as a problem (and its easy to add three lines or so to keep track of an end of turn tracker) if you just start a rounds counter at the start of every combat situation, and just clear it at the end of the encounter. and if a spell is counted in rounds, its only needed to be tracked for that encounter, generally. also, if you integrate the script I mentioned before, you have no need to actually code rounds or keep track of conditions with your script, it does a very good job of doing so itself (i use it in both my current campaigns), it just does not keep track of actual time passed, only rounds in combat (it uses ONLY the combat tracker to keep track of status effects, which is ok but not ideal). being able to hook it into this script would expand exponentially the quality of BOTH scripts, with only minimal work on both authors. right?

Finally had some free time last night to get back to this, new verison is in gist. I did a pretty massive overhaul after thinking about your suggestions. So first off, I went ahead and integrated chronos & the torch timer into one script, since I was calling the torch timer anyway & duplicating some functionality. I completely changed the chat commands, simplifying the handling (at least from a code perspective). Now it's all one command, "!chronos", which can take a comma-separated list of values for year, month etc. like so: "!chronos 1y,2m,3d,5h,6n" (using n for minutes was just simpler than coding for "mn" or something like that). It'll accept any combo of values -- "!chronos 1d,3h" or "!chronos 1n" and adjust the timer accordingly. It currently recognizes any parameters included at the end of the command after a "-", though it doesn't yet do anything with them. Also fixed a bug in the calculation of the chat output. So, no really new functionality, but this sets me up to be able to implement triggers for rest, rest with care, rest without moving the clock, etc. Next up, the actual handling for different timer/healer conditions.

Ok, this is where I would like to point out that I have a unique calender in my world, which your script does a great job of keeping track of. The only glitch, so to speak, is that I have 5 'holy days', spread throughout the year, that are not a part of any month and are themselves named based on their time of year, not as a part of a week (they lie between the days of the week, for instance, the month of Frayaver ends ending its week at kingsday( the final day of the week in my calender), and Winters-Break (the holy day) arrives. the day after that is the first day of the next week, (Godsday) of the next month (Marches). Basically, a way to add in a day like that would be good, though I can manually add it in as the game progresses (its a 365 day year. each week is 6 days, and there are 5 weeks in a month (thats 30 days), leaving five holy days that round out the year to completion.)

You can add "holy days," sort of, by adding them as an extra month with only one day in the month array. I.e., ['January',31],['Holy Day',1],['February',28]. This will still count it as a regular day of the week, though, and the chat display will look a little wonky -- "Holy Day 1, 6:00pm". The chat display will not be too hard to clean up, but skipping a day of the week will be trickier. I'll need to rewrite the way the day of the week is calculated - right now it's just based on a straightforward count of the days since year 0, day 1 - but I figured I'd need to fix that eventually anyway (there's a lot of stuff that I need to go back and clean up - you're seeing the sausage being made ;-). Then it's just a matter of adding an optional flag to the month array to indicate that a month shouldn't count towards regular day-of-week progression. I just hope you don't use leap years in your calendar. ;-)

nope.

just wondering how the script is going? its working perfectly for tracking time for my game (the players are now noticing the advancement of time in the game now that they can just type and get the date and time themselves). they are really starting to stress when things hold them up now. most recently a blizzard that snowed them in for three days in hostile (frost giant) territory when they had a meeting they were 4 days of travel away from. That alone makes this script worth it. and it also makes me want to integrate a weather roll into each day (a simple function call, easy enough to write, but I don't know what your script currently looks like) because its an easy roll to make, but I hate having to look up the tables for it (though generally roll 1d100 the bigger the worse it gets is good enough, I like the certainty of tables as a DM, seeing as they are constant and generally fair

I haven't used it yet as I just started up a live game and trying to get settled into it. Looks good so far.

Hey, I'm glad it's working for you! Trapped in a blizzard while the hours tick away sounds like some excellent tension. Kind of sounds like my life lately -- I've had all my free-time sucked up by other obligations while the script just sat there day after day. ;-) I had progress towards including resting and healing in the script before getting pulled away, though. It took a while because I wound up re-doing most of the way the script stores the current time values (using state properties instead of a character, which is just better practice, I think). Anyway, I uploaded the current version (which works, though it's not very well documented). You can now add parameters to the end of the !chronos command to turn on torch tracking and healing or bedrest: t for torches, r for rest (regulars healing, needs at least 8 hours), h for bedrest (needs at least 24 hours). I got bogged down in trying to code it to handle every possible variation of healing rules, but it should cover the basics. There's another array declared at the top to include the hours required & rate of healing for each type of rest (normal and bedrest). Hope that makes sense, I'll try to get to writing up better documentation this week. Oh, and I need to add some output to explain why no healing happens if you, e.g., try !chronos 4h -r (not enough time).

sounds good, more to play around with in my game (assuming the API is working today - had issues yesterday where it crashed even with NO scripts loaded at all)