>Usefulness of automatically going to the latest update.
I guess where I'm coming from, as a guy with lots of free time and little life, I check the sight quite frequently and have a pretty good idea if a quest updated or not. So most times I'm clicking on a thread not to see if there's an update but to reply. So I had suggested that feature to save myself some clicks. It definitely would not be useful to someone who checks in ever few days or once a week.

>>29343
Do you use Watched Threads site feature?

>>29344
I do not. I keep forgetting that feature exists and notice the button to do so once in a blue moon.

>>29345
Well, the WT list provides the exact feature that you're looking for. Whenever anyone posts in a thread that you're watching, an alert is added next to a thread on the WT list. Clicking on the alert will take you to this new post.

The extension recognizes this and shows you the update containing the post that you're trying to see, which in this case would be the last update.

>>29346
Good to know! I"m still very much learning this site, so a lot of my suggestions will be from the perspective of someone only aware of half the features.
Case in point, since I didn't see much activity on /meep here, I mostly ignored it. So in actually reading the first pinned post and finding out that it's actually another extension and not general site updates. Imagine that!
Basically, take anything I say with a grain of salt, but I will still try to note any bugs I find.

This is a really nice extension, especially for reading through completed threads.

I do have a suggestion for full thread mode: only expand images after the most recently viewed update. That way it wouldn't waste time and bandwidth expanding all the images in the thread, when you only want to see the latest update.


>>29338
>I'd love to add this, but I don't have a database of which threads belong to which quests. As of this moment, the site hosts 3940 quest threads, so it would be quite a job to organize them all.

Well, that data has already been organized. You'd just have to scrape it from the Wiki. Still a lot of work just to add a next thread button though.

>>29348
>only expand images after the most recently viewed update
Done. Actually, I made it even better. It will now only expand the current and the next image, and will expand images on-the-fly as you scroll up or down.

The only problem is that I had to disable smooth scrolling when navigating up using buttons/hotkeys. That's because if the scrolling up was smooth, it would bug out due to images changing sizes while scrolling, causing it to scroll to a wrong location.

Among other things, I also added a new feature. The tab title, which up until now always showed the board name (eg. "Quests"), will now show the quest title instead.

>Well, that data has already been organized. You'd just have to scrape it from the Wiki.
Adding a button is simple. The problem is the data. Some quests have a lot of threads, with various timelines and settings, which may be entirely unconnected. For instance, https://tgchan.org/wiki/AsteroidQuest you can't easily determine which threads is next simply going by the thread list. And you even have NSFW threads mixed with SFW ones. Well, I'll see what I can do.

naileD 2019/08/18(Sun)15:21 No. 29351 ID: 3e9573
File 156616690852.png - (81.70KB , 750x750 , 9wikilink.png )

Link to quest's wiki
A quest reader may sometimes find that a thread does not provide easy access to its own wiki article. They may find it convenient to always have such a link available without having to do any searching.

The extension adds a link to a quest's wiki article to the top and the bottom right of the page. It accomplishes this by searching the wiki for the thread ID and enables the links if the correct article is found.

(I had to do a whole lot of scraping, checking what redirects where and whatnot, and correct a whole bunch of stuff in the wiki, but I'm now happy to report that pretty much all of the current ~3950 quest threads can be found. There's still some corrections to be done, but this is mostly due to problems in the wiki.)

naileD 2019/08/18(Sun)15:22 No. 29352 ID: 3e9573
File 156616696789.png - (65.48KB , 974x600 , 10questdislink.png )

Link to quest's discussion thread
A quest reader may find it convenient to have quick and easy access to a quest's discussion thread.

Similar to the previous feature, the extension adds a link to the quest's latest discussion thread, if it can be found in the wiki.

naileD 2019/08/18(Sun)15:24 No. 29353 ID: 3e9573
File 156616705122.png - (302.17KB , 1500x750 , 11selectthread.png )

Navigate between quest's threads
A quest reader may wish to navigate between the threads that belong to the quest that they're viewing.

The extension adds a dropdown menu, where each (properly titled) option represents one of the quest's threads. Changing the selected thread will cause the browser to navigate to the newly selected thread.

It's like magic.

naileD 2019/08/18(Sun)15:25 No. 29354 ID: 3e9573
File 156616712681.png - (154.05KB , 750x750 , 12titles.png )

