Map Interface Standard

[Fabiari]

Discussion thread for Map Interface Standard. If you would like to add a comment, click the Post Reply button.

[Soresha]

I proposed changing the map standards to include the new riftway xml files when I was working on InfoMap for GU4. I had 2 positive responses, but didn't feel that alone was justification to go ahead and change the wiki. Maybe a new thread here will get more attention.

Riftways

The discussion so far:

Soresha:
http://vginterface.com/forums/sh...&postcount=134

Anyone wishing to build InfoMap into another UI mod please take note:
InfoMap now has it's own versions of the RiftMaps.xml and RiftAnimations.xml files under the Map directory.

How do people feel about changing the "Map Standards" defined on the wiki to include these new files? Because technically I just broke the current standards, heh.

Aalwein:
http://vginterface.com/forums/sh...&postcount=135

Anytime the game changes dramatically (as it has for GU4) I don't think a change in the "standards" is unwarranted. Better to adjust the standards then to have every new UI mod be uncompatible with each other.

Xndyr:
http://vginterface.com/forums/sh...&postcount=142

Soresha, I agree with you. I think when SOE releases a game update that changes any aspect of the Map in the default, and XML/Files that are used by it, we should adjust the Map Standards so that all UI mods can still interoperate correctly.

With this update, all mods should reflect the newly added riftmaps, and by updating the Map Standard, we can help ensure that any Map Mods and UI mods will continue to work together correctly.

The structure I used in InfoMap v1.4 for GU4 is:

-+ UiDir
|-+ Map
| |-- MapSkin.xml
| |-- RiftAnimations.xml
| |-- RiftMaps.xml
| |-- VGUIMiniMap.xml
| `-- VGUIMap.xml
|
|-- Index.xml
`-- SkinInfo.xml

To my knowledge, versions of the following mods have been released for GU4 with InfoMap included in them: AssimX UI, CoreUI3, Darker2.0 UI, ManicUI and MyUI.

For standalone use, InfoMap does not have the structure given on the wiki (with Index.xml and SkinInfo.xml inside the Map directory). It is identical to above but "UiDir" is simply "InfoMapAdvanced". I have no idea how or why this difference exists (I only just realised now that the wiki said something different!) However there are thousands of players who are used to seeing the current InfoMap structure so at this point I'd suggest changing the wiki rather than causing confusion amongst the playerbase.

Expanding Map Mods

There's another problem I'm currently encountering whilst writing new features for the future v1.5 of InfoMap. The map standards prevent me from adding my own xml files, I believe I can only add to the existing files? Well my VGUIMap.xml is getting ridiculously long now, so I'm looking for suggestions on how to manage this with the authors who are including InfoMap in their mods or wish to make their UIs compatible with InfoMap. Alternatives I can see are:

1) Break the map standards, add my own files as necessary and cause confusion with UI authors and players making their own compilations. Not really an option! But I'm listing it here as something I have ruled out.

2) Accept the restriction and live with VGUIMap.xml going over 10,000 lines. Awful to work with, but this is the route I'm taking atm.

3) Is there any way to add xml files without putting them in the index.xml? I tried using "include file" but with no luck. I suspect this can't be done and all xml files must be referenced in index.xml, but maybe someone else can think of another way to do this?

4) Add a number of dummy files that can be used by map modders as necessary to expand map mods. Eg:

-+ UiDir
|-+ Map
| |-- MapSkin.xml
| |-- RiftAnimations.xml
| |-- RiftMaps.xml
| |-- VGUIMiniMap.xml
| |-- VGUIMap.xml
| |-- MapExtra01.xml
| |-- ...
| `-- MapExtra10.xml
|
|-- Index.xml
`-- SkinInfo.xml

If the community would accept something like this, I could divide all the extra xml for InfoMap across the extra files. I doubt v1.5 would have enough to require 10 files so some would remain empty stubs for now, but this would allow the flexibility to use more files in the future as and when necessary.

Your thoughts please!

Thanks,

Soresha