 |
Castle Paradox
|
View previous topic :: View next topic |
Author |
Message |
msw188
Joined: 02 Jul 2003 Posts: 1041
|
Posted: Fri Jul 07, 2006 11:26 am Post subject: What is 'True' in a plotscript? |
|
|
I was just reading a thing on one of those things dealing with some things here, and apparently there is some confusion on what number corresponds to the word 'true' in the OHR, and what number is returned as true from certain commands. In addition, there is also the question of what the flow control commands are looking for when they are deciding how to flow.
I seem to remember having a problem with this in connection with the command 'fight formation'. I would have a line that read:
if (fight formation (enemy) ), then
begin
#INCREDIBLE THINGS
end
and the INCREDIBLE THINGS would never happen! I thought that the problem was the existence of an 'after battle' script on the same map that interrupted the return of 'fight formation', but maybe it was also related to this problem?
Regardless of this, the problem becomes very real when we consider the difference between:
if( some command that returns true or false ), then
versus
if( (same command) == true ), then
Some people write one way, some the other. I began writing everything the second way in an attempt to fix the problem mentioned above about 'fight formation', before I began messing with the presence of an 'after battle' script. I was hoping someone could clarify what is going on, what the problem is currently, and if we should be converting our current scripts to one or the other of the two syntaxes (?) above. |
|
Back to top |
|
 |
Bob the Hamster OHRRPGCE Developer

Joined: 22 Feb 2003 Posts: 2526 Location: Hamster Republic (Southern California Enclave)
|
Posted: Fri Jul 07, 2006 1:48 pm Post subject: Re: What is 'True' in a plotscript? |
|
|
Code: | if (fight formation (enemy) ), then
begin
#INCREDIBLE THINGS
end |
The above is absolutely correct. Are you sure you remember the details of the problem correctly? Are you sure that was the exact if confitional that was causing the problem?
Code: | if(fight formation (enemy)==true), then |
is a bad idea because true is indeed ambigious. Anything other than zero is true, but in some cases true is technically a zero, in other cases it is technically -1 and (1==-1) will cause unhappyness.
The places where true is -1 have been fixed for ubersetzung (relase-after-next), so this sort of problem will be lessened then, but it is still best to write:
Code: | if(fight formation (enemy)), then |
|
|
Back to top |
|
 |
Mike Caron Technomancer

Joined: 26 Jul 2003 Posts: 889 Location: Why do you keep asking?
|
Posted: Fri Jul 07, 2006 1:51 pm Post subject: |
|
|
The Truth is out there. Truth is how you define it. You can't handle the Truth.
Ahem. True is defined as "1". False is defined as "0". These constants are defined in plotscr.hsd:
plotscr.hsd wrote: | define constant, begin
#...
0,false
1,true
#...
end |
However, to the if statement, Truth is handled a bit differently. False is 0, as usual, but True is defined as "not 0". So, 1, -1 and 5123 are all true.
To reiterate, "Real" true is "1", where as "Logical" true is anything that isn't 0. (this is important)
This discrepancy between Real True and Logical True is why "if(foo == true)" and "if(foo)" are not the same. The first compares foo to the actual value of true ("if(foo == 1)"), and then sees if the == operator returns 0 (not equal) or "anything except 0" (equal). The second step forgoes the == operator, and just checks to see whether foo is 0 or not-0.
Now, normally this isn't a problem (if foo is "1", then 1 == 1), and if foo is actually a function call (key is pressed(), for example) which returns true or false, then that's not an issue. However, you may be tempted to do something like this:
Code: | foo:= random(0,2) #1/3 chance of it being 0
if(foo, and, key is pressed(key:j)) then (...) |
Now we have a slightly different problem. What many people don't realize is that the AND operator is NOT a logical operator. That is, it's not boolean. It is a bitwise operator. That is, it operates on each bit in the numbers. I won't go into detail, but basically, for each bit, it says "If the bit in the first number is 1, and the bit in the second number at the same place is also 1, set that particular bin the result to 1. Otherwise, set it to 0."
First case, foo == 0:
Code: | 00
01 #true == 1
--
00 |
Ok, great! The result is 0, just like it should be. Now, let's look at when foo == 1:
Perfect! 1, and, 1 == 1! Now, let's look at when foo == 2:
Code: | 10 #2 in decimal
01
--
00 |
Oops, the bits in 1 and 2 don't match at all, so the result is all zeros, which evaluates to 0, and thus, Logical False.
(if you didn't understand any of that, that's ok, it is confusing) _________________ I stand corrected. No rivers ran blood today. At least, none that were caused by us.
Final Fantasy Q
OHR Developer BLOG
Official OHRRPGCE Wiki and FAQ |
|
Back to top |
|
 |
Cube Dimensional Traveller

Joined: 02 Feb 2003 Posts: 294
|
Posted: Fri Jul 07, 2006 10:01 pm Post subject: |
|
|
A while back I found fight formation() to be broken. I told TMC and Mike about this on IRC but I dunno if it was ever taken care of. I guess it wasn't, heheh.
But at any rate, I too couldn't get it to work right, so I eventually had it do:
show value(fight formation(formation))
And every single time, show value() would display the formation ID I fought instead of if I won or ran/lost. Hopefully now that I've posted this on the forums it won't get forgotten next time  |
|
Back to top |
|
 |
Mike Caron Technomancer

Joined: 26 Jul 2003 Posts: 889 Location: Why do you keep asking?
|
Posted: Sat Jul 08, 2006 2:16 pm Post subject: |
|
|
Well, I just tested it, and it returns either 1 or 0. So... yeah.
Anyway, last night, after writing that post, I added a few new operators to hamster speak, those being logical and ("&&"), logical or ("||") and logical xor ("^^"). They are used like this:
Code: | show value(1 && 1) #1
show value(1 && 0) #0
show value(1 || 0) #1
show value(1 && 54) #1
show value(42 || -5412) #1
show value(1 ^^ 0) #1
show value(1 ^^ 1) #0 |
Note that since they use symbols (&& instead of "and"), no commas are necessary ("1 && 2", NOT "1, &&, 2"). _________________ I stand corrected. No rivers ran blood today. At least, none that were caused by us.
Final Fantasy Q
OHR Developer BLOG
Official OHRRPGCE Wiki and FAQ |
|
Back to top |
|
 |
msw188
Joined: 02 Jul 2003 Posts: 1041
|
Posted: Thu Jul 13, 2006 9:42 am Post subject: |
|
|
(In reply to James Paige):
If I remember correctly, the problem occured because there was an 'after-battle' script on the map in question. Thus, the other script would get 'interrupted' after the player fought the battle, and so the return of fight formation did not get through correctly...?
I say this because the
if(fight formation (number) ),then
worked on maps without 'after-battle' scripts. |
|
Back to top |
|
 |
|
|
You can post new topics in this forum You can reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|