Use path-based keys in MPMaps.ini

[CnCRAZER]

This pull request solves issue #842

Refactor the MultiMaps section in package\INI\MPMaps.ini to replace numeric index entries (e.g. "0=Maps...") with explicit path-based key=value entries (e.g. "Maps...=Maps...").

Update the mpmaps-updater service (tools\mpmaps-updater\service\mpmaps-updater.service.ts) to read/write the new format so map lookups don't rely on numeric ordering and are easier to maintain.

[Copilot]

Pull request overview

This pull request refactors the MultiMaps section in MPMaps.ini to replace numeric index entries with explicit path-based key=value entries, solving issue #842. This change produces stable, minimal diffs when maps are added or removed, eliminating the large diffs caused by renumbering all entries.

Changes:

• Updated mpmaps-updater.service.ts to generate path-based keys instead of numeric indices for the MultiMaps section
• Converted all 561 map entries in MPMaps.ini from numeric format (e.g., 0=Maps\...) to path-based format (e.g., Maps\...=Maps\...)

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
tools/mpmaps-updater/service/mpmaps-updater.service.ts	Modified the updateMultiMaps method to use map paths as keys instead of sequential numeric indices, with explanatory comments
package/INI/MPMaps.ini	Converted 561 map entries from numeric to path-based format in the [MultiMaps] section

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[DeathFishAtEase]

To be honest, I originally just took the case where the key and the value are the same can also work properly as an example. What I actually had in mind was to handle it at the client processing layer later to allow for a syntax similar to Ares' +=. But it's no big deal, using this method to solve it is also good.

[CnCRAZER]

To be honest, I originally just took the case where the key and the value are the same can also work properly as an example. What I actually had in mind was to handle it at the client processing layer later to allow for a syntax similar to Ares' +=. But it's no big deal, using this method to solve it is also good.

I take things literally 😆

[MahBoiDeveloper]

Overcomplicated IMO. Better to change client's code to read only keys that are paths to the maps, i.e.

[MultiMaps]
Maps\YR\Survival\example

[Maps\YR\Survival\example]
; Map settings

[DeathFishAtEase]

Overcomplicated IMO. Better to change client's code to read only keys that are paths to the maps

Ah, this one is good, and it's perfectly acceptable too, even though it's not the standard key=value syntax (besides, such a list doesn't require complex standards at the syntax parsing level anyway).

[CnCRAZER]

Overcomplicated IMO. Better to change client's code to read only keys that are paths to the maps, i.e.

[MultiMaps]
Maps\YR\Survival\example

[Maps\YR\Survival\example]
; Map settings

@DeathFishAtEase @MahBoiDeveloper In your opinions how should we proceed on this matter? Try and get XNA to read just the paths or is this PR change good as temporary solution?

[DeathFishAtEase]

your opinions how should we proceed on this matter?

If he is willing and able to add support for the described approach soon, I think it would be better to rebase the branch where the PR is located onto the develop branch after updating the client program, and add handling for TypeScript and INI files.
Otherwise, in my opinion, the existing solution is perfectly acceptable to start using immediately.