Quirks...

[kagehi]

Ok. For the sake of argument, since I don't plan to post the whole of all the code I had to re-do to make it work, here is some simple code I was trying to use to determine a result of a flag being set, and deciding what the "roll outcome" would be. This uses something that a) should work, but refuses to, i.e., it compares the value of adv to see if its "TRUE", this fails regardless of if I have if use "adv = TRUE" or just "adv" by itself. I had to actually have it evaluate "adv = 1" to get it to work, and set the variable adv to 1 to do so. The second trick is in the math. Boolean does strange things in various sorts of BASIC. In Visual Basic the code below will work, because I am forcing it to evaluate the < and > to determine which one is true, and this produces -1 and 0, so using ABS forces these values to become 1 and 0. Then the math simply multiplies one of them r1, for example, if that was the larger value, by 1, and r2 by 0, and your get only r1 returned. If r2 is higher, then it gets multiplied by 1, and r1 is multiplied by 0, and the returned result is r2. Saves having to do a bunch of if-then nonsense, when it works. Some other BASICs return 1 or 0, instead of -1 or 0, so the ABS command isn't even needed. Supposedly Just BASIC should do this, but I find its always safer to use ABS.

In any case... When I tried to do things this way, none of it seemed to work. Even replacing the "result" math with an if-then didn't do anything, because the "if adv = TRUE then" part never branched.

Aside from having to use [branch] calls, instead of gosubs, because gosub operations also don't seem to work either... Again, resulting in a bit of annoying restructuring to get a round this, the fact that this won't work bugs the hell out of me. What is going wrong? lol

r1 = int(rnd(0) * 20) + 1

if adv = TRUE then

 r2 = int(rnd(0) * 20) + 1
 result = (r1 * abs(r1 > r2)) + (r2 * abs(r2 > r1))
else
 result = r1
end if


[xxgeek]

ABS( n )
Description:
This function returns | n | (the absolute value of n). "n" can be a number or any numeric expression.

Simple
abs(r1 > r2) and abs(r2 > r1) are NOT numeric expressions, nor do they resolve to a number.

Look into  MAX and MIN to help you get the results you're looking for.

MAX( )
MAX( expr1, expr2 )
Description:
This function returns the greater of two numeric values.

Usage:

input "Enter a number?"; a
input "Enter another number?"; b
print "The greater value is "; max(a, b)

See also: MIN( )

[B+]

print "TRUE = ";TRUE

TRUE is not a constant in JB

Best way to see if something is TRUE, is to see that it doesn't = 0

If x <> 0 then print "x = TRUE" else Print "x = FALSE"

[kagehi]

Hmm. Ok. lol Good to know. Mind, the "simple" solution would then be to actually set variables TRUE as 1, and FALSE as 0, then it would work fine. The problem is that the documentation in the help file does actually imply, quite clearly, that boolean operations "can" return a result of 0, or 1. However, I am guessing that it does so as a boolean result, so.. maybe a possible solution would be to replace ABS() with INT()? Hmm. Will have to experiment. But, got to love the weird inconsistencies between versions of BASIC with some of this stuff.

Also, thanks for the advice of using MIN and MAX. My head space, often, defaults to Apple BASIC, since that is what I learned on, and back in the day using that fun bit of math saved not just code, but memory space, since every single statement in the line had to be converted into a token, and using a mess of if then stuff to do something would literally double the bytes eaten up by the code (besides which, evaluating the math was also faster by a few processor cycles). There where no MIN or MAX commands. Less critical here, but.. I still use it because having a whole bunch of if-then tests slapped together is.. maybe more readable in some cases, but also, to me, messier.

On the other issue I mentioned.. When I tried to do something like:

button #Main.clickme "Clickme", handleit, UL, 10, 10
[loopy]
wait
goto [loopy]

[handleit]
'do stuff here
return

(Forgive me if I got some things out of order there...) The result of this was that clicking the button did zip, nada, nothing. I had to replace it with something like this:

button #Main.clickme "Clickme", [handleit], UL, 10, 10
[loopy]
wait
goto [loopy]

[handleit]
'do stuff here
goto [loopy]

I don't get why this wouldn't work. I assume, logically, that, in the wait loop, it would see the click, gosub to the event handler for that button, do what ever it was supposed to, then return to the line immediately after the "wait", which would loop it back to waiting again. Instead.. it didn't seem to make the call at all. Am I missing something? I mean, its simple to work around, I just have to use goto to redirect execution back to the loop, but.. I had enough of the, "Wait!!! You are using GOTO??? Never use GOTO!!!", drummed into my head from OOP and so called "sound design practices" that I am kind of weirdly offended that its not working as I assume its supposed to. lol

[kagehi]

Hmm. Poking around in the help.. Can probably use a "sub" instead, and presume that would work right? Sometimes wish example fragments where a bit "less" simple in help files. Sometimes they just confuse things more, since its never the usage you are trying to employ them in that is in the example given.

