error playing online

prastle

@prastle issue is simple it auto installs 32 bit if you don't have java yet
even with 64 bit dl

prastle

@RoiEX I guess the true test would be to install java before dl triplea on a clean install

BUT

I can 100% say
since I watched it do it!
If you dl TripleA stable
It will install java
if you don't have it yet
and will screw up your 64 bit bots
then you will ask Roi wtf?
and he will help you eidt it to 32 bit

hopefully this jogs your memory bro

Panther

@roiex @ssoloff The issue has been resolved for the user. Indeed he had an older JRE in a C:\Program Files\Common Files\i4j_jres directory. It might be interesting for you that he had experienced this problem using Update 144 that had been bundled obviously!
So manually deleting 144 and using the system-wide update 151 resolved the problem.

ssoloff

Thanks for the update, @panther! I'll take a look at the truststore in the build 144 bundled JRE to see if it's missing the root CA used by GitHub. I know my build 121 JRE installed from Oracle includes it, so presumably build 144 or later would also include it. I wonder if there's something defective about the bundled JREs we get from install4j?

ssoloff

@prastle I installed 64-bit TripleA (7950) on a system with no pre-installed JREs (32-bit or 64-bit). The TripleA installer downloaded the 64-bit bundled JRE (144), and I confirmed TripleA uses that JRE when started. Can you elaborate on what you saw that indicated the bundled JRE that was downloaded by the TripleA installer was 32-bit?

@Panther I installed 32-bit TripleA (7621) and 64-bit TripleA (7950) on a system with no pre-installed JREs (32-bit or 64-bit). The former installation downloaded and installed the 32-bit bundled JRE (144), while the latter downloaded and installed the 64-bit bundled JRE (144). I verified that, in both cases, I was able to download the map listing and PBF on A&A.org. So I'm not really sure why I can't reproduce the problem the user was having when using the 144 bundled JRE. It's concerning that there may be something machine-specific going on here.

@prastle @Panther Note that in both of my tests, I installed TripleA as a user without admin rights, so my bundled JREs were installed under my user profile rather than under C:\Program Files or C:\Program Files (x86). I can't see why that would change which bundled JRE was downloaded or cause a certificate validation failure, but it may be another variable worth exploring if this happens again.

The only other difference I can see between my environment and the OP's is that they were on a 32-bit machine, whereas I'm testing on a 64-bit machine. Again, nothing jumps out at me as to why that would matter for the scenario we're testing.

prastle

@ssoloff roiex had to help me rewrite my bots to 32 bit for them to run.

Panther

@ssoloff Interesting, indeed. Maybe something related to access with or without admin rights depending on the target directory...

prastle

@ssoloff This occurred when I used stable (.7634) to install (I had no Java installed) so it downloaded the JRE with Triplea.

ssoloff

@prastle Right. You said previously that you used the 64-bit TripleA installer, but it downloaded the 32-bit JRE. Is your OS 32-bit or 64-bit? How did you identify the JRE as 32-bit vs. 64-bit?

RoiEX

@ssoloff
.@prastle Noticed that his bot scripts were no longer working.
This was due to the -server Flag not working on 32bit systems.
At this point you might notice where the issue is: java is being invoked via the commandline in the bot scenario, but invoked by the install4j launcher when normally launching TripleA.
I already told him to just fix his PATH env variable, to no longer point to C:\ProgramData\Oracle\Java\javapath

prastle

@ssoloff ... @RoiEX identified the problem since after new install bots wouldn't run without being reverted to 32 bit code. My OS is 64 bit.

Panther

@ssoloff Unfortunately the issue is back for the user we recently resolved it for. Please take a look at https://www.axisandallies.org/forums/index.php?topic=41182.msg1727681#msg1727681 . The (over there) attached image shows the same error message we dealt with before (see above). Now the latest Java is installed at the correct place and there is no bundled installation interfering. What has worked for two weeks all of a sudden seems to no longer work. What can we do? Thank you.

ssoloff

@panther I posted directly to the thread on axisandallies.org. It will reduce one hop in communication.

Panther

@ssoloff That's great! Thanks!