05-08-2006, 09:09 PM
We've had a few ups and downs along the way during the brief history our city has existed. In the beginning, before the game was released, there were fears in the general Elder Scrolls community that we would never be able to use custom models in our mods. If that had turned out to be true, we'd been nipped in the bud... but luckily we found out about the Civ4 NIF exporter, and lately NifSkope has come along and holds great promise.
Then came the problem of working together, as there was no way to merge plugins back then. We tried a little system of making plugins dependant on the alpha .esp, thinking that the alpha and plugins could be loaded together (like it was possible to do with TES3 mods). The isolationist problem put a stop to that system, since a plugin can't affect the same space as another plugin, so if you put a barrel in the exterior city in such a plugin it simply wouldn't turn up in the game.
Then came first TesSnip and then later on TES4 Plugin Utility, both of which can merge .esp's although TES4 P. U. had the added benefit of auto-renaming conflicting form ID's. If two form ID's conflict, only one of the items will turn up in-game. That allowed us to bring in several finished claims, and the current version of the main alpha has four contributions from modders other than myself.
That worked out pretty well, although it still wasn't possible for a plugin to be dependant on the main alpha. It's wanted to be able to have plugins dependant on it so that modders can interact with stuff that's already been added - like setting up AI behavior in the exterior town, for instance making an NPC stroll around town during the afternoons. So I got to thinking that if I made the main alpha an .esm file instead of an .esp then it should be possible for plugins to be dependant on it without the isolationist problem causing trouble. (because a plugin dependant on a plugin didn't work, since stuff wouldn't show up in the town exterior, it wouldn't have been possible for a modder to bugtest stuff s/he set up)
[blockquote]And I think it's safe to say that that part of the equation worked out. Just like a mod like "Oblivion Cats" can put felines in the towns of Cyrodiil, so could a plugin put stuff in the locations of the main alpha. And all was well... or so I thought.[/blockquote]
The problem was instead in the merging process. It turned out that a modder that affected anything related to the main alpha caused their plugin to save a copy of the ID of the affected entry. So if you put a vase in the town exterior, your plugin would keep a record of the town exterior worldspace itself. That shouldn't cause any problems while playing, since obviously mods like "Oblivion Cats" work without a hitch. But because there *are* two records, TES4 Plugin Utility will see that as a conflict and refuse to merge it. :bash:
The glimmer of hope I can see lies in TesSnip. TesSnip's drawback of not renaming form ID's or caring about conflicts could actually be a strength in this case, because it could merge plugins that really don't conflict, but which TES4 P.U. think they do. Conflicting form id's are still a problem, so it would be a shaky alternative at best, and it just feels like keeping plugins un-dependant on the main alpha in the future is the only safe and reliable way to go.
And that's ok, for now. It limits the amount of interaction a modder can set up with the outside world, but I don't mind setting that up on my end if I can. It won't give access to all the models that's been brought in, but perhaps one can make do without them for now. A plugin doesn't really have to be dependant on the main alpha right now.
It might have to soon, though... because I've almost finished setting up the first Redoran neighbourhood in Soluthis, and will soon get on with bringing in interior house models for the exteriors, and then we're pretty much set to open up Redoran claims. But how do you mod a Redoran home if you can't make your plugin dependant on the main alpha, and thus don't have access to the interior model? That, my friends, is the meat of my conundrum.
If you have any ideas on solutions, please, share them! I have an idea myself. Do you guys think it could work?
[title]"Base Plugins"[/title]
The "Base Plugins" would be a collection of .esp files. Each .esp contains just one interior house model list entry, and there would be one base .esp for each interior model. I'd link to the appropriate base .esp in each open claim I posted.
The base plugins wouldn't contain the models themselves; rather, those would ship with the main alpha package. They'd just have the list entry for the model in the construction set, so if the modder has extracted the main alpha package and load up the base .esp, they can drag-n-drop that list entry into an interior cell to get the interior model to show up. The IDs for the list entries would differ from those in the main alpha, but the location of the models would be the same.
Then, when time comes to merge their interior to the main alpha, I'd end up with two list entries for the same interior house model. Perfect - no conflicts reported by TES4 P.U. Then I just select their interior house model, go to "Edit > Search & Replace...", and switch it out with the standard list entry ID. Now, the interior model list entry from the merged plugin is unused, so I just delete it, freeing up that slot for the next plugin that uses the same base plugin.
A modder still wouldn't be able to affect anything outside their hut though, which is a pity. But an intrepid modder can expand the 'base plugin' idea and create new list entry ID's and hook them up to models from the main alpha package, and so would get to use as many custom models as he liked. Within reason!
Imagine a hundred plugins that each had two hundred list ID's that needed changing... if I spent a minute switching each ID, I'd have to keep at it for close to fourteen days straight, no sleep. Hehe. But a dozen of them, sure, that'd work.
Let the ideas flow!
Then came the problem of working together, as there was no way to merge plugins back then. We tried a little system of making plugins dependant on the alpha .esp, thinking that the alpha and plugins could be loaded together (like it was possible to do with TES3 mods). The isolationist problem put a stop to that system, since a plugin can't affect the same space as another plugin, so if you put a barrel in the exterior city in such a plugin it simply wouldn't turn up in the game.
Then came first TesSnip and then later on TES4 Plugin Utility, both of which can merge .esp's although TES4 P. U. had the added benefit of auto-renaming conflicting form ID's. If two form ID's conflict, only one of the items will turn up in-game. That allowed us to bring in several finished claims, and the current version of the main alpha has four contributions from modders other than myself.
That worked out pretty well, although it still wasn't possible for a plugin to be dependant on the main alpha. It's wanted to be able to have plugins dependant on it so that modders can interact with stuff that's already been added - like setting up AI behavior in the exterior town, for instance making an NPC stroll around town during the afternoons. So I got to thinking that if I made the main alpha an .esm file instead of an .esp then it should be possible for plugins to be dependant on it without the isolationist problem causing trouble. (because a plugin dependant on a plugin didn't work, since stuff wouldn't show up in the town exterior, it wouldn't have been possible for a modder to bugtest stuff s/he set up)
[blockquote]And I think it's safe to say that that part of the equation worked out. Just like a mod like "Oblivion Cats" can put felines in the towns of Cyrodiil, so could a plugin put stuff in the locations of the main alpha. And all was well... or so I thought.[/blockquote]
The problem was instead in the merging process. It turned out that a modder that affected anything related to the main alpha caused their plugin to save a copy of the ID of the affected entry. So if you put a vase in the town exterior, your plugin would keep a record of the town exterior worldspace itself. That shouldn't cause any problems while playing, since obviously mods like "Oblivion Cats" work without a hitch. But because there *are* two records, TES4 Plugin Utility will see that as a conflict and refuse to merge it. :bash:
The glimmer of hope I can see lies in TesSnip. TesSnip's drawback of not renaming form ID's or caring about conflicts could actually be a strength in this case, because it could merge plugins that really don't conflict, but which TES4 P.U. think they do. Conflicting form id's are still a problem, so it would be a shaky alternative at best, and it just feels like keeping plugins un-dependant on the main alpha in the future is the only safe and reliable way to go.
And that's ok, for now. It limits the amount of interaction a modder can set up with the outside world, but I don't mind setting that up on my end if I can. It won't give access to all the models that's been brought in, but perhaps one can make do without them for now. A plugin doesn't really have to be dependant on the main alpha right now.
It might have to soon, though... because I've almost finished setting up the first Redoran neighbourhood in Soluthis, and will soon get on with bringing in interior house models for the exteriors, and then we're pretty much set to open up Redoran claims. But how do you mod a Redoran home if you can't make your plugin dependant on the main alpha, and thus don't have access to the interior model? That, my friends, is the meat of my conundrum.
If you have any ideas on solutions, please, share them! I have an idea myself. Do you guys think it could work?
[title]"Base Plugins"[/title]
The "Base Plugins" would be a collection of .esp files. Each .esp contains just one interior house model list entry, and there would be one base .esp for each interior model. I'd link to the appropriate base .esp in each open claim I posted.
The base plugins wouldn't contain the models themselves; rather, those would ship with the main alpha package. They'd just have the list entry for the model in the construction set, so if the modder has extracted the main alpha package and load up the base .esp, they can drag-n-drop that list entry into an interior cell to get the interior model to show up. The IDs for the list entries would differ from those in the main alpha, but the location of the models would be the same.
Then, when time comes to merge their interior to the main alpha, I'd end up with two list entries for the same interior house model. Perfect - no conflicts reported by TES4 P.U. Then I just select their interior house model, go to "Edit > Search & Replace...", and switch it out with the standard list entry ID. Now, the interior model list entry from the merged plugin is unused, so I just delete it, freeing up that slot for the next plugin that uses the same base plugin.
A modder still wouldn't be able to affect anything outside their hut though, which is a pity. But an intrepid modder can expand the 'base plugin' idea and create new list entry ID's and hook them up to models from the main alpha package, and so would get to use as many custom models as he liked. Within reason!
Imagine a hundred plugins that each had two hundred list ID's that needed changing... if I spent a minute switching each ID, I'd have to keep at it for close to fourteen days straight, no sleep. Hehe. But a dozen of them, sure, that'd work.Let the ideas flow!
Kudos to sandor for his
great help in these tests.
great help in these tests.
