...and a question for the ATMOSians
This is an example of how logical organization of minutia can make the development of a total conversion (TC) less prone to errors. Simple things make life easier or complex things are easier to deal with if they are logically simplified. Consider this: There are more NCBs (10,000) than there are resources that use NCBs (8,585 total NCB-using resources, if all were used). The default Nova scenario NCB allocation did not take full advantage of this fact. Nova uses less than 6% of the total number of NCBs available. The mission resources make the most use of NCBs since they have the most fields (7) that can test and set NCBs. Nova's 791 missions control 85% of the Nova scenario's 552 NCBs. Anyone who has developed a plug that needs to be integrated with the existing Nova scenario (especially storyline strings) will be aware that it is difficult and time consuming to determine which resources and which NCBs have to be dealt with or avoided in order to successfully merge the developer's plug with the default Nova scenario. In fact, TC development is actually easier than plug development from the aspect of NCB and resource allocation, since there are no concerns about dealing with integration into an existing scenario.
KEY POINTS:
Use blocks of NCBs for dedicated purposes, matching resource RID numbers with NCB least significant digits.
Recognition of what a specific NCB controls is then readily apparent based on the block of NCB numbers.
Maintain a master list of all NCB allocations made (spreadsheets are your friends).
(note- the following examples only work for TCs, since any plugs developed for use with the default Nova scenario must take Nova's NCB usage into account)
Mission NCB allocation example:
Typical mďsn resource practice is to use an NCB to indicate that a mission has been successfully completed and to prevent the mďsn from being available more than once. The vast majority of Nova's missions operate in this manner. This mission NCB can be viewed as either a mďsn-done NCB or as a mďsn-inhibit NCB. This same NCB is also typically used to enable the next mission in the storyline string via the subsequent mission's Availability(test).
e.g.-
Availability(test): b<previous_mďsn_done> & !b<this_mďsn_done>
OnSuccess(set): b<this_mďsn_done>
(note- the <this_mďsn_done> NCB could also be set OnAccept and/or OnFail and/or OnRefuse, etc.)
So assigning one unique NCB to each and every possible mďsn (max = 1000) is no great drain on the total NCB populatiion, even if all of the missions aren't used.
e.g.- b128 is assigned to mďsn(128), b129 is assigned to mďsn(129), b1127 is assigned to mďsn(1127)
This greatly simplifies identification of which NCB is set by which mission. It also reduces the possiblity of unintentional multiple usage of an NCB, i.e.- bugs.
Oufit and ship NCB allocation example:
The Availability(test)s for oufits and ships also lend themselves to having unique NCB assignments for every possible oütf (max = 512) and every possible shďp (max = 768). Once again, no great burden on the total NCB populatiion, even if all possible oütf or shďp resources aren't used (or they have no availability restrictions).
e.g.- oütf 128 through 639 Availability(test) could use NCBs 4128 through 4639
and shďp 128 through 895 Availability(test) could use NCBs 2128 through 2895.
It's better to use individual NCBs for each outfit/ship, even if a given mission (or whatever) is going to enable the availability of several different outfits or ships. This makes identification, maintenance, and modifications very much easier and less prone to introduction of errors.
So even if you were to put all of the previous mďsn, shďp, and oütf examples into practice, they would consume only 2280 (22.8%) of the total NCB population.
You could even add in an NCB for every possible crön (max = 512) and still not create any NCB usage restrictions. Attached below is a screenshot of the NCB allocation scheme that I'm currently using. This practice of assigning blocks of NCBs to a dedicated resource type could of course also be used with the other resources that can test or set NCBs. In fact the concept of block number assignments could also be extended to Special Tech Levels (STL) by assigning an STL for every possible spöb (128..2175) and also an STL for each gövt (3128..3383). Or assigning blocks of dësc resources (M.C.B. did this religiously in EV and EVO) or blocks of STR# resources to specific purposes. I'm sure you can think of other block number assignment possibilities as well, like maybe RID numbers.
The Question:
After having sifted through all of the Nova default scenario resources for a couple of years now, I have a question for the ATMOS development team. How did you folks decide which NCBs were allocated to which purposes? I suspect that a rotating dart board and several pints of ale were involved, but I could be mistaken (sorry, just kidding). The same type of question also applies to mission RID allocation, how did you decide which RIDs were assigned to which storyline strings? I ask these questions because, after having created distribution plots of both NCB usage and mission RID usage for the default Nova scenario storylines, I obtained what appears to be a pretty much random scatter plots (and I do mean scatter). I'm not criticising the ATMOS development practices (20-20 hindsight is always perfect), I'm just curious if there is indeed any rhyme or reason that isn't obviously apparent. And besides, it's really the end result that counts, and in this case the end result is one of the greatest computer games of the genre.
Attached File(s)
NCBallocation.GIF (10.81K)
Number of downloads: 48
), you are much safer and development takes way less time.