because the traditional way sucks.

Most of us probably know the annoying and bit-intensive way most strings are done in terms of ncb's. Well, SpacePirate and I decided that method sucked.

What I'm suggesting is this: let's say we have 10 strings, each with 50 missons. now, we could waste 501 bits, or we could use 61. Let's call bit 0 the in-string bit; when set, you are in a string. Bits 1-50 are which-mission bits; which mission in any string you are at. Bits 51-60 are which-string bits; which string you are in.

So, to determine if the player has finished the 37th mission in the 6th string, you would use: b56 & b37

A lot better, eh? And to check if they're in a string at all: b0.

Comments? Questions? Anything?

This would make development of strings go smoother and faster, and it would be way easier to check for missions completed. Not to mention how much easier it would be to read the pilotlog and answer questions.

orcaloverbri9, on Jun 24 2005, 09:32 PM, said:

Most of us probably know the annoying and bit-intensive way most strings are done in terms of ncb's. Well, SpacePirate and I decided that method sucked.

What I'm suggesting is this: let's say we have 10 strings, each with 50 missons. now, we could waste 501 bits, or we could use 61. Let's call bit 0 the in-string bit; when set, you are in a string. Bits 1-50 are which-mission bits; which mission in any string you are at. Bits 51-60 are which-string bits; which string you are in.

So, to determine if the player has finished the 37th mission in the 6th string, you would use: b56 & b37

A lot better, eh? And to check if they're in a string at all: b0.

Comments? Questions? Anything?

This would make development of strings go smoother and faster, and it would be way easier to check for missions completed. Not to mention how much easier it would be to read the pilotlog and answer questions.View Post

On the other hand, it might be easier to keep track of what string you're in, and read pilotlogs, if you declare each string to have 100 bits at its disposal:
String 1: 100-199
String 2: 200-299
String 3: 300-399
Etc.

The hundreds could be the "which-string" bits, and "mission-number" bits would be 1, 2, etc. in each mission's set of bits. Remember, just because it's the same general style as Nova uses doesn't mean that it needs to be as scattered and incomprehesible as Nova. And, with 10,000 bits at your disposal, I seriously doubt that you will ever run short.

Also, about your use of seperate "mission-number" bits: Unless your storylines are so closely scripted that the same mission in each of them has the same purpose, I can see little value in being able to check which mission you are on independent of which storyline you are in.

Anyway, it's an interesting system, it's just that I can't see much reason for it.
Edwards

I really don't think this is anything new.

My idea of a "cleaner" string is to clear the previous bit at the end of every mission. Then you've only ever got one bit set to indicate where you are in the string - this would make it very easy to jump around within strings if necessary.

This post has been edited by Guy : 24 June 2005 - 11:55 PM

Guy: there's a problem with only having one bit set. Namely, if you want to check whether a given mission has been completed you need a complex swath of bit checks. That is, say a given mission, such as an offshoot, can be offered any time after a particular storyline mission has been completed, or that a given dësc changes if that mission has been done. For example, if the "test" mission is Fed 12, then the offshoot has to test for either Fed 12's bit, or Fed 13's, or Fed 14's, and so on and so forth.

Orca's original idea works well for exclusive strings, but when there is crossover between strings the bits can get hectic. There is an even larger problem when the storylines are not exclusive, and you can do one after the other, or worse, two or more at once. In the former case you encounter the same problem as Guy's idea has. In the latter, chaos.

I think for a perfectly "clean" setup each mission needs six bits associated with it: available, accepted, refused, succeeded, failed, aborted, ship goal completed, and you'd have to assign each storyline its own block of six hundred bits, with say 1-99 being the avail bits for each mission, 101-199 the onaccept bits, and so forth.

Qaanol, on Jun 25 2005, 03:46 PM, said:

Guy: there's a problem with only having one bit set. Namely, if you want to check whether a given mission has been completed you need a complex swath of bit checks. That is, say a given mission, such as an offshoot, can be offered any time after a particular storyline mission has been completed, or that a given dësc changes if that mission has been done. For example, if the "test" mission is Fed 12, then the offshoot has to test for either Fed 12's bit, or Fed 13's, or Fed 14's, and so on and so forth.
View Post

Easy - just use another bit for the offshoot. Then you'd do the same thing as you went along the offshoot string, clearing the bits behind you.

Edwards, on Jun 24 2005, 11:09 PM, said:

Remember, just because it's the same general style as Nova uses doesn't mean that it needs to be as scattered and incomprehesible as Nova. And, with 10,000 bits at your disposal, I seriously doubt that you will ever run short.

Also, about your use of seperate "mission-number" bits: Unless your storylines are so closely scripted that the same mission in each of them has the same purpose, I can see little value in being able to check which mission you are on independent of which storyline you are in.

Scattered or not, it makes development that much more work, which is almost entirely the point of it. As for the other one, don't make assumptions. When you assume , you make an ass out of u and me.

What if you had every system randomly changing hands? Have suns go nova at random? Have systems be destroyed by enemies randomly? All in a very big "universe" - say, several hundred systems? That's use up tons of bits, not including all the other bits you would use. If you have a big, dynamic universe, you'd be amazed how fast those 10,000 bits disappear.

Now, obviously this will happen rarely if ever, which is why I randomly added it.

Also, I didin't mean to imply that the numbers strictly told what mission you were on. They could be used for anything string-specific.

And...how many TCs do you honestly expect to have complimicated string crossing like Nova does?

EDIT: Well that was rather hypocritical of me. In any case, this won't work for every TC, but it should work for most.

This post has been edited by orcaloverbri9 : 03 July 2005 - 10:59 PM

My understanding of how you would do this to Nova:
Entering the Polaris string and passing the point where you can no longer pull out sets b51. b51 stays on forever. The Auroran missions, for example, can not have b51. Polaris have to. In other words:
Assuming the first mission of every string is the "point of no return:"
Polaris: Grants b51. All missions require b51, and require you not to have b52, b53, b54, b55, b56.
Auroran: Grants b52. All missions require b52, and require you not to have b51, b53, b54, b55, b56.
Rebel: Grants b53. All missions require b53, and require you not to have b51, b52, b54, b55, b56.
Vellos: Grants b54. All missions require b54, and require you not to have b51, b52, b53, b55, b56.
Federation: Grants b55. All missions require b55, and require you not to have b51, b52, b53, b54, b56.
Pirate: Grants b56. All missions require b56, and require you not to have b51, b52, b53, b54, b55.

The first mďsn of string X grants b1 upon completion. b1 allows you to start mďsn 2 of string X, which, upon completion, grants b2, and so on. Getting b1 does not let you start mďsn 2 of string Y because mďsn 1 of string X granted you X's special bit, so that only string X mďsns can be offered from then on. Of course, a mďsn like the one on Kania, where you choose to go for either the Rebels or Feds can delete X's special bit, and add Y's (or Z's, etc), allowing the player to be offered string Y/Z's mďsns.

Sounds VERY simple. And also easy to check. If you could make finishing mďsn 2 delete b1, all you would see in the pilotlog would be b2- about to accept the third mďsn- and b51-60, depending on what string you are in. Of course, making finishing mďsns delete obsolete bits would make pilotlogs hugely easie to read anyway.