More outfit availability troubles

I have just made 4 different afterburners. However when one is bought I don't want any of the others to be able to be purchased. So I made them available when !b9, and then set b9 when purchased and !b9 again when sold. However if I sell my ship it gets rid of the afterburner but does not set b9 back to !b9. Is there any way of sorting this out easyer than putting !b9 in every ships OnSell field because I have a s###load of other outfits that need a similar effect?

I apologize if there is an obvious way that I am overlooking, I am thoroughly inexperienced with bits though and very often don't make the connection in situations where they need something more complex to give me an effect which I need. (Heh, I dread the time when it comes to figuring missions out)

How about the NCB Oxxx operator? If you have two afterburners (to make for a simpler example), ID 200 and 201, oütf 200 would have !O201 in its Availability field, while oütf 201's availability would be !O200. Will this do what you want?

Yes, I believe that's exactly what I am looking for. Thank you.
And just to check things, if I'm doing it with more than one other outfit I need to add an & between the two !Oxxxs?

@sp3cies, on Apr 29 2008, 03:09 AM, said in More outfit availability troubles:

And just to check things, if I'm doing it with more than one other outfit I need to add an & between the two !Oxxxs?

Yes. For two other outfits, it would be !O200 & !O201. For three, it would be (!O200 & !O201) & !O202, because of the way the engine handles NCB parsing.

Err wouldn't it be an "or" in this case and not an "and"?

@keldor-sarn, on Apr 29 2008, 01:13 PM, said in More outfit availability troubles:

Err wouldn't it be an "or" in this case and not an "and"?

The idea is to make the four items mutually exclusive. So, outfit 200 should require lack of 201, lack of 202, and lack of 203. If you used 'or' instead of 'and', that would mean you could buy any three of them at once, since !O200 | !O201 evaluates to true even if you have one of the items.

Oh right, negatives are confusing

Though, computationally speaking, !((O200 | O201) | O202) would probably be a better expression.

:blink: Eh, would that make things run smoother? Or does it really not matter all to much? And what about if there are 4 or more items other than the one that has been bought, how should I write that?

I'll go with it really doesn't matter. And to add more outfits to the mix just keep on adding another set of parenthesis around the previous statement and add the & !Oxxx on to the end.

(!O200 & !O201) & !O202

becomes

((!O200 & !O201) & !O202) & !O203

etc.

Hmm, goodie. Well alright, thank you.

@keldor-sarn, on May 1 2008, 03:05 AM, said in More outfit availability troubles:

I'll go with it really doesn't matter.

Ok, granted, you're probably not going to notice much of a difference. But considering how many things Nova generally has to do, don't you think it'd be a good thing to reduce that load as much as you can? The expression !(A|B|C) requires almost half as many operations to be performed as does (!A&!B&!C), and if your expressions are going to be getting large, you'd want to try keeping it as simple as possible. You can tell how much more computational power it takes just by reading it out loud - the second statement reads "not A and not B and not C", while the first reads "not A or B or C", which is much nicer to say.

Quote

And to add more outfits to the mix just keep on adding another set of parenthesis around the previous statement and add the & !Oxxx on to the end.
...
((!O200 & !O201) & !O202) & !O203

On a similar vein, it'd probably be a good idea, if only for readbility concerns, to continue grouping your terms in pairs rather than endlessly nesting the first pair in more and more brackets. Namely (if you're going to stick with the and-not structure rather than the not-or structure)

(!O200 & !O201) & (!O202 & !O203)

It may seem here that I'm quibbling over nothing with both my points, but when your expressions start getting big and clunky, then you really want to have things as simple as possible. When things start getting big, that's when typing errors start to creep in. I'm sure the game can handle a whole lot more than eight operations per frame, but why make it handle more than it has to when you can easily perform the same expression with only five?