Can i rename a core?

I need to rename the filename of a core. MAME in particular. The latest MAME core other than the main one is mame2016. This is pretty old, i want to upgrade my set but i need the core to be stable after that while continue upgrading the latest core.

That means i need a mame_2019 or something like that. Can i rename the main MAME core to that and keep a second copy that i can continue to upgrade?

Is possible i think, you need to create a core info file to handle it by RetroArch.

Are you wanting to rename the core in your filesystem or what exactly? If you want it to show up by a different name in the core list inside RetroArch, you can just change the name inside the core info file. If you want it to create different directories etc. for core overrides, it needs to be compiled with a different name.

I want to rename it to something else than “mame_libretro” because i need a stable 0.213 core that won’t be updated anymore and i can still keep mame_libretro and update that. Not sure about the core directories though. Didn’t think of that.

ok, yeah, just rename it in your filesystem and rename the core info file to match and it won’t get overwritten by the core updater even if you accidentally try to update it.

2 Likes

Can confirm this works beautifully. I have my MAME 0.191 set to mame_v0191_libretro.dll. The hell with trying to keep a MAME romset up to date lol.

2 Likes

Ok i’m having this problem now.

I’m using mame for a bunch of systems like Tiger Game com. But there is a conflict in the core options.

mame_boot_from_cli = “disabled” - makes Game com games to not work. But mame roms work. mame_boot_from_cli = “enabled” - makes mame roms not work but game.com games do work.

How am i going to avoid this conflict? Renaming the core doesn’t work because they still share the same cfg folders

Could someone compile a “mame2019_libretro” core that also creates core config and shader with the new name?

As it is now, it’s impossible to use the main MAME core for both arcades and MESS systems. Arcades need “mame_boot_from_cli” to be enabled and other systems need it to be disabled. But there is no way to separate core options per directory like all other overrides.

1 Like

Well, I am not sure about this, but is there a 0.213 core yet??? I just updated my mame_libretro core on the PC and it says it is still v0.212??

Yeah it’s still at 0.212.

0.214 was released a few days ago btw.

I’ve been using my renamed MAME core for arcade, and my mame_libretro up-to-date core for MESS systems.

I don’t know a whole lot about MAME in general, but MESS even less… I just know my Neo Geo CD and Philips CD-i games are working well in this split setup.

Is there a benefit/need to use the old core for MESS systems? (I mean that as a sincere question, not as snarky as it might sound)

All i know is that i can’t use MAME for both arcades and some home systems at the same time.

Even if you rename the cores, they will still use the same cfg folders because the “internal” name is still the same. So the mame core options file is the same for any core you have renamed. They all share the same core options.

The problem with this is that some systems need a different core option to work. I’m talking about the “mame_boot_from_cli” option. Some systems need it disabled in order to boot. Arcades/MAME needs it enabled. Others like the Tiger gamecom or the Megaduck need it disabled. So you can’t use mame for all these systems at the same time because you can’t save different core options per directory.

The only solution right now is to use a second core that is compiled to save in different folders. The next best thing is mame2016. That’s the most recent one that isn’t the main core. But that’s too old. The other solution would be the ability to save core options per directory. This way you could have different core options per system and you could use the same core with no issues.

1 Like

Yeah that does make a lot more sense now. Particularly the "“mame_boot_from_cli” option. Some systems need it disabled in order to boot." That wasn’t something I’d run into yet as both MESS systems (NGCD and CD-i) I use need that turned on.

I don’t know if this helps, but barring any other solution, maybe?

I know at one point I needed vastly different configurations, and I honestly just duplicated my RetroArch install to another folder named “RetroArch_Alt” and made the few changes I needed there - then set a matching module in RocketLauncher to boot to my 2nd install for the system that needed said changes.

I don’t know if you even use a frontend like that, but maybe something along those lines could be a janky work-around. Hopefully there’s a more elegant solution though. That’s a pretty hard roadblock from the sound of it right now.

Yeah, i do use Rocketlauncher as well. And did a similar solution for a different problem. I had a separate RetroArch install for the cores that needed a different video driver. But since i started using GL for everything i deleted the extra install.

Seems that’s the only thing i can do again. I wish i could avoid that though, having extra folders and thousands of files that waste space, plus it makes the setup look janky like you said.