Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Go!Explore - kicks back to PPSSPP home screen #15932

Closed
5 tasks done
meowthed opened this issue Aug 30, 2022 · 18 comments · Fixed by #18665
Closed
5 tasks done

Go!Explore - kicks back to PPSSPP home screen #15932

meowthed opened this issue Aug 30, 2022 · 18 comments · Fixed by #18665
Labels
I/O Affected by I/O timing settings, or other kind of I/O issue.
Milestone

Comments

@meowthed
Copy link

meowthed commented Aug 30, 2022

Game or games this happens in

Go!Explore

What area of the game / PPSSPP

Currently, running any of the Go!Explore discs would boot up before kicking back to the PPSSPP menu screen. These titles require the use of a NavNGo GPS, attached to the USB.

What should happen

I don't have real hardware to test in hand but I assume that once the title finds the GPS device, it would work fine, just like in this video: https://www.youtube.com/watch?v=o2IHJBbdqfA

Logs

ppsspplog.txt

Platform

Other

Mobile phone model or graphics card

OPPO:CPH2349, Nvidia Geforce GT 740M

PPSSPP version affected

1.13.1

Last working version

No response

Graphics backend (3D API)

Other

Checklist

  • Test in the latest git build in case it's already fixed.
  • Search for other reports of the same issue.
  • Try resetting settings or older versions and include if the issue is related.
  • Try without any cheats and without loading any save states.
  • Include logs or screenshots of issue.
@anr2me
Copy link
Collaborator

anr2me commented Aug 30, 2022

Probably need to emulate the usb device for the GPS too for the app to run, right? or is this app supposed to run (at least not to crash/exit immediately) even without GPS device plugged in?

@meowthed
Copy link
Author

yeah, I need someone with a real PSP to test if it does exit to menu if it doesn't find the USB device.

@sum2012
Copy link
Collaborator

sum2012 commented Aug 31, 2022

From full debug log ,https://gist.github.com/sum2012/3dcbd12fa1e2796a97470a7014060b66
I only see this usb thread
54:10:418 user_main D[SCEKERNEL]: HLE\sceKernelEventFlag.cpp:241 291=sceKernelCreateEventFlag(DTECT_USB_GPS_SUSPEND, 00000000, 00000000, 00000000)

@sum2012
Copy link
Collaborator

sum2012 commented Aug 31, 2022

It can run in Jpcsp emulator
1
From jpcsp log
https://gist.github.com/sum2012/2062c43bb5830b921a25f9bff93720ca
06:03:55 WARN hle.ThreadManForUser - user_main - hleKernelWaitEventFlag already another thread waiting on it

@anr2me
Copy link
Collaborator

anr2me commented Sep 1, 2022

Do you also have the logs from real PSP @sum2012 ?

@sum2012
Copy link
Collaborator

sum2012 commented Sep 1, 2022

@anr2me here it is https://gist.github.com/sum2012/37da5ea25c65507a0761c2efc5dc7799
It get error code SCE_KERNEL_ERROR_EVF_MULTI
20:32:47.836720 user_main - -> sceKernelWaitEventFlag 0x2FC0307, 0x1, 0x10, 0x9FFD330, 0x0 = 0x0
20:32:47.836769 user_main - <- sceKernelWaitEventFlag 0x2FC0307, 0x1, 0x10, 0x9FFD330, 0x0 = 0x800201B0

@anr2me
Copy link
Collaborator

anr2me commented Sep 1, 2022

0x800201b0 = this event flag cannot accept waits with multiple threads

is this mean race condition?
Does the app freezes on real PSP while getting those errors? or you can still see something changed on the screen?

@sum2012
Copy link
Collaborator

sum2012 commented Sep 1, 2022

No problem

Does the app freezes on real PSP while getting those errors? or you can still see something changed on the screen?

@Florin9doi
Copy link
Contributor

Currently GoExplore not only that fails to start, but crashes the emulator completely. The crash is observed at this line :

myVector.reserve(entry->children.size() - 2);

image

@anr2me
Copy link
Collaborator

anr2me commented Jan 2, 2024

Did you know what was the value returned from entry->children.size() ? (you can use the Watch to get the value)

@hrydgard
Copy link
Owner

hrydgard commented Jan 2, 2024

Fixed the crash. However, this thing is weird. Additionally to the weirdness mentioned above, it tries, and fails, to open the paths "/filelist.txt" and "/READHELPER.idx", which we interpret as references to the memory stick, but presumably it means the UMD. I think it's likely we're just handling paths starting with "/" wrong.

@Florin9doi
Copy link
Contributor

Florin9doi commented Jan 2, 2024

On PSP, READHELPER.DAT and READHELPER.IDX are created in the memory card's root during every start.
image

They are created on PPSSPP also, but they are empty:
image

@anr2me
Copy link
Collaborator

anr2me commented Jan 2, 2024

On PSP, READHELPER.DAT and READHELPER.IDX are created in the memory card's root during every start. image

They are created on PPSSPP also, but they are empty: image

According to this, those files also existed in the disc.

@Florin9doi
Copy link
Contributor

sceIoDread doesn't work for disc0:/ paths ?
jpcsp returns PSP_GAME and then all its subdirs.

