Street Fighter Alpha 3 Max broken in more recent (or at least post-1.9.3) builds

[mukiex]

I'm just bringing it up in case it's not a known issue? At some point since 1.9.3 was released, SFA3 multiplayer broke in Ad Hoc mode.

Originally I couldn't figure out what I was doing wrong, as either I would get "Connection Terminated" in-game as soon as the match was getting set up, or even trying to get into the lobby. Or the first machine would get to the lobby, and the second machine would hang trying to get in, and fail to connect or see the other player. This was also happening to me in LunaMoo's 1-machine-2-instances build, and I couldn't figure out why.

Then I noticed that I was getting connections between two Windows clients running 1.9.3. Eventually I noticed the newer software version was the weak point (I even had trouble with RetroPie, whose non-libretro PPSSPP build is about 15 days old), and even LunaMoo's fork worked perfectly on one machine after I downloaded the late October release.

Is there anything I can do to help narrow that issue down? Log uploads or whatnot?

[Zinx777]

I think its Unknown he did something with the networking code that broke some stuff.
Possibly its this PR : https://github.com/hrydgard/ppsspp/pull/12712

[AdamN]

(05-10-2020 11:52 AM)Zinx777 Wrote:  I think its Unknown he did something with the networking code that broke some stuff.
Possibly its this PR : https://github.com/hrydgard/ppsspp/pull/12712

I don't think that commits affect multiplayer much tho.
If SFA3 is using AdhocMatching, changes that could affect it are probably related to mipscall/callback, I/O Timing settings might also affect multiplayer games that use multi-threading for networking.
Even my newer code got broken and i'm still stuck trying to fix it LOL

[Zinx777]

It still works on your latest build BTW as someone told me.

[LunaMoo]

(05-09-2020 06:14 AM)mukiex Wrote:  (...)
Is there anything I can do to help narrow that issue down? Log uploads or whatnot?

Prefferably bisect builds to find last version working by cutting the range between last known to work and first known to break in halves, so go to buildbot and if you know that last one working was 1.9.3 and you only know latest doesn't work, cut that in half and try v1.9.3-382-g8f623be3e, if this one works, then cut the range between that build and the latest in half again and test v1.9.3-572-gcc0cfcd33, if it doesn't, then cut the range between it and 1.9.3 and test v1.9.3-189-g6d8ddb7a7.

Bisecting like that should allow you to find where things broke in just a few tries, instead of blindly blaming things which might not be related. Ie. this could just as well be related to async I/O stuff and not any adhoc code.

[AdamN]

(05-11-2020 08:31 PM)Zinx777 Wrote:  It still works on your latest build BTW as someone told me.

Well, when i found out it breaks MH games i'm starting to feel hesitate to release new version since currently multiplayers breaks/fixed by itself whenever i pulled the latest commits which i couldn't figured out what's going on, and i really don't want to breaks games that has been working for ages like MH games.

Anyway, the one i have right now seems to have no issue with MH games and Soul Calibur, at least on localhost and LAN (PC vs Android) but not sure when going through internet (public adhoc server or VPN) since it never worked using my internet connection.

[Zinx777]

(05-11-2020 09:54 PM)LunaMoo Wrote:  

(05-09-2020 06:14 AM)mukiex Wrote:  (...)
Is there anything I can do to help narrow that issue down? Log uploads or whatnot?

Prefferably bisect builds to find last version working by cutting the range between last known to work and first known to break in halves, so go to buildbot and if you know that last one working was 1.9.3 and you only know latest doesn't work, cut that in half and try v1.9.3-382-g8f623be3e, if this one works, then cut the range between that build and the latest in half again and test v1.9.3-572-gcc0cfcd33, if it doesn't, then cut the range between it and 1.9.3 and test v1.9.3-189-g6d8ddb7a7.

Bisecting like that should allow you to find where things broke in just a few tries, instead of blindly blaming things which might not be related. Ie. this could just as well be related to async I/O stuff and not any adhoc code.

Sorry i blamed but i think something got broken before or after that commit.
So someone needs to check around that.

---

(05-12-2020 03:50 AM)AdamN Wrote:  

(05-11-2020 08:31 PM)Zinx777 Wrote:  It still works on your latest build BTW as someone told me.

Well, when i found out it breaks MH games i'm starting to feel hesitate to release new version since currently multiplayers breaks/fixed by itself whenever i pulled the latest commits which i couldn't figured out what's going on, and i really don't want to breaks games that has been working for ages like MH games.

Anyway, the one i have right now seems to have no issue with MH games and Soul Calibur, at least on localhost and LAN (PC vs Android) but not sure when going through internet (public adhoc server or VPN) since it never worked using my internet connection.

Yeah that's why i deleted the test build thread i felt it was not good for use.

[Adhenovan]

well if it break mh games compat.ini can be temporary solution until we found out all api call on adhoc module and start implementing them properly.

many of my test program yield different result with current PPSSPP adhoc and yes we have many wrong implementation especially on that SceNetAdhocctl module..

