I appreciate your enthusiasm :), unfortunately all I can ask you for now is to have some patience, as the time I can give to work on the game is fairly limited during the week, so most of my progress is achieved on weekends.
As much as I would like to do this full-time that is not possible at the moment as only my main job can provide enough for the monthly expenses that I incur.
As for the content on the next version, the scenes this time around are quite simple, but the changing in the split of consent scenes and defeat scenes required a refactor in most older scene logic, which is taking me some time, besides the performance testing and optimization. Hopefully by the end of next week I’ll have this finished with help from my friend and the version can go into the translation phase.
With the workaround I’m less worried, but still I’m working on improving resource loading on the game as to attempt to recover the previous performance, hopefully I can find most critical loading issues :).
It’s not a virus, but sometimes an antivirus (Windows Defender, I’m looking at you) may report the game as potentially dangerous.
If you’re unsure, run the game with Sandboxie, the game as no online features so you loose absolutely nothing and you run lesser risks because Sandboxie blocks internet access for the game and restricts the files it can mess with :).
You might find some links on the Mushi no Kangoku wikia. The original Japanese wikia page as been deleted or moved it seems, which there was a link there to but you might find other links.
Oh I see, no there is no specific scene for the mushroom worm. The only scenes present in the original were for the parasite worm. So catching any of them always leads to those scenes.
The most likely is performance, I might have made changes on v0.81 that deteriorated performance. I think so because the time from the end of the introduction title to arriving at the beach takes almost 5 second in your case and in my test device takes only 1 second, running the same version, so on slower devices the performance degradation is probably crucial for the bug to happen.
Already checked it. It is still hard to understand the problem, but I have an idea of several things that might be going bad. I think one might be the explore button not being protected, other might be indeed performance, and it also depends on the Android device, for example, in my test device it is not possible to repeat this error using a finger, I might need an auto clicker that can click faster than me XD.
I’m not sure, but I would say that it is possible that either the next release schedule or assistance with Android issues are the most frequent questions :P.
We are aiming for the typical period, so that would be like slightly less than 2 weeks from this point, depending on how much progress we dish out this week :).
Along the updates I made a mistake between the logic and the updates, Rumia should only be available on Tuesdays, Wednesdays and Thursdays, but I wrote the opposite.
I’ll double check this with the original game, but anyhow, in the next update this will be corrected, and on Rumia’s days off, you won’t be able to enter the shop, as originally intended.
Thank you for the report. This issue was already confirmed in a few posts below and it will be fixed by the next version :). The workaround meanwhile is to spam press the buttons until they detect the press. Clicking outside the menu panel first can also improve the chance of detection.
OpenGL 3.3 is a bit old yes, it was released in 2010 I think. After some research, it seems the last version of the engine did not update the OpenGL driver, it was already 3.3 on the previous version, but it added a compatibility layer driver called ANGLE. There is a list of 66 graphics cards in the engine where ANGLE is enabled by default so it might be the case that older hardware will have an incompatibility error because of this. I’m not sure however as I’m just speculating based on what I found.
Still, I think even if the graphics cards are from before 2010, as long as there is a driver update to add OpenGL 3.3 support, it should work :).
Someone already suggested a dolphin enemy on the update thread :P.
It is a good idea, but given the issue with the CGs, execution will depend on having someone capable of making the animations for such an event. Without an animator it will be very difficult to add this encounter.
Thank you for the feedback, I was able to replicate this. This is an issue in the game engine with scroll windows. There are good news however, there is a way to mitigate it. I’ll test it out and implement it on the next version :).
Meanwhile, there is a sort of workaround on the current version, which is if you spam the button, eventually it will press, sorry for the boring quick solution :(. This is like a race condition between the scroll bar and the buttons. It seems to only happen on the menus you mentioned, other menus work fine because they have no hidden scroll bars.
The engine version was updated to its last on the most recent version of the game (v0.85). This may have included an update to the graphics driver as well on the engine side.
The solution is to update your graphics card drivers to their latest version, if possible.
I’ve seen a few reports of the bug on the encounters, I’m attempting to investigate it but I’m having some trouble reproducing it on my device. Nofunnis found that if you put the battle speed to x2.0 in the settings, this bug does not occur, or is less likely to occur.
The color inversion on the icons is on purpose, as it is the hovering effect of the buttons, when they loose focus, for example moving the mouse away or pressing anywhere else, their color returns to normal. I noticed recently that this tends to persist on Android when it shouldn’t I’ll see if I make a slight change on the button feedback effect.
I see, maybe I’ve forgotten to update something on the translated recall menus and they have a bug when unlocking, I’ll see into fixing it by the next version if that is the case.
I think the idea would be interesting, the limitation is the lack of CGs. I’m not a big fan of the drowning part myself, but I’m sure we could come up with something.
I’ll put it in the backlog in case I’m able to arrange CGs that match this or an animator for the extension roadmap :).
I think the more details I get, the more confusing the source becomes xD. But they’ve been a great help none the less!
I’ve compared the changes from 0.80 to 0.81 and unfortunately there is nothing obvious for me that seems capable of causing these problems, so I’ll have to drill by trial and error on the testings :(. DO you at least hear the battle jingle the battle starts, or does it just straight up freezes?
