Dragon Ball Z Tenkaichi Tag Team disconnects during wireless battle

[MajinDipu]

This thing right here. It’s been around here since dawn of civilization.

I think anybody who tried to do multiplayer in DBZ TTT knows about this problem. During ad-hoc battles the game will display "Connection Lost" message and it will disconnect you from the match. It happens all the time. Can't even play this game peacefully with my friends.
The whole match is supposed to be played without any interruptions but this happens.
Doesn’t matter which device or hardware I use this is guranteed to happen. I twicked all the settings but it just won’t go away! Fast memory enabled or disabled it will happen.

Please fix this!

[ghost]

The game is like that its really sensitive to the distance and connection.
If you will try to play the game over Xlink Kai online you would also get disconnections even from the Ad-hoc menu lol.
The netcode is just not meant to be played online etc but if its locally over wifi then I dont know.
It does seem like the game worked better in the past though: https://www.youtube.com/watch?v=shTrcz-EVI8

I wonder how they messed this game up because compared to Shin Budokai 2 that game got like a god hood netcode lol for a fighting game on PSP.

[MajinDipu]

I was talking about local multiplayer tho. Don't know why it’s an issue in local multiplayer. Any solution? (Yes, for local multiplayer. I am not crazy enough to try it online lol)

[MajinDipu]

It does seem like the game worked better in the past though: https://www.youtube.com/watch?v=shTrcz-EVI8

I wonder how they messed this game up

What version those guys were using? It was clearly ok back then

[anr2me]

Are you playing this between PC vs Android?
if it is, it might be the same disconnection issue with Dissidia 012 when using some ability/skill and being played on 2 different architecture, there might be some inconsistencies on the data being sent (ie. floating point precision on a specific value)
I think GvG Next Plus also suffer from similar issue when being hit by a certain type of attack, but if that attack didn't hit you it won't cause a disconnection.

Other than that, another possibility is that the game might be measuring their own timing to checked for timeouts and bumped into a weird timeout comparison (ie. a negative signed value being treated as unsigned) which could happened when the time goes backward for some unknown reason.

[MajinDipu]

Are you playing this between PC vs Android?

Right now yes, I am testing with PC vs Android bcz I only have one mobile. But in android vs android situation it also happens. I think disconnect happens less often in android vs android.

[MajinDipu]

So umm... no solution, eh?

[ghost]

Maybe try to disable the JIT or the VFPU option in the JIT.
You can do it in Tools -> Developer tools Or something.
Both sides need to disable it though.

[anr2me]

So umm... no solution, eh?

Unlike crashes that can be easily caught where the issue was using debugger (as long they can be reproduced), disconnection in the middle of gameplay is hard to detects, since we don't have any clue which commit affecting it, and debugging on Android is a pain since the logcat often goes EOL and stopped printing anything.
And the video didn't even mentioned which version was being used and whether all players are using the same platform or multiple platforms.

So it will probably takes a long time until we can findout what exactly happened.

Most games only do regular Send/Recv during gameplay, and calculate timeout using currentTime - lastRecv > timeout, and we know that Send & Recv already working properly, while there is still an issue where time can goes backward, one of my solution to prevent disconnection was by faking the lastRecv timestamp to currentTime - 10ms so it shouldn't have much issue on the timeout, since most games is trying to sync data on every frame (ie. 16ms on 60 FPS games)
As i remembered Vantage Master Portable was one of the game that significantly affected by this fake lastRecv (it's one of the game that treats timeout comparison as unsigned value), without faking it the game will get disconnected after a few minutes without doing anything on multiple instance, while with faked time i can leave the game and do nothing for 30 minutes (probably more but didn't bothered to wait any longer) without getting disconnected.

I can try adding notification message on screen when detecting time that goes backward, so that we can at least findout if the disconnection occurred right after this notification or not.

[ghost]

So umm... no solution, eh?

Unlike crashes that can be easily caught where the issue was using debugger (as long they can be reproduced), disconnection in the middle of gameplay is hard to detects, since we don't have any clue which commit affecting it, and debugging on Android is a pain since the logcat often goes EOL and stopped printing anything.
And the video didn't even mentioned which version was being used and whether all players are using the same platform or multiple platforms.

So it will probably takes a long time until we can findout what exactly happened.

I remember that the game disconnected before and you somehow fixed it on some commit but I dont remember which.
Maybe it got regressed.
Best to use 1.10.3 or earlier because I think it worked better there then for now.

