Dissidia 012: Duodecim Final Fantasy

[AdamN]

(10-28-2015 08:30 PM)Sys-XN Wrote:  (THIS IS HAMACHI-RELATED.)

Hello, this is Sys, posting from another forum (DissidiaForums). I am posting today about some Networking problems involving Hamachi and PPSSPP that I have encountered with several of my online buddies over the course of a few days. If anyone else has encountered the same following issues as I have before, please chime in so we can resolve this together.

What I was trying to do over the last few days was basically to try to conduct a Group Battle in Duodecim 012 with more than 3 people. However, we have had very limited success with this because whenever one of us hosted a room with 3+ people, the farthest we've gone was the "Preparing for Online Battle..." screen and nothing more than that (Not counting that one exception where we were ACTUALLY able to get 3 different people to participate in a match, one of them being a spectator). Here are our PPSSPP Networking Settings:

Enable networking/WLAN = ENABLED
Change PRO ad hoc server IP address = one of our IPs in our party (we tried Coldbird but no one wanted to try DMZ-ing)
Enable built-in PRO ad hoc server = DISABLED
Change MAC address = UNCHANGED

Various errors encountered:

- Socket error when connecting to XX.X.XXX.XXX IP address
- Packet loss
- frame-by-frame lag in the miracle that 4 of us are able to proceed to the "Prepare for Online Battle" screen at once, cannot proceed to Party A/Party B screen

It is very frustrating that these redundant Networking problems are occurring with PPSSPP and Hamachi in the first place, and so, here's what we tried so far:

