Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
An NCB question
Poll: Which is a better NCB allocation plan? (4 member(s) have cast votes) Which is a better NCB allocation plan? Number NCB's based on the resource ID of the missions that control them. (3 votes [75.00%]) Percentage of vote: 75.00% Number NCB's based on the resource ID of resources they control. (0 votes [0.00%]) Percentage of vote: 0.00% Some other NCB numbering system. Please specify in detail. (1 votes [25.00%]) Percentage of vote: 25.00%
As far as I can tell the two are mutually exclusive in a scenario where missions affect other resource types and NCB's are needed to control the interactions of mission availability/completion, outfit availability, dësc test strings, spöb and s˙st visibility, etc.
That is to say, you can either have NCB numbers aligned with mission numbers, or have them aligned with the numbers of other resources they control, but its impossible to, for example, have an NCB set by a mission that allows the purchase of an outfit to both match the mission number and the outfit number, especially if there are multiple bits set by the mission or multiple missions allowing the outfit to be purchased.
I'm not sure I'm explaining this well. Basically, I'm asking you to decide which of these two systems is more useful, and to post your own ideas:
An NCB allocation technique for TCs by Arturo. A cleaner way to do strings by orcaloverbri9 with commentary by Edwards.
Thank you for your thoughts, opinions, and anecdotes.
Well it's fairly obvious where my vote went, but let me add a few side notes:
1. I don't think that this is a majority rule sort of decision. I mean I can imagine development situations where I might want to make use of either of these methods. The usefulness of either method is pretty much plug/scenario dependent.
2. That said, trying to conserve NCBs is something like holding your breath to conserve air. In either situation your efforts don't really mean much and it just makes you dizzy. With 10,000 NCBs, conservation is a non-issue.
3. As with any technical problem, there are usually more than just two possible solutions, often many more. I just happen to use the one that seems most logical to me. And I think that's what should really decide for each of us, i.e.- whatever works best for you is the best method to use.
4. In counterpoint to the previous note, compatability with other plugs or scenarios would be greatly enhanced if everyone used the same method. Fat chance of that ever happening, but it would be a nice goal for the EV development community in general. However, with somewhere around 700 plugins already in existence and most of those incompatible with the other 699, compatability standardization is pretty moot.
Personally, I agree with Arturo. When the NCB's are based off of the missions, it is usually easier to organize, but it could be done either way, depending on what one is doing.
It would be nice if people actually TRIED to make things compatible (and for those of you who have done so, thankyou).
sigh.
Arturo, on Jun 25 2005, 11:32 AM, said:
That said, trying to conserve NCBs is something like holding your breath to conserve air. In either situation your efforts don't really mean much and it just makes you dizzy. With 10,000 NCBs, conservation is a non-issue. <snip> In counterpoint to the previous note, compatability with other plugs or scenarios would be greatly enhanced if everyone used the same method. Fat chance of that ever happening, but it would be a nice goal for the EV development community in general. However, with somewhere around 700 plugins already in existence and most of those incompatible with the other 699, compatability standardization is pretty moot. View Post
It's not about conserving bits, really. It's actually about wasting bits and skipping whole tracts of bits just to make it easier to know what a bit does, or how it got set.
As far as compatability goes, I have an idea. This won't make all plugs compatable. This won't even make most plugs compatable. In fact, if employ fully, it's won't make any plugs any more compatable than they already are. What it will do, however, is make it much simpler for the end user to manually adjust the plugins he or she uses to be compatable with one another.
It is simply a read-me or sorts, or more accurately, a "bits bible" for each plugin. It doesn't even require any extra work on the part of the author, either. You see, if the plugin developer simply keeps a list of each NCB his or her plugin uses, and a parallel list of each resource that affects those NCB's, and each list includes descriptions of what the bits and resources do, then that developer has an aid to bug fixing.
Additionally, if those lists are bundled with the plugin itself, or available seperately, then anyone who wishes to can change only those resources or bits necessary to ensure that a given plugin doesn't interfere with another given plugin, at least mission-wise. Ships, outfits, planets and stations are another matter entirely. In fact, that kind of makes this pointless for TC compatability with plugins not designed for that TC, but otherwise it is excellent for compatability between nonTC plugins.
I voted "other".
Actually it's too bad that the IPB poll mechanism isn't a "Check all that apply" type of voting scheme instead of mutually exclusive radio buttons, because I would have liked to ticked all three.
Are you aware that there is a Novatools utility that does almost exactly what you describe? It's called Mission Bit Map or Nova Bit Map, depending on the incarnation one finds. This utility was posted at one time long ago by Dr. Ralph and sometime later by pipeline after Dr. Ralph's original site went down. But it is unfortunately nowhere to be found nowadays. The Bit Map utility gives a summary of all NCBs used, set, and tested. It then goes on to summarize all operator usages and which resources use them. And then finally gives a bit-by-bit rundown identifying each resource that sets or tests each bit. Really very useful. But getting every plug developer to provide such info is, I fear, doomed. Heck, more than half the plugs out there don't even have (meaningful) ReadMe files.
(virtual-pat-on-the-back) Thanks for making me aware of the Online Etymology Dictionary in another thread today! (/virtual-pat)