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).
...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.
I will add that for EVN expansion plug developers, there is an easier way to find one's way than by checking every mďsn resource, Mark Chai's "EVN Bits Bible" (v. 1.0) states the following in its description: "Have you ever wondered what all those control bits really meant? At last with Version 1.0 of the EVN Bits Bible, all will be revealed! All 531 bits used in the EV-Nova default scenario have been covered and their secrets unlocked in over 120 more details annotations. A perfect tool for any plug-in developer and curious minds. Visit http://homepages.ihu...m.au/~markchai/ for the latest version. Currently the file has 657 text entries and each bit has been classified by story string. By The Wanderingwalrus."
I see there is a little difference between your 552 bits and Mark Chai's 531 bits Anyone care to update the Bits Bible?
Anyway, with this document (which I've spent hours using, mark my words ), you are much safer and development takes way less time.
This post has been edited by Pace (haldora) : 19 June 2005 - 01:12 AM
I'm sure ATMOS started out with a good scheme. But it constantly evolved from the EVO plug it started as and their scheme probably just fell to pieces. It's pretty difficult to develop a scheme with enough flexibility to still hold together after years of development.
Personally I would of killed for another 64 con/req bits. But I can use NCBs for that too. Not as easy though...
Arturo, on Jun 18 2005, 11:42 PM, said:
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.View Post
The one difficulty that might come from this is if you have a mission that makes a very large number of things available. It is possible to run out of space in a set string (IIRC, it was something like 51 three-digit set expressions). Not a likely problem, and there are work-arounds, but I just thought I'd mention it. Anyway, very nice system. I like it.
Pace said:
,Jun 19 2005, 12:03 AM) I see there is a little difference between your 552 bits and Mark Chai's 531 bits Anyone care to update the Bits Bible? View Post
Actually, I've got a list of the changed bits. I haven't looked up what they do, but it shouldn't take more that an hour to find out and write it up.
1.0.6 to 1.0.8 bit changes: Added: 34, 45, 46, 47, 48, 49, 327, 415, 467, 518, 519, 612, 613, 666, 667, 677, 681, 838, 3721, 4322, 4444, 6137, 7878, 7879, 7880, 8340, 9334
Removed: 150, 151, 421, 9237
Edwards
Pace, on Jun 19 2005, 12:03 AM, said:
I see there is a little difference between your 552 bits and Mark Chai's 531 bits Anyone care to update the Bits Bible? View Post
Pace (haldora said:
,Jun 18 2005, 11:03 PM) Visit http://homepages.ihu...m.au/~markchai/ for the latest version. View Post
That URL is stale. I get a "404 Not Found error" from it. And for anyone that's interested in making their own list of NCBs used by EV:N 1.0.8, here's the complete list from Dr. Ralph's Nova Bit Map utility:
Bit Usage Analysis: ------------------- Total Bits Used : 0 Total Unique Bits Used : 552 Total Bits Tested : 2748 Total Unique Bits Tested : 533 Total Bits Set : 2194 Total Unique Bits Set : 548
Bits Tested But Not Set: 335,503,3005,9999,
Bits Set But Not Tested: 467,4322,5763,5765,6001,6003,6014,6015,6018,6019,6020,6021,6022,6024,6025,6026,6027,6032,6034,
Used Bits: --------- 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19, 20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39, 40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59, 60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79, 80,81,82,83,84,85,86,87,88,89,90,96,123,124,125,126,127,128,129,130, 131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149,152,153,154,155,156,157,158,159,160,161,162,163,164,165,166,167,168,169,170,175,178,179,180,181,182,183,184,185,186,187,188,189,190,191,192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,208,209,210,211,212,213,214,215,216,217,218,219,220,221,222,223,224,225,226,227,228,229,230,231,232,233,234,235,236,237,275,276,277,278,279,280,281,282,283,284,285,286,287,288,289,290,291,292,293,294,295,296,297,298,299,300,301,302,303,304,305,306,307,308,309,310,311,312,313,314,315,316,317,318,319,320,321,322,323,324,325,326,327,330,331,332,333,334,335,340,341,347,348,349,350,351,352,353,354,355,356,357,358,359,360,361,362,363,364,365,366,367,368,369,370,371,372,373,374,375,376,377,415,417,422,423,424,425,426,427,428,429,430,431,432,433,434,435,436,437,438,439,440,441,442,443,444,445,446,467,500,502,503,509,510,511,512,513,515,516,517,518,519,600,601,602,603,604,605,606,607,608,609,610,611,612,613,650,651,652,653,666,667,677,681,749,750,751,752,753,800,801,802,803,804,805,806,807,808,809,810,811,812,813,814,815,816,817,818,819,838,850,851,852,995,1000,1100,1300,1301,1302,1303,1304,1305,1306,1307,1308,1309,1500,1501,1502,3000, 3001,3002,3003,3004,3005,3006,3007,3009,3015,3025,3050,3721,3789,4000,4322,4444,5757,5758,5759,5760, 5761,5762,5763,5764,5765,5770,5999,6000,6001,6002,6003,6004,6005,6006,6007,6008,6009,6010,6011,6012, 6013,6014,6015,6016,6017,6018,6019,6020,6021,6022,6023,6024,6025,6026,6027,6028,6029,6030,6031,6032, 6033,6034,6100,6101,6102,6103,6104,6105,6106,6137,6200,6201,6202,6203,6204,6205,6206,6300,6301,6302, 6666,6723,6724,7777,7778,7779,7780,7781,7782,7783,7784,7785,7786,7787,7788,7878,7879,7880,8338,8339, 8340,8444,8888,8889,8890,8891,8892,8893,8894,8895,8896,8897,8898,8899,8900,8901,8902,8903,8904,8905, 8906,8907,8908,8909,8910,8911,9011,9012,9013,9014,9015,9111,9200,9201,9202,9203,9204,9205,9206,9207, 9208,9215,9216,9333,9334,9500,9501,9666,9812,9995,9998,9999,
Guy, on Jun 19 2005, 04:02 AM, said:
I'm sure ATMOS started out with a good scheme. But it constantly evolved from the EVO plug it started as and their scheme probably just fell to pieces. It's pretty difficult to develop a scheme with enough flexibility to still hold together after years of development. View Post
I'm sure you're right because 382 of the 552 NCBs in Nova are below the 512 bit maximum that EV:Override has.
Edwards, on Jun 19 2005, 10:33 AM, said:
The one difficulty that might come from this is if you have a mission that makes a very large number of things available. It is possible to run out of space in a set string (IIRC, it was something like 51 three-digit set expressions). Not a likely problem, and there are work-arounds, but I just thought I'd mention it. Anyway, very nice system. I like it. View Post
Usually my own personal threshhold of tolerance occurs long before the 255 character limit is reached. At about a half dozen or so of outfits or ships in one statement, I'll switch over to using a group availability NCB. But once again I'll use NCBs from one of the FREE groups shown in my spreadsheet that are closely associated with outfits and/or ships. For example I use the 2896-2999 block for groups of ships and the 4000-4127 block for groups of outfits. For something like the Vell-os lockout NCB (424), which occurs virtually everywhere, I'd use one of the special purpose flags in the 0-127 block.
This post has been edited by Arturo : 20 June 2005 - 11:19 PM
Okay, I've managed to find most of the functions of the new bits, but not all
I've been looking through the mďsn files, since Nova Data 4 hasn't changed since 1.0.6. Haven't checked all the crön resources.
Those missing in my update of the EVN bits bible are in bold:
Quote
Added: 34, 45, 46, 47, 48, 49, 327, 415, 467, 518, 519, 612, 613, 666, 667 , 677, 681, 838, 3721, 4322 , 4444, 6137 , 7878, 7879, 7880, 8340, 9334
I've also been trying to find what happens to bit 9237, deleted. In 1.0.6, it seems to have marked the "Accepted Vellos Silent Outfits Mission", but I couldn't find any mission of the kind in Nova Data 1 So I don't know if it was just replaced or fully abandoned.
If you manage to find the "missing bit functions", I'll put a newer version of the Bits Bible here (maybe also on the add-ons page, if I manage to contact Mark Chai).
Oh, yes, Arturo, sorry about putting the URL tag there. I knew it didn't work, but I somehow forgot
So what you are saying is that, during scenario creation, NCB's should be numbered to match what resource type and number they affect, and that a spreadsheet should be used to keep track of what resource(s) controls each NCB?
Sound logical and useful. May as well maintain an independent list of what each NCB in a scenario under construction does, so that data is fully cross-referenced for bug-fixing purposes.