Character Info Toolbox

Boesbert · Jul 20, 2016

Bale said:
I do not know why it is driving you bonkers. Perhaps you are experiencing something that we are not. The best way to figure this out would be to tell us WHY it is driving you bonkers.

There is a way for you to change it back, but I'd rather hear the details of your problem before I describe the procedure for altering the script to your liking.

heeheehee: Is there a way to make this optional?

It just scrolls back to nonsensical positions. I just upped the effect of empathy and of singer, and both times it scrolled to beer barrel polka. Not sure what the actual pattern here is, or why it is doing this. It wasn't doing this before this update.

xKiv · Jul 20, 2016

Well, jquery on scrollTop:

The vertical scroll position is the same as the number of pixels that are hidden from view above the scrollable area. If the scroll bar is at the very top, or if the element is not scrollable, this number will be 0.

The posted code stores scrollTop, but not when it is 0.
Then it restores scrollTop, but not where it was 0. (this probably shouldn't matter, since everything should *start* scrolled to the top)

It should restore scroll position by pixels, so if you add/remove buffs *above* the last scroll posiiton, it will scroll to a "different" place - a different buff will be at the visible top (than what was there before the reload).

xKiv · Jul 21, 2016

But what do you know, if I scroll all the way to the top, chit keeps scrolling back to the last stored position that isn't "all the way to the top" ...

ETA: probably because there was only one scrollable element, so it didn't store the (empty) map of scrolls, so the old (and now invalid) map stayed in localStorage.

heeheehee · Jul 21, 2016

Well, that's a simple enough fix. Just remove the check on Object.keys(scrolls).length -- the first block then becomes

Code:

$(window).unload(function () {
	var scrolls = {};
	$('div').each(function () {
		var scroll = $(this).scrollTop();
		if (scroll !== 0) {
			scrolls[$(this).attr('id')] = $(this).scrollTop();
		}
	});
	localStorage.setItem('chit.scroll', JSON.stringify(scrolls));
});

AlbinoRhino · Jul 21, 2016

Is there some reason not to just use sessionStorage ?

heeheehee · Jul 21, 2016

AlbinoRhino said:
Is there some reason not to just use sessionStorage ?

Not particularly, other than the fact that I tend to forget these things exist. Although, apparently sessionStorage is local to each page session, so it doesn't persist if you open a new tab.

Bale · Jul 21, 2016

Commited heeheehee's bugfix.

I think it would be better if the information expired with the page. Could one of you whip up that version?

AlbinoRhino · Jul 21, 2016

You would just replace "localStorage" with "sessionStorage" wherever you see it. I tend to use sessionStorage with all my personal javascripts for this game. However, I usually do everything in a single tab. It seems to me sessionStorage is associated with the browser address (in this case 127.0.0.1:*) so it's not immediately clear to me why it wouldn't be available to multiple tabs, as long as the original session is still active, but I can't say from personal experience that I've tried it either. About to log in, so I guess I can do some experimenting.

Bale · Jul 21, 2016

It does seem to work the way you describe even though you do not understand why. Committed.

heeheehee · Jul 21, 2016

I'm basing my comments on the bolded statement at the start of https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage. Presumably each tab is its own "top-level browsing context", since you shouldn't be able to directly interact between tabs; thus, any browser which allows sessionStorage to persist across tabs is not acting in accordance with the specification (https://html.spec.whatwg.org/multipage/webstorage.html#the-sessionstorage-attribute).

AlbinoRhino · Jul 21, 2016

From the specification you posted:

[FONT=&quot]Each [/FONT]top-level browsing context[FONT=&quot] has a unique set of session storage areas, one for each [/FONT]origin[FONT=&quot].

I know that when you're viewing storage with browser development consoles, it's always broken down by the origin. So a new tab shouldn't qualify as a new top-level context unless a new origin is associated with it. At least, that's my understanding of reading that.[/FONT]

heeheehee · Jul 21, 2016

Origins have nothing to do with browsing contexts, though. Yes, session storage is subdivided by origin. But you foremost have separate session storage areas for each tab.

For the most part, we see nested browsing contexts arise from using frames (inline or otherwise). The top-level context is bound to the window object of the tab/window. You can check this for yourself by setting something like window.name, then clicking around on navigation links. Or, the obvious thing to test, set something in session storage and watch as it doesn't persist across multiple tabs.

AlbinoRhino · Jul 21, 2016

So, it appears the browser tools don't update themselves when you change tabs (at least in chrome) and you in fact have to open a new instance for each tab. Who knew ? Not me ! lol

Bale · Aug 4, 2016

Code:

Commit r406:
Author: soolar121

If you have one of the usable floundry items equipped and haven't used it today, the gear picker will now have a link reminding you to use it.
------

Thanks, but if only you'd made that commit the day before yesterday it would have really helped me out. I lost several turns because of your slothfulness.

soolar · Aug 7, 2016

Bale said:
Code:

Commit r406: Author: soolar121 If you have one of the usable floundry items equipped and haven't used it today, the gear picker will now have a link reminding you to use it. ------

Thanks, but if only you'd made that commit the day before yesterday it would have really helped me out. I lost several turns because of your slothfulness.

Sounds like we had the same problem on the same day!

Bale · Aug 7, 2016

What a weird coincidence!

PS. Nice work lately, but what is up with chit.familiar.hiddengear? Why did you add such a feature?

soolar · Aug 7, 2016

One of my friends was complaining that the familiar gear picker gets really cluttered with things like the ant hoe/sickle/etc and other not-particularly-useful generic familiar items, and I feel the same way. That seemed like the simplest solution. I'm still thinking about other ways to make improvements there, though.

billybobfred · Aug 18, 2016

Unknown variable 'drunkGear' (chit_brickGear.ash, line 260)

That doesn't seem correct.

Bale · Aug 18, 2016

Wow. That bug only existed for seven minutes before I caught it. You really found the wrong time to update the script.

Anyway, it is working again so please update again.

Bale · Aug 18, 2016

In case people don't read the release notes (or don't understand them) I'd like to announce that soolar has recently added a rather nice new feature: A Source Terminal brick! Congratulate soolar for this rather nice feature.

The Source Terminal brick allows you to manage your source terminal skills from the charpane. (It doesn't handle enhance, extrude or enquiry, but those are much simpler to handle and mafia does a good job with them.) It is disabled by default so you'll need to add "terminal" to your layout to make use of it.

You can add the brick to your chit.roof.layout or chit.walls.layout for the full brick or if you can add it to chit.stats.layout for a miniature version.

For example:
zlib chit.roof.layout = character,stats,terminal
zlib chit.walls.layout = helpers,thrall,vykea,terminal,effects
zlib chit.stats.layout = muscle,myst,moxie|hp,mp,axel|mcd|trail,florist|terminal|gear

Please only add it to one of the above layout areas or else things get a little bit wonky!

Character Info Toolbox

Member

Active member

Active member

Developer

Active member

Developer

Minion

Active member

Minion

Developer

Active member

Developer

Active member

Minion

Member

Minion

Member

Member

Minion

Minion