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).
Hello ,
This is a guide I wrote sometime ago , but since I see many people asking and wondering about Nova Control Bits again on these forums I felt it was appropriate to repost it.
Enjoy.
Entarus,
---------------------------------- A explanation of Nova Control Bits
Here follows an explantion of nova control bits. Bits were also available in previous versions of EV , but in nova they became much more powerful but also more difficult. Control bits are an essential part of making things happen in Nova, so I suggest you read trough this section carefully. I use parts from the EVN bible and explain each part.
- In Nova there are 10000 Nova Control bits (nbcs). Control bits are accessed through logical expressions that allow powerful and logical scripting. These expressions are divided into two types test and set.
Test These are boolean expressions(Boolean means that they can be TRUE or FALSE) that are used to determine when something happens; for example, when a mission is to be offered, or when a particular ship should be made available for purchase. In general, if the logical expression defined in a given test expression field evaluates to be true (nonzero), the associated property will be activated (mission becomes available, ship appears, etc ).
Lets explain this with an example :
We have made a ship , and want to add this into our plug , but we dont want to give it to the player right away. He must complete a difficult mission before hes is allowed to buy the ship.
We can use nbcs to accomplish this. We will use the Availability field of the ship resource for this. Its a test field we enter a ceratin expression in to the field. The player will be able to purchase our type of ship when the expression evaluates to true.
We decide to use bit 4999 for this.
-In the missions OnSuccess field( its a SET field , as explained below) we enter the following : b4999
-In the Availability field in the ship resource we enter the same : b4999
Lets see what happens : All bits are turned off as default. So we presume bit 4999 is unused and its turned off. When the player completes the mission , the Onsuccess field will be exectuted. This means that bit 4999 will be turned ON. Remember that our Availability field tested for bit 4999 to be true (ON)? So when bit 4999 is turned on the ship will appear , because all conditions are met. The ship will not appear as long as bit 4999 is false (OFF). You can use all SET fields to turn 4999 ON after a certain event.
There are several terms and operators to test. Lets have a look at them :
bxxx Lookup the value of control bit xxx. Bits are numbered from b0 to b9999. pxxx Check if the game is registered ((P)aid for) ... evaluates to 1 if the game is registered or is unregistered but less than xxx days have elapsed. Evaluates to 0 only if unregistered for more than xxx days.
G Lookup the player's gender - 1 if male, 0 if female
Oxxx Returns 1 if the player has at least one of outfit item ID xxx, 0 if not
Exxx Returns 1 if the player has explored system ID xxx, 0 if not
| Logical or operator
Can be used to test if an expression is true OR the an other expression is true.
& Logical and operator
Can be used to test if an expression is true AND another expression is true.
! Logical negation operator
Can be used to test if an expression is FALSE
( ) Parenthetical enclosure
The Nova evaluator is fairly primitive, it may do unpredictable things if you give it an expression like b1 & b2 | b3 ... instead, use proper parentheses to make it b1 & (b2 | b3) or (b1 & b2) | b3, as appropriate.
Let see this in two examples :
b13 & (b15 | !b72)
This will test if bit 13 is true , and either bit 15 is true or bit 72 is false. If both conditions are met the associated property will be activated .
!(B42 | B53) & b103
This will test if either bit 42 is false or bit 53 is false and if bit 103 is true. If both conditions are met the associated property will be activated .
Note that if you leave the field for a test expression blank, it will evaluate to true as a default.
Also note: The Oxxx operator also considers any carried fighters that are deployed when it examines the player's current list of outfits, although this feature may be confused if presented with a universe that includes multiple fighter bay weapons that launch the same ship type, or different outfits that grant the same fighter bay ammo. Set
Weve briefly touched SET expressions in our first example. Now we will go into detail. The following text comes STRAIGHT from the EVN bible.
Always read the EVN bible , its a very important tool.
These are simpler than the test expressions... basically all you are doing here is listing what bits you want to be modified when the expression in a give field is invoked. This will happen when the player does something (completes a mission, buys an item, etc.) as defined by the other resources. The syntax of set expressions is best illustrated by an example:
b1 b2 !b3 ^b4
In this set expression, bits 1 and 2 will be set, bit 3 will be cleared, and bit4 will be toggled to the opposite of whatever it was previously. No parentheses are supported for set expressions. Note that if you leave a set expression blank, no control bits will be altered.
n this set expression, bits 1 and 2 will be set, bit 3 will be cleared, and bit 4 will be toggled to the opposite of whatever it was previously. No parentheses are supported for set expressions. Note that if you leave a set expression blank, no control bits will be altered.
One other feature of the set expression is the ability to make random decisions. By specifying R(<op1> <op2> ) you can make Nova randomly pick one of the two possible choices and execute it, skipping the other one. For example:
b1 R(b2 !b3)
...this expression will set bit 1, and then either set bit 2 or clear bit 3, but not both at once. Which operation will be picked is completely random, which allows for the design of interesting mission strings that branch unpredictably.
There are also a number of other operators that allow you to do many interesting things:
Axxx - if mission ID xxx is currently active, abort it.
Fxxx - if mission ID xxx is currently active, cause it to fail.
Sxxx - start mission ID xxx automatically.
Gxxx - grant one of outfit item ID xxx to the player
Dxxx - remove (Delete) one of outfit item ID xxx from the player
Mxxx - move the player to system xxx. The player will be put on top of the first stellar in the system, or in the center of the system if no stellars exist there.
Nxxx - move the player to system xxx. The player will remain at the same x/y coordinates, relative to the center of the system.
Cxxx - change the player's ship to ship type (ID) xxx. The player will keep all of his previous outfit items and won't be given any of the default weapons or items that come with ship type xxx.
Exxx - change the player's ship to ship type (ID) xxx. The player will keep all of his previous outfit items and will also be given all of the default weapons and items that come with ship type xxx.
Hxxx - change the player's ship to ship type (ID) xxx. The player will lose Any nonpersistent outfit items he previously had, but will be given all of the default weapons and items that come with ship type xxx.
Kxxx - activate rank ID xxx.
Lxxx - deactivate rank ID xxx.
Pxxx - play sound with ID xxx.
Yxxx - destroy stellar ID xxx.
Uxxx - regenerate (Un-destroy) stellar ID xxx.
Qxxx - make the player immediately leave (absquatulate) whatever stellar he's landed on and return to space, and show a message at the bottom of the screen. The message is randomly selected from the STR# resource with ID xxx, and is parsed for mission text tags (e.g. <PSN> and <PRK> ) but not text-selection tags like those above (e.g. {G "he" "she"} ) (see dësc and mďsn resource descriptions for more examples)
Txxx - change the name (Title) of the player's ship to a string randomly selected from STR# resource ID xxx. The previous ship name will be substituted for any '*' characters which are encountered in the new string.
Xxxx - make system ID xxx be explored.
------------------ "Don't wait for your life to happen , find something you are happy with and do it" (url="http://"http://www.ariossoftware.com/products/evone/")EVONE 1.0pb2 - the plugin editor for EV/EVO/EVN(/url) -- (url="http://"http://www.AmbrosiaSW.com/cgi-bin/ubb/forumdisplay.cgi?action=topics&number;=9&SUBMIT;=Go&urgaylol;=yes")EV Developer's Corner(/url)
Quote
Originally posted by Entarus: pxxx Check if the game is registered ((P)aid for) ... evaluates to 1 if the game is registered or is unregistered but less than xxx days have elapsed. Evaluates to 0 only if unregistered for more than xxx days.
It should be noted that this particular operator is meaningless for plug and TC developers. The reason is that it is necessary for the game to be registered in order to use plugs or TCs, therefore the Pxxx test operator will always return true in any plug. Only Nova Files folder data released by Ambrosia Software can make meaningful use of this operator.
...and thanks Entarus for the reprint.
Topic bookmarked and will be served back to people asking for info about this. When I'll have more time (you may notice I'm only answering now, RealLife is keeping me incredibly busy now), I'll write something about applying that to mission strings.
EDIT: Damn. Thanks.
------------------ The (url="http://"https://secure.ambrosiasw.com/cgi-bin/store/hazel.cgi?action=serve&item;=breakdown.html&BREAKDOWN;_SKUID=1480")Ambrosia Mac CD(/url) with other registrations - 5$. Paying for (url="http://"http://www.ambrosiasw.com/games/evn/")EV Nova(/url) as it's such a great game - 30$. The (url="http://"http://www.ambrosiasw.com/games/evn/tshirts.html")1337 EV Nova T-shirt(/url)(url="http://"http://www.ambrosiasw.com/webboard/Forum25/HTML/000003.html#ZachaPedro05-18-200409:42AM") (/url) - 22$. The (url="http://"http://w00tware.ev-nova.net/")NovaTools(/url) by wOOtWare to tinker with your Nova - FREE! The feeling you're a Nova geek - priceless. There are things money can't buy or that are free, for everything else, there's indeed Mastercard.
(This message has been edited by Zacha Pedro (edited 07-03-2004).)
(This message has been edited by Zacha Pedro (edited 07-04-2004).)
Zacha, to make a , you have to type , not &tm;.
------------------ The programmer's code of entomology: there's always another bug. There are 10 types of people in the world: those who understand binary and those who have friends. Windows users: stop asking for plugins. (url="http://"http://www.aznt.com/EVN/EVNEW/")Make one yourself.(/url) (url="http://"http://www.cwssoftware.com")Sephil Saga Website(/url) | (url="http://"http://www.evula.org/infernostudios/search.html")Add-ons Search Engine(/url)
Okay, here it comes:
A note to what you already posted: one should always parenthesise as much as possible test expressions, as even expressions that can't be misinterpreted such as b1 | b2 | b3 may be rejected by the engine; so to make sure the parsing (the operation that interprets the string of characters and make it meaningful for the computer) goes well, write (b1 | b2) | b3 instead.
Now, how to specifically apply that to mission strings? It depends how the missions actually branch. Let us say you start from scratch (i.e. you're starting a TC or you're not basing yourself on any already-present mission and associated mission bits), and you want to branch missions the usual way: the pilot may refuse, fail, and abort the missions as long as he wants, they will keep being offered, and once completed they will no longer be offered. Then it allows for the next mission (which is not started automatically, the player has to pick it up at the bar like he's used to).
The first mission is to not show up every time, require some combat rating or some leagl status, or be available only on a remote planet, so that the new pilot won't always start this one rightaway, so set the appropriate values. It's still to be able to be picked up, though, and no bit is set yet at this point, the beggining. So we'll leave the AvailBits field blank (for now). Note that the field may not have this exact name in your plug editor; since I can't cover them all, I'll use the names of the fields in the ResEdit templates (that are used in the Bible), from now on, you'll match them with what your editor shows you. AvailBits is a test expression that, if evaluated false, will make the mission not be offered, and if true allow the mission to be offered (if the other conditions such as minimal legal rating, for instance, are met). OnAccept is a set expression that will be evaluated when the mission is accepted, we'll leave it blank (for good), same thing with OnRefuse, OnFailure, OnAbort and OnShipDone since we don't want these to have any consequence. Remains OnSuccess (I hope the point these set expression are evaluated is obvious). Pick an unused NCB, to be certain it won't be set by anything else nor be tested by anything else. Let us say it's b1 (note: I'm pretty sure it's actually used by the Nova scenario, but for the purpose of this tutorial we'll consider it unused). In order to have the following mission know it can be proposed when the pilot already completed the first one, we'll make the first one set b1. So just enter b1 in the OnSuccess field. But- we also want the first mission to be no longer offered afterwards. We'll just test for the same bit, and the mission will check that it's not set yet. Yes, not , so check back the introduction to ncbs, you'll see that in order to check that bit bxxx is not set, you use a ! before bxxx. So we just put !b1 in the mission's AvailBits field. You may now associate to b1 the meaning "first mission has been completed". Notice that unless you want to reset the pilot and make it start the mission string anew, it won't be possible to touch the value of b1 again, as doing so would make the first mission offered anew, and this would have little meaning, so we'll use another bit for the second mission. You don't need to worry about the first mission being offered while it runs as b1 is not set yet - an already running mission will never be offered again while it runs.
Now the second mission. It depends how you want the mission go after another, but it's usual practice to make it available in the destination planet of the first mission, in the bar, all the time. But it has to check for completion of the first mission, so put b1 in the AvailBits field. Leave blank the others, save for OnSuccess, put b2 in it. Just like the first mission, we don't want it to be offered again when completed, so the second mission has to make sure b1 is set and b2 is not set. Yes, you heard well, and , so you need to link b1 and !b2 with &. So replace b1 in the AvailBits field by b1 & !b2. Now consider b2 means "second mission completed". Now mission 3 will have b2 & !b3 in its AvailBits field and b3 in its On Success field. This has been common practice for a long time for such a simple case: each mission sets one bit, checks at the beginning that this bit is not set, and the following one checks that this bit is set, and it's common practise too to use consecutive mission bits (there are more convoluted ways to use less ncbs, but with 10000 of them, who cares?). Looks simple enough? For now, that is.
*You may decide that at this point, "regular" missions become available (that is, missions that have no consequence whatsoever and can be taken as many times as one wants, such as cargo runs), let's say passenger transport missions for the government you've just started working with. It's really easy: instead of requiring nothing, like the basic mission in this (url="http://"http://www.ambrosiasw.com/webboard/Forum9/HTML/005410.html")tutorial(/url), take this mission from the tutorial and put b3 in its AvailBits field, change so that you transport 1 ton of quantityless "passengers", and have departure and destination planets be haphazard ones in the government space; then make one or two copies of this mission, it's usual practice since that allows the pilot to make more than one instance of this mission at once (remember one mission won't get offered when it's already running, it would make little sense that, because some passengers are already transported, none are wanting transport). These missions will just require the pilot to have made mission 3, otherwise they are just like usual passenger missions. Next we allow the pilot some free time to make these missions.
Notice that sometimes it's good to give the pilot a break in the storyline, maybe in order to make him reach an higher combat rating or have a better ship (such things could be tested by the mission after the break). To that end, you tell in the debriefing of the mission before the break that the pilot should not expect a next mission rightaway (in the lines of "good job, it's done. That's all for now, but we'll tell you when we'll need your services again. Oh, I've also been informed that you can get a new toy to play with."), and make the next mission not available in the same planet and/or not appear every time and/or require and higher rating/legal status and/or not appear until a few days. This is the most interesting (didactically to show use of ncbs outside missions) way to do it, and it's new to the Nova engine. To that end, you use a crön. It allows for timed events, something one couldn't do before.
Create a new crön resource, set all FirstXXX and LastXXX to -1, Random to 100, Duration to the time (in days) you want the pilot to wait, PreHoldoff and PostHoldoff to 0, flags (or checkboxes) empty. EnableOn should contain the bit you want the crön to be activated by, let us say it's b3 in our last example so enter b3 in the field. Leave OnStart blank, and put b4 in OnEnd. But perhaps it's not wise to have the crön relaunch as soon as it stops, and so on for all time, so change the EnableOn field to b3 & !b4, this way it will only run once just like the missions we just made. Well, we have a working crön, we might as well use it to display the breaking news of the formidable feat of the pilot, so you can fill some NewsGovt and GovtNewsStr fields with the relevant governments (and allies) that are to display in the bar news that pilot has been great, for the pilot to read while he's waiting (read the Bible for what's actually to put in these fields). Now you can set the fourth mission to require b4 and set b5, and so on.
Also, you may wish to let the (lucky) pilot play with a new toy in reward for his incredible feat while he's waiting, so take the outfit that you always thought to give to the pilot, but not rightaway, and put b3 in its Availability field, that way it will be available after the third mission only. As you may guess, this test expression allow for the appearance and purchase or the outfit.
Not, let's enter the more nitty-gritty ways of making missions branch and go one after another. Firstly, you want to make a big, uninterupted mission, but it's too long to fit in one actual mission, so we'll break it into small submissions that will all have the same name; or you want the pilot to be stuck for a short time and not let him take any break. You can do that by making that the mission that is to be taken not only available in the planet the pilot finished the previous mission, 1OO% of the time, and so on, but also set it to be offered in main spaceport (value 3 in AvailLoc) and have the flag "can't refuse" (0x0004) and the field CanAbort to 0 (or the corresponding checkboxes checked). The pilot does not even need to know that the window in which he's clicking okay is actually a mission he can't refuse. This way you can make missions go uninterrupted one after another and release the pilot only when you feel like it. Notice you should avoid things that may make this mission not offered, such as requiring cargo transport or rating/legal, etc... You can also do it by putting Sxxx to the OnSuccess field of the first mission instead of setting a byyy; mission ID xxx (the following one), instead of checking for byyy, be proposed and mandatorily taken, will be automatically started by the engine, and once again the pilot needs not know the mission has technically changed. However, there will be a big difference: if one mission in the set of mission is stopped for whatever reason (failure, for instance), the first way will have the pilot just have to redo the very mission he failed, while the second will force the whole mission set to be redone from the beginning (makes more sense if you wish to persuade it's actually the same, long mission). Whenever you're planning something using ncbs, don't just consider "mission xxx will succeed, it will allow mission xxx+1 which on success wil...", failure is part of life and has not to be avoided, and can be used constructively, for instance you may decide that on failure the pilot will have to go back to school or even may then start the opposite campaign! Therefore, you have to consider the whole range of possibilities at each point to avoid lockup, or its contrary, loopholes. More on that later
Secondly, say you want some mission to react differently to the case we considered before: if refused and/or failed and/or aborted, then the mission will no longer be offered, and the mission string won't go on. Take then a new mission bit, say b100, and set OnRefuse and/or Failure and/or Abort *(depending on the intended behavior) *to be b100. Then, change the AvailBits to be (bxxx & !bxxx+1) & !b100. Notice you can't use bxxx+1 instead of b100, as it would make the mission string go on in case of failure/abort/refuse - it would make very little sense. But usually, we don't lock out people definitely like that - it tends to generate hate mail, unblocking requests, and a number of topics in the Nova board. So we'll choose a less punishing option: have the pilot wait for some time (and be told he needs to wait) before the mission is offered again. This means using a crön, again. The crön should start if b100 is true, last a few days, then unset b100 at it's end; you should now be able to make it yourself.
Lastly, you may want to make some missions available at the same time, but once the pilot takes one, he can't take the other(s). This is frequent at the beginning of EVs: much of the interest of the game is in the possibility to play for different sides of the same conflict (with different pilots, obviously): EU/Voinian, Rebs/Confeds, etc... But you also want to prevent the same pilot from taking both storylines, as it would make no sense at all... This is a more difficult task, and EV, EVO and even EVN have loopholes allowing such nonsense, that you should strive to avoid. The usual way is to add a lockout bit: say the first mission string, that lets the pilot play the PSG, uses bits from 1000 and up, and the second, that lets the pilot play the OM, uses bits from 2000 and up. We add a new bit, b3000. Both initial missions will test it to see it's not set, and both initial missions will set it. So you could put !b3000 in the AvailBits of first missions of both the PSG and OM strings, b1000 b3000 in the OnSuccess of the first mission of the PSG string, and b2000 b3000 in the OnSuccess of the first mission of the OM string.
But there is a little, far from being obvious, problem: a pilot may start one mission, then start the other while the first runs, and complete both, as nothing will prevent it (check: the second string first mission will only be prevented when the first string first mission ends ), allowing him to make both strings. The most famous example was that you could make both EU and Voinian strings this way in EVO and still in the EVO port. To avoid that, you could make that both missions have date limits that prevents such loopholes, but sometimes that's not feasible as the opponents may be close from each other (a date limit too restrictive may prevent people with big ships from taking the mission string, while too long would allow a fast ship to exploit the loophole, and sometimes there's no middle ground avoiding both). So we'll use ncbs again to prevent such a thing.
We could set b3000 at mission start in the two strings instead on mission success, by putting it in OnAccept instead of OnSuccess, but then if the pilot fails or aborts the chosen initial mission, neither of the two will be available ever again - not good. We'll use this policy: if the player accepts and starts the initial mission for one string, the initial mission of the opposing string won't ever be offered to him afterwards, even if he fails, as the opposing govt will already consider him an ennemy (however, he will be able to take again and complete the initial mission of the first string that he failed before). To that end, we introduce two ncbs: b3001 and b3002, that will replace b3000. The initial mission of the PSG string will be so: AvailBits !b3002 & !b1000, OnAccept b3001 , OnSuccess b1000 ; and the initial mission of the OM string will have: AvailBits !b3001 & !b2000, OnAccept b3002 , OnSuccess b2000. It will then work as expected. If you would prefer a different policy, make sure you plan all the possibilities to rule out potential loopholes.
(note: people could add other examples here, though I think the "classic" cases are all present)
You may notice this is more of a tutorial. That's normal: the implementation of ncbs in the set and test fields heavily depends on the way you want the missions to react to the different possibilities, and there are ten power a zillion bazillion gazillion ways you may want the missions to branch. Therefore, you'll have to find your implementation yourself, I just listed the most common cases. Notice ncbs can be a hell to debug, so I suggest you to regularly make (url="http://"http://home.comcast.net/~slagblah/pilotlog.html")pilotlogs(/url) to check the currently set ncbs; also, you can have the first mission of the string you wish to test be available all the time at first for debugging purposes, so that you can take it as soon as you start a new pilot (you will often start new pilots when testing mission strings).
I wish you the best of luck, as this is arguably the most difficult aspect of plug-making outside of obtaining material (i.e. making graphics and stories).
EDIT: pretty important update, added stuff is between *es, and there are other small corrections such as replacing "him" with "the pilot" and such stuff to make it more readable.
(This message has been edited by Zacha Pedro (edited 07-10-2004).)
Wonderful.
Anyone have (EDIT: d'oh!) technical comments on it? Also, it would be awesome if someone could make it more english-looking (I just know there are mistakes and phrasing that seems odd to the English-native, but I don't know where they are).
Originally posted by Zacha Pedro: Anyone has technical comments on it? Also, it would be awesome if someone could make it more english-looking (I just know there are mistakes and phrasing that seems odd to the English-native, but I don't know where they are).
You mean like saying anyone have rather than anyone has?
I might try and edit it for English-lookingness. Or you could (url="http://"http://bri_code.tripod.com/convert.html")do it yourself(/url) (popup alert!).
I didn't notice any grammatical mistakes, though an native-English teacher would be better (I'm just a native. Heh =)). At one point I became confused about the bits (where the cron had to not start over and over and over...), but after examination it looked okay and made sense.
A good starting guide..
------------------ (url="http://"http://www.evula.org/infernostudios/search.html")The plug-in search engine!(/url)
I edited guide; see there.
Especially, I'm looking for comments on: -instantaneous understanding. Remember, we're pretty used to mission bits, so this may seem easy to understand, but it might not to a newbie. Therefore, this is to be understood instantly by anyone here, at least, so that we can expect someone unexperienced to understand it. -technical accuracy. It must be PERFECT from this point. I don't want to teach erroneous information.
Also, you may see I'm introducing habits, customs, practises and such - I have to. Tell me if you think those are appropriate.