Show quest's title and author in tab title
When a quest reader has a lot of quests open in browser tabs, it becomes important for them to be able to differentiate between them. Up until now, the tabs were titled by the board names. If a tab contains a quest thread, it would be convenient to show the quest's title and author instead.

The extension changes the title of the tab in the browser to the quest's title. Similarly, it changes the title element at the top of the thread. The priority is given to the Subject element of the OP post, however the extension will still search the wiki to find the author's name.

Hey, thanks for the update! Glad for the ability to move between threads.

Some bugs: Still experiencing the bug that brings you to the middle image when navigating to the next update sequence. Can't replicate it when I encounter it, but I have noticed that the last two times it has happened to me that a lot of the posts were saged. There was a gif involved in the second instance, and I can't remember for the first.

The second problem I've encountered is that when going to the latest update in a quest through a link on the discord, it doesn't register as me seeing that latest update. Thus, when I refresh the page (which I do to see if people have already made suggestions) it brings me to the previous update as if that was the last one I saw and not the update I was linked to.

Thanks for all the work that you're putting into this though!

>>29355
You're welcome!

Ok, I managed to fix both bugs. You can update and they will be gone.

Man, it took me a while to figure out this scroll bug. You're using Firefox, right? This bug only affects Firefox (66.0+) because it has internal bugs in the way it implemented scroll anchoring. But yeah, I managed to solve it.

I also did a lot of wiki editing so that all the quests can be found, plus inserted all the missing discussion threads in there.

Maybe a way to adjust the size and/or res the images expand to?

When opening a quest thread with a saved position, the page doesn't always scroll to the correct position. I think it's a issue with the page scrolling before the images are done loading.It doesn't seem happen on recently opened threads, probably because the images are still cached.

>>29357
This is pretty much the next feature I was going to add. That is, the ability for the user to manually set the size limits to which the images expand.
Also, the ability to stretch the images to this size if they're smaller than that limit.

>>29358
Try updating now (version 11) and tell me if the problem is still there.

>>29359
Nope. I'm using Firefox, if I clear the cache then try opening a thread, it will only scroll part of the way down on longer threads.



Also, the navigation buttons are greyed out when viewing the first image of a thread in this version.

>>29360
Ah, thanks for catching that. Both bugs should now hopefully be fixed.

naileD 2019/08/28(Wed)01:02 No. 29366 ID: 18f1c5
File 156697933624.png - (290.29KB , 1500x750 , 13replyformstyle.png )

Changing the Reply form style
A reader may find the default design of the Reply form annoying for various reasons. The inconsistent length of the fields, fields not functioning as expected, fields not functioning at all, confusing placement of the elements, to name a few, may be some of the design features that a reader would wish improved upon for a better experience.

The extension changes the way the Reply form looks. It changes the following things:
- It removes the first column which contained text field names. Instead, it uses placeholder text to describe what each field is
- It adds a "Reply form" header with two icons in the top right. The left icon minimizes the form (Basically, the "Hide form" button from the initial features). The right icon... more on that in the following post.
- It signifies that the empty Name field will result in a default name of "Suggestion"
- It renames the Email field into Options, so someone doesn't accidentally input their actual email address there
- It moves the Reply button to the bottom right, where a user would usually expect to find it
- It removes the "(reply to ######)" text. We already know that we're replying to the thread if we have the thread open
- It hides the info in the bottom bullets and instead shows it when hovering cursor over a new * element to the left of Spoiler checkbox.
- It hides the Embed field. That field doesn't even work.
- It adds a ? element, which shows "Password for post and file deletion" tooltip when hovering cursor over it, while removing the original text next to the password field

Hmm. Maybe I should simply have put "Suggestion" as a placeholder text for the Name field. Or "Suggestion (default name)" would be better. Anyway, the changes to the Reply form are hard-coded for now. If someone doesn't like the new look of the Reply form, please say so, and I'll either make it a setting or fix the problems you have with it.

I also plan on adding a few additional changes. For instance, I want to hide the Options field and add a "sage" button, and a "dice" button instead.

naileD 2019/08/28(Wed)01:03 No. 29367 ID: 18f1c5
File 156697938310.png - (192.14KB , 1500x750 , 14replyformpopout.png )

