List of Compatible Web-Browsers for Kamihime PROJECT-R
Historically, I had recommended the Atom-Browser or Nutaku-Client to play KP-R, but, due to past issues with game-updates, I must now revise those recommendations. Fortunately, I have done some searching around, field-testing, etc., and here are my findings...
Browser-Name
Description/Findings
Chrome-style Russian-based web-browser. Was doing really good for a long time, but, ever since a past update with KP-R, the KP-R screen will get stuck on black if you try to multi-task, such as watching an animé-video in full-screen, whilst KP-R is loaded in Atom at the background (when in the middle of Quests/Missions such as for Guild-Order/Accessories/etc). Otherwise I still do use this browser a lot (just no longer for KP-R).
I now rate this as THE most stable browser for KP-R, how-ever, the animations, such as for hentai-scenes, will cycle much more slowly than the animation-speed you would otherwise get from other web-browsers. Also, whilst the BGM (Back-Ground Music) will play, perhaps at lower-than-normal volume, sound-effects/voice(s) seem to be mute during battles.
Although KP-R does load via this Client on my newestlaptop, running over-crowded raids will result in frequent «There was a server error» messages, but, I still get black-screened via my desk-top (I even uninstalled then re-installed client to test if it would resolve issue but to no avail as loading still remains black-screened for desk-top).
Many people were using Opera, for some reason, back when none of the other browsers seemed to be able to load KP-R (either black-screened or frequent Niké-error-pages). This was a decent browser to use, for a while, but, like with Atom, quests/missions would go black-screened if you multi-tasked with this browser in the back-ground whilst doing something else full-screen, whether portable or desk-top version seemed to make no difference.
This worked well, initially, but, for some reason, the browser auto-closed on me after a while when KP-R was running in the background (this was via the portable-version). I also installed the desk-top version for further-testing and obtained same results. I have a new laptop now so I may be soon-testing whether that makes any difference before this is next-updated.
I found the performance of this particular web-browser for KP-R to be historically impressive. Even though full-capacity raid-errors are far less frequent (almost non-existent which comes pretty damn close to Falkon's stability), I still managed to some-how find a way to break the game, even with this browser; details further down...
Highly versatile, full of custom-options, such as locating address-bar at bottom instead of top of the browser; how-ever, raid-battles will not auto-complete, even though the raid-battle itself should remain stable (i.e.: NOT plagued with frequent [if any] «There was a server error» pop-up message-windows) UP TO the point of any raid-bosses being defeated; i.e.: The «There was a server error» message should only appear ONCE per raid-battle (at finish).
The latest browser that I had tested (via my most-recent laptop). Although this seems to be a decent browser, for purposes of KP-R, expect your crowded raid-battles to be met with frequent «There was a server-error» window-dialogue warnings, unfortunately. You should be fine otherwise if you are not multi-tasking or doing high-participants raid-battles.
UDATED ADDITIONAL FINDINGS :
The other day, when I set AAB-Mode (Auto-Battle with Auto-Abilities) for a Hero-Difficulty Quest/Mission/Battle, via the Super-Bird web-browser, the browser that I historically rated as the most-stable for KP-R (that title/ranking now belongs to the Falkon-Browser), and left it running whilst I went to do other tasks/errands, I came back surprised to see it on a Niké Error-Page. Refreshing the browser-page also resulted in only loading a Niké Error-Page; I cleared the Cache as a result...
Cache-clearing allowed me to return to the Event-Battle; how-ever, upon resuming the battle, whilst there was only ONE Kamihime remaining (the rest were all knocked out), and each and every action was taking a very long time to load (i.e.: use of an ability, attempting to attack normally, etc), something like up to a whole minute or possibly even longer per action if I remember correctly. Waiting around just for ONE action to be performed at a time was proving to be too time-consuming so I decided that I wasn't going to waste any more time waiting for several minutes just for the battle to progress what should have only taken a few seconds to fully animate.
The results of this experience has lead me to conclude (theorise?/hypothesize?) that, possibly due to the way that battle-animations are saved in cached files/images, this may be what is causing that HUGE spike in RAM-usage when Kamihime start getting knocked out during battles (this became very apparent for when I was multi-tasking Game-of-Dice via the BlueStacks-Emulator whilst letting KP-R run in the back-ground via AAB for those very long and drawn-out battles and, suddenly, the BlueStacks-Emulator frame-rates dropped considerably enough to the point where I could no longer accurately control my Dice-Meter [i.e.: dice-meter animation was suddenly too choppy for me to predict which number-range I was trying to activate]). I thus describe some of my resulting conclusions in the next paragraph...
I am taking a possibly wild but semi-educated guess here that, when the cache is created, that the battle-animations for the Kamihime are saved in said caches, BUT, that replacement Kamihime who are supposed to replace the Kamihime which have been knocked out are possibly being loaded from the same cache-section that holds the animation for the already knocked out Kamihime, potentially causing some problems and possibly even divide-by-zero errors, resulting in the frequent need to re-load browser and/or even clear the whole entire browser-cache altogether. I believe that a possible way for this issue to be rectified is to have KP-R save its animations in a slightly different manner, such as a completely separate cache-space for when all of the Main Kamihime are still healthy enough to still remain on the battle-field, but, switching to a different cache-space when any Kamihime get knocked out.
Granted, the above suggestive-idea for bug-fixing may take some extra work beyond what was initially described in the above paragraph, for example, completely separate cache-spaces (additional arrays ?) may be needed for any combination of remaining Healthy Kamihime versus K.O.'d Kamihime, such as if 123456 are all still Healthy, but #4 gets knocked out and replaced with #5, that a separate section of the cache be used for the entire team animation, and, possibly yet another section allocated for the next configuration of Kamihime-animations, such as when #1-3 ends up getting replaced with #6, etc. One can think of it as when Array[1] is the animation-configuration for when the entire team of Kamihime are Healthy, Array[2] is another completely different animation-configuration for if Kamihime-Member #1 gets replaced with Kamihime-Member #5, Array[3] becomes yet another animation-configuration in a different section of the cache for when any other Team-Member gets replaced by Team-Member #5 or #6, etc.
Caveat : I am not entirely sure (I just do not remember specifically right now), but, another possible animation-configuration issue that may need to be addressed is for when Kamihime run low on health (the animations for Healthy Kamihime are different than the animations for Kamihime who are in Critical-Condition after all). The same (possible ?) «fix» that I described in the previous paragraph may possibly need to be done for any combinations of Kamihime on the battle-field whenever there are changes to the number of Healthy Kamihime, Critical-Condition Kamihime, and Knocked Out Kamihime, for, I think I remember several instances of KP-R becoming unstable enough to force a browser-refresh once Kamihime end up being low on health; just my observations and «educated guesses» recommendations.
This page last updated/modified:
025TL06m11d (025TL = 2021CE)