Twine version 2.1.3 / Sugarcube 2.18.0
I've read the calendar/clock posts three dozen times. I'm confused where I'm messing up. StoryCaption displays properly.
My set up is this:
StoryInit:
<<set $now to new Date()>>
<<set $now to new Date("2017-06-26T06:00")>>
StoryCaption:
Date & Time: <span style="color:coral">$now</span>
In Passage in question:
<<if $work eq true>><<if $gameDate.getUTCHours() gte 16 and $gameDate.getUTCHours() lte 18>>
Go to work<<else>>Work is closed<</if>><</if>>
Error displayed upon testing:
Error: <<if>>: bad conditional expression in <<if>> clause: Cannot read property 'getUTCHours' of undefined
I have <<set $work to true>> set in the previous passage to the one with the issue and have verified variable is set.
I'd like to make it to where the individual can go to school but only during certain times.
Any assistance would be appreciated.
Thanks!
Comments
Which "calendar/clock posts" specifically? There are at least a few different threads which you could be referring to.
One oddity is that you're assigning two different Date objects to $now—back to back no less. The former assignment is overwritten by the latter.
Unless you have code that you haven't shown here, you haven't defined $gameDate anywhere, so that's why you're receiving that error. Perhaps you meant to use $now instead? I'm guessing this is a copy/paste issue.
Also, a tip—this has nothing to do with the above error. All conditional expressions ultimately reduce to a boolean value. If you have a boolean value to start with, there's no point in comparing it to the boolean literals. Just use it. For example:
You are initialising the $now variable twice in your b]StoryInit[/b] special passage when you only need the one of those two <<set>> macro calls. If you want the $variable to store the current date-time then use only the first <<set>> macro, if you want to assign the $now variable a particular date then only use the second <<set>> macro.
When testing is a variable equals either true or false you don't need to compare it's value against a Boolean literal, you can do the following instead.
The reason you are getting an undefined related error message is because you are trying to call the getUTCHours() function on the value stored within the $gameDate variable, but you haven't initialise a variable with that name in your StoryInit special passage. I suggest you change that <<if>> macro to use your $now variable instead.
Thanks for responses.
I don't know what "Please use the code tag—it's C on the editor bar—when posting code or markup." means. Where is the editor bar?
Additionally, I'm very new to coding (as I'm sure you can tell) and I'm referencing different time posts I guess. Whenever I use one, it doesn't work so I'm combining several. Probably not a good idea but it seems to almost work when combining more than one as individual ones do not work.
Do you have a suggestion as to which time usage is best?
I changed the coding per your suggestions and now "Go to school" shows up but it shows up regardless of time of day as if it's ignoring the time reference and only going on the boolean True/False.
Removed <<set $now to new Date()>> in Init passage.
Set: <<if $school>><<if $now.getUTCHours() gte 7 and $now.getUTCHours() lte 12>>Go to school<<else>>School is Closed<</if>><</if>> to new passage.
There is no 'best' solution, it all depends on what functionality you want your time system to have. You will need to describe that functionality to use so that we can make a recommendation on one of the existing methods, or give advice on how to design one to suit your needs.
The Date object you are storing within the $now variable is a static value and it will either contain the date-time at of the moment it was created if you use the first <<set>> in your original example, or it will contain the date-time you passed to the object if you use your second <<set>>.
The value of the Date object does not automatically change as time passes by, you need to manually update the object if you want it to change value. Again because I don't know exactly which "calendar/clock" code you are using I don't know what time-changing functionality it has built into it which means I can't give you a related example.
My story is set in two settings. The first one will be at home in which I want the player to be able to do a few things per day but eventually need to sleep.
My coding for the primary passage of that is:
An example of an offshoot is:
And that works well. When I go to do chores, my time advances 45 minutes and it adds 10 to my $money.
The primary issue I'm having is that in the first section, I'd like it be to where you can only go to school between 7am and noon but when you log in, I've set it to 6:30am starting time and GO TO SCHOOL is active and remains so until you click it.
That's the issue I'm having right now.
The secondary location of my story will require pregnancy and a timer to track that. I only bring that up as you needed to know my desires for "timing" to help advise of a good one to use.
Did I do better on providing the information you need to help me? I'm learning. Slow but steady.
Thanks again!
For example, the following—pulled from your initial examples—sets a local date/time because you didn't specify the timezone in the ISO 8601 timestamp:
If you're going to use the UTC methods, then you should always specify the date/time in UTC. There are a few ways to do that with ISO 8601 timestamps, the easiest of which is to append a Z after the seconds. For example:
In the end, it may be better to not use the UTC methods and to use a local timestamp, otherwise non-UTC players will see times that are off by their UTC offset when you simply print $now.
For example, instead of the UTC-based methods you're using now: The local time version would look like the following:
I'd like to have my school time end at 3:00pm regardless of when they go.
I'm using the version of time in my story.
How would I put in something into my School passage that would advance time to 3:00pm of the same day?
Is not the answer. lol
I did that because you are now using the non UTC based functions to access the individual components of the date-time, so it is now OK for the initial value to use the Reader's local time-zone.