R(bxxx byyy) or (xxx | yyy)?

OK, the topic description here isn't really totally accurate, but I was worried about hitting a character cut-off

Also, before I go into this, I know there will be questions about how one mission can have 8-11 objectives and even if it does, how one could make it so that it would be progressively harder to accomplish each. Just trust me on this one.

Aaaanyhow, I'm going to try to do this without giving too much away again, since I'm dealing with the tail end of the second installment of Anathema, in which everything changes. There are some missions in which the better the player does (i.e. completing 8 particular missions instead of just 2), the odds of preventing something from happening go up. The question really is two-fold. Firstly, is it even possible to have some sort of "sliding scale" in this sense instead of an either/or deal? Secondly, if it is, can it be accomplished in the following way:

There are two things in the nova scripting that allow for something random to happen in terms of mission bits. The first is the r(xxx yyy) command, and the second is the | "or" operator. The bible isn't clear on this, and it would be enormously time-consuming to test this, so I wanted to know if anybody knew if these commands can be used to this particular end.

Say that the player manages to accomplish only 1 out of 8 (there's actually 11, but let's just make it objectives in this mission. We'll call these objectives "Buying Lottery Tickets." Also, let's say that every complete objective has a 20% of creating the desired effect. Let's call it winning 1B credits. I know that this isn't a perfect analogy, because one can win more than once in this example while the desired effect is static, but just ignore that pesky detail for now. :rolleyes:

So, if the player buys 1 ticket, the chance of winning 1B credits is only 20%, and if the player manages to buy all 8 tickets, the chance of winning is ~83.3 from the equation (1 - (.8^8))x100. Obviously, there is a sliding scale that creates better odds the more tickets are bought.

Now, let's try to put this into Nova scripting. 20% turns into the fraction 1/5, so each ticket represents a 1 in 5 chance of winning. Therefore, it may be possible to represent this using bit xxx as "losing" and bit yyy as "winning" and running the following Random Ž script every time a "ticket" is "bought": r(bxxx bxxx bxxx bxxx byyy). Or, we could use the "or" operator by running the script: b(xxx | xxx | xxx | xxx | yyy). This would effectively simulate the odds increasing for every "ticket" "bought" without taking up one additional crön or mďsn for every possible combination of "tickets" "bought" (since every "ticket" in this case is independent and acquired in a different way). Because that's a ton of resources.

While these both work in theory, I'm really not sure if the Nova scripter can handle more than 1 random, nor if it will properly deal with having the same expression repeated in an "or" operator. Does anybody know if either of these will work out?

(edit) Oh, and if this is just a pipe dream and I'm totally insane, feel free to let me know that too. I certainly won't disagree.

This post has been edited by Archon : 01 September 2007 - 07:52 PM

Huh...? Confuzzeling.

1. Or is a test operator. Trying to use it as a set operator doesn't even make sense.
2. Operators only work with two expressions. Everything needs to be properly parenthesised. Eg, to test for b1 or b2 or b3 or b4 you would have to write "((b1 | b2) | b3) | b4", or something similar. To randomly set one of those bits with a 25% chance for each you would need to write "r(r(b1 b2) r(b3 b4))".
3. Achieving a 20% random factor is tricky, to say the least. If you really wanted to you could try adding smaller chances together. "r(bx r(bx r(bx by))) r(bx r(bx r(bx r(bx by))))" would give you 1-((1-0.125)*(1-0.0625)) = 0.1796875 chance of setting y.

This post has been edited by Guy : 01 September 2007 - 08:35 PM

Um... What he said. I think.

R( ) doesn't work that way.

(Edit)
You could consider R to be a "50% randomizer."

If you write R(bxxx), half of the time it will set bxxx, and the other half it will do nothing. ("!bxxx" or "bxxx")

If you write R(bxxx byyy), half the time, it will set bxxx, and the other half of the time it will set byyy. ("bxxx" or "byyy")

If you write in any more terms than that e.g. R(bxxx bxxx byyy), Nova won't interpret it properly. (Not Defined)

If, however, you write R( (bxxx bzzz) byyy), then Nova will treat (bxxx bzzz) as a single expression, running properly. ("(bxxx bzzz)" or "byyy")

Concerning Guy's #2
Nested R's, e.g. "R( R(b1 b2) R(b3 b4) )" definitely does not work. This was put to the test a long time ago.

Something that was considered once, that you could try, was a crön with the expression:
R(^b8000) R(^b8001) R(^b8002) R(^b8003) R(^b8004) R(^b8005) R(^b8006) R(^b8007)

The crön would run this expression every game day. Each of the bits 8000 through 8007 would randomly flip values, and could be tested against for Mission or Outfit availabilities e.g.: "(b8000 & !b8001) | (b8002 | b8003)"

If you wanted a chance of 25% for something you could write: "b8000 & b8001" since those bits would only both be set approx. 25% of the time.

Purchasing additional "Tickets" would not improve the chances of winning, here.

This post has been edited by Eugene Chin : 01 September 2007 - 09:21 PM

Additive changes in probability will be tough, is the message, I guess.

But you could fairly easily arrange things to double the probability each time....or halve it.

| only works as a test function? Hmm, that seems strange given that all the other operators – ( ), &, !, ^, etc. – are expressed in the bible as working for set expressions as well.

Despite that, the general feeling I'm getting here is "in your dreams." Just for clarity though, Eugene is saying that Guy's "r(bx r(bx r(bx by))) r(bx r(bx r(bx r(bx by))))" won't work at all, correct? Meaning there's really no way to do it?

Oh, and 20% was just a number I pulled out of thin air because it seemed like a good number to go with. Making each have a 12.5% chance will probably work better in-game anyways, so something along the lines of r(bx r(bx r(bx r(bx r(by))))) assuming that even works?

edit#2, regarding Eugene Chin's edit:

Well, the set-up using cröns that you described seems to be used to generate entirely random events rather than give a sliding scale of variability based on events the player undertakes. However, you did give me an idea (I think).

This post has been edited by Archon : 01 September 2007 - 09:28 PM

"Edit Pending" == "I'm writing this as fast as I can and will add more in a minute"

OK, Eugene just gave me a great idea! Not sure how, but as soon as I read his edit this just popped into my mind!

The things that trigger the "buying of the tickets" are landing on particular spöbs to complete a particular mission, which changes the planet's owner. So, there is really an easy solution to this problem that never even occurred to me! Make a mission that is only available from each changed spöb and make a crön that corresponds to each spöb's change. Say completing every mission sets bx and b2. The system will be changed when bx is set (varying per stellar), and the "lottery ticket" mission is only available when b2 is set. Put in a crön that runs when b2 becomes set that one day hence will clear b2. This means that after blast-off, landing on another (or the same) planet will not give you another chance at the "lottery ticket mission." Finally, make this "lottery ticket mission" available from the Main Spaceport so it automatically runs after completing the missions, and give it a 12% or so chance of being available!

I think this will work!

This post has been edited by Archon : 01 September 2007 - 09:52 PM

@eugene-chin, on Sep 2 2007, 01:46 PM, said in Random Bit Settings:

Concerning Guy's #2
Nested R's, e.g. "R( R(b1 b2) R(b3 b4) )" definitely does not work. This was put to the test a long time ago.

Oh dang, I should have remembered that. In that case you could just have your 8 missions set something like "r(b1) r(b2) r(b3)" and then there'd be a 12.5% chance of "(b1 & b2) & b3" evaluating to true. Or as a new example of the one I already showed, "r(b1) r(b2) r(b3) r(b4)" with a 17.96875% chance of "((b1 & b2) & b3) | (((!b1 & b2) & b3) & b4)" evaluating to true (hope I got that right).

@eugene-chin, on Sep 2 2007, 01:46 PM, said in Random Bit Settings:

If, however, you write R( (bxxx bzzz) byyy), then Nova will treat (bxxx bzzz) as a single expression, running properly. ("(bxxx bzzz)" or "byyy")

Just tested: this doesn't work. Half the time you get bx & by, the other half you get bx & bz & by.

@eugene-chin, on Sep 2 2007, 01:46 PM, said in Random Bit Settings:

Something that was considered once, that you could try, was a crön with the expression:
R(^b8000) R(^b8001) R(^b8002) R(^b8003) R(^b8004) R(^b8005) R(^b8006) R(^b8007)

The crön would run this expression every game day. Each of the bits 8000 through 8007 would randomly flip values, and could be tested against for Mission or Outfit availabilities e.g.: "(b8000 & !b8001) | (b8002 | b8003)"

Wait, what would you use this for? If I understand right, the cron is just generating a new random number each day. Why would you this for mission/outfit availabilities rather than the avail random field already provided?

@archon, on Sep 2 2007, 01:59 PM, said in Random Bit Settings:

| only works as a test function? Hmm, that seems strange given that all the other operators - ( ), &, !, ^, etc. - are expressed in the bible as working for set expressions as well.

You may be looking at the wrong parts of the bible. | and & are test operators. ^ is a set operator. Parentheses are primarily used in test expressions but are also used for r( ) in set expressions.

This post has been edited by Guy : 01 September 2007 - 11:20 PM

Ahh yes I see. I've been throwing in functions that didn't do anything for years now. :mad:

Does that seem like a feasible solution though? The 1-day crön and 12% mission? I know 1-day cröns sometimes get messy (or is that 0-day cröns that just don't work?), but there are a few ways around that too.

edit to Guy's edit: I'm pretty sure that if mission Z sets b1 upon completion, a mission with b1 as the only requirement that is available from the main spaceport will be offered immediately. I.e., you land, mission Z completes and sets b1, and at that exact moment, mission A (which requires b1) fires up, assuming the chance was 100%. Or, in this case, mission A has a 12% chance of firing. I think I actually did this a few times already, like when you head to New England, yell at Penton, and then after completing that mission are immediately offered the mission to test the Sentinel, all in one fell swoop.

This post has been edited by Archon : 01 September 2007 - 11:27 PM

Gah, I've been making too many edits while you've been reading that. After reading your solution twice I think I get how it works. Of course you're using additional crons and stuff to do that (not to mention the bugs with crons), plus if you make a jump rather than landing then you miss out on your 12% chance that day. See the first part of my last post, I think that way would work okay.

To get lower percentages, look at ARPIA2 Data 1, the last few missions ("Death" and the following). But you then need a bunch of cröns/mďsns.
To get 12.5%, for example, I used "R(sXXX bYYY)", with bit YYY being a dud one (in total: 50% chance of getting sXXX so far). Then mďsn XXX says "R(sXXY bYYY)" (in total: 25% chance of getting sXXY so far). And then mďsn XXY is "R(bYYY bZZZ), ZZZ being the one I want.

It means you can ultimately get any 1/(2^n)th of 100% chance (for example, 37.5% chance uses "R(sXXX bYYY)", then "R(sXXY bZZZ)" in mďsn XXX and then "R(bYYY bZZZ)" in mďsn XXY.

If you want to see an example of a more complex random thing, look at the "Culuria Change" cröns in ARPIA2 Data 2, which basically control which version of Culuria out of 7 the player will see any given day.

(/shameless advertising)

I like it. No dealing with messy 1-day cröns. That's some seriously innovative scripting!

Just to clarify, you have, a string of 50/50 branches that dud half of the time, with the desired result being at the end, right? My only question (it actually won't make a difference for my purposes, but just out of intellectual curiosity) is will you end up running this whole string out instantly? Or is there some game-time delay on it? I know sometimes you need to land/jump for things like that to run.

Those mďsns have an immediate effect, and are set as "auto-abort", with the aforementioned expressions in the "OnAccept" field.
This means they work both when the sequence is started in flight and when it is started on a planet (for example, Death in ARPIA2 is based on a not-so-random factor determined in flight, if I recall correctly, whereas I think a couple of missions in ARPIA2 are "dud" auto-aborting ones that start as soon as the player lands).

And yes, it's basically always a 50-50 chance, with one dud bit (not dud, but filler for example, I used a bit already set by the first mission of the Arpian storylines, so it's just re-setting that bit) and one expression that bears more meaning.

Awesome! Thanks for the help Pace! You may want to see about getting that method of random chance generation put on the "cool nova hacks" string so it gets the sticky it deserves.

So now it's just a simple matter of scripting those missions in. Me likey!

Nah, because otherwise I would just put "see ARPIA2 Data files for hacks"

Wait wait, I've just come up with an idea.
"r(b1) r(!b1) r(!b1)"
What's the result of this? Why, a 12.5% chance of b1 being set, of course
Use a different bit for each of your 8 missions and your final mission can simply check for "((((((b1 | b2) | b3) | b4) | b5) | b6) | b7) | b8".
Actually, depending on how your final mission works you might be able to just use one bit.

This post has been edited by Guy : 02 September 2007 - 06:11 PM

@pace, on Sep 2 2007, 07:07 AM, said in Random Bit Settings:

Death in ARPIA2 is based on a not-so-random factor determined in flight, if I recall correctly

No, it's entirely pseudorandom. It is, however, calculated in-flight.

I did say "not-so-random", and the formulation implies that it isn't random, just that it appears somewhat random