EDIT: OK, after further reading it explicitly says that its either branching or "SUB"s. So, that was what I was doing wrong. Mind.. it runs without an error, if you use it wrong, so.. probably should have an error generated if you try to use a sub name, and no sub exists, instead of a branch label. But, good to know. Thanks for the help with the other oddities.

[xxgeek]

I'm no expert but I look at things in my own way when it comes to programming.
This is the way I look at it.

All buttons are sitting there doimg nothing until pressed, (they are waiting for that "press")

All your code referring to that "press" needs to be between the [buttunclick] and the "wait" statement. You can exit from there when you like, and then the button waits again for another "press".

[xxgeek]

Here's a small example.

nomainwin

WindowWidth = 752
WindowHeight = 630

UpperLeftX=int((DisplayWidth-WindowWidth)/2)
UpperLeftY=int((DisplayHeight-WindowHeight)/2)

bmpbutton #main.bmpbutton40, "apps\hacker.bmp", [bmpbutton40Click], UL, 22, 100

button #main.button1, "BAT<>EXE<>CMD", [button1Click], UL, 486, 131, 122, 25
button #main.button2, "CREATE EXE FILE", [button2Click], UL, 486, 166, 122, 25

open "Software" for window as #main
print #main, "trapclose [quit.main]"

print #main, "font ms_sans_serif 10"
print #main.button1, "!font Arial_Black 8 bold"
print #main.button2, "!font Arial_Black 8 bold"
wait

[button1Click] 'bat2exe 'button1'
run "apps\bat2exe.exe"

wait
[button2Click] 'SFX-Creator 'button2'
run "apps\sfxcreator.exe"
goto [wherever]
wait

[wherever]

[quit.main]
close #main
end

Hope this helps you understand JB a little better. It took me a while too, still learning...
Also if you go in the menu and RUN FreeForm editor. You can add buttons etc to a form, and then use the menu in there to use Output/Produce code + outline to get the code and syntax made up for you..

[B+]

The problem is that the documentation in the help file does actually imply, quite clearly, that boolean operations "can" return a result of 0, or 1.

Sure! here is example:

print 5<10
print 5>10
print (5<10) + (6<10) + (7<10) + (8<10) + (9<10)


[kagehi]

Thanks xxGeek. My mistake was assuming that a "gosub" referred to a "sub", or acted like one. So, when I was giving it a sub name (without the []), Just BASIC failed to generate an error, to tell me that no such "sub" existed. Instead, when ever a button was pressed, it simply failed to call anything at all - since a branch label isn't a "sub" (but, confusingly can be called using "gosub"). Basically, if I had read the help files more to work out what was going on I would have realized I needed to actually create something like:

sub handleit
stuff
end sub

Then it would have worked as expected (and how I originally intended). Whoops!

Funny enough I was busy trying to write, and debug, this *in the middle of* a DND campaign, since all the dice rollers out there are stupid, and can't handle the insane madness that actually happens in a real game. In this case, the madness is, "I need to roll, sometimes with advantage, a 1d20, add my modifier, then also roll damage, which is 1d8 + 6, but I also add +2 if using special ammo, and +2 again if its a favored enemy, plus I add 1d6 if I am using hunter's mark, but then if I am also using the bows phase ability I add another 1d8, then, if its the first shot, and I have a bonus action, I can also add another 2d8..." So.. How the F do you do that with all these dice rollers that exist already? Answer: You can't, because almost none of them let you roll more than one die at a time, of a different type, none of them let you roll your attack, along with damage, and absolutely none of them let you set up conditions, where some dice get rolled, and some don't, based on which freaking features/abilities you have active.

