Closed ShiftaDeband closed 10 months ago
This is caused by the client flags being broken somehow. The client is sending the config data 32 AC 99 83 00 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 00 FF FF 80 FF FF FF, which is wrong - it should be mostly 00, not mostly FF. This has the effect of enabling all the client flags, which causes this kind of incorrect behavior. Can you set HideDownloadCommands to false in config.json and capture a full session log, starting with the patch server and ending with the crash?
You bet. Here you go - let me know if I didn't do something correctly here.
Thank you!
The client is doing something pretty strange here. Can you also upload your psobb.exe? I'd like to take a look at some of the command handlers.
You bet. Here's that 1.24.3 executable I mentioned earlier. Please note that this does look for _e files as opposed to some other clients that replace the base/Japanese files.
For what it's worth, I'm still seeing the same results even with the most recent commit on a 'CreateTethEXE'.
I'll try to see where this was broken - I have used this client in the past without issue until last night/today.
Edit: I created a branch from commit 522c184
/'use a cleaner method to deal with duplicate 97 commands' and the client works here. Going down the list since then.
It appears to be related to the changes here: https://github.com/fuzziqersoftware/newserv/commit/84ed80365cd290320dbbf05dbeb90935dfc397e1
Using any of the commits immediately before this works. When building and running this one causes it to try to send the quest again. Here's the log with commit 84ed803: BB-NotWorking-84ed8036.txt
And the version immediately before this, 87440437: BB-Working-87440437.txt
EDIT: Just to avoid posting another comment, in the revision that things are working, I'm seeing that my mag is being referred to as an Ushasu. I was wondering if this was related, so I deleted the player and related character data from the server, restarted using the latest commit, created a new character, and I still get disconnected/sent the quest. Regardless, I'll be happy to dig into this more.
EDIT2: This just looks like a desync between the server items_v4.json and my server/client items file.
This bug led to the discovery of a behavior I didn't previously know about: if a certain field in the login response command (E6) is zero, the client scrambles the client config. (Previously, we thought this field was team_id, but it apparently is not.) d478e9b0 implements the relevant descramble logic - please try it again with that commit.
I tested with the newest commit on the Tethealla client with ENG mode enabled, and on first glance I see my inventory items with their correct names and mags, i also loaded a quest and verified again and saw no issues, is there anything more specific I should look for?
Thank you so much for all you do. The latest commit fixed my issue, I'll close this.
As for the item issue - I can investigate that more. Everything seems to line up for the most part, but I'm using outdated English (1.24.3) files, which is probably causing my other issue. For what it's worth, everything lines up with the $i command, it's just the labels themselves that aren't matching. For instance, generating a Mag creates a Ushasu, but displays as a Mag in-game.
Other examples: Team Points 10000 creates a Platinum Pen which can be exchanged for 10,000 points, which I assume was the English version name before it was likely changed at some point, and in Ephinea's example, likely a better translation from the 1.25.x game. Disks past disk 7 (which is just DISK Vol.7
in my unitxt_e) don't exist with names, and trying to play them causes silence. I never tried placing the corresponding OGG file, though, so it may still "work", but the item name will be blank.
I need to get this 1.24.3 client uploaded at some point to archive.org. The English final patch is probably still out there somewhere, but I've never had good confirmation that the alleged 1.24.3 version I've had is complete and matches 100%.
Last but not least, I have some of the PSOBB CN client files, but I am assuming that most quests, including Government, Battle, Challenge, and others are lost to time. Someone went through the effort to translate them, but they certainly are not the files from the server. And even then, the project I've seen for this just replaces the base Japanese files (ones without _e, for example) with the translated ones. (I believe the CN client used _c
for these?)
More on all that later. I'm hoping someone out there has the Simplified Chinese quests and final patch files somewhere, but I'm not going to hold my breath.
Anyway, after going mad off topic -- thank you.
@ShiftaDeband Well regarding your last comment, the client version expects a specific unitxt for that version in the case of the final US BB 1.24.3 and the final JP BB 1.25.13 you need to provide the proper unitxt of each version as the indexes of the items vary greatly thats why you see different items and scrambled names if you attempt to load the 1.25.13 unitxt into the 1.24 client and vice versa.
It doesn't really matter if it's a unitxt_j or unitxt_e but the indexes of that file inside should be the ones the client version is expecting to find for correct operation.
I recommend to enable the ENG switch in the Tethealla client which will turn the client into pretty much the US BB client with the very latest updates from JP BB you can find all the notes and required files in the notes/psobb
folder.
The hidden switch should also enable the chinese support but this version I believe was a little bit different than USBB/JPBB .... but if you enable it the client should still expect the usual files to end with _cs
for correct operation in this regard.
One little trick that can be used in case the files are not found is to enable CN support in the hidden lang switch and copy the unitxt files from the base japanese version (the most updated one) and rename them to unitxt_cs
for example, then the game should load just fine but all the items will be in japanese but ready to be localized into chinese.
I think the texture files such as the localized PSOBB chinese logo in the title screen, the headers in the in-game menus, or the textures of the F12 menu should all be inside the data.gsl already so you dont need to source the game should just load them as usual as soon you start the game with the CN switch enabled. But if they are not they should still be present in the chinese client with the _cs
prefix added at the end usually these texture files are compatible between versions.
At the bare minimum you require these files to exist in the client folder (not counting the textures ones)
unitxt_cs.prs
unitxt_shop_cs.prs
openning_cs.pae
map_XXXX_on_cs.bin
Hopefully this mess of an explanation helps you solve your doubts about the PSOBB client localization shenanigans.
@nolrinale
This is probably the best and easiest to understand write up I’ve ever read.
Thank you, this is unbelievably helpful. Thank you so much for your assistance with all this!
Good evening,
I typically leave EnableEpisode3SendFunctionCall on with a welcome message, wait a moment, then press A - this typically allows for the
EnableEpisode3SendFunctionCall
to work without crashing the Episode III USA client. (I assume this is a side effect of the patch being applied/loaded, which I can understand why it's disabled by default.)Anyway, the issue I'm seeing right now is two-fold. With the
EnableEpisode3SendFunctionCall
enabled, and since a recent commit that I need to track down, it appears that this quest/file is being loaded onto PSOBB clients, which causes them to crash during the 'Go to Lobby' and 'Disconnect' screen.I believe this is related to this command, because without this, I can get to the above screen. I also believe I recall seeing
m999999p_e.bin
being sent for Episode III clients in the past to allow for patches, although I'm not sure.For what it's worth, I'm using a modified, allegedly clean but decompressed and with Game Guard removed 1.24.3 client executable, but also tried building my own with CreateTethExe and the same issue occurs.
Here's a log of the issue: