VisualBoyAdvance-M

it keeps on creating it in appdata, i dont want that [img]<fileStore.core_Emoticons>/emoticons/sad.png[/img]/emoticons/sad@2x.png 2x" width="20" height="20" />

either your ini is not named vbam.ini its named vba.ini or you have multiple instances of the vba process open which has it always write to the appdata (a legit bug)

Seems to work now, must have been what you describe, sorry.

Got a "second player disconnected" message while link mode is deactivated, though...

that would've meant you had 2 instances open.... another bug to be fixed when adam returns.

I've got this issue as well, and I'm a little confused about what's actually occurring.

 

Is there anything I can do about the phantom second instance? My native saves from every game I've loaded since the bug started have, unfortunately, been overwritten as a result, and if no save is present, the default one has the "-2" added, as if I were the second player.

 

Clearing the .ini from AppData didn't solve anything, though I didn't think it would. Do I need to poke around in the registry? Blocking the program in Windows Firewall also doesn't help.

 

In regards to the "Player 2 Disconnected" message, I can only get that to pop up when loading a non-GBA rom, which makes sense.

Well, I don't manage the project, but I'm reading that somebody who does left that as a bug side effect standing to be mended.

 

So to prevent the phantom process from being created, I don't think it should be possible for a second copy of the process to launch if you've only ran the executable once, since the last time you checked using a Windows processes viewer that any subsequent times of opening the program didn't leave the process open, before opening it again. It should be easy to just right-click the taskbar, "Start Task Manager", to do a safety check, or you can just leave a third-party process viewer constantly open like I do.

 

About the INI file issues, I wrote my own algorithm for configuration file access, but there are still at least a couple other settings file access methods that Adam could have used in the source. (I am too lazy to check lol; I don't use MSVC anyway.) The "private profile" read and write classes provided by Microsoft kind of come at the expense of a bunch of other built-in functions that do unneeded things like access the registry anyway, so maybe that would have played a part in that sort of issue.

Yeah, Task Manager never shows another instance of it running. I can confirm when the issue arises, though. Test this at your own peril, because it seems to permanently fuck any system on which it is performed.

 

Open an instance of 1030b, enable GBA Linking, and start a server. Open another instance, record the IP Address from the previous instance, and connect under the "Client" tab.

 

After that, any instance of 1030b that you open will treat you as the second player on the computer, writing .ini setting to AppData and treating your saves differently. You'll also get the "Second Player Disconnected" message when starting a GBC game.

 

I'm not sure if it occurs when doing the standard connection through localhost. For what it's worth, both computers on which this was tested were running Windows 7 x64.

Hah, I had to actually update the version of VBA-M I had installed from 3 years ago, just to get this far. [img]<fileStore.core_Emoticons>/emoticons/biggrin.png[/img]/emoticons/biggrin@2x.png 2x" width="20" height="20" />

 

I'm running 64-bit Windows 7 as well, although I don't have any GBC games to test (or any familiarity with them honestly ;P). I did as you described and got some blank, text-less error dialogue box from one window, got an "all players connected" success dialogue message from the second instance of VBA 1030b. I've not found a way to get a disconnection error message as player 2 on this simple GBA chess game I have installed.

 

About the INI, though, I got it to stop creating under AppData\Roaming\VBA-M by renaming my old VBA.INI initialization settings file to VBAM.INI, just adding the 'm'. Of course I would then get at least one error message about incompatibility with the settings methods that the original VBA used, but then that's easy to correct.

the second, third, 4th instances always use the ini in appdata (needs to be fixed)

 

but this doesn't "Fuck" anything. the first instance (when all have been closed) always uses the local vbam.ini file and default battery file naming

alright, just committed a fix for the app data annoyances, have to wait for adamn to come back and update the link version