Scripting question(s)

There's nothing wrong with fallout's division.

script said:
display_msg(""+(2/2)); //Should be 1
display_msg(""+(2.0/2)); //Should be 1.0
display_msg(""+(2/2.0)); //Should be 1.0
display_msg(""+(2.0/2.0)); //Should be 1.0
display_msg(""+(3/2)); //Should be 1
display_msg(""+(3.0/2)); //Should be 1.5
display_msg(""+(3/2.0)); //Should be 1.5
display_msg(""+(3.0/2.0)); //Should be 1.5

Outputs 1, 1.00000, 1.00000, 1.00000, 1, 1.50000, 1.50000, 1.50000. Just like I'd expect it to.

Note that there's a huge difference between 1 and 1.0 in computing terms; if you put two integers into a division, you will get an integer out. If you have two integer variable and need to divide them, but want a floating point result, add 0.0 to one of them before doing the division. (Similar to the '""+...' trick to turn things into a string)

more code said:
var a=3, b=2;
display_msg(""+(a/b)); //Will print 1
display_msg(""+((a+0./0)/b)); //Will print 1.50000

Where there certainly is a problem is in the sfall script compilers constant folding when floats are involved. If you compile the top script with optimization turned on, you get:

//1, inf, 0.00000, 1.00000, 1, inf, 0.00000, 1.00391

That's definitely something I'll fix if I ever get some time to make another release, and is presumably the cause of the weird answer you got from 2.000/3.000. The bug wont effect variables, only when both sides are constant, but if there's a chance of you doing that make sure you turn optimization off.
 
Thanks! I knew I had to be doing something wrong.

Edit: I got it to work, but for some reason it's a bit more complicated (for me at least) than the above example. The only way I can avoid the dreaded result of

//1, inf, 0.00000, 1.00000, 1, inf, 0.00000, 1.00391

is not with

var a=3, b=2;
display_msg(""+(a/b)); //Will print 1
display_msg(""+((a+0.0)/b)); //Will print 1.50000

but with

var a=3, b=2;
display_msg(""+(a/b)); //Will print 1
display_msg(""+((a+0.0)/(b+0.0))); //Will print 1.50000

Edit2: Aha, ((2+0.0)/(3+0.0)) also works.

Edit3: Something tells me you already explained this with the "If you have two integer variable and need to divide them, but want a floating point result, add 0.0 to one of them before doing the division." remark, but I was just too thick to understand it.
 
JimTheDinosaur said:
Edit3: Something tells me you already explained this with the "If you have two integer variable and need to divide them, but want a floating point result, add 0.0 to one of them before doing the division." remark, but I was just too thick to understand it.
No, I explained it with 'if there's a chance of you doing that make sure you turn optimization off.'

Like I said, fallout can do division just fine. If you're getting integer results, it's because you divided two integer variables. If you're gettings inf's and incorrect answers, you need to turn the sfall script compiler optimisations off.

Edit: Note that in my var a=3, b=2; display_msg(""+(a/b)); example, a and b are constant and will still get folded if you don't turn optimization off. Look at the compiler output if you want to see what it's doing.
 
Timeslip said:
JimTheDinosaur said:
Edit3: Something tells me you already explained this with the "If you have two integer variable and need to divide them, but want a floating point result, add 0.0 to one of them before doing the division." remark, but I was just too thick to understand it.
No, I explained it with 'if there's a chance of you doing that make sure you turn optimization off.'

Like I said, fallout can do division just fine. If you're getting integer results, it's because you divided two integer variables. If you're gettings inf's and incorrect answers, you need to turn the sfall script compiler optimisations off.

Edit: Note that in my var a=3, b=2; display_msg(""+(a/b)); example, a and b are constant and will still get folded if you don't turn optimization off. Look at the compiler output if you want to see what it's doing.

Sure, but if the ((2+0.0)/(3+0.0)), etc. workaround works fine, why would I want to turn off optimization (sorry if I'm missing a very obvious problem).
 
JimTheDinosaur said:
Sure, but if the ((2+0.0)/(3+0.0)), etc. workaround works fine, why would I want to turn off optimization (sorry if I'm missing a very obvious problem).
It wont work in general. It might trick it into working in that particular case. In a real script it might not. I advise against tempting fate.
 
I was wondering: is there a way to force the player to exit the inventory screen?

Alternatively (though even less likely), is there a way to force an end turn, regardless of whether the player is in inventory or not?
 
Jim, you might try set_critter_current_ap(dude_obj, 0). I have no idea if it will work or not, but it may be woryh a try.

Anyone, is there any way to return the actual combat hit roll or how much it is made by?
I tried how_much in a global registered for afterhitroll but it doesn't return anything.
I've read through commands.doc and sfall function list several times with no luck.
 
Now that I know the answer to my previous question, here's another:

Is there a way to check whether the path from one tile to another is unblocked? So, basically obj_can_see_obj but stripped down so it doesn't take facing and perception into account? There has to be right?
 
Back
Top