[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!

[github.com] [github.com]

Download & Installation

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

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


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, 07:22

Actually, I made it flow 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 flow 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.

In my case, there is no comfortable place to put the flow info panel to, and it's difficult to quickly map datas what I want to the monster, this result the info panel being useless. The feature I want is to only show some of key values instead of all Miti datas (in option). Embed (replace) data into the monster panel is also good option I think. As it directly modify the monster Element so the Monsterbation's UI changing features won't result problem. In your design, maybe just provide a option that not to show Miti data in flow panel is better than show all of them, that could make the UI more clearly.
I make a example UI for both solution, the embeded infos are using the CSS pseudo-element

As here is a new standalone monster info script, I think Monsterbation is not likely to add new monster info function to it. I can write a small script to implement this function myself by using the exported API, but it won't change the usefulness of this script, as not much user like to install mutiple script only to get one additional feature. but maybe I will do it myself one day if this feature is not going to implement

This post has been edited by what_is_name: Apr 28 2021, 23:38

In my case, there is no comfortable place to put the flow info panel to, and it's difficult to quickly map datas what I want to the monster, this result the info panel being useless. The feature I want is to only show some of key values instead of all Miti datas (in option). Embed (replace) data into the monster panel is also good option I think. As it directly modify the monster Element so the Monsterbation's UI changing features won't result problem. In your design, maybe just provide a option that not to show Miti data in flow panel is better than show all of them, that could make the UI more clearly.
I make a example UI for both solution, the embeded infos are using the CSS pseudo-element

As here is a new standalone monster info script, I think Monsterbation is not likely to add new monster info function to it. I can write a small script to implement this function myself by using the exported API, but it won't change the usefulness of this script, as not much user like to install mutiple script only to get one additional feature. but maybe I will do it myself one day if this feature is not going to implement

I see. It could be a very exciting feature.

I will implement the "compact" option first, then the pseudo-element option (I don't know if Monsterbation will add any other changes in the monster element in the future, so I tend to limit my DOM modification in the standalone floating window).

v1.1.0 is now released! Thanks Necromusume, sigo8 and what_is_name for their bug reportings and suggestions!

This post has been edited by OnceForAll: May 24 2021, 04:54

Feture request (website):
can we have a chart like this

not sure if the range filter can be implement but it may be useful

and about the Firefox + TamperMonkey problem, don't know if because my explain too chaos to read or you have other plan to resolve it, I will try to explain detaily:

In short:
- to resolve this problem, just change @run-at `document-end` to `document-idle` is fine
- add and check special element is not necessary, if you want to prevent double run cause by native DOMContentLoaded event, just check the event.isTrusted

To prove my saying, here is a short test code:

CODE

// ==UserScript==
// @name         test DOMContentLoaded
// @include      http://example.com/
// @run-at       document-end
// @grant        unsafeWindow
// ==/UserScript==
(async function() {
    'use strict';
    console.log('document state:', document.readyState);
    window.addEventListener('load', showEvent);
    //await 1;
    document.addEventListener('DOMContentLoaded', showEvent);

    setInterval(()=>document.dispatchEvent(new Event('DOMContentLoaded')), 1000);

    function showEvent(ev) {
        switch(ev.isTrusted) {
            case true:
                console.log('broswer native event:', ev.type);
                break;
            case false:
                console.log('script trigger event:', ev.type);
                break;
            case undefined:
                console.log('TM trigger event:', ev.type);
                break;
        }
    }
})();

- Running this code in TamperMonkey will always get DOMContentLoaded triggered by TM only, no DOMContentLoaded triggered by script will be catch, no matter on Chrome or Firefox and TamperMonkey 4.12 or 4.13
- if you change the document-end to document-start, sometimes you get broswer native DOMContentLoaded + DOMContentLoaded triggered by script, sometimes get DOMContentLoaded triggered by TM only, depend on the document readyState
- if you change the document-end to document-idle, then you always get DOMContentLoaded triggered by script only

that's what the really problem is, TM trigger the DOMContentLoaded by itself and block other DOMContentLoaded in special condition, and that's definely intentional behavior, so I said it more like feature than bug. use document-idle can simply avoid this behavior

- addition test: add `await 1;` before DOMContentLoaded listener, you will see that in Chrome you get DOMContentLoaded triggered by script only, but in Firefox, you still get DOMContentLoaded triggered by TM only.

There is an await action before DOMContentLoaded listener in your script also, that's why it work on Chrome but not work on Firefox.
for why await make it work on Chrome, it may because of different "special condition" judgment between TM on Chrome and Firefox, that may be part of reason why your test code run different on Chrome and Firefox too

This post has been edited by what_is_name: May 28 2021, 22:43

change @run-at `document-end` to `document-idle`

That seems to run fine, and it fixes the problem with the floating window not showing when using "advance to next round using ajax" on Firefox that otherwise this version still has.

Feture request (website):
can we have a chart like this

not sure if the range filter can be implemented but it may be useful

Great idea! I will add those charts soon!

In short:
- to resolve this problem, just change @run-at `document-end` to `document-idle` is fine
- add and check special element is not necessary, if you want to prevent double run cause by native DOMContentLoaded event, just check the event.isTrusted

...

that's what the real problem is, TM trigger the DOMContentLoaded by itself and block other DOMContentLoaded in special condition, and that's definitely intentional behavior, so I said it more like a feature than a bug. use document-idle can simply avoid this behavior

[github.com] Quoted from the developer of a ViolentMonkey:

...and document-idle was never a solution for this, it's basically the same as document-end but without forcing it to run at the exact time DOMContentLoaded is fired.

But also, I found documentation related to Chrome/Firefox's contentscript API:

Chrome: [developer.chrome.com] https://developer.chrome.com/docs/extension.../#document_idle
Firefox: [developer.mozilla.org] https://developer.mozilla.org/en-US/docs/Mo..._scripts#run_at

Since nearly all modern userscript managers are implemented based on contentscript API, I guess I should use document-idle.

That seems to run fine, and it fixes the problem with the floating window not showing when using "advance to next round using ajax" on Firefox that otherwise this version still has.

Thanks for testing!

This post has been edited by OnceForAll: May 29 2021, 14:25

it's basically the same as document-end but without forcing it to run at the exact time DOMContentLoaded is fired.

That's the key point, basically document-end is the same as document-idle in injected time.
And both double run and not work with ajax round in your script are not the problem about inject time.
Both document-end and document-idle inject slow enough that you should't get native DOMContentLoaded event in script theoretically.

Actually if you run the #24 test code in ViolentMonkey you will see that both document-end and document-idle run the same, you will never see 'TM trigger event', and your script can work fine in Firefox + ViolentMonkey.

The real problem is, the document-end mean to forcing to run at the exact time DOMContentLoaded is fired.
consider the #24 test code result in TamperMonkey, it may be a feature that TamperMonkey is trying to make sure you get one DOMContentLoaded.
so it trigger a DOMContentLoaded by itself and block other DOMContentLoaded event, even if the script injected after native DOMContentLoaded.
the DOMContentLoaded triggered by TamperMonkey cause the monster info show twice, and it block other DOMContentLoaded event cause ajax round not work, they are the same problem in here.
and because of document-idle means without forcing, so TamperMonkey doesn't do this behavior and the script run fine, even it's the same as document-end in injected time

This post has been edited by what_is_name: May 29 2021, 16:49

Feture request (website):
can we have a chart like this

not sure if the range filter can be implement but it may be useful

The feature is now implemented!

Excellent work, thanks so much. I really missed the monster database and integration when it went down.
That said, when I try to scan monsters (making sure to do so as the first thing in the round before any stat adjustments from effects), it doesn't appear to update the DB. I turned on debugging, and it looks like all of them get this error: "HVMDB WARN Amphibious Morphism is not legible for scan, ignoring the scan result!" Any thoughts on this? Am I doing something wrong?

Excellent work, thanks so much. I really missed the monster database and integration when it went down.
That said, when I try to scan monsters (making sure to do so as the first thing in the round before any stat adjustments from effects), it doesn't appear to update the DB. I turned on debugging, and it looks like all of them get this error: "HVMDB WARN Amphibious Morphism is not legible for scan, ignoring the scan result!" Any thoughts on this? Am I doing something wrong?

That's probably because:

- The monster could be imperiled, or have a spell/spike shield effect, which would affect its mitigation level
- The monster is already dead by the time the script read the battle log
- The script faces an internal error (technical details: the script has lost the track of the monster's element, causing the script can't determine whether the monster has been imperiled, etc.). In order to prevent false data from being uploaded, the script ignores the scan result.

In the first two cases, the script will ignore the scan result (And in order to prevent interrupting battle, as you can see, the warning is silent and print in the dev tools console only). Although you do try to scan the monsters at the beginning of per round, it is still possible that you parry/block the attack from the monster during the scan, causing them to gain spike shield effects.

If it is the last case, that could be a bug of some kind. I will investigate this in case I did miss something earlier.

This post has been edited by OnceForAll: Jun 9 2021, 04:36

That's probably because:

- The monster could be imperiled, or have a spell/spike shield effect, which would affect its mitigation level
- The monster is already dead by the time the script read the battle log
- The script faces an internal error (technical details: the script has lost the track of the monster's element, causing the script can't determine whether the monster has been imperiled, etc.). In order to prevent false data from being uploaded, the script ignores the scan result.

In the first two cases, the script will ignore the scan result (And in order to prevent interrupting battle, as you can see, the warning is silent and print in the dev tools console only). Although you do try to scan the monsters at the beginning of per round, it is still possible that you parry/block the attack from the monster during the scan, causing them to gain spike shield effects.

If it is the last case, that could be a bug of some kind. I will investigate this in case I did miss something earlier.

Yeah, I confirmed it's throwing that error every time, even when I dodge, thus not triggering spike shield (not to mention, spike shield doesn't decrease the mitigation level a fair amount of the time even when it does cause damage, as shown by the relevant status effect not triggering). As scan is the first action I take in battle, it shouldn't be any other mitigation effect. I also haven't once seen any monster data appear in the infobox, which also strikes me as somewhat suspicious. Maybe the whole script is being stopped somewhere? I don't think I have any irregular security or script settings, but I'll do some digging. The same issue occurs on both the latest Chrome with Tampermonkey and Firefox with Greasemonkey.
If I can provide any more information, do let me know.

This post has been edited by Quackytheduck: Jun 10 2021, 22:03

Yeah, I confirmed it's throwing that error every time, even when I dodge, thus not triggering spike shield (not to mention, spike shield doesn't decrease the mitigation level a fair amount of the time even when it does cause damage, as shown by the relevant status effect not triggering). As scan is the first action I take in battle, it shouldn't be any other mitigation effect. I also haven't once seen any monster data appear in the infobox, which also strikes me as somewhat suspicious. Maybe the whole script is being stopped somewhere? I don't think I have any irregular security or script settings, but I'll do some digging. The same issue occurs on both the latest Chrome with Tampermonkey and Firefox with Greasemonkey.
If I can provide any more information, do let me know.