Floating Reply form
When a user is writing a reply, they may find it more convenient to have the Reply form hover on the screen, next to the post(s) they're replying to, instead of it having a fixed position on either top or the bottom of the page, especially when the distance between the post(s) and the reply form is large.

The extension adds an icon in the top right corner of the header of the Reply form. Clicking on this button pops out the Reply form and makes it float on the screen. When the Reply form is in the floating mode, the header serves as a drag handle, so it's possible to move the form around.
Lastly, the Reply form will become transparent or opaque, depending on whether the mouse cursor is over of it, and whether one of the input fields has focus.

I'm not sure if the transparency is helpful or just annoying. May need some feedback on this.

naileD 2019/08/28(Wed)01:04 No. 29368 ID: 18f1c5
File 156697949637.png - (172.26KB , 1500x750 , 15imagesizelimits.png )

Custom image size limits
A quest reader may prefer to set their own size limits to images when they're expanded.

The extension now has a new Image settings section. This section contains two new settings, the "Max image width", and "Max image height", which control the maximum percentage of the browser window the expanded images are limited to.

Note that 100% isn't the actual width of the screen, but about 50 pixels less. This is so that the offset to the right of the image matches the offset to the left of it.

naileD 2019/08/28(Wed)01:06 No. 29369 ID: 18f1c5
File 156697961438.png - (118.39KB , 1500x750 , 16stretchimages.png )

Stretching small images
A quest reader with a large screen may prefer to have small images stretched beyond their intrinsic resolution so that they're easier to see.

The extension adds a new setting called "Force fit images" to the Image settings. Enabling this setting will cause the images to stretch beyond their resolution to try to fit an image container. The size of the image container is defined by the "Image container width" and "Image container height" settings.

This is kinda problematic because I can stretch an image to a certain width, or I can stretch it to a certain height, but I can't easily stretch it to both a width and a height while keeping image's aspect ratio. A simple solution that I found is that I can fit an image to a certain container, but then this container will usually have empty space in one of the dimensions. I could make it work so that there would be no empty space, but it wouldn't be very simple~ so I'll wait and see if there's any demand for that first.

I've noticed the tweaks to the reply box. I quite like them. I haven't tried having it hover, but I'll try to give it a try in the future and see how it feels.

Bit of a bug, similar to what I was experiencing before. >>29355
This time, however, it moves me to the previous update instead of the latest one when I post a reply. Same thing happened when I updated my own quest. It moved me to the previous update and not the one I just posted.

I will confirm I am using firefox, just in case that's relevant again.

>>29371
>when going to the latest update in a quest through a link on the discord
- Fixed so that when opening a thread with a hash, the stored update position is discarded and replaced with the one that contains the post that is linked.

>when I updated my own quest it moved me to the previous update
Hmm, I haven't thought of that. That is, if you, as the Quest Author, make a post, then that would usually create a new update. So after a refresh, the current position would stay the same while the total amount of updates would increase, causing the current position to no longer be the last.

The way I see it, if you're a normal suggester, and you make a post, then it's a correct behavior that the current position doesn't increase. After all, it's important for a suggester to notice that a new update was posted while they were writing their post.
On the other hand, if you're the Quest Author, then you would obviously want to be automatically moved to the last update, as you would already know that your own post would create a new update.

- Fixed
When clicking on the Reply button, the extension will now check the Name field in the Reply form and compare it with all the names/IDs that the author used. If they match, it should know that you're the author, and it will automatically move you to the last update after a refresh. Now, I wasn't able to test this functionality entirely, since I'm not an author any quests, so please update and tell me if it works correctly.

naileD 2019/08/30(Fri)14:16 No. 29375 ID: 18f1c5
File 156719980395.png - (144.60KB , 1500x750 , 17postreferences.png )

Show post references (AKA backlinks)
When a quest reader is also a suggester, it may be hard to find which exact posts are replying to the reader's own posts.

The extension adds a set of links underneath each post. Each of the links points to a post that contains a reference (link) to the said post, allowing for a quick and easy way to see if a post got any replies or was referenced for any other reason. This is a standard imageboard feature which seems to be missing on this imageboard.

The extension also adds a setting that controls whether these links should be shown or not. Or only for non-update posts.
Considering suggesters usually reference update posts for no reason, or rather, that referencing the last update post is already implicit, it doesn't make much sense to show these links in update posts. That's why the default value for this setting is "For non-update posts".

