PCSX2 Langs folder was being changed to an EmuCR location?

[Ryudo]

Yes.... you read the topic right. I have no idea what's going on here.

First of all, let me clarify - I did not get my PCSX2 from EmuCR. I got it from the buildbot site.


After I had let PCSX2 create a clean ini file, I wanted to make it point to the Langs folder located under My Documents/PCSX2, rather than the root PCSX2 directory.
So I changed the following:

Code:

UseDefaultLangs=enabled

to

UseDefaultLangs=disabled

And changed the folder location line to:
Langs=F:\\Users\\Ryudo\\Documents\\PCSX2\\langs

Upon changing it, it seemed fine, but after I closed PCSX2, the .ini file was updated again automatically and this was added:
Langs=F:\\pcsx2\\EmuCR-Pcsx2-20141005\\sersyudoocumentsCSX2angs

I was able to reproduce this twice. I deleted the old inis to make sure it wasn't fetching the info from there and just let pcsx2 create clean ini files.


Nobbs suggested I tried an older build (a build prior to some changes made to the Langs files), and after testing that version it seemed to stick like normal even after closing PCSX2. The WEIRD PART HOWEVER, is that even the version that was bugged before now seems to work OK, and the weird EmuCR line isn't being readded.

I have no idea where this originated from though, and why it was doing this to clean ini files in the first place. Does anyone else have any idea what may have been causing it?

I'll keep an eye on my settings just in case to see if it gets changed randomly again.

[gregory]

maybe it uses a string from the windows database (regedit stuff)

[refraction]

yeh it sounds like an old registry string from when you did download an EmuCR version, this is one reason we advise against those builds

Anyway this isn't a bug, this is user error and not cleaning up after a dodgy build, not really something we can fix, so moving to support.

[Akio]

Anyway this isn't a bug, this is user error and not cleaning up after a dodgy build, not really something we can fix, so moving to support.

It's PCSX2 that reads the value, isn't it? Why can't you fix this?

[refraction]

It's PCSX2 that reads the value, isn't it? Why can't you fix this?

PCSX2 reads the value, but PCSX2 (at least our version) didn't put it there. The user has previously configured an EmuCR version and hasn't cleaned it up before putting an official one on, this isn't a bug.

[Ryudo]

Well the last time I used any emucr version was literally 2 years ago. And my Windows has been reinstalled since then multiple times. I did import some registry files. But what was imported was ffdshow settings only (contained in a .reg file).

[refraction]

Well you have remenants of emuCR somewhere, we have NO (I mean 100% absolutely none) code which would reference EmuCR or put files there, this is leftovers from you having an EmuCR version previously and I damn well refuse to "fix" something caused by a 3rd party build which we recommend against getting because we don't know what may be in those builds.

Your issue is either registry or a rogue ini file laying around somewhere, failing that windows is sandboxing your folder and restoring previous versions.

[Blyss Sarania]

Ryudo and I did some investigating and it seems to be a combination problem.

First we did establish he has some old PCSX2 stuff in his registry. We don't know how it got there. He maintains it's from well before 2 years ago when he formatted and since some of the strings match REALLY old PCSX2 versions it seems to be. One of the strings points to a directory he says he hasn't ever had PCSX2 in on his current drive - rather it was there from before he got an SSD.

Either way what seems to have happened is PCSX2 read some of the stuff from the registry. It then seems to have combined the strings in a weird way to produce the above result. There is no string that matches "Langs=F:\\pcsx2\\EmuCR-Pcsx2-20141005\\sersyudoocumentsCSX2angs" exactly, rather it seems to be a combination of:

F:\\Users\\Ryudo\\Documents\\PCSX2\\langs

and

C:\pcsx2\EmuCR-Pcsx2-20141005\ (found in registry)

So, while I think the problem itself was caused by something in the registry, I think PCSX2 may have handled the value incorrectly and partially mixed two values. So I think there may be something to look at after all. Where is the code for this located? I'd like to take a look to see if I'm right.

That's my two cents.

[Akio]

PCSX2 reads the value, but PCSX2 (at least our version) didn't put it there. The user has previously configured an EmuCR version and hasn't cleaned it up before putting an official one on, this isn't a bug.

If the user edits a configuration file and closes PCSX2, shouldn't PCSX2 update the Registry? Actually, why does PCSX2 use both the Registry and the configuration file? In any case, the configuration file should take precedence over the Registry. Looks like a bug to me.

[Blyss Sarania]

If the user edits a configuration file and closes PCSX2, shouldn't PCSX2 update the Registry? Actually, why does PCSX2 use both the Registry and the configuration file? In any case, the configuration file should take precedence over the Registry. Looks like a bug to me.

It shouldn't use the registry (much) anymore. That's what this is about.

It used to use the registry a LOT, but we changed that because it was tacky and not the best way. So now it uses the ini. BUT there could be old config stuff in the registry, so it looks for it there and if it finds it it puts it in the INI and deletes the reg value.

I think that's what happened here, except it mixed the two values in a weird way.