[X] My Assistant

The Monster Database (Rebuild)

The new rebuild monster database that stores all the monster data, and a better-designed webpage for querying monster (created by me, yay): [hv-monster.skk.moe] https://hv-monster.skk.moe/

HentaiVerse Monster Database UserScript

The userscript is used with the brand new monster database server!

(IMG:[img.shields.io] https://img.shields.io/npm/v/hv-monsterdb-userscript?style=flat-square#.png) [github.com] (IMG:[img.shields.io] https://img.shields.io/github/license/SukkaW/hv-monsterdb-userscript?style=flat-square#.png) [github.com] (IMG:[img.shields.io] https://img.shields.io/github/workflow/status/sukkaw/hv-monsterdb-userscript/Test?label=GitHub%20Action&style=flat-square#.png)

Download & Installation

 hv_monsterdb.es2020.user.js.txt ( 95.3k ) Number of downloads: 4083

 hv_monsterdb.es2016.user.js.txt ( 245.1k ) Number of downloads: 121


ES2020 version is for modern browsers. It is the preferred version.
Only use the ES2016 version if you are using the browsers with old engines (Pale Moon, SeaMonkey, etc.). This version is much slower because it has additional code to be compatible with those browsers.

You can also download the script from [unpkg.com] UNPKG.

Then install the script to your UserScript Manager.

Usage

There is nothing else you need to do! The script will handle everything for you!

• The script will update the local database from the server once a day, typically at the Dawn of a New Day and out of the battle.
• During the battle, the script will automatically show monster information on the page. All information comes from the local database, with no network requests to the database server involved.
• Every time you scan a monster, the script will automatically parse Battle Log, update the local database, and send the scan result to the server.

Please be aware that because the database is used for public purposes and because you probably appreciate seeing your own monsters appearing in it, it is everyone's duty to keep the monster database up to date by scanning them during battles (while using the script). If you intend to use the database without feeding it yourself, well... shame on you.

Script API

If you are a userscript writer or an advanced player, you might be interested in the [suka.js.org] API Documents.

Change Log & History versions

The full change log can be found on GitHub: [github.com] https://github.com/SukkaW/hv-monsterdb-user...er/CHANGELOG.md.

You can find history versions of the script at UNPKG [unpkg.com] UNPKG.

It is open-sourced!

The source code of the script is released on GitHub under MIT License. You can find the source code and the compile instruction at [github.com] https://github.com/SukkaW/hv-monsterdb-userscript

This post has been edited by OnceForAll: Mar 20 2022, 01:22

Monster Database UserScript Change Log

The full changelog can be found on GitHub: [github.com] https://github.com/SukkaW/hv-monsterdb-user...er/CHANGELOG.md
All history versions is avaliable on UNPKG: [unpkg.com] https://unpkg.com/browse/hv-monsterdb-users...pt@latest/dist/

2.0.0

A brand new version of the script!

- NOTICE: The script now drops the support for IE, Chrome < 79, Firefox < 60 (SeaMonkey is basically Firefox 60 so it is not affected), Safari < 11
- NOTICE: The old server is fading away. You have to update to this version in order to update your local data from the new server, and submit your scan to the new server.
- The script is now compatible with the Pale Moon and SeaMonkey (you still have to use `es2016` version of the script)
- The script now perfectly supports GreaseMonkey 3, for those who are using Pale Moon / SeaMonkey which doesn't have the latest UserScript Manager available.
- The script now uses Browser's IndexedDB to store the monster data. It is slower, but it allows the script to perform "atomization" updates, which means less write to your disk, extending your precious SSD life span.
- The script should do the migration automatically. If you encounter any issues, please report them to me.
- The old database server are fading away. I have completely rewritten the monster database server with brand new and much more lightweight architecture.
- Fixed a bug that the script will try to check if the Isekai has been reset even you are actually in the Persistent world.
- Fixed a bud that you can drag the floating information box out of your viewport. Now the information box will always stay in your viewport.
- Many performance improvements to keep your battle experience smooth. If you are interested in the technical details, here are the changes:

* Uses a statement library to make the UI reactive, and to make sure only re-render the UI when the data actually changes
* Rewritten UI in JSX, and use a brand new Virtual DOM library to further reduce the dom operations
* Merge multiple async calls into `Promise.all`
* Prefetching monster id from battle log whenever possible
* Add more keywords to the encoding dictionary, to reduce the storage usage

1.2.0
Thanks Necromusume, Quackytheduck and what_is_name for their bug reportings and suggestions! The full changelog of this version can be found on GitHub, link above.

- Change userscript `run-at` property to `document-idle` in order to fix some race condition caused by TamperMonkey & ViolentMonkey
- New feature `darkMode` which will use a dark theme for the float window (credits @raraha)
- Some ui improvements made by @indefined.
- Fix the width of the float window when `compactMonsterInfoBox` is enabled.
- The script is now able to detect the Isekai has been reset or not. And monsters in the Isekai will expire only once per season.
- Some performance improvements (Technical details if you are interested: Use virtual dom to minimize the dom operations, and fix some potential or rare memory leaks by preventing unnecessary object allocation).

1.1.0
Thanks Necromusume, sigo8 and what_is_name for their bug reportings and suggestions! The full changelog of this version can be found on GitHub, link above.

- New feature `highlightMonster`, which will highlight monsters where the name, id, class, attack matches
- New feature `compactMonsterInfoBox`, which will hide mitigation data in float window (only show trainer, PL, monster class) when enabled.
- `scanExpireDays` configuration is now ignored in Isekai (Monster won't get update inside Isekai so there is no need to re-scan)
- Fix a bug that Isekai monster data collision with Persistent monster data.
- Fix the compatibility with Monsterbation's `ajaxRound` (Firefox + TamperMonkey is still not supported, seems to be a bug on TamperMonkey side, still investigating)

1.0.1
Improve the compatibility of the ES5 version.

1.0.0
The initial version.

This post has been edited by OnceForAll: Mar 20 2022, 01:26

Reserved.

Awesome.
It’s a blessing to have you willing to contribute like this

nice idea, good news for players.

excellent!!

Issues when using Monsterbation:
"advance to next round using ajax" causes the Monster DB floating window to disappear when advancing to the next round (and advancing without ajax is much slower)

Issues with or without Monsterbation:
Scanning or imperiling a monster causes all the monsters to be listed twice in the floating window.

This post has been edited by Necromusume: Apr 12 2021, 22:33

Issues when using Monsterbation:
"advance to next round using ajax" causes the Monster DB floating window to disappear when advancing to the next round (and advancing without ajax is much slower)

Issues with or without Monsterbation:
Scanning or imperiling a monster causes all the monsters to be listed twice in the floating window.

That's strange. What browser and which version of the script do you use?

Tor Browser 10.0.15 (based on Mozilla Firefox 78.9.0esr) (64-bit)
and the ES2020 version.

According to [kangax.github.io] this table, FF 78 ESR should support all the ES2020 features.

Using tor browser without tor:
[www.ghacks.net] https://www.ghacks.net/2018/11/26/can-you-u...tor-connection/
Short version:
$ TOR_SKIP_LAUNCH=1 TOR_TRANSPROXY=1 ./start-tor-browser.desktop
and then network.dns.disabled -> false

This post has been edited by Necromusume: Apr 13 2021, 04:55

Tor Browser 10.0.15 (based on Mozilla Firefox 78.9.0esr) (64-bit)
and the ES2020 version.

According to [kangax.github.io] this table, FF 78 ESR should support all the ES2020 features.

I am testing the script on Firefox now, and I do find some race condition issues. Let me dig it through.

thanks for giving

Tor Browser 10.0.15 (based on Mozilla Firefox 78.9.0esr) (64-bit)
and the ES2020 version.

According to [kangax.github.io] this table, FF 78 ESR should support all the ES2020 features.

Using tor browser without tor:
[www.ghacks.net] https://www.ghacks.net/2018/11/26/can-you-u...tor-connection/
Short version:
$ TOR_SKIP_LAUNCH=1 TOR_TRANSPROXY=1 ./start-tor-browser.desktop
and then network.dns.disabled -> false

For the record, I can reproduce the issue on Firefox, and I do know what happened.

Monsterbation will dispatch the DOMContentLoaded event per round start, and my script does listen to the event to be compatible with the ajaxRound feature.

The problem is, TamperMonkey on Chromium-based browser tends to inject the userscript after the DOMContentLoaded event is fired. But TamperMonkey on Firefox will inject and execute the userscript after document.readyState property is changed, but before DOMContentLoaded event is fired. So if I invoke a function and then attach it to the DOMContentLoaded event, on Chromium-based browsers the function will be called only once, but on Firefox it will be called twice. That's why you see duplicate monster information in the floating window.

Monsterbation uses a tricky (but also dirty) way to solve it by adding an element to the DOM when the function is invoked, and the function will be able to check if the element already exists. I might have to use the same trick as well, if I don't come out with a better solution.

----------

Update

I have reported the issue to the Tampermonkey.

[github.com] https://github.com/Tampermonkey/tampermonkey/issues/1218

This post has been edited by OnceForAll: Apr 15 2021, 01:08

The problem is, TamperMonkey on Chromium-based browser tends to inject the userscript after the DOMContentLoaded event is fired. But TamperMonkey on Firefox will inject and execute the userscript after document.readyState property is changed, but before DOMContentLoaded event is fired. So if I invoke a function and then attach it to the DOMContentLoaded event, on Chromium-based browsers the function will be called only once, but on Firefox it will be called twice. That's why you see duplicate monster information in the floating window.

[developer.mozilla.org] https://developer.mozilla.org/en-US/docs/We...lready_complete
Add this to the start of the function callled on `DOMContentLoaded`.

CODE

  if(document.readyState === 'loading') {
    return;
  }

I noticed that you don't have any GM3 compatibly despite the fact you're distributing a version for older browsers and how trivial it is to add.

CODE

// @grant       GM.getValue
// @grant       GM_getValue
// @grant       GM.setValue
// @grant       GM_setValue

....

    async function getStoredValue(key) {
        if(typeof GM === 'undefined') {
            return GM_getValue(key);
        } else {
            return GM.getValue(key);
        }
    }
    async function setStoredValue(key, value) {
        if(typeof GM === 'undefined') {
            return GM_setValue(key);
        } else {
            return GM.setValue(key);
        }
    }

Written from memory and untested, but should work unless I messed up something silly.

Also you have deleteValue in you grants but don't use it.

[developer.mozilla.org] https://developer.mozilla.org/en-US/docs/We...lready_complete
Add this to the start of the function callled on `DOMContentLoaded`.

CODE

  if(document.readyState === 'loading') {
    return;
  }

Actually, the issue is caused by Tampermonkey buggy implementation. I have tried only bind event after window load event is fired (when the DOMContentLoaded event should already been fired):

CODE

window.addEventListener('load',() => {
  document.addEventListener('DOMContentLoaded', inBattle);
});

But it is not working either. The bug is already confirmed by Tampermonkey, see GitHub Issue here: [github.com] https://github.com/Tampermonkey/tampermonkey/issues/1218. According to its milestone, Tampermonkey will fix the issue in version 4.13. Fun fact: if Monsterbation does not use the "DOMContentLoaded" event in the "ajaxRound" feature (it can use a CustomEvent instead, just like its "battleEnd" event), I won't run into all this.

I noticed that you don't have any GM3 compatibly despite the fact you're distributing a version for older browsers and how trivial it is to add.

CODE

// @grant       GM.getValue
// @grant       GM_getValue
// @grant       GM.setValue
// @grant       GM_setValue

....

    async function getStoredValue(key) {
        if(typeof GM === 'undefined') {
            return GM_getValue(key);
        } else {
            return GM.getValue(key);
        }
    }
    async function setStoredValue(key, value) {
        if(typeof GM === 'undefined') {
            return GM_setValue(key);
        } else {
            return GM.setValue(key);
        }
    }

Written from memory and untested, but should work unless I messed up something silly.

The original idea is that although the browser might be outdated, the userscript manager might still up to date. I am going to include a polyfill in the ES5 build, as you wish (GreaseMonkey has implemented an "official" polyfill: [github.com] https://github.com/greasemonkey/gm4-polyfill ).

Also you have deleteValue in you grants but don't use it.

Actually, I do use the deleteValue in my code: [github.com] https://github.com/SukkaW/hv-monsterdb-user...c/util/store.ts . I declare the function and grant because it might be used in the future. Since the function "removeStoredValue" hasn't been used, the bundler (specifically I am using Rollup) tree-shaking it away from the produced code.

This post has been edited by OnceForAll: Apr 15 2021, 23:04

[hv-monster.skk.moe] https://hv-monster.skk.moe/

Suggest to hide the Trainer Monster Amount Toplist & Trainer Monster PL Toplist blocks for Isekai.

[hv-monster.skk.moe] https://hv-monster.skk.moe/

Suggest to hide the Trainer Monster Amount Toplist & Trainer Monster PL Toplist blocks for Isekai.

Make sense. Those two charts are now hidden for Isekai.

Status update.

Issues when using Monsterbation:
"advance to next round using ajax" causes the Monster DB floating window to disappear when advancing to the next round (and advancing without ajax is much slower)

I can't reproduce the issue on Chromium-based browsers, but I do reproduce it on Firefox ESR. I am still investigating the issue.

Issues with or without Monsterbation:
Scanning or imperiling a monster causes all the monsters to be listed twice in the floating window.

The issue has been solved (even with the current stable version of Tampermonkey which is known to have bugs) as I have ported an implementation from Monsterbation and can avoid such a race condition. The fix will be included in the next version: when "debug" is set to true, you can see the "Race condition of inBattle has been detected and mitigated!" message in the dev tools console.

This post has been edited by OnceForAll: Apr 27 2021, 23:45

The problem is, TamperMonkey on Chromium-based browser tends to inject the userscript after the DOMContentLoaded event is fired. But TamperMonkey on Firefox will inject and execute the userscript after document.readyState property is changed, but before DOMContentLoaded event is fired.
...

That's not really the problem is. The script Manager inject scripts in "Do Best" , the execute time is not reliable.

The really problem is, if the script run in sandbox mode and @run-at document-end, then TM will trigger a DOMContentLoaded event itself and block other DOMContentLoaded, it more like a feature than a bug. Simply remove the await before DOMContentLoaded listener in the release script you will see the problem happen in Chrome also (actually the await action make the listener add after load event). The bug you found is that in Firefox TM trigger this action even after load event, but it not that matter. To resolve it, just use the @run-at document-idle, it will inject after DOMContentLoaded handled and will not trigger or block other DOMContentLoaded event. I did used a custom eventname in my code to bypass it (the 'HVReload' that you don't know what is), but it not necessary

Monsterbation doesn't suffer from this problem actually, as it neither run in sandbox nor document-end, but as the inject time is not reliable, it always good to check and prevent double run


Some other bug or logic problem report:
- the last update time is shared by Presistent and Isekai, but only one of them will be update per day
- the exports API is available out of battle, but it return nothing whatever you call it (because the database is not load outside the battle. personally I would like the find method can be access if there is a option to turn it on
- should verify the monster name and MID before data show because the monster name is changeable. use the MID as premary key may be better. (but personally I would like the find by name method keep available in exports API

Other feature request or suggestion:
Personally I would say this script is useless. The database is good, but I dont think much player care about monster's Miti data, as it totally impossiable to change playstyle to against them. The datas show by this script is too much and too messy to find what I need in battle. Mostly I think player may only care the monster's trainer/plv/class, to make the script more useful, I would suggest:
- make option to show only some of compact data, like trainer/plv/class
- make the compact data embed in the monster panel instead of float. I would suggest to replace the monster icon with class(+a letter or number), replace the level with plv, and the trainer can be add after the name. use the :before/:after/attr css3 feature can make it easier maybe (suggest only
- make option to highlight monster if it match special condition, like plv=2250 or class=giant or trainer=me, etc. ( don't know if it forbidden although
- finally I would say it should have a setting storage, especially if the feature requests above are fulfilled. it's a bad idea that user should edit the script after every update, not to mention maintain a special branch only to change the setting.

- make option to highlight monster if it match special condition, like plv=2250 or class=giant or trainer=me, etc. ( don't know if it forbidden although

Monsterbation already did this - technically forbidden (parsing live data), but an exception was made so it's okay.

Some other bug or logic problem report:
- the last update time is shared by Presistent and Isekai, but only one of them will be update per day
- the exports API is available out of battle, but it return nothing whatever you call it (because the database is not load outside the battle. personally I would like the find method can be access if there is a option to turn it on

Noted. Will be fixed in the next version.

- should verify the monster name and MID before data show because the monster name is changeable. use the MID as premary key may be better. (but personally I would like the find by name method keep available in exports API

Unlike the monsterbation, the userscript is designed to be stateless. The mid is only available at the start of per round (in the battle log), while the monster name is always available in the DOM. That's why I design it like this.

- make the compact data embed in the monster panel instead of float.

Actually, I made it float because of Monsterbation's UI changing features. I personally love the Monsterbation's Effects Above Monsters, Vitals Above Monsters and Quickbar Besides Monsters. By making it float players can drag it to wherever they want.

That's also why I add those exported API: Monsterbation could utilize the API to show data as well. And there is an option in my script to disable highlight & floating window completely.

- make option to highlight monster if it match special condition, like plv=2250 or class=giant or trainer=me, etc.

Noted. It is a planned feature since the first day.

- finally I would say it should have a setting storage, especially if the feature requests above are fulfilled. it's a bad idea that user should edit the script after every update, not to mention maintain a special branch only to change the setting.

So far there are only limited options available. So I haven't decided to add a setting UI or not.

This post has been edited by OnceForAll: Apr 28 2021, 20:04