[MajinDipu]

I can try adding notification message on screen when detecting time that goes backward, so that we can at least findout if the disconnection occurred right after this notification or not.

OK I did not understand for the most parts but it was helpful. And that adding notification message thing might be a beginning step to fix this?

[MajinDipu]

Maybe try to disable the JIT or the VFPU option in the JIT.
You can do it in Tools -> Developer tools Or something.

Too lazy to try this right now but I will test it later :)

[ghost]

I think that disabling the VFPU or JIT helped me with getting Dissidia 012 to not disconnect...
But it makes the game very slow on some android devices.

[anr2me]

I wondered if the android build was compiled with precise precision like we had on Visual Studio (/fp:precise) or not...

[MajinDipu]

I think that disabling the VFPU or JIT helped me with getting Dissidia 012 to not disconnect...
But it makes the game very slow on some android devices.

OK can you tell me which option are you talking about specifically? There is JIT Debug tools in
Tools> Developer Tools> JIT Tools
And inside there are many other options. Inside JIT Tools everything is disabled including 6 different VFPU options.

Should I change CPU Core? It's set to Dynarec (JIT)

[unknownbrackets]

Hm. Is it relying on both sides calculating floats to exactly the same bits?

-[Unknown]

[anr2me]

Not sure, but there is a possibility for the game to treat specific floating point value as a different value (ie. rounding/normalizing denormalized numbers) due to some issue, which might happen if the game was ported from a different platform.

[anr2me]

Btw, we're using -mfpu=neon on ARMv7 right?
It seems Neon is not IEEE754 compliant, according to this https://wiki.debian.org/ArmHardFloatPort/VfpComparison

[unknownbrackets]

We might also be doing fused calculations in some places, among other things. We are not bit exact to PSP results in multiple ways, and platforms are not always identical to each other either. I guess this may be a problem for networking...

Between PSP and PPSSPP though, you just have to look at i.e. #2990 to see differences in opinions on floating point calculation. Much of the PSP VFPU was not IEEE754 compliant either.

-[Unknown]

[hrydgard]

NEON on ArmV7 is indeed not IEEE754 compliant, fortunately ARM64's NEON "ASIMD" is compliant.

As Unknown says, there can still be minor differences, the spec doesn't do a good job of defining signs of NaNs and stuff like that. It's a very difficult problem to solve.

[MajinDipu]

Hey guys, I have a info to share with you. Using IR Interpreter the game had a stable connection. Meaning disconnection happened rarely. But the con here is the game becomes super laggy with IR Interpreter. Dynarec JIT gives better speed but in multiplayer it gets disconnected almost immediately.

So my stupid theory is that The laggier the game gets the more stable the connection becomes. Although that's not a solution since laggy gameplay is the worst gameplay

[anr2me]

Does it disconnects when both of you not doing anything (ie. not fighting)? because most of the issue i suspects to be related to VFPU were happened when someone get hit with a certain attack, if that attack missed it won't cause disconnection.

If it disconnects by just idling, both device (PC and Android) might not be running at the same pace, causing the slower one to be flooded by packets from the faster one, thus the receive buffer gets full and new packets gets dropped since the slower one can't process the data fast enough, and because of this dropped packets it will eventually desync.

PS: And i don't think frame skipping will be helpful in this case, but switching who host and who join might help.

[MajinDipu]

OK I haven’t tested with idling but surely will. The thing is both device runs at virtually same speed. But I guess not running at same speed technically

[ghost]

On the video I shared before you could see the players overclock the emulated CPU to high levels before they play it.
So messing with the emulated CPU option in System can also help I guess.

[MajinDipu]

Update: Doing nothing in the match or simply idling doesn’t make the game disconnect. I did nothing for like 500 seconds and the game was fine. Then decided to fight a little and it got disconnected after minute.

[MajinDipu]

On the video I shared before you could see the players overclock the emulated CPU to high levels before they play it.
So messing with the emulated CPU option in System can also help I guess.

Thanks for the head up Mojo. I will check that out again

[MajinDipu]

So I tried with emulated clock speed to 1000 MHz and I think it helped to prevent us from getting disconnected big time. Needs more testing by other people on other devices. Also I changed the I/O timing method to "Fast" from "Host".

