Issue with Tribes 2 after TribesNext Patch on Voodoo 5 rig

Comments

• Krash

  February 7 edited February 7

  Unhandled exceptions are just a general crash, but when the address is an actual memory location I can usually pinpoint specifically what went wrong. In this case it's not particularly useful without observing the call stack -- an address that low basically just means a pointer wasn't set correctly, probably a required call to a function in one of the linked libraries wasn't found.

  This can happen on video initialization (and might be more common on a Voodoo card) if the context creation fails, but if you were able to run before applying the patch, it's not related to video drivers - the currently released version doesn't alter anything related to rendering/windowing. We made sure at the time to maintain XP/2000 support, so it's shouldn't be targeting later platform/VCRT libs than are required by the game, but it is possible you're missing some library or have an earlier runtime version missing something it's looking for.

  Not having a comparable system to test/inspect dependencies (or having touched 98 in many years), my initial offhand guess would be maaaybe something like incompatibility with the WS2_32 binding of the ruby interface preventing it from loading. Try installing these DLLs to your GameData directory - while they were compiled with supporting an old WINE version in mind, the imports may be more compatible with an older system:

  TribesNext_RC2_LinuxVersion.zip
• NotBushman

  February 9

  Thanks for the initial reply, Krash. There was no observed change after installing the provided DLLs in GameData unfortunately. Is there any kind of verbose flag I can pass here to at least produce a more detailed log about startup? Looking through console_start.cs, I do see a number of options, but nothing that's producing any kind of debug info.
• Krash

  February 9 edited February 9

  Nothing particularly low level, but you can add setLogMode(1); and setEchoFileLoads(true); to the top of console_start and it could give some indication of the last place it reaches, however because this is strictly a log of console output it won't provide any useful information if it's not actually progressing past application initialization. Assuming you are loading the same shortcuts and it is loading up the same mod paths as you had run pre-patch, the main immediate differences in launch execution are going to be some interfacing with the background Ruby interpreter process (which shouldn't cause a crash if it's not able to run) and an online lookup for the authentication server address.

  In principle either of these will get far enough into the launch that you should see the window before it crashes, and it'd definitely get to a point where the log could identify either. The latter is known to cause crashes in cases where you don't have an internet connection or it otherwise fails to retrieve the address, but that'd normally bring up a different UE. Still, adding this patch to console_start would prevent that particular crash if it were the cause:

  // Gracefully fail failed WinSock DNS lookups
  memPatch("A3DC30", "565383EC148B5424248B5C24208B4424288B4C242C81FA01040000742389442428B8839A5500895C2420894C242C8954242483C4145B5EFFE08DB42600000000");
  memPatch("A3DC70", "89CEC1EE1081EEF92A000083FE0377CD8B1DC0A7830085DB7510EB5E8D7426008B9B0C04000085DB745039830004000075EE8B8304040000C705D0A783000100");
  memPatch("A3DCB0", "0000A3D4A783008B8304040000890424FF15BCC87D00B8303E4000C78304040000FFFFFFFF8B0D94829E0083EC04C70424CCA78300FFD083EC0483C41431C05B");
  memPatch("A3DCF0", "5EC2100090909090");
  
  memPatch("559A83", "5589E5535657EB0B");
  memPatch("559A90", "E99B414E00");
  

  
  

  The former is... ah. Oh. Yeah, I figured out the missing piece: we used EnumProcesses to look through and check if the parent process is still alive, and PSAPI isn't available on Windows 98. Unless someone made a PSAPI.dll wrapper to provide those NT functions for 98, it'd need a new build to work around that.
• NotBushman

  February 9 edited February 9

  

  Progress made. I found an appropriate wrapper for PSAPI.dll based on what's used in KernelEX (https://github.com/sherpya/psapi/releases). I am now able to launch Tribes 2 up to the login screen. I have yet to be able to connect to the authentication server, but will be trying to set logging modes next in case there's other info I can glean
• NotBushman

  February 9 edited February 9

  Update: Without using the older rubyintersect.dll and msvcrt-ruby187.dll, I would hit a "authentication server lookup returned an address with an invalid signature." error in the logs, seeing a prompt of "Not using patched executable" error in the sign-in UI.

  
  

  With using the older ruby DLLs, I am able find tribesnext.thyth.com:60659 and am able to get to a ready to authenticate state. I noticed a ruby error when attempting to open t2csri/certstore.rb and I get "Authentication: Unknown recovery status code returned from server" error in the logs. I'm assuming I basically have no local certs to work with given the Ruby error, thus here we are.
• NotBushman

  February 9 edited February 9

  I'm following up on older Linux/Wine install threads for RC1. I'm suspecting I'll be going down a similar path with handling local credentials, server list browser rendering, and such. Later today, I'll comb through that to avoid possible redundant questions here.
• NotBushman

  February 10 edited February 10

  Copied over my public.store and private.store files from my Windows 10 install. I assume that works around the cryptography implementation in Ruby, as I can now sign in, pull up server lists, and play!

  
  

  I'm still reading through any workarounds or fixes for irc issues.

  

  
  
• Krash

  February 12

  No data is sent to the account server until the final signing step, it will have just been offline or something blocked the connection if it failed on the first step. But yeah, you can always use credentials from another install to login -- and on an older machine this will have saved you from sitting through a lengthy key generation step.

  Nobody's on IRC anymore since it's died off, but if you wanted to see how the standard client worked you could try setting $IRCTestServer = "irc.quakenet.org:6667"; in a startup or autoexec script, or install Turkeh's script for something that had a little more work on it: https://www.tribesnext.com/forum/discussion/1230/new-in-game-irc-client/p1

  If you wanted to just stop it trying to connect though you should be able to set $IRCClient::state = IDIRC_CONNECTING_WAITING;