PFRPG Time Manager

I don't know if I'm thinking wrong, but the events and alerts created should not be triggered with the time running, even if that time runs through a trip and I don't know if it would be possible to create a kind of a player for the watch allowing to pause and start the clock.
Example: I defined that my date is 08/15/1950 and it is 08:00 am when the campaign starts I play on the clock and the seconds start to run, if I travel, advance the time and things like the time the clock progresses and the event triggers and alerts appear on the screen the number of times the clock reaches the event and when the session ends the clock is paused, returning at the same time in the next session?

Are you referring to the idea of adding a real-time clock?
I have considered this but it doesn't really interest me as I can't imagine using it in game.
If this is something you're interested in adding you might want to look at the combat timer extension to see how they implemented a timer: https://www.fantasygrounds.com/forum...-%28v-0-0-1%29

If you do do that, you're welcome to contribute it back on the GitHub page.

Quote:

---

Originally Posted by RobboNJ69

Every 10 rounds the combat tracker resets to 0. Is that intended - I imagine so.

A second feature request/idea: enabling the message that tells you when an effect expires while using the time advance feature. A couple of players didn't realize their buffs wore off since they're used to seeing the message pop up in the chat window: "Effect ['Misc'] -> [EXPIRED] [on Xxxxxxx]"

---

1) Yes, unfortunately I couldn't think of a better way to avoid bugs with the automatic time adjustment based on elapsed rounds. I agree that it's not idea as it is nice to have that record of what round you're in in 20+ round combats (as rare as I find those to be). One thing that could be done is to add another rounds counter that counts the number of 10 rounds that elapse (and could be reset when clearing initiative). I have added this as issue [6] for future consideration.

2) Absolutely, I have been meaning to do this but keep forgetting to add it to the issues list. Thanks for the reminder! I have added it as issue [5].

Yes, I have this desire for a real time clock ... but the question is also why when I define an event | alert it is not triggered when I set up a trip?

Quote:

---

Originally Posted by yako2020

Yes, I have this desire for a real time clock ... but the question is also why when I define an event | alert it is not triggered when I set up a trip?

---

Not sure, I haven't messed around with that feature at all. Perhaps ask the original creator in the ClockAdjuster thread?
I have added that to my list of things to investigate when I have time but perhaps they will have an answer.

I already asked, before asking here but I didn't have an answer, I will stay tuned in both posts in the hope of a solution coming from one of the two :D

bmos,
Instead of resetting the round number to 0, could you instead start it at 1, and then in your test for the 10th round test for the nCurrent MOD 10 = 0 and then advance the minutes by 1?

current

Code:

---

                -- bmos resetting rounds and advancing time
                if nCurrent >= 10 then
                        local nMinutes = math.floor(nCurrent / 10)
                        nCurrent = nCurrent - (nMinutes * 10)
                        CalendarManager.adjustMinutes(nMinutes)
                        CalendarManager.outputTime()
                end
                -- end bmos resetting rounds and advancing time

---

proposal

Code:

---

                -- bmos resetting rounds and advancing time
                if (nCurrent % 10) = 0 then
                        CalendarManager.adjustMinutes(1)
                        CalendarManager.outputTime()
                end
                -- end bmos resetting rounds and advancing time

---

I think I have the lua coding correct.

I was not able yet to run a game in a year, so, no time yet to test the extensions; but for considering the round number: One might combine that with the thought that the flat-footed automation in the overlay package only works in round 0 :) (surprise round; though the historical reason behind this is that I always resetted with return which puts that number to 0 instead of 1 as when one would use the reset in the CT) So, depending on what type of reset you're discussing here, either 1 or 0 might be better in regards of that other automation :D

If we stick with starting at 0, then we would change the nCurrent % 10 = 9, such that it will add a minute in every 9th numbered round (every 10th round of combat).

combat traditionally starts at round zero, for surprise rounds :)