any update compability list on latest git build ? i am looking for game that freeze on connection to use as refrence reversing the adhocctl module

[Zinx777]

(05-13-2020 08:58 PM)Adhenovan Wrote:  well if it break mh games compat.ini can be temporary solution until we found out all api call on adhoc module and start implementing them properly.

many of my test program yield different result with current PPSSPP adhoc and yes we have many wrong implementation especially on that SceNetAdhocctl module..

any update compability list on latest git build ? i am looking for game that freeze on connection to use as refrence reversing the adhocctl module

I remember that Dissidia 012 had freezing issues sometimes.
Final Fantasy Tactics also had a freezing issue (dont remember if latest git tho).
I think Ratchet & Clank: Size Matters got either a crash or a freeze if you tried to connect (most likely a crash).

[Adhenovan]

final fantasy tactics wotl work on amultios protocol so doesnt know where is the part it hang on proadhoc, will look investigate later, if someone could help me with the log on games call that can be a great help.

Just thick
scekernel - info
scenet - debug
sceutil - info

most of adhoc feature related on that module that cause freeze.

[Zinx777]

It would be easier if i could test it on a single PC with 2 instances of PPSSPP...
Unless Android to PC tests are also good.
Also rememberd that The Force Unleashed also got a freezing issue (latest git as well).

[Theboy102]

it working bois 1.9.3-729

[Theboy102]

it working bois

[AdamN]

(05-13-2020 08:58 PM)Adhenovan Wrote:  well if it break mh games compat.ini can be temporary solution until we found out all api call on adhoc module and start implementing them properly.

many of my test program yield different result with current PPSSPP adhoc and yes we have many wrong implementation especially on that SceNetAdhocctl module..

any update compability list on latest git build ? i am looking for game that freeze on connection to use as refrence reversing the adhocctl module

As far as i know most of the freezes (permanent freezes) are either due to using blocking socket with infinite timeout (0), OR due to access violation exception within PSP side (crashes with fast memory or freezes without fast memory) probably due to register/memory corruption during a callback/mipscall, while minor freezes (short freezes) are usually due to lost packets

Currently i'm trying to implement a better blocking socket implementation by using sceIo as references to fix the freezes related to blocking sockets, but hecks i don't even understand how sceIo works LOL

[Adhenovan]

(05-22-2020 05:36 AM)AdamN Wrote:  As far as i know most of the freezes (permanent freezes) are either due to using blocking socket with infinite timeout (0), OR due to access violation exception within PSP side (crashes with fast memory or freezes without fast memory) probably due to register/memory corruption during a callback/mipscall, while minor freezes (short freezes) are usually due to lost packets

Currently i'm trying to implement a better blocking socket implementation by using sceIo as references to fix the freezes related to blocking sockets, but hecks i don't even understand how sceIo works LOL

well i cannot figure it out either how to not block the main emulator host os thread even tunneling project aka amultios protocol all use non blocking operation. as all of the packet is queued on another host os thread and use compression alot it can travel on network very fast. i don't even understand how ppsspp main thread work to just continue the emulation and not waiting the packet as its already processed in the background instead of inside HLE call.

looks like we re working on same issues actually need to figure it out how to make better blocking socket. the timing is so sensitive here so i need to delay some packet that arrived too fast or just block when its not arrived and give up. most of our packet timing is faked in getState or getPeerList the game that broke by this implementation is Digimon World Re:Digitize . Monster Hunter is fine if the packet time that fake time received can handled properly.

the one that make game permanent freeze is for sure is on sceNetAdhocctlInit function that not implement another psp thread do its work (friend finder etc) if we fail to connect into adhoc control (proadhocserver) just create the adhoc control and update it later from the real server. this is what real psp do update the control later when we re connected like peer and such. we cannot rely on single point of failure here were simulating adhoc network the create is never fail if its meets the requirement based on previous HLE call. ppsspp just return the error wrong code often if we fail.

already implement this partially in amulios protocol but not really create the adhoc control thread on psp kernel yet to make it work properly. we have some error like ERROR_NET_NOMEDIUM << this can be used if the control is not connected but create should be never fail. there is an issues on digimon that i use to dig this behavior how the game use the adhocctl function with some proper test on 2 PSP . still waiting on another of my 2 PSP to arrive.

another short freeze is that timeout 0 on blocking socket yes its waiting for packet but we must avoid blocking the hle thread . just keep the networking thread in host background running and poll from there with the timeout parameter. game like tekken is really helped with this implementation especially over internet as we re always have packet if there is no packet in the background then thats means the connection sucks :v . on local play its looking really good relying with this implementation.

right now im working on something that like SocketManager , NetPlayProtocolManager , and some of PacketManager to handle the packet in the background and sync that with the emulated sceNetAdhocPdp and sceNetAdhocPtp so we can simulate the timing better. looks like we re getting into working on sames issues to be resolved on https://github.com/hrydgard/ppsspp/issues/10832