Only time it disconnected when something weird happened right before connection lost. My player Vegeta was charging up away from enemy Goku in my screen but on the other screen Vegeta was standing right in front of Goku. I hit one attack button and " Connection lost" massage showed up. What happened was Goku knocked me away and I tried to rush to him immediately pressing Up+O. I missed the timing on my android device but for some reason I was succesfully rush charged into Goku on PC.

Anyway I hope this info will be useful. But I still believe making the emulated CPU clock speed to 1000 MHz and I/O timing method to "Fast" actually helped a lot. But as I mentioned before this theory needs more testing by other people. Also wish there was some way to increase clock speed over 1000 MHz as 1000 is the max range.

[anr2me]

I think it's normal to get weird behavior when forcing the CPU to a certain clock, it could also causing the FPS to dropped on some games due to the extra burden from overclocking.

Did you overclock both side? have you tried overclocking only one side?

Btw, if both side showing different things on the screen and followed by disconnection, the game might be desynced, it may happen when packets being dropped/lost too many times.

[MajinDipu]

Did you overclock both side? have you tried overclocking only one side?

Overclocked both sides. Maybe I will try overclocking one side only. Also how do you think it would affect the connection if we could increase the CPU clock speed over 1000 MHz (2000 MHz for example)?? Is it possible that the "Connection lost" error message will become an extremely rare occurrence if not gone forever by doing so?

[unknownbrackets]