The question that I have is, what would be a good title for these link sets? "Links:", "Linked in:", "Linked from:", "Backlinks:", "References:", "Referenced in:" "Replies:"(current), etc. I can't quite decide heh.

>>29373
Seems to work, at least for a single image update. I'll keep an eye out if anything wonky happens with multi-images and saging.

>>29375
I prefer Replies. While not always accurate, it's succinct and a bit more intuitive to it's nature than something like 'backlinks'

Did someone just try to necro rapequest?

naileD 2019/09/01(Sun)05:00 No. 29378 ID: b3c4cf
File 156733925207.png - (192.58KB , 1500x750 , 18speed.png )

Speed
A quest reader may find the loading times of quest threads inconvenient, especially when the threads get large.

The extension now decreases the time it takes to load a quest thread, especially when using a paged view mode.
That's right, loading quest threads is now faster with the extension than without.

Loading time decrease:
Whole thread: 15%
Paged view: 66%
Measurements done in Chrome when viewing a quest thread with 2000 posts.

The extension accomplishes this by starting up earlier in the page loading process and hiding the whole page until it's done processing the posts. This eliminates the need to render elements which the extension was going to hide anyway. Unfortunately, the loading of thumbnails still happens in the background. There's no way to prevent that from my side.

>>29377
The choice of quest threads used in examples is arbitrary. I'm open for recommendations tho.

>>29367
Been giving this a try. Been handy in checking the spelling of characters names and when thinking of responses to particular posts in an update. Not very useful though when viewing a quest by post or even by sequence if the update and suggestions are low enough, But I guess that's why it's optional :P

The only minor thing is that it only goes transparent if you've clicked off of it, I find. So if you've moved it over something you have to move your mouse off the reply box and click. Might not be a bad thing? But i figure I should bring it up anyways.

>>29373
Also, updated my quest with multiple images and one saged. Problem seems to be fixed on my end.

>>29381
>if the update and suggestions are low enough
Yeah, it's mostly useful in the whole thread view, or when the update has a lot of suggestions.

The real benefit of it is in the handling of the Insert ID links.
As you know, in the header of any post, there's No. 123456 text. The No. part is a perma link, while the 123456 part is an "Insert ID link". Clicking on the Insert ID link inserts the >>123456 text into the message box. I always found clicking on these links to be super annoying because clicking on it scrolls you all the way to the top of the page, where I then have to scroll all the way back to the post to see what I was going to write.
With a floating Reply form, no disrupting scrolling ever happens, which is nice.

In fact, I just added a new feature. For the "Reply form" setting there's now a new option: Auto-float. Choosing this setting will cause the Reply form to be hidden by default. However, clicking on any of the Insert ID links, or the "Reply" link at the bottom, will call up an already-floating Reply form. This saves you from having to first scroll to the top/bottom and click on the form's popout button.
Hmm. I feel that this setting should be the default.

>it only goes transparent if you've clicked off of it
I'm glad you noticed this. Yeah, the form is opaque if any of the textboxes in there have focus.
This is intentional because when someone wants to write some text, they will usually move the cursor away so that it isn't in the way of writing. It would be quite bothersome if they had to keep the cursor inside the reply form the whole time.
So yeah, once you've clicked on the reply form, you have to click off of it to make it transparent. Perhaps it would be better if it was simply opaque all the time?

>Problem seems to be fixed
Good. Of course, as I develop the extension further, new bugs will pop up, either for the new or the old features, so be on the lookout :P

naileD 2019/09/11(Wed)18:44 No. 29389 ID: b3c4cf
File 156825265190.png - (106.91KB , 750x750 , 19analytics.png )

Analytics features

The extension now has 4 additional Analytics settings:
- Color suggester IDs
- Show user post counts
- Show per-user nav
- Show multi-posts

These features are primarily meant for quest authors. They used to be in my other extensions (>>28635), but I carried them over so that the other extensions can be removed.

Color suggester IDs
By turning on this setting, the background color of suggester IDs is changed.

When suggesters are anonymous, the only way to distinguish them is by reading their IDs (or by using the Pony theme). If the suggester IDs are colored, a single glance becomes enough to recognize who's who, which, in theory, is faster than reading text. Of course, this can also be distracting, which is why it's a setting. Hmm. Maybe a better solution would be to generate some icons for every user instead. Just not pony icons.

