Installation fails when ...? Using a foreign language in Windows?

[Iritscen]

(Read subsequent comments for changes to the theory of what is going wrong.)

As seen in our latest support request, when Java was installed on C:\ and Oni on D:\, something failed in the installation process. We know that XmlTools failed to patch properly, which might mean that this is an XmlTools bug, or perhaps the path was not passed properly to it? It doesn't seem possible that a failed XML patch would ruin the whole installation, so a deeper problem must be present.

I don't have time to investigate this right now myself, but perhaps the first thing we need to do is figure out what exactly failed. The level data seems to be about the right size (though smaller than what I see on my Mac, perhaps owing to more compressed textures). Oni's debugger.txt reported that ONGS could not be found, which indicates that the level file was built incorrectly (ONGS is the first instance in level0_Final.dat).

We might want to ask the affected fan to upload his level files for us to examine, but perhaps for a level besides zero since level0 is so large (this is assuming that the other levels also have the problem).

[Christian]

Not being able to reproduce. Java shouldn't have any issues with this anyway, the logs look fine, just XmlTools can't find one of the XMLs. So either XmlTools or OniSplit, if there really was something wrong caused by our toolchain and not the user's system.

[Iritscen]

Reopening since we have another user who experienced this issue. To clarify, we know now that it's not the location of Java vs. the AE that matters since the AE is now always using a local JRE, and the problem still occurs. All we do know is that, when the AEI is not on C:\, it fails to see the vanilla level0_Final.dat during the mod installation process, thus building incomplete level data files and causing Oni to crash on startup.

[Iritscen]

Updating since we now have an example of the same problem occurring when everything is on C:\. This may mean that the whole subject of drive location was a red herring. I am attaching the relevant logs from this latest crash report. Note that this was a Russian system, and the user name looks like abbreviated Unicode. Could it be the user path to the temp location that causes this issue?

The earliest sign of the problem seems to be in Installation.log, when the AEI cannot find the .oni files in the temp directory when trying to extract them to XML and apply patches. This then causes level 0 not to be built correctly when these patched files are supposed to be combined with the selected mods, since there is nothing in the patched file directory. Looking at filelist.txt, the end result is that the .dat for level 0 is way too small, and level 1's files are also too small for some reason.

P.S.: Why does aei_output.log say "Command: null"? Is that an issue? In some other logs we've received, it also says "null", and in some it says something like "bin\AEInstaller2.jar".

[Iritscen]

Out of the four cases reported so far, the first user was in Bhutan, the second and third were in Germany, and the last was in Russia. However, I don't see odd characters in the user names or other paths of the logs besides the Russian user's. I do see evidence that one of the German users was running Windows in German, and that the Russian user was running in Russian. The other two users *seem* to be running in English. So I don't know if system language is related to the problem.

[Iritscen]

Updating to add that we recently observed a problem on the computer of a user who was running Windows in English but with Devanagari numerals. Switching to Arabic numerals fixed his problem. I'll point out here that Bhutan (mentioned in my previous comment) speaks Dzongkha, which also has its own numeral system (which is often in base-20!).

This leads me to wonder if the issue here is due to foreign numeral scripts. In the one verified case where this was an issue, the problem was specifically caused by the foreign numerals being used in place of Arabic ones in package numbers, e.g. "42000DashingAI" would be presented to Java as "४२०००DashingAI", confusing the AEI. This could also theoretically occur in the level names, e.g. "level०_Final.dat", perhaps explaining why we have seen the AEI failing to recognize level files in cases of failed installation.

That being said, German and Russian use Arabic numerals, so I would guess that this is not just a numeral issue and that we may be seeing two similar malfunctions, one caused by foreign numerals and one caused by Unicode characters in directory names.

[Christian]

Would need someone with such an issue to work with on this but AFAIR they didn't reply to such a suggestion.

[Iritscen]

Yes, I never got back any responses from the users that I asked questions of. I don't know why it's so hard to find testers in this community.

[Iritscen]

Just heard from a user on our Discord that his AE would not install. He was stuck at the part where the AEIU checks out the AEI, and his updater_output.log had the error:

Error while checking out a working copy for the location 'http://svn.aei.oni2.net': svn: E200030: Invalid expression
org.tmatesoft.svn.core.SVNException: svn: E200030: Invalid expression

Noticing that his system was running in Turkish, I asked him to switch to English and try again, and the installation worked. I think this confirms that there is an issue with some foreign scripts, perhaps localized to the SVN code in the AEIU.