Are you using "Force real clock sync" (I'd recommend having it on for networking)? I would recommend "Host" io timing as well for network play, and try to avoid frameskip if possible. The force 60 FPS setting might be good too.

-[Unknown]

[unknownbrackets]

sceDisplayWaitVblankStartMulti() is the one.

-[Unknown]

[MajinDipu]

It's cool ANR2ME. Take your time.
And I searched the whole internet for the 60 FPS cheat code without any luck. Also asking people if they ever made any patch/cheat for this game to run at 60 FPS but again no luck :(

[anr2me]

Hmm.. looks like the reason why it didn't get the packet after 2 frames and deleting the socket, because it wasn't even trying to recv the packet on one of them frame ... i wondered why it skipped doing any networking on that frame other than checking the WLAN switch state at 01:648~01:682

Or may be there is a timeout for idling too long on "Rematch" menu...

Edit: LOL it did have a count down timer during "Rematch menu" 😅 i didn't noticed it because i was using 1x Window and the timer is covered by FPS info
So i guess the disconnection during "Rematch menu" is normal, and now we're back to square one... don't know why some attack could cause disconnection, since i can't reproduce it (yet)

[anr2me]

Hmm.. i'm not sure how to create the cheat properly.
This is the code (li a0,0x2) which set the FPS to 30 when multiplayer game started, where this 0x00000002 value will be stored at 0x08A78E0C and being read as arg of sceDisplayWaitVblankStartMultiCB

After multiplayer ended the game will set the value at 0x08A78E0C to 1 (60 FPS) using the same function (z_un_08837a00)

I tried to create the cheat like this:

_S ULUS-10537
_G DBZ TTT [US] 
_C1 60 FPS
_L 0x08AB7EC8 0x34040001
_L 0x08A78E0C 0x00000001

But when i checked the instruction and the value stored in memory, they're not changing :( did i use the address in the wrong way? (in case the cheat have a base address)

PS: Replacing the instruction should be sufficient, replacing the vblank value in memory isn't really needed.

Update: Looks like i need to subtract the PSP address with 0x08800000 and added it with 0x20000000
So the correct cheat is:

_S ULUS-10537
_G DBZ TTT [US] 
_C1 60 FPS
_L 0x202B7EC8 0x34040001

But the animation seems to be moving too fast.. probably not a good idea to use 60 FPS other than for testing purpose.

[MajinDipu]

Edit: LOL it did have a count down timer during "Rematch menu" 😅 i didn't noticed it because i was using 1x Window and the timer is covered by FPS info
So i guess the disconnection during "Rematch menu" is normal, and now we're back to square one... don't know why some attack could cause disconnection, since i can't reproduce it (yet)

Are you sure that the disconnection in match and after the match happens for different reasons? Yes I know it has a countdown timer but do you think that packet and floating point things might be same in 2 situations? Or just completely different?

[MajinDipu]

Update: Looks like i need to subtract the PSP address with 0x08800000 and added it with 0x20000000
So the correct cheat is:

_S ULUS-10537
_G DBZ TTT [US] 
_C1 60 FPS
_L 0x202B7EC8 0x34040001

But the animation seems to be moving too fast.. probably not a good idea to use 60 FPS other than for testing purpose.

Bruh, I guess it’s so complex to make a 60 FPS cheat for this game that everyone who tried failed. Indeed this is one weird game. Anyway I will use the cheat. For testing purposes only lol

Update: Well it looks like your cheat tricked this game to run at 2x speed. And ah... It got disconnected when Frieza was powering up 😅

[anr2me]

Edit: LOL it did have a count down timer during "Rematch menu" 😅 i didn't noticed it because i was using 1x Window and the timer is covered by FPS info
So i guess the disconnection during "Rematch menu" is normal, and now we're back to square one... don't know why some attack could cause disconnection, since i can't reproduce it (yet)

Are you sure that the disconnection in match and after the match happens for different reasons? Yes I know it has a countdown timer but do you think that packet and floating point things might be same in 2 situations? Or just completely different?

The disconnection after the match is normal because it happened after the countdown ended, while the one during battle is not normal, i'm still suspecting it has something to do with collision calculation when an attack hit the target based on the symptom similarity to GvG Next Plus which was suspected to be related to VROT/VCOS.

Anyway, it's difficult to fix since i haven't been able to reproduce it my self during battle, thus unable to check the log.

[anr2me]

Btw, if it happened quite often on your test, could you test disabling some of the JIT feature on both players, like this:

If it didn't disconnect during battle, try removing each section (SIMD, LSU, FPU, VFPU) on each test to findout whether it's related to JIT or not, if it ever get disconnected it might be related. (btw, checklisted = disabled JIT)

[MajinDipu]

Btw, if it happened quite often on your test, could you test disabling some of the JIT feature on both players, like this:

If it didn't disconnect during battle, try removing each section (SIMD, LSU, FPU, VFPU) on each test to findout whether it's related to JIT or not, if it ever get disconnected it might be related. (btw, checklisted = disabled JIT)

Will do. But everything is already unticked. I will enable everything then try disabling everything one by one.

Edit:- Umm, I thought checked means enabled but it actually means disabled. Didn’t read your last part. So OK.... Will do the work

[ghost]

There is that PR here that chagnes stuff related to VFPU :
#14406
Maybe it helps with this issue if it is related to VFPU...

[MajinDipu]

It's merged. Does this mean if it’s related to VFPU and I use latest versions the problem might be fixed?

[MajinDipu]

@anr2me Hey man, I got a tips to reproduce that connection lost thing. It's not in 1v1 tho. And requires a CPU But might help. Here's what you have to do.

1. Setup a 2v1 battle. Have 2 human players in one team and 1 CPU on the other.
2. Set CPU difficulty to very weak.
3. Pick any characters and any stage
4. When the match starts both human player should approach CPU immediately. Very much possible to do alone.
5. When 2 human players are close to the enemy, start punching and kicking (square button) simultaneously. Don't do the punch punch smash away and teleport kick thing. Hit 2 punch then take a breath then 2 punch again. 2 human should do it simultaneously.
6. Other things that you can do are ki attacks together both from close range and far away. Or use your super attacks together like Kamehameha and Gallick Gun to the CPU at the same time. Have one player do the kamehameha while other one does dragon rush. etc

This has 100% success rate of disconnecting. Good luck.

[anr2me]

It's merged. Does this mean if it’s related to VFPU and I use latest versions the problem might be fixed?

Have you tried with the latest version to see whether that PR fixed this issue?

Btw, i'm not familiar with DBZ games, other than regular attack (close combat and ki) i don't know any other moves LOL
i don't even understand what "punch punch smash" mean :D
And since i'm playing this alone, it's kinda difficult to do this simultaneously on Android & PC.
Also, you didn't mention in your step-by-step when is the expected disconnection to happen? on step 7?

[MajinDipu]

Oops. Ok I didn’t test it on the latest build. To answer your 2nd question disconnection can occur in step 5 or step 6. Step 6 is divided into two parts but it might happen simply with ki attacks. So I hope kamehameha or gallick gun is not needed.
I know it is hard to simultaneously control both android and PC but I said in step 4 it is very much possible if you set CPU's difficulty to very weak. At least you know how to punch and kick. That will be it.

[MajinDipu]

@anr2me Yoooo, you gotta check this out! The latest build made this game unstable in multiplayer. Everything is sooo fast and acting weird all of a sudden.
Here's the video link -> https://youtu.be/NCbTLKTJEuQ
Needs testing by others with this build before creating a new issue. Who knows it might be my device. Please anyone who sees this, u gotta try multiplayer with the latest build. In case you are wondering if it is happening with other games then no. Tested Tekken 6 and it was fine and just as before. Not sure about other Arena fighters like Dissidia or Gundam tho.

[unknownbrackets]

Is it fine in v1.11.2-550-gdbe665880 and bad in v1.11.2-558-g0ccc63b43? That does look potentially like some kind of not good sin/cos problem...

-[Unknown]

[MajinDipu]

I think I had v1.11.2-543 before and it was good. Not sure about 550

[unknownbrackets]

Well, I'm surprised we didn't have a vrot test for cos(2 * pi/2). Sorry, will be fixed in a84df25.

-[Unknown]

[MajinDipu]

GG

[anr2me]

So did the latest version right now fixed this disconnection issue?

[MajinDipu]

OK only tested 2 match. 1st match was the cleanest match we had in a long time. Everything went perfectly. Also we tried to do many things to force disconnection but it was all good. After the 1st match we pressed rematch. In the 2nd match again that disconnection occurred. Needs more testing but rn Imma sleep. I have this weird feeling that the connection might've actually improved. But that's too early to say bcz only played 2 match. But damn! That 1st match was magical!

[anr2me]

May be the game uses more VFPU other than VROT and VCOS/VSIN (i'm not sure what kind of calculation usually used to checks for collision, but usually the colliders are in simple shape like box, sphere, and capsule).
But it's nice to know you had your first ever stable gameplay :D

[ghost]

Tried to find out what happens with Android to PC on Dissidia 012...
WIth the latest dev build it will disconnect not long after the match starts.
But if you disable the VFPU stuff from the JIT the match seems to last longer but will still disconnect.
I noticed that the intro animation when the battle begins is a bit wonky with the VFPU stuff disabled and its kinda funny lol.
Tried overclocking to the max cpu limit of 1000 mhz but I am not sure if it helped or not (the match still lasted a bit longer).

[ghost]

I don't think the issue where you get disconnected when getting hit by a certain attack while doing multiplayer Android vs PC ever got fixed on GvG.

It was an old bug, i think it was first reported on forum, but between JPCSP vs PPSSPP https://forums.ppsspp.org/showthread.php?tid=12357&pid=99304#pid99304

I've noticed that the error (2:45) happens only after someone receives an attack, specially the triangle button attacks (or a couple of seconds after). If the attacks don't hit, the error won't show up.
As the battle gets more and more chaotic the error will pop up, if any AI is present the error will happen a lot more faster (5 to 30 seconds).
Of course, this error only happens when using JPCSP as host and PPSSPP as player. JPCSP to JPCSP is perfectly fine.

But later also happened on PPSSPP Android vs PC as i remembered.

It happened on JPCSP vs JPCSP too when playing betwwen old and new version (suspected to be related to VROT/VCOS) https://forums.ppsspp.org/showthread.php?tid=12357&pid=106915#pid106915

this error will happens when using jpcsp-rbd345a4 with jpcsp-r3ad1872(or older)
as gid15(author of JPCSP) say: That can happen if the game is exchanging values computed using VROT or VCOS through the network: both sides have to use the exact same algorithm.
I guess when playing against jpcsp with ppsspp, ppsspp need fixed VROT or VCOS.

Found out that using IR Interpreter only on the PC side seem to solve this issue for now and only for GvG.
I only tried 1vs1 Android to PC though
BTW I remember trying JPCSP vs PSP and it still disconnected there recently...

[anr2me]

Does using IR interpreter on both Android and PC also worked better?

[ghost]

Most Android devices are too slow for using the IR interpreter but I guess it will also work well (also disabling the VFPU stuff in JIT works too).
Still wonder if it's possible to get JPCSP/PPSSPP to work against PSP though...

[ghost]

Also it seems like desyncs could happen on real hardware that use just ad-hoc.
Here is an example for GTA Chinatown Wars when you shoot a taxi lol (happens on PPSSPP too):
https://user-images.githubusercontent.com/33392696/145994817-1268580d-c3bd-4d02-a4c4-a6a78a004f93.mp4

I have a theory that because they ported the game from DS they didnt account for CPU changes between ARM and MIPS but who knows.

[ghost]

Lately this issue happens even on PC with localhost lol.