- hosting with several different IP addresses amongst our group (everyone left the Networking settings unchanged, making sure they're all the same otherwise)
- getting the host to enable "Enable built-in PRO ad hoc server" while everyone else disables this option

(Obviously, none of the above got us to play even a single match in a party of more than 3+ people)

I've started reading today about the implications of TCP and UPnP in the "Status Update on Coldbird / PRO Online" thread on coldbird.net. Have no idea how any of this connects to this issue since I have close-to-zero technical networking knowledge, so any help on this would be greatly appreciated.

Page 5 forum(dot)coldbird(dot)net/viewtopic(dot)php(questionmark)f=23&t=1067&start=40
Page 6 forum(dot)coldbird(dot)net/viewtopic(dot)php(questionmark)f=23&t=1067&start=50

------

QUICK-NOTE: We all otherwise have no problems playing 1v1 matches. They play perfectly with very few random crashes.

Try using this Win32 build https://www.dropbox.com/s/xdgwhfnwt8fuu3...s.zip?dl=0
(based on http://github.com/ANR2MERefork/ppsspp with a fix to some of the crash issue, but there is still one crash issue remaining)



PS: There seems to be a crash issue at Jit.cpp (at line: ((void (*)())enterDispatcher)(); ) when i started the multiplayer battle with 4 players (running 4 instances of the attached PPSSPP on the same computer), 2 of the players always crashed at the same location, while the other 2 are okay.

Edit: There is also an issue where Adhoc MatchingHandler MipsCall/Callback failed to return within 250ms while it usually only takes a few milliseconds making the game stuck unable to communicate properly, could be a race-condition occurred.

[Sys-XN]

(10-29-2015 06:42 PM)AdamN Wrote:  Try using this Win32 build [link]
(based on [link] with a fix to some of the crash issue, but there is still one crash issue remaining)



PS: There seems to be a crash issue at Jit.cpp (at line: ((void (*)())enterDispatcher)(); ) when i started the multiplayer battle with 4 players (running 4 instances of the attached PPSSPP on the same computer), 2 of the players always crashed at the same location, while the other 2 are okay.

Edit: There is also an issue where Adhoc MatchingHandler MipsCall/Callback failed to return within 250ms while it usually only takes a few milliseconds making the game stuck unable to communicate properly, could be a race-condition occurred.

I should also mention that we all run 64-bit with PPSSPP. If there is a 64-bit version of the 32-bit you posted, that would be great (we tried this build even though we all run 64 and it derped)

I will continuously post updates as necessary.

[AdamN]

(10-30-2015 07:22 PM)Sys-XN Wrote:  

(10-29-2015 06:42 PM)AdamN Wrote:  Try using this Win32 build [link]
(based on [link] with a fix to some of the crash issue, but there is still one crash issue remaining)



PS: There seems to be a crash issue at Jit.cpp (at line: ((void (*)())enterDispatcher)(); ) when i started the multiplayer battle with 4 players (running 4 instances of the attached PPSSPP on the same computer), 2 of the players always crashed at the same location, while the other 2 are okay.

Edit: There is also an issue where Adhoc MatchingHandler MipsCall/Callback failed to return within 250ms while it usually only takes a few milliseconds making the game stuck unable to communicate properly, could be a race-condition occurred.

I should also mention that we all run 64-bit with PPSSPP. If there is a 64-bit version of the 32-bit you posted, that would be great (we tried this build even though we all run 64 and it derped)

I will continuously post updates as necessary.

Updated:
Win64 build : https://www.dropbox.com/s/irubwwu9wf6lg9...4.zip?dl=0
Win32 build : https://www.dropbox.com/s/xdgwhfnwt8fuu3...s.zip?dl=0

Edit: After testing it further it seems the main issue was related to Adhoc MipsCall/Callback, either it's running on a wrong thread or not all registers used by the callback get restored after returning, thus corrupting some of the register (usually ended with invalid address warnings in the log)
This issue has been existed for a long time in some games.

[onelight]

(10-31-2015 01:42 AM)AdamN Wrote:  Updated:
Win64 build : https://www.dropbox.com/s/irubwwu9wf6lg9...4.zip?dl=0
Win32 build : https://www.dropbox.com/s/xdgwhfnwt8fuu3...s.zip?dl=0

Edit: After testing it further it seems the main issue was related to Adhoc MipsCall/Callback, either it's running on a wrong thread or not all registers used by the callback get restored after returning, thus corrupting some of the register (usually ended with invalid address warnings in the log)
This issue has been existed for a long time in some games.

https://github.com/ANR2MERefork/ppsspp/c...d564ff68fd
Added Port-shifting support for games that use privileged ports (< 1024) is good. But compile android build failed, what's wrong?

[AdamN]

(11-01-2015 07:30 AM)onelight Wrote:  

(10-31-2015 01:42 AM)AdamN Wrote:  Updated:
Win64 build : https://www.dropbox.com/s/irubwwu9wf6lg9...4.zip?dl=0
Win32 build : https://www.dropbox.com/s/xdgwhfnwt8fuu3...s.zip?dl=0

Edit: After testing it further it seems the main issue was related to Adhoc MipsCall/Callback, either it's running on a wrong thread or not all registers used by the callback get restored after returning, thus corrupting some of the register (usually ended with invalid address warnings in the log)
This issue has been existed for a long time in some games.

https://github.com/ANR2MERefork/ppsspp/c...d564ff68fd
Added Port-shifting support for games that use privileged ports (< 1024) is good. But compile android build failed, what's wrong?

Because that commit also includes multiple instance of PPSSPP support, which was intended for Dekstop (Windows, Linux and OSX) and not mobile devices, but i didn't know the exact definition to use to filter-out mobile device, and it seems using __linux__ will also include android devices
While the port-shifting support shouldn't have any issue with mobile.

Btw, the port shifting still need a GUI to set the port offset value, and i don't know how to add the GUI either.

Edit: i've made some new commits to fix compilation errors on non-windows platform along with some bug fixes https://travis-ci.org/hrydgard/ppsspp/builds/88635666

[AdamN]

After digging my old bugfix commits long ago (which didn't get merged) and i was right, the issue with crash/blank screen/disconnection with Dissidia 012 when playing with more than 2 players was due to registers corruption, just like what happened long ago on another game (i forgot which game was that, i think it was Lord of Arcana)

Here is the new build tested to play Dissidia 012 with 4 players in localhost without any issue
Win32: https://www.dropbox.com/s/xdgwhfnwt8fuu3...s.zip?dl=0
Win64: https://www.dropbox.com/s/irubwwu9wf6lg9...4.zip?dl=0

   

[Sys-XN]

Quote:After digging my old bugfix commits long ago (which didn't get merged) and i was right, the issue with crash/blank screen/disconnection with Dissidia 012 when playing with more than 2 players was due to registers corruption, just like what happened long ago on another game (i forgot which game was that, i think it was Lord of Arcana)

Here is the new build tested to play Dissidia 012 with 4 players in localhost without any issue

Win32: [link]
Win64: [link]

Thank you very much, your efforts are greatly appreciated. I will test this build amongst my friends as soon as I can, will report back ASAP ^^;

Also quick question, is this build able to support 5v5 for a maximum of 10 people at once in one session? For DF people like us, that has long been nothing more than a pipe dream ever since we migrated from Sony's extremely faulty PS3 AHP app, full of bugs, crashes, network desyncs, and overall connection incompatability. We even birthed a nickname to it: "DDCFF" (Dissidia Disconnections Final Fantasy) ;(

I will also list what happened when we tested the previous build you linked, AdamN.
[previous attempted build fix testing 1.1.1.1-1-2]
- same errors as before
- white screen
- FPS counter displays in gibberish

[onelight]

(11-01-2015 08:54 AM)AdamN Wrote:  Because that commit also includes multiple instance of PPSSPP support, which was intended for Dekstop (Windows, Linux and OSX) and not mobile devices, but i didn't know the exact definition to use to filter-out mobile device, and it seems using __linux__ will also include android devices
While the port-shifting support shouldn't have any issue with mobile.

Btw, the port shifting still need a GUI to set the port offset value, and i don't know how to add the GUI either.

Edit: i've made some new commits to fix compilation errors on non-windows platform along with some bug fixes https://travis-ci.org/hrydgard/ppsspp/builds/88635666

Thanks for fixed non-windows builds. compile android success. And it working fine
testing on android
   
   
   
   

[AdamN]

(11-02-2015 12:56 PM)Sys-XN Wrote:  

Quote:After digging my old bugfix commits long ago (which didn't get merged) and i was right, the issue with crash/blank screen/disconnection with Dissidia 012 when playing with more than 2 players was due to registers corruption, just like what happened long ago on another game (i forgot which game was that, i think it was Lord of Arcana)

Here is the new build tested to play Dissidia 012 with 4 players in localhost without any issue

Win32: [link]
Win64: [link]

Thank you very much, your efforts are greatly appreciated. I will test this build amongst my friends as soon as I can, will report back ASAP ^^;

Also quick question, is this build able to support 5v5 for a maximum of 10 people at once in one session? For DF people like us, that has long been nothing more than a pipe dream ever since we migrated from Sony's extremely faulty PS3 AHP app, full of bugs, crashes, network desyncs, and overall connection incompatability. We even birthed a nickname to it: "DDCFF" (Dissidia Disconnections Final Fantasy) ;(

I will also list what happened when we tested the previous build you linked, AdamN.
[previous attempted build fix testing 1.1.1.1-1-2]
- same errors as before
- white screen
- FPS counter displays in gibberish

The previous builds didn't even works with 3 players, but my last builds should works, not sure about 5v5 i only tested it on Group Battle using Tournaments mode.

(11-02-2015 01:33 PM)onelight Wrote:  

(11-01-2015 08:54 AM)AdamN Wrote:  Because that commit also includes multiple instance of PPSSPP support, which was intended for Dekstop (Windows, Linux and OSX) and not mobile devices, but i didn't know the exact definition to use to filter-out mobile device, and it seems using __linux__ will also include android devices
While the port-shifting support shouldn't have any issue with mobile.

Btw, the port shifting still need a GUI to set the port offset value, and i don't know how to add the GUI either.

Edit: i've made some new commits to fix compilation errors on non-windows platform along with some bug fixes https://travis-ci.org/hrydgard/ppsspp/builds/88635666

Thanks for fixed non-windows builds. compile android success. And it working fine
testing on android

Have you tried the port shifting feature on android? i never tested it on android.
Try changing the portOffset value to a number above 1024 (i recommend using a number above 5000) and test it on games that have issue on android.
Btw, i don't think we should talk about other games (non-Dissidia 012) in this thread

[Shinoda]

(11-02-2015 03:53 PM)AdamN Wrote:  The previous builds didn't even works with 3 players, but my last builds should works, not sure about 5v5 i only tested it on Group Battle using Tournaments mode.

First of all, What's up. I'm one of the guys from that group who wants Group Battles up and running.

We were able to get 3 people (Including person creating the room) in group battle with the 1.1.0 official release last Friday. Nothing more though. It was finicky but it did work. The limitations appeared to be that whoever hosts the PRO Ad-Hoc Server has to be the one who creates the Group Battle room. That was useful since the host was spectating and streaming on the matches on Twitch. I tried this new build you just put up on my own through localhost (actually 127.0.0.1 if you wanna be picky about it) and wasn't able to even do what we were doing last friday, let alone get 5 emus (including host) in. As soon as I would hit "Start Group Battle" with the host it would say dropped because of connection error.

I did a bit of traffic monitoring before while doing normal 1v1s through the lobby but have yet to try it with group battles... the emulator seems to be all over the place when it comes to ports it uses. Is it me or does it use UDP to connect to the host and then randomly assign a random TCP port between the 2 players when they initiate a match? It's been a while but I remember something ridiculous like that. Might be affecting how the Group Battles operates? Just throwing an idea out there. You probably know way more than I do already about the networking process behind the Ad-Hoc Server. Just a network security student here. I have yet to have full experience of the stuff.

Also, personal request while I'm here... Would be nice to have a way to connect to people without using a VPN or using DMZ... I know it's kind of a pipedream but it's would make things much easier for people who don't know crap about VPNs or worries about vulnerabilities of using something like Hamachi. Maybe a built in Tunneling thing? I don't know... I'm no programmer. I just would love to have the ability to connect to one main server somewhere and connect to people that way. Hell, if it was possible without messing with VPNs and such, i'd pay for a central server to run the basics for all of us. like Coldbird but without the need for people to know how to DMZ (And considering we're talking emulator here and not actual PSP, DMZing your main computer is a bad idea in general).

[AdamN]

(11-02-2015 07:40 PM)Shinoda Wrote:  

(11-02-2015 03:53 PM)AdamN Wrote:  The previous builds didn't even works with 3 players, but my last builds should works, not sure about 5v5 i only tested it on Group Battle using Tournaments mode.

First of all, What's up. I'm one of the guys from that group who wants Group Battles up and running.

We were able to get 3 people (Including person creating the room) in group battle with the 1.1.0 official release last Friday. Nothing more though. It was finicky but it did work. The limitations appeared to be that whoever hosts the PRO Ad-Hoc Server has to be the one who creates the Group Battle room. That was useful since the host was spectating and streaming on the matches on Twitch. I tried this new build you just put up on my own through localhost (actually 127.0.0.1 if you wanna be picky about it) and wasn't able to even do what we were doing last friday, let alone get 5 emus (including host) in. As soon as I would hit "Start Group Battle" with the host it would say dropped because of connection error.

I did a bit of traffic monitoring before while doing normal 1v1s through the lobby but have yet to try it with group battles... the emulator seems to be all over the place when it comes to ports it uses. Is it me or does it use UDP to connect to the host and then randomly assign a random TCP port between the 2 players when they initiate a match? It's been a while but I remember something ridiculous like that. Might be affecting how the Group Battles operates? Just throwing an idea out there. You probably know way more than I do already about the networking process behind the Ad-Hoc Server. Just a network security student here. I have yet to have full experience of the stuff.

Also, personal request while I'm here... Would be nice to have a way to connect to people without using a VPN or using DMZ... I know it's kind of a pipedream but it's would make things much easier for people who don't know crap about VPNs or worries about vulnerabilities of using something like Hamachi. Maybe a built in Tunneling thing? I don't know... I'm no programmer. I just would love to have the ability to connect to one main server somewhere and connect to people that way. Hell, if it was possible without messing with VPNs and such, i'd pay for a central server to run the basics for all of us. like Coldbird but without the need for people to know how to DMZ (And considering we're talking emulator here and not actual PSP, DMZing your main computer is a bad idea in general).

In Group Battle this is what the game did:

* Host (who create a room) will broadcast UDP data to everyone in the same Group on AdhocServer (usually everyone playing the same game) using port 1 every few seconds.

* Client (who scan for rooms) will bind to port 1 and when receiving the broadcasted data from Host will show a room in the screen.

* When Host started the battle, Host will delete the room and bind to port 1,2,3 (UDP) and 4 (TCP) and Clients will automatically try to connect to these ports on Host (when client detects that the battle has been started) and communicate for the rest of the battle using these ports.
If one of the client failed to connect to these ports on Host the rest of the players will stuck unable to start the battle.

You can try to open the console log to see what happening at the time it stuck/having connection issue.

If you're still having issue with 3/4 players, the only conclusion i can made is that there might be a possibility for a client to get kicked out (when the room gets deleted) before getting the information from Host that the battle has been started, thus making the client think it's just simply kicked out of the room and didn't try to connect to port 1-4 (may be related to packet loss on UDP)


About tunneling to a server, isn't it the same way what hamachi did? and tunneling to a remote server will only increase the latency isn't? and not many games works with high latency (afterall adhoc games was designed for LAN)
Anyway, the old adhoc code seems to contains a plan to implement UPNP for automatic port forwarding, but not sure who understand how to implement this, especially since we need to make it cross-platform.


Edit: I tried to test it with 6 players and it seems 3 of them getting blank screen
One of the client who gets blank screen seems to try executing an invalid opcode (0x05050505) which i think that number is a mac address instead of opcode, i guess there is another issue with the callback to be fix.

[Shinoda]

(11-02-2015 11:30 PM)AdamN Wrote:  * Host (who create a room) will broadcast UDP data to everyone in the same Group on AdhocServer (usually everyone playing the same game) using port 1 every few seconds.

* When Host started the battle, Host will delete the room and bind to port 1,2,3 (UDP) and 4 (TCP) and Clients will automatically try to connect to these ports on Host (when client detects that the battle has been started) and communicate for the rest of the battle using these ports.
If one of the client failed to connect to these ports on Host the rest of the players will stuck unable to start the battle.

So both the room and one of the potential ports for the battles is Port 1 (UDP)? Sounds like potential conflicts if packets don't go fast enough... I'm guessing that's built-in the game and not something the emulator could attempt to stabilize though, right? Like, Room is port 1 (UDP) and Battle is port 2 (UDP). No random ports and clients scanning for which of the 4 Host might have picked?

We did some tests tonight (with results that I think Sys should be posting soon) and we got it to work sometimes (Once in about 10 tries). Couldn't isolate variables. Some clients got to "Preparing for battle" and some others got "Room deleted" and even a few times the emulator just crashed when the host would start the battle.. Maybe the "Room deleted" events happened because of that random port crap and the others got the preparing for battle because they succeeded in finding the port?

No blank screens to report though.

[AdamN]

(11-03-2015 02:47 AM)Shinoda Wrote:  

(11-02-2015 11:30 PM)AdamN Wrote:  * Host (who create a room) will broadcast UDP data to everyone in the same Group on AdhocServer (usually everyone playing the same game) using port 1 every few seconds.

* When Host started the battle, Host will delete the room and bind to port 1,2,3 (UDP) and 4 (TCP) and Clients will automatically try to connect to these ports on Host (when client detects that the battle has been started) and communicate for the rest of the battle using these ports.
If one of the client failed to connect to these ports on Host the rest of the players will stuck unable to start the battle.

So both the room and one of the potential ports for the battles is Port 1 (UDP)? Sounds like potential conflicts if packets don't go fast enough... I'm guessing that's built-in the game and not something the emulator could attempt to stabilize though, right? Like, Room is port 1 (UDP) and Battle is port 2 (UDP). No random ports and clients scanning for which of the 4 Host might have picked?

We did some tests tonight (with results that I think Sys should be posting soon) and we got it to work sometimes (Once in about 10 tries). Couldn't isolate variables. Some clients got to "Preparing for battle" and some others got "Room deleted" and even a few times the emulator just crashed when the host would start the battle.. Maybe the "Room deleted" events happened because of that random port crap and the others got the preparing for battle because they succeeded in finding the port?

No blank screens to report though.

I don't think it use random ports, everytime i tested it it always use port 1-4, i know it's an absurd port number in most system, but on a real PSP no other application is using those port, and all port can be used by the game i guess.
I updated my build recently to add another network option (thanks to LunaMoo) to change the port offset value so it won't use absurd or privileged (<1024) port anymore.

And client didn't actually "scan" but it listen to broadcasted data from host in order to know that there is room available.

Anyway, i think the remaining issue is caused by memory corruption in the PSP memory, which probably related to adhoc callback, as i have no information whether the buffer used by the callback should be managed (freed) by system or by the game, currently i assume it's allocated and freed by system (part of adhoc implementation) and i'm sharing the same buffer to be used for all matching events.
I'll try to separate the buffer for each event later to see whether it makes any difference when i had the time.

[Sys-XN]

(11-03-2015 03:17 AM)AdamN Wrote:  I don't think it use random ports, everytime i tested it it always use port 1-4, i know it's an absurd port number in most system, but on a real PSP no other application is using those port, and all port can be used by the game i guess.
I updated my build recently to add another network option (thanks to LunaMoo) to change the port offset value so it won't use absurd or privileged (<1024) port anymore.

And client didn't actually "scan" but it listen to broadcasted data from host in order to know that there is room available.

Anyway, i think the remaining issue is caused by memory corruption in the PSP memory, which probably related to adhoc callback, as i have no information whether the buffer used by the callback should be managed (freed) by system or by the game, currently i assume it's allocated and freed by system (part of adhoc implementation) and i'm sharing the same buffer to be used for all matching events.
I'll try to separate the buffer for each event later to see whether it makes any difference when i had the time.

Tonight's summary (64-bit build only):

2 out of 10+ attempts worked. Both times used my IP, all other attempts on other client's IP which failed. Note that the first succeeded attempt was with 3 players, and the second succeeded attempt was with 4 players. The total # of clients capped at 5 which failed.

Network settings used by everyone:
Enable Networking/WLAN = ON
Enable built-in PRO AdHoc server = ON (host only), OFF (everyone else)
Change MAC Address = changed at least once every time we tried a group session. (Does it matter what numerical digits the MAC address is? Always confused about that)

- One of our clients, after the second successful attempt with 4 people, suggested to us to try doing Group with us 64-bit people with his 32-bit test build, but only as a spectator. That attempt failed due to a network desync (most likely because not everyone was using the same bit and/or partly because there was too many people?)

- Most of the failed attempts were due to socket errors, white screens, crashes, and the like.

- The included attachment also shows the distorted/bugged graphical display of the PPSSPP's menus in the test build... it caused complications at first and it may cause more in the future with newer users of this test build if this isn't rectified.

=End of report=

- quick note, did you upload the wrong version of Windows 32? We all tried it and it didn't work out... either that or we didn't test it thoroughly enough
- Also, what does Port offset do exactly? We left it alone for most of our tests except one where we changed 0 -> 100 (seemed like it made no difference)

Good to know you tried playing with 6 people at least, although it didn't work out... hope this report helps in this endeavor

EDIT: A small suggestion, but would it help any if you coded it to force Dissidia to use only one specific port used by Sony so that it would always only use that port for everyone to connect to automatically? It should be a port that is already available and yet is commonly used... then again I don't know anything about networking stuff at all, but if it helps then ^^;

[AdamN]

(11-03-2015 03:52 AM)Sys-XN Wrote:  

(11-03-2015 03:17 AM)AdamN Wrote:  I don't think it use random ports, everytime i tested it it always use port 1-4, i know it's an absurd port number in most system, but on a real PSP no other application is using those port, and all port can be used by the game i guess.
I updated my build recently to add another network option (thanks to LunaMoo) to change the port offset value so it won't use absurd or privileged (<1024) port anymore.

And client didn't actually "scan" but it listen to broadcasted data from host in order to know that there is room available.

Anyway, i think the remaining issue is caused by memory corruption in the PSP memory, which probably related to adhoc callback, as i have no information whether the buffer used by the callback should be managed (freed) by system or by the game, currently i assume it's allocated and freed by system (part of adhoc implementation) and i'm sharing the same buffer to be used for all matching events.
I'll try to separate the buffer for each event later to see whether it makes any difference when i had the time.

Tonight's summary (64-bit build only):

2 out of 10+ attempts worked. Both times used my IP, all other attempts on other client's IP which failed. Note that the first succeeded attempt was with 3 players, and the second succeeded attempt was with 4 players. The total # of clients capped at 5 which failed.

Network settings used by everyone:
Enable Networking/WLAN = ON
Enable built-in PRO AdHoc server = ON (host only), OFF (everyone else)
Change MAC Address = changed at least once every time we tried a group session. (Does it matter what numerical digits the MAC address is? Always confused about that)

- One of our clients, after the second successful attempt with 4 people, suggested to us to try doing Group with us 64-bit people with his 32-bit test build, but only as a spectator. That attempt failed due to a network desync (most likely because not everyone was using the same bit and/or partly because there was too many people?)

- Most of the failed attempts were due to socket errors, white screens, crashes, and the like.

- The included attachment also shows the distorted/bugged graphical display of the PPSSPP's menus in the test build... it caused complications at first and it may cause more in the future with newer users of this test build if this isn't rectified.

=End of report=

- quick note, did you upload the wrong version of Windows 32? We all tried it and it didn't work out... either that or we didn't test it thoroughly enough
- Also, what does Port offset do exactly? We left it alone for most of our tests except one where we changed 0 -> 100 (seemed like it made no difference)

Good to know you tried playing with 6 people at least, although it didn't work out... hope this report helps in this endeavor

Thank for the report

For the GUI issue try downloading the latest official version from here http://buildbot.orphis.net/ppsspp/ and then overwrite the exe using my build, since my builds are based on those nightly version.

The port offset is used to prevent PPSSPP (PSP games) from using privileged port (<1024) which usually requires Admin rights and to prevent the game using an already used port (ie. there are games that use port 80 where some people using it for web server)
For example, if the game normally using port 80 with port shift = 5000 the actual port will be used by the game will be 5080 (and hopefully that port isn't being used by other application also), the game it self will choose the port they wanna use, emulator can only shift it.
So if you wanna use port shifting make sure to set it to 1024 or higher (i recommend higher than 5000), And all players need to use the same port offset in order to communicate properly.

Btw, what do you mean Win32 build didn't work? was it DLL issue? if it's you'll need to install the vcredist for 32bit also, on my laptop i installed both x86 and x64-bit of vcredist so both versions worked just fine on my laptop.
PS: I build those using visual studio 2015
Here is the vcredist for vs2015 https://www.microsoft.com/en-us/download...x?id=48145

Edit: I tried running 2x 64bit + 2x 32bit on localhost and didn't have any issue starting group battle (i tried round robin (3 rounds) this time), but after a few seconds in battle i did get network sync issue
And i was mistaken the port Dissidia 012 using is port 100-103 instead of 1-4 1-4 is the socket id

Btw, if you're having issue when Starting group battle, try starting it as soon as possible (right after the last player joined)

Edit2: I've reuploaded my builds to fix an issue with Port Shifting feature.