Are you using a Firefox based browser of some kind? If so, replace the "document-end" to "document-idle" to see if it helps.

Are you using a Firefox based browser of some kind? If so, replace the "document-end" to "document-idle" to see if it helps.

Tried with "document-idle" but got the same result. And again, it happens both on Chrome and Firefox for me. Would screenshots or log dumps be helpful in any way?

Tried with "document-idle" but got the same result. And again, it happens both on Chrome and Firefox for me. Would screenshots or log dumps be helpful in any way?

Probably not. If you don't see any errors besides the script generated messages, then not something useful to identify the issue. I will investigate at my side.

But if you do see some other error messages, please let me know.

This post has been edited by OnceForAll: Jun 11 2021, 14:40

By now, I'm only seeing low-level monsters in Isekai in the Tower. But, every day it highlights Green Slime in orange as needing to be scanned. I guess there's some off-by-one error that's causing it to not exclude one of the Common-class monsters.

[edit]Happening again today, I see it's MID #1.

This post has been edited by Necromusume: Jul 17 2021, 12:26

Do i need to install Monsterbation script also?

I install only this script alone, and the "drag'n'drop" list is completely empty.

Do i need to install Monsterbation script also?

I install only this script alone, and the "drag'n'drop" list is completely empty.

It is not required with Monsterbation. But the current version has some bugs that yet to be fixed.

Edited: duplicated posts caused by my network problem.

This post has been edited by OnceForAll: Oct 6 2021, 19:31

Monster database userscript 1.2.0 is now released!

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/

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).

Is there a way that I can submit my own monsters to the database from the monster lab? I would think that would be a useful feature.
For instance, absolutely everything except their special attacks should be derivable from the info on this page, and it'd mean that someone wouldn't have to waste a turn scanning my monsters in HV (or at least not as often).
[i.imgur.com]

I know it's not a direct translation like we can get from a scan, though.

This post has been edited by dragontamer8740: Oct 8 2021, 08:11