Show user post counts
By turning on this setting, a number appears to the right of every user ID. This number represents the user's post count in the thread. If the user is new, that is, if they only made posts in a single update, the number will turn red, eg.(1).

This feature makes it easier to distinguish between new and old suggesters. Also, it can be used to quickly spot any votestuffing.

Show per-user navigation
By turning on this setting, two buttons appear to the right of every user ID. If enabled, the left button (up arrows) will navigate to the user's previous post, while the right button (down arrows) will navigate to the user's next post.

This feature makes it easy to move between a user's (or your own) posts. This can be useful for a variety of reasons.

Show multi-posts
By turning on this setting, a red-colored text post X/Y will appear next to posts of suggesters that made more than one suggestion for the update. The number X represents the post index and Y the total number of posts. So if a suggester posts two suggestions in an update, the first one will get "post 1/2" and the second one "post 2/2".

This feature makes it convenient for quest authors to spot which suggesters made multiple posts for the update. By using the per-poster navigation, they can then move between such posts so they can easily decide which one of the suggester's multiple suggestions they should take into account.

>>29389
Been loving the colour IDs. Been putting that setting on in a lot of the quests I follow. Just always nice to know who's who. I've also been using the user post count for my own quest. It's a nice addition.

Haven't used the other two features, but I could see them helping to parse through things.

I should also mention I haven't encountered new bugs, but I also haven't been playing around with the settings as much.

When scrolling in thread view, images in multi image updates don't expand until they're half way up the screen.

naileD 2019/09/20(Fri)10:02 No. 29393 ID: a13082
File 156899894211.png - (139.93KB , 1500x750 , 20time.png )

Change timezone and format
The server currently uses Pacific Time (PST/PDT) timezone for all post timestamps. A quest reader who is not in the server's timezone may prefer to have these times converted to their own timezone, or use a relative time format, making it easier for them to figure out when exactly a post was made.

The extension adds a new setting called Timestamp format. This setting controls the way in which post timestamps are displayed.
The setting options include:
- Server time: Leave post timestamps as they are.
- Local time: Convert post timestamps to browser's local timezone.
- Relative to now: Show how much time has passed since the post was made to right now.
- Auto: Show relative time if the post was made less than a day ago, otherwise show local time.
- Hidden: Hide post timestamps. If you're simply reading a quest, do you even need to know when exactly posts were made?

The extension now also allows the user to click on post timestamps to quickly switch between relative and absolute time.

I also thought about adding a "Relative to update" option, which would show how much time has passed between a suggestion and the update it was made for, but I dunno if anyone would find that useful.

>>29392
Is it better now?

>>29394
Yes, images are expanding properly now. Thanks for the update.

Some fixes and optimizations:
- The extension will now remember the wiki page for the quest. It will also use the browser's session storage to remember wiki data. This way the wiki won't get hammered no matter how much you're refreshing the quest hehe.
- The site has a bug in the Watched Threads list where the "X New Posts" link takes you to the wrong post; it takes you to the last read post instead of the first unread post. If a quest is updated, this bug causes you to visit the post before the last update (effectively showing the wrong update in a paged view mode) instead of the last update itself. I implemented a workaround for this bug: If the page is loaded where the #hashed post ID is the last suggestion for an update, it will show the next update instead.
- Added tooltips for all the settings
- When the "Force fit images" is enabled, the container will no longer have vertical empty space. Horizontal empty space still remains a problem, however.
- Other small fixes

Stuff I'm working on next:
- Have the extension function in all the threads, not just quest threads, plus the board thread list. Albeit with quest-related settings disabled.
- Add a button to replay animated gif's

Stuff I'm thinking about:
- Stretch thumbnails to full image sizes in the Whole Thread view mode if expand images is enabled. That way the layout wouldn't jump around anymore as the images expand on the fly. Instead, a blurry image (stretched thumbnail) would simply be replaced by a non-blurry one.

>Button to replay gif's

That'll be nice. I know there's been a couple times reading a thread and the author's added a "blink and you'll miss it" shock or clue in a gif, but the gif's been long played by the time I get to it.

I'm guessing you're working on updating to the new site name?
Cause holy shit is this awesome, this real needs to be a native part of the site.

This is an awsome script!