In short, they are all garbage, unless you want to roll every "dice" separately, and do all the math in your head, and not even people using real dice roll them all one at a time, by themselves. Keeping track of all this conditional stuff is just madness. So.. I figured, for my own sanity, I should write something that did it for me. Then I procrastinated until like 9 this morning, got annoyed with how hard most solutions would be (including trying to get it to work in Visual Basic, where I couldn't just dump out of the program, add another button, do a quick run, and fiddle - its a bit more complicated than that, and a form editor actually gets in the way of doing this sometimes), found Just BASIC online, started throwing the thing together around 1 PM, the game started at like 2:30, and it took me until almost that to fight the code into something that "worked, but not how I wanted". Then.. the DM tells us, "BTW, this monster has fire resistance, so I need to know if any of you are doing fire damage, and how much." So.. in the minute or so that it took to go through everyone else's actions, I had to rewrite the code, again, to split out the damage types, and display them each, by themselves, instead of just totaling all the damage up.

Not sure if this was "fun", or "hair pulling". lol

But, that said, there is something to be said for the fast and dirty coding you can do with something that still behaves like the old QBasic, and the like, where you don't need to shove everything through a compiler, and running it (and getting a result) is immediate - even when the coders miss things, like having boolean results convert to integers when in equations, something "most" versions of basic do, though the result may sometimes be -1, instead of 1, and other minor quirks, which someone may have learned to take advantage of over the years, to short cut things.

At least next session of the game I will have everything working, having managed to create a framework to build on, instead of looking at my options to write it in and going... "Oh, man.. All of these will be just such a pain in the ass to even get started with!"

[B+]

On the other issue I mentioned.. When I tried to do something like:

button #Main.clickme "Clickme", handleit, UL, 10, 10
[loopy]
wait
goto [loopy]

[handleit]
'do stuff here
return

(Forgive me if I got some things out of order there...) The result of this was that clicking the button did zip, nada, nothing. I had to replace it with something like this:

button #Main.clickme "Clickme", [handleit], UL, 10, 10
[loopy]
wait
goto [loopy]

[handleit]
'do stuff here
goto [loopy]

I don't get why this wouldn't work

button #Main.clickme "Clickme", handleit, UL, 10, 10 '<<<<<<< This is looking for a sub called handleit

button #Main.clickme "Clickme", [handleit], UL, 10, 10 '<<<<<<<<<<<<<< This is looking for a GOSUB line label [handleit]

[kagehi]

Jan 24, 2021 4:27:37 GMT B+ said:

The problem is that the documentation in the help file does actually imply, quite clearly, that boolean operations "can" return a result of 0, or 1.

Sure! here is example:

print 5<10
print 5>10
print (5<10) + (6<10) + (7<10) + (8<10) + (9<10)


Hmm. OK.. Weird. Guess I need to experiment more. It may be a case of how I did the equation, rather than it being impossible... Not that I need it, with the MIN and MAX commands. But I do wonder how it went wrong and kept returning 0 for the result. Oh well, sure it was just an error in my math.

[kagehi]

Thanks B+. Seems like I replied just as everyone else was doing so, or something, so we cross talked. lol I kind of figured out the sub/branch issue. Though, didn't occur to me to leave the "return" lines in, instead of using goto to get back to the loop. A bit of deeper reading left me realizing, "Oh, duh!" lol

[B+]

Yeah JB is a bit different than VB!

[xxgeek]

Here's another example to help you out with some syntax.

nomainwin

WindowWidth = 752
WindowHeight = 630

UpperLeftX=int((DisplayWidth-WindowWidth)/2)
UpperLeftY=int((DisplayHeight-WindowHeight)/2)

button #whatever.bat2exe, "BAT<>EXE<>CMD", [bat2exe], UL, 486, 131, 250, 40
button #whatever.sfx, "CREATE EXE FILE", [sfx], UL, 486, 166, 250, 40

open "Any Title You Wish" for window as #whatever
#whatever, "trapclose [anytext]"

#whatever, "font ms_sans_serif 10"
#whatever.bat2exe, "!font Arial_Black 8 bold"
#whatever.sfx, "!font Arial_Black 8 bold"
wait

[upthere]
[bat2exe] 'bat2exe 'button1'
run "apps\bat2exe.exe"
x=x/y
v=1
for t=10 to 100
y=y/t
next t
wait

q=14

[sfx] 'SFX-Creator 'button2'
run "apps\sfxcreator.exe"
goto [anytext]
wait
B$= "Hello World lol"
[wherever] Must label match goto [wherever]
a=60
goto [upthere]
[anytext]' Match label with "trapclose [anytext]"
z=1
a=a+4
close #whatever
end


Personally I learn by reading the code others write, and I find the JB help files rather confusing, and discouraging. But it's free, and I never have to see a barber anymore

I just started with JB a couple of months ago and am learning as I my interests need.
Good luck with your dice project.
The guys in this forum have helped me every time I've asked.
Damn, I hate asking....like to figure things out myself.
But don't hesitate if you need it.

[kagehi]

lol I find that with almost all "documentation". There seems to be an assumption, probably due to them being even techier, or, kind of like happened with Blender, too close to the project, to recognize that the people that need to use their language are *not experts at it*, and what is obvious to them isn't obvious to everyone else. The least annoying cases of this are like seen in JB, where they show a code fragment that is "literally" the simplest example of usage possible, when the most likely/common use, for anyone that actually knows enough to code something complicated, is *never* in the examples. The worst example of this had to be back when the Apple IIgs came out, and the flags needed to set options on some controls where... well, the documentation for the compiler was really hard to dig through, the books on the subject assumed you where coding in machine language, and the controls themselves sometimes had revisions that rendered some flags invalid, so it was literally impossible to look at the documentation for any for the C, BASIC, or Assembly and find that the flag values freaking worked between them. And.. this could mean either that the GUI element would crash, load, but not work, work, but not return recognizable values, work 100% right, as long as you don't mind all the text being wrong, or any combination there of. It was a mess, and without realistically priced hard drives back then (as in remotely affordable), trying to even run a compiler, so you where using "known" values, for a single language, and the result would be vaguely predictable, was.. troubling.

But, yeah. I despise a lot of "documentation" that exists out there. Its always easier, like you say, to look at a full, working, program, if you can get your hands on such (which isn't always possible), and hope it has the usage/format, you need for the commands you are interested in, to have to do what you are trying to do.