harik

I did some work back in the early fragmented mod era towards fixing exactly that, by using name-based dynamic mappings in the save file. Since vanilla blocks were at their same numbers, it was compatible with vanilla. All mods got dynamic IDs, and I added a tag to each chunk that was a compressed form of the mapping (Vanilla{1=1,2=2,3=3} Buildcraft{1=4096,2=4097}...) Basically it didn't matter what mods you had or what order they loaded in, the world was always coherent. When loading, if a mapping corresponded to a mod you didn't have, it cloned an airblock to that ID. I could start a world (with mods), place mod blocks, save it, remove the mods, load the world - the missing mod blocks looked and acted like air - save it again, re-add the mods, re-load and the mod blocks were back where they should be. It also worked when multiple mods claimed the same ID, by presenting blocks to them with the ID they expected, but maintaining a different ID in the in-memory storage. It didn't have much overhead in runtime or storage, since the on-disk format was identical to vanilla with an extra compound tag that vanilla would ignore.

Adding commands server side, either via local server or remote server is easy. I'm trying to migrate WorldeditCUI to 1.5.1/latest forge, and the sticking point is capturing commands at the local end so it can inject them via the worldedit API channel. What the author currently does is abuse reflection to change private fields to public using the obfuscated field names, and tries to inspect every packet added to the network queue to see if it's of type 'Packet3Chat', and if so decode it and see if it should be passed on or not. Ugh. Even if you ignore how hideously ugly that is, it doesn't work with forge as forge overrides some of the classes it intends to hook so bombs out with an unknown field error. It looks like the cleanest place to hook it would be net.minecraft.client.Minecraft.handleClientCommand(string), which is a stub that currently doesn't do anything, and forge already replaces that class. Unless I'm missing something, hooking chatHandler only handles received chat from the server, outbound commands do not show up there. My thought was adding a registerLocalCommand(string command, ILocalCommandHandler) to something (NetworkRegistry?) and have handleClientCommand() call that. Is there a better way to intercept some commands (at the client) before they're sent to the server and handle them locally? If not, is there any interest in me coding this up and submitting it?