I always wanted to do something similar with reading out the wiki and making threads and important posts more accessable...
But I always were a bit short on time and energy during the last years...

I think you did a really great job at this.
Also nice that it is compatible "questden-BLICK".
reply form and post rescaling fits nicely with your script in my opinion.

Also, if you use tgchanquestden-BLICK's "View image by Hover" feature, you can restart .gif animations every time you hover over an image ;)
I think, I did it by changing the img.src to a different picture shortly. That way the gif is started again after setting the img.src to it.

I updated the extension to reflect the new name. I also fixed a bug that I introduced with the last update where links to quest's other threads weren't being generated properly. Unfortunately, this is all I can show for now as the development has stalled D:

>>29419
Thanks! Due to the lack of feedback, I haven't had much of an incentive to work on this lately (well, I've also been busy with work) so it feels good that the extension is useful to you.

>>29421
>This is an awesome script!
Thanks a lot! I think your script can be very useful as well.

>nice that it is compatible
Some of your delform CSS selectors were giving me a headache haha

>tgchanquestden-BLICK's
It's funny how a long time ago I predicted that this site would eventually get renamed. So I chose an extension name that didn't depend on the site name.

>you can restart .gif animations every time you hover over an image
I know but, the mouse hover isn't as convenient as having images simply expand on their own. Also, the same can be accomplished by opening the image in a new tab. The problem that I'm having is finding a way to determine which gif file is animated and which one is not.

>>29423
> restart/detect animated gif
Sorry, if I wasn't clear. To restart, you can quickly replace the src attribute with some other valid image.

This works with animated and non-animated images, so you wouldn't need to check if it's animated.

To display some tag for animated gifs... I heard there are some libraries in npm that can be "browserfied", but never did that...
Someone also made a function that counts frameheaders, but I also did not try this: https://gist.github.com/lakenen/3012623

> painful css selectors
Sorry, I get a bit lazy sometimes. ^^

> not working at +50/+100 pages
I disabled the code-section and the code seemed to work fine. Is there a reason why you prohibit it from running on +50/100 pages? I didn't look in detail. ^^

>>29429
Thanks for the link. That's what I was looking for. I know the src trick, but I'd only want that feature to be active for the animated gif's, not the non-animated ones.

>why you prohibit it from running on +50/100 pages?
As I explained here >>29338
>The extension needs to "see" the whole thread to be able to properly determine which posts are updates. Also, if it doesn't see the whole thread, then it cannot navigate to the start, the position cannot be re/stored properly, and various other bugs would be had.
The fact that it worked fine in that case was simply a coincidence hehe.
I could make it work with background loading of the full thread I suppose. Do you think it's important for this extension to work on the last 50/100 pages?

Safety First ( https://questden.org/kusaba/quest/res/933892.html ) is linking to the wrong Wiki and discussion pages.

>>29451
Fixed.

naileD 2020/01/14(Tue)13:08 No. 29488 ID: 404f0f
File 157903611645.png - (177.39KB , 750x750 , 21discussion.png )

Link to last visited quest thread
A quest reader may find it convenient to have a way to quickly navigate back to quest from the quest's discussion thread.

When visiting a quest's discussion thread, the extension will now show a link to the last visited quest thread, provided the user visited one before. This also works if the discussion thread is shared between multiple quests.


Other changes:
- The extension now works on all boards
The extension now works in all board threads (it doesn't work for thread lists yet), not just quest boards. So for instance, you can now visit /draw/ threads and use the extension's image settings to be able to scroll through art more conveniently.

- The "Navigate between quest's threads" feature was extended to work in discussion threads
When viewing a quest's discussion thread, the dropdown menu to navigate to a different thread will feature all of the quest's threads, not just the ones in the same thread group. In case the discussion thread is shared among multiple quests, this dropdown menu will list all the quests and all their threads.

- The "Link to quest's wiki" feature was extended to work in discussion threads
When viewing a quest's discussion thread, a link to quest's wiki will now be available. In case the discussion thread is shared among multiple quests, the link will instead point to the list of the quests. Hmm, maybe it would be better to simply point to the wiki of the last visited quest in this case.

Just stopping by to say thanks and to bump it up past the dead threads getting necro'd by spambots

Previews when hovering over a link seem to be broken on Firefox.

>>29771
Ok, should be fixed now.