jpcspppsspp
DEBUG hle.IoFileMgrForUser - user_main - sceIoChdir path=0x08C60CD4('disc0:/')
 INFO hle.IoFileMgrForUser - user_main - pspiofilemgr - filepath disc0
DEBUG hle.IoFileMgrForUser - user_main - sceIoChdir returning 0x0
DEBUG hle.IoFileMgrForUser - user_main - sceIoDopen dirname=0x08C60CDC('/')
DEBUG hle.IoFileMgrForUser - user_main - sceIoDopen - isofilename = 
DEBUG hle.IoFileMgrForUser - user_main - sceIoDopen returning 0x3
DEBUG hle.IoFileMgrForUser - user_main - sceIoDread id=0x3, direntAddr=0x09FFF290
DEBUG hle.IoFileMgrForUser - user_main - sceIoDread id=0x3 #1 dir='disc0', dir='PSP_GAME'
DEBUG hle.IoFileMgrForUser - user_main - sceIoDread returning 0x1
DEBUG hle.IoFileMgrForUser - user_main - sceIoDopen dirname=0x09FFF190('/PSP_GAME/')
DEBUG hle.IoFileMgrForUser - user_main - sceIoDopen - isofilename = PSP_GAME
12:19:440 user_main    D[SCEIO]: HLE\sceIo.cpp:2124 sceIoChdir(disc0:/)
12:19:471 user_main    D[SCEIO]: HLE\sceIo.cpp:2409 sceIoDopen("/")
12:19:471 user_main    D[SCEIO]: HLE\sceIo.cpp:2471 sceIoDopen ret = 283
12:19:471 user_main    D[SCEIO]: HLE\sceIo.cpp:2497 sceIoDread( 283 09fff490 ) - end
12:19:472 user_main    D[SCEIO]: HLE\sceIo.cpp:2552 sceIoDclose(283)
12:19:472 user_main    D[SCEIO]: HLE\sceIo.cpp:2409 sceIoDopen("/")
12:19:472 user_main    D[SCEIO]: HLE\sceIo.cpp:2471 sceIoDopen ret = 284
12:19:472 user_main    D[SCEIO]: HLE\sceIo.cpp:2497 sceIoDread( 284 09fff490 ) - end
12:19:473 user_main    D[SCEIO]: HLE\sceIo.cpp:2552 sceIoDclose(284)

@Florin9doi
Copy link
Contributor

image

@Florin9doi
Copy link
Contributor

Florin9doi commented Jan 4, 2024

v2

diff --git a/Core/FileSystems/MetaFileSystem.cpp b/Core/FileSystems/MetaFileSystem.cpp
index 5dece8e210..2f36663e2f 100644
--- a/Core/FileSystems/MetaFileSystem.cpp
+++ b/Core/FileSystems/MetaFileSystem.cpp
@@ -372,7 +372,13 @@ std::vector<PSPFileInfo> MetaFileSystem::GetDirListing(const std::string &path,
        std::lock_guard<std::recursive_mutex> guard(lock);
        std::string of;
        IFileSystem *system;
-       int error = MapFilePath(path, of, &system);
+
+       int error;
+       if (path == "/") {
+               error = MapFilePath(currentDir[__KernelGetCurThread()], of, &system);
+       } else {
+               error = MapFilePath(path, of, &system);
+       }
        if (error == 0) {
                return system->GetDirListing(of, exists);
        } else {

@hrydgard
Copy link
Owner

hrydgard commented Jan 4, 2024

Huh, interesting. Looks like we're indeed missing some handling there. Although, '/' should probably not be relative to currentdir but to the root of the currentdir.

@Florin9doi
Copy link
Contributor

This issue is observed only for ISOs and not for memstick.

  1. MetaFileSystem::MapFilePath(_inpath="/") is mapped to prefix: "disc0:", path: ""
    outpath = realpath.substr(prefixPos + 1);
  2. ISOFileSystem::GetDirListing(path="") is called
    std::vector<PSPFileInfo> ISOFileSystem::GetDirListing(const std::string &path, bool *exists) {
  3. ISOFileSystem::GetFromPath(path="") returns &entireISO
    return &entireISO;
  4. entireISO doesn't have any children and ISOFileSystem::GetDirListing(path="") returns an empty vector
    for (size_t i = 0; i < entry->children.size(); i++) {

v3

diff --git a/Core/FileSystems/ISOFileSystem.cpp b/Core/FileSystems/ISOFileSystem.cpp
index 4fb682684e..f070ff362f 100644
--- a/Core/FileSystems/ISOFileSystem.cpp
+++ b/Core/FileSystems/ISOFileSystem.cpp
@@ -647,6 +647,9 @@ std::vector<PSPFileInfo> ISOFileSystem::GetDirListing(const std::string &path, b
                        *exists = false;
                return myVector;
        }
+       if (entry == &entireISO) {
+               entry = GetFromPath("/");
+       }

        const std::string dot(".");
        const std::string dotdot("..");

Can I submit a PR with this patch?

hrydgard added a commit that referenced this issue Jan 6, 2024
Fix Go!Explore🗺️🧭 issue with GetDirListing(/); closes #15932
@hrydgard hrydgard added this to the v1.17.0 milestone Jan 6, 2024
@hrydgard hrydgard added the I/O Affected by I/O timing settings, or other kind of I/O issue. label Jan 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I/O Affected by I/O timing settings, or other kind of I/O issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants