Aller au contenu

Photo

Custom content and compatibility


  • Veuillez vous connecter pour répondre
4 réponses à ce sujet

#1
MasterChanger

MasterChanger
  • Members
  • 686 messages
There's been some talk on some module-discussion threads about the challenges of building in compatibility for the work of various CC-authors, such as Kaedrin, Kaldor Silverwand, and so on (I'll throw in Drammel's Tome of Battle since it's one of my personal favorites). Some of the discussion has been about the difficulty of ensuring compatibility with feature releases. I thought I'd raise some questions in a thread specifically about this topic.

First, it seems to me that much difficulty can/could be avoided with a proper 2da/tlk merge tool. I know I've tried to merge tlk's with tlkedit2 without much success. If this process were made really easy, say with the tool The Fred was talking about a while ago even non-advanced users could easily pick and choose the content they wanted to use. Of course, this would require observing the reserved 2da ranges but I'd think that an author could do that much, at least.

Kaldor brought up issues of modifying the same event scripts. This seems to me like an issue where event hooks could be really handy. I'm talking about something similar (the same?) as the way the HCR2 framework builds in hooks to check for variables storing event handlers. Would it be possible for someone like Kaldor to build in a conditional that checks for a Kaedrin event handler, runs it if it's there, and then returns to Kaldor's? The other way around? Could using these placeholders/pointers be a way to ensure compatibility even if other developers change the scripts themselves?

Feel free to tell me what I'm talking about is impossible. It just seems a shame to put players in the middle of turf battles, or to unduly frustrate modders who are just trying to make fun CC on their particular schedules and according to their particular interests and abilities..

#2
c i p h e r

c i p h e r
  • Members
  • 261 messages
I think it's unrealistic to expect that everyone who opens the toolset and creates something will observe standards set by the community. Even if the standards were bundled with the toolset, which they aren't, chances are still good that *somebody* wouldn't bother to read the documentation or abide by it.

Consequently, I think a proper merge tool would simply abstract all of the 2da business entirely from the end user and just do what needs doing, whether or not the content creator has observed standards. If they have, great, no conflicts. If they haven't, the tool moves the content around to fit.

The biggest problem though I think are the blueprints. Updating those is far more time intensive than moving lines around in the 2da. So an ideal merge tool would update blueprints as well. One way to do that I suppose would be to load the original blueprints and original 2DA, then load the updated 2DA, compare, and update blueprints accordingly.

Anyway, I figure if someone isn't up to the task of overcoming these challenges, they're really not up to the task of building modules or worlds. So it's ultimately moot to me. I tend to not trust automated tools anyway so even if the mother of all merge tools existed, I probably still would do things by hand.

#3
MasterChanger

MasterChanger
  • Members
  • 686 messages
Sure, someone might not follow the reserved ranges, but the main CC producers who actually discuss their work with anyone else are certainly aware of it.

The merge tool would need to be about more than blueprints, actually. There's also the question of scripts. Hopefully, a CC author would put all their constants that refer to 2da lines (classes, feats, spells) in a separate include file, but I think even if someone adjusted that they'd end up having to re-compile any script that calls those constants--not a good scene.

#4
dunniteowl

dunniteowl
  • Members
  • 1 559 messages
I don't know if it's doable or not. My view is this: It's great to know how to do it by hand -- which I can barely manage -- but, no matter how good at it I got, an ultimate merge tool would definitely speed up the process (even if I went back and "hand" verified everything I merged with it) and allow me to do just that much more than I could without it. Additionally, others out there who cannot grok or cannot afford to invest the time to learn YATFMM (Yet Another Tool For Making Modules) in order to concieve their project will still be doing it the old way. Others out there, new to the process should be mentored (if possible) to show them the ropes of the standards the Community has learned to embrace over time for better overall custom content compatibility, which means a greater amount of interoperability for the end user -- the player -- as well as flexibility and power to the producer of modules (authors, who are already up against a wall of time, which is called "spare.")

I say, anything that can, ultimately, make development and production easier for new builders has that same potential for veteran authors/builders and should allow them to realize their story/objectives that much quicker in the same overall number of 'man'-hours. That's a good thing, isn't it? The faster you can do something without automatically compromising quality the better. It would ultimately mean more overall content, period, as a player.

I support this idea if it's possible.

dunniteowl

#5
MasterChanger

MasterChanger
  • Members
  • 686 messages
As far as merging stuff, I think TLK's are even more of a PITA than 2da's, personally.

Incidentally, the SP Install instructions Kaedrin provides are pretty much what I was talking about in terms of script hooks. You set up the module events and you've (theoretically) built in down-the-road compatibility.

From the horse's mouth:

Kaedrin 23 Aug 2010, 18:14 GMT-04

Yes. Bioware/OEI didn't bother setting up a consistent set of module
event scripts so "new" modules don't have anything close to what the
campaigns all have. Which means anything done for the SP campaigns will
not work for any user-module unless they set up the same events and
script names. It's the biggest failure point for "one stop CC."


Modifié par MasterChanger, 09 janvier 2011 - 03:21 .