Not quite a Nova hack

I got to thinking today and came up with a way to have many more mission bits, just in case anyone is getting close to running out of them anytime soon. I hadn't seen this posted before, so here it is:

Use a series of bits for your missions, such as b1, b2,..., b9, b10. Then use another series of bits as "placeholders", say b101, b102,..., b110.

As your missions progress, setting bits 1, 2, etc., after b10 is set, have the next mission clear the previous ten and set bit 101. Then re-use the bits 1, 2, etc. again, setting b102 at the end. With ten series bits, and ten placeholders, you'll get twenty bits acting like one hundred. For ease of use one should keep the series fairly small, but not so small that you're using placeholder bits every two missions.

While it does require a little extra work (especially since one would have to make availability requirements based on all of the placeholders as well as the series), but if you really need to squeeze in a few more missions here and there, then you can.

I have no idea if anyone is running up against the 10000 bit limit, but it could be useful for another step of plug-in organization, especially for TC's where the creator is expecting other users to make plug-ins for it.

It could also be useful for developers adding strings to Nova and they want to ensure that their plugs are more widely compatible with other plug-ins in existence.

Heh. Yeah, I guess since there's 2^10000 possible combinations of bits there's no excuse to complain of a shortage

You're behind the times. This is/was a feature I am/was planning for Genesis. It was my answer to all other resources being effectively unlimited - if you have enough plug-ins. My take on the problem was as follows:
- The NCBs are the most ubiquitous of all resources in Nova. However, they are also the most used, in that they are needed to tie together numerous things.
- Many bits clog the pilotlog, making it harder to read.
- A more complex availiability ( if b1 & b74 & (b1893 | b12 & b92) ) solves both problems - with a bit of additional effort in the beginning.

The only case where this sort of thing becomes necessary is when you're using either horribly complex storyline stuff (interlacing crons, misns, and so on...) or when you have multiple consecutive (or indeed concurrent, although that's a little more frustrating) plugins/data files.

That's nothing. I can make a thousand-mission storyline use a mere 10 ncbs. There sure are indeed ways to use less ncbs, but with 10000 of them, who cares? The traditional system is still best, particularly for maintenance reasons (if you want, say, to insert a new mission...)

Zacha Pedro, on May 26 2005, 02:18 PM, said:

That's nothing. I can make a thousand-mission storyline use a mere 10 ncbs.
View Post

thinks about it

How do you do that? Counters don't help you enough there. There's something I'm missing, I'm sure

Just binary code the point you are: say I represent these 10 bits from, say 1000 to 1009 by 1009: XXXXXXXXXX :1000, then before the first mission, you have:

0000000000

then after the first:

0000000001

then after the second:

0000000010

after the third:

0000000011

and so on...
0000000100
0000000101
0000000110

To this end, you need to test ALL bits at the beginning of each mission, say for mission 4, you would need the follling test expression:

((!b1009 & !b1008) & (!b1007 & !b1006)) & ((!b1005 & !b1004) & (!b1003 & !b1002)) & (b1001 & b1000)

(if that seems a bit long, consider the maximum length of test and set expressions are 255 characters, so there is still some room, I use "only" about 100 here...)

and at the end, the mission sets and clears the changing bits, for mission 4 it would be:

b1002 !b1001 !b1000

The problem is that, to check that the pilot is after some mission (say for the availability of an outfit), and the situation just after the mission is:

0000100110

then you need to have an expression which is true for all values after that, and false before. It's a bit complicated, but here's how one can do it:

b1009 | (b1008 | (b1007 | (b1006 | (b1005 & (b1004 | (b1003 | (b1002 & b1001)))))))

Simple, isn't it? That's why I recommand sticking to the traditional way, which far more debuggable.

Okay, I knew it was in binary, but never thought of setting multiple bits at the end of the mission

Indeed, it would be hell to debug.
me imagines the poor guy on mission 542 trying to figure out the debuglog and pilotlog

Zacha Pedro, on May 27 2005, 05:41 AM, said:

Just binary code the point you are: say I represent these 10 bits from, say 1000 to 1009 by 1009: XXXXXXXXXX :1000, then before the first mission, you have:

0000000000

then after the first:

0000000001

then after the second:

0000000010

after the third:

0000000011

and so on...
0000000100
0000000101
0000000110

To this end, you need to test ALL bits at the beginning of each mission, say for mission 4, you would need the follling test expression:

((!b1009 & !b1008) & (!b1007 & !b1006)) & ((!b1005 & !b1004) & (!b1003 & !b1002)) & (b1001 & b1000)

(if that seems a bit long, consider the maximum length of test and set expressions are 255 characters, so there is still some room, I use "only" about 100 here...)

and at the end, the mission sets and clears the changing bits, for mission 4 it would be:

b1002 !b1001 !b1000

The problem is that, to check that the pilot is after some mission (say for the availability of an outfit), and the situation just after the mission is:

0000100110

then you need to have an expression which is true for all values after that, and false before. It's a bit complicated, but here's how one can do it:

b1009 | (b1008 | (b1007 | (b1006 | (b1005 & (b1004 | (b1003 | (b1002 & b1001)))))))

Simple, isn't it? That's why I recommand sticking to the traditional way, which far more debuggable.
View Post

if you wanted to be weird, you could go in the following order

0001
0011
0010
0110
0111
0101
0100
1100
1101
1111
1110
1010
1011
1001
1000

etc... Course, the only conceivable advantage is that the onfinish field for the mission only ever needs one bit. And that your code has absolutely no chance of being reverse engineered except by people that really, really care.

Oh, yeah, grey code is even cooler (read: geekier) than usual binary. But I have no idea on how I would make the “always set after some mission” test expression. By the way, with my method here’s how you would write this test in a general way:

if the status just after the mission is:

0100010011

then the test expression that will always be set once the mission has been done, and after all missions onwards, is:

1009 | (b1008 & (b1007 | (b1006 | (b1005 | (b1004 & (b1003 | (b1002 | (b1001 & (b1000 & ALWAYS_TRUE)))))))))

For each 0, you write a |, and for each 1 a &. Of course, there is no ALWAYS_TRUE constant in ncb TEST expressions (of course you could put a dummy one such as (b0 | !b0), but we might as well simplify, if only for efficiency...), so you simplify: you replace “(anything | ALWAYS_TRUE)” by “ALWAYS_TRUE”, and “(anything & ALWAYS_TRUE)” by “anything”, until ALWAYS_TRUE disappears, which gives here:

1009 | (b1008 & (b1007 | (b1006 | (b1005 | (b1004 & (b1003 | (b1002 | (b1001 & b1000))))))))

EDIT: (in response to below) oh, yes. My bad (I wrote (b0 & !b0)...)

This post has been edited by Zacha Pedro : 30 May 2005 - 10:22 AM

Thats cool, I didnt know that. To be a nitpicking ass, which isnt really appropriate here, you mean (b0 | !b0).

I really didnt know that about the test expression thing. My dad has a little plastic toy that has 8 pins that play through the grey code. Its very odd...