Ambrosia Garden Archive
    • Need help with strange behaviour in Nova test expressions


      Hi, I've been trying to make my first plug for Nova, mainly for self use. I'll post what the plug is supposed to be about if additional information is needed from me, but to get to the point, this is the expression that I have in the availability field in a new outf resource that I am trying to incorperate:

      (!(b511 | b515)) | (b511 & (!b129) & (b50 | b61 | b62 | b64 | b66 | b3000 | b500 | b67))

      For some reason, through testing, I found that the above expression always evaluates to FALSE, when my test pilot has the following bits set:

      Mission bits currently set:
      b0
      b9
      b10
      b11
      b12
      b14
      b33
      b34
      b42
      b50
      b51
      b52
      b53
      b54
      b511
      b512
      b513
      b515
      b518
      b801
      b3789
      b4000
      b6006
      b6008
      b7781
      b7783
      b7786
      b7878
      b7879
      b7880
      b9215

      Although I don't do programming very often and this is my first attempt at making a plug, I do know my boolean algebra, and I am quite certain that the above expression should evaluate to TRUE. But Nova thinks otherwise...

      I am really scratching my head for this one, any help would be greatly appreciated.

      OS - Win XP
      Tool - EVNEW
      Nova version - 1.0.6

      ------------------

    • Whoa! Even Matt Burch recommended not to use so many bits for a mission.

      ------------------

    • Quote

      Originally posted by Setheus:
      **Hi, I've been trying to make my first plug for Nova, mainly for self use. I'll post what the plug is supposed to be about if additional information is needed from me, but to get to the point, this is the expression that I have in the availability field in a new outf resource that I am trying to incorperate:

      (!(b511 | b515)) | (b511 & (!b129) & (b50 | b61 | b62 | b64 | b66 | b3000 | b500 | b67))

      For some reason, through testing, I found that the above expression always evaluates to FALSE
      **

      I've encountered this problem as well. The parser used for NCB operations is very simple-minded and cannot tolerate dealing with more than two terms at a time. Try reformulating your expression as follows:

      !(b511 | b515) | (b511 & (!b129 & (b50 | (b61 | (b62 | (b64 | (b66 | (b3000 | (b500 | b67)))))))))

      EDIT:
      Wait a minute. You've got both b511 and !b511. But since it's a logical OR relationship it won't effect the outcome. It does however clutter the issue. It also means you need to rethink what you're trying to accomplish. If this is indeed in the Availability(test) field of an outfit resource, then using both NCB 511 statements as a qualification doesn't make much sense.
      The default Nova scenario uses NCB 511 to indicate that a major string has been started.
      NCB 515 is a multi-task bit used to indicate that the player is currently doing an initial non-Polaris/Vellos mďsn.
      NCB 129 is used to show that the player has completed either Rebel 04 or Fed 21(regain) missions.
      NCB 50 is used to show that the Fed 01 mission has been completed.
      NCB 61 signifies completion of Fed 12
      NCB 62 signifies completion of Fed 13
      NCB 64 signifies completion of Fed 15
      NCB 66 signifies completion of Fed 17 and that a random choice fell to NCB 66 instead of NCB 3000
      NCB 3000 signifies completion of Fed 17 and that a random choice fell to NCB 3000 instead of NCB 66
      NCB 67 signifies completion of Fed 21
      NCB 500 signifies acceptance of Fed 13

      Maybe if you explained more about what you're trying to do it would help.

      (This message has been edited by Arturo (edited 07-04-2004).)

    • It would really help to have a bit of an explanation behind it. Usually its best to stick with a simpler expression, I find the most I ever use is maybe 6 bits at once in a complicated multi-mission setup.

      As Arturo suggested, you should try bracketing everything in pairs. I find this makes Nova's logic much more reliable. But, if it is at all possible, it would be best to simplify that a bit I think.

      ------------------
      (url="http://"http://www.evula.org/aftermath")Aftermath(/url)

    • Yah, from Aruto's research, I'd have to say that having all of b50, b61, b62, b64, b66, b3000, b66, b67 AND b500 in the test expression is riduculously repeditive, superfluous and repeditive, since b61 will never be set unless b50 is already set, and b62 will never be set unless both b61 and b50 are both set, etc etc. This is because they were set by previous missions in the Fed string, and will not be unset again. And furthermore, b511 will always be set during the string. From what I can tell, you want this outfit to anyone doing the Fed string, from the very first mission, and has not gone via the Rebel string - in which case, the entire expression you will need is b50 & !b129, which as you can see is significantly simpler. If this wasn't what you meant, then I think I'd have to go with the flow, and tell us what you want it to do.

      If it's worked out by hand, then your full expression will evaluate to true the moment you finish the first Fed mission, as then you will have

      (!(1 | 0)) | (1 & (!0) & (1 | 0 | 0 | 0 | 0 | 0 | 0 | 0))
      = (!1 | (1 & 1 & 1))
      = (0 | 1)
      = 1

      and it will remain true until b129 is set or b511 is cleared, regardless of whatever else happens. The other bits in the extended OR expression will be set as you proceed down the string, but it won't change the overall outcome of the full expression.)

    • Of could, we are still under the assumption that he is making something to fit into the Nova strings. It could be for something different. It would really help if Setheus made this clear or not.

      ------------------
      (url="http://"http://www.evula.org/aftermath")Aftermath(/url)

    • I thought Nova couldn't handle nests. Is this true or not? If so, isn't that why the original expression doesn't work?

      ------------------
      "The Macintosh may only have 10% of the market, but it is clearly the top 10%." — Douglas Adams

    • Quote

      Originally posted by Belthazar:
      (!(1 | 0)) | (1 & (!0) & (1 | 0 | 0 | 0 | 0 | 0 | 0 | 0))
      = (!1 | (1 & 1 & 1))
      = (0 | 1)
      = 1

      No, you made an error. Here's what it should look like:
      !(1 | 0)) | (1 & (!0) & (1 | 0 | 0 | 0 | 0 | 0 | 0 | 0)
      = 1 | (1 & (1 & 1))
      = 1 | 1
      = 1
      See, you evaluated the (1 | 0) and then checked that this was false, and the Nova engine, last I checked, didn't work this way, but rather checked to see if either one was false, which evaluates to true in this case.

      ------------------
      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)

    • Quote

      Originally posted by Guy:
      **I thought Nova couldn't handle nests. Is this true or not? If so, isn't that why the original expression doesn't work?
      **

      The game-engine can't handle nesting of two specific operators. The random R(<op1> <op2> ) operator and the dësc mutation {Bxxx "stringIfTrue" "stringIfFalse} operator. In other words you can't do anything other than what's specified inside the parens or braces (or is it brackets, I can never keep those two straight). Other than those two operators you can nest your Bxxx and other operators at will. I've used nesting of the normal operators up to 20 deep without problems.

    • Quote

      Originally posted by Arturo:
      The game-engine can't handle nesting of two specific operators. The random R( <op1> <op2> ) operator and the dësc mutation {Bxxx "stringIfTrue" "stringIfFalse} operator. In other words you can't do anything other than what's specified inside the parens or braces (or is it brackets, I can never keep those two straight). Other than those two operators you can nest your Bxxx and other operators at will. I've used nesting of the normal operators up to 20 deep without problems.

      Ah, I see. That's good to know.
      BTW, I think {} is braces, () is brackets, and () is parentheses.

      ------------------
      "The Macintosh may only have 10% of the market, but it is clearly the top 10%." — Douglas Adams

    • Sorry for being so inactive being the person who asked for help, it's been so busy that now is the first time since I posted the topic that I can sit in front of my computer and think about games.
      :frown:

      I'll try to explain what my plug is about and what I was trying to achieve using that long test expression, but before I get into that, let me point out that Arturo's first post helped me to solve the problem - which is, indeed what he described: the parser for NCB test expressions cannot work with more than 2 boolean variables at a time and thus (this bit is my guess) always evaluates an expression to FALSE whenever it can't deal with it.

      Now what my plug's about (for those who are interested):

      Andcarne's assumption is right. I am sick of all those Fed bstrds attacking me on sight 'coz I am flying around in a captured Rebel IDA III. It was pretty easy to make a new rank that prevent that, but I always like things to make sense (and consistent with the original default scenario), even if it's just for my personal use. So then the next logical thing (to me anyways) is to make this privilage (that Feds don't auto attack Rebel Cap ships) item dependent, so I thought about licenses. But who can issue licenses in the defualt scenario? The Feds. But then my thought went on and thought about the fact, that being able to buy this privilage with an arbitary amount of money (credits are too easily obtainable) is waaaaaayyy too cheap, the comfort for not getting harrased can be bought too easily, right down to the level where I consider my plug to be a cheat plug.

      So then I thought harder, and arrived at the conclusion, that since the Feds issue those licenses, why should they issue them to you when you are not even working for them, or even going against them (like, being a true Rebel, not a fake one in a real rebel ship). Soooo, to carry-on the logical flow, I decided to make it so that I can't buy the license unless I am a true civilian (ie - not in any major story), or doing the Fed string. Since there's couple of places where one can enter the Fed story so I'd have to recognise all of them (I have to admit I went a bit overboard but better safe than sorry - I hate debugging). Aaannnnd, since there are links over to rebel story from Fed story as well (eg: b50 is set, but then later on I might defect to the rebel story), I had to deal with that. I think it makes sense 'coz until b129 is set I am still a low-level delivery boy for the rebel so the Fed don't know that I am opposing them yet and thus the license is still available to me in some "transition" periods.

      Arrghh I am crap at putting my thought into words but oh well, I better stop here coz I am not making sense anymore. Actually, I just found out that I could get a sort of commander rank with the Fed story if I get far enough, and that will prevent the automatic attack as well, but it's just plain pain in the *rse, and I doubt if I can make it that far into the Fed story without hanging myself due to the harrasement.

      Btw the plug doesn't stop there in curing the "problem" but I think I typed way too much for one post, and in actual fact I need to play more and understand more of the game anyways, so until next time.

      Big thanks for all your helps and feedbacks - Greatly Appreciated!!!!!!!!!

      ------------------