That's actually a cooler idea than what I was talking about. My code "shakes the cup" until you tap a key. But "hold down the key, and when you release it, then take the random number" is an even better idea. I need to try that out. Much more interactive. You can even use the old trick where you print "\", "|", "/", "-" in sequence (with back spaces before each print!) while looping waiting for the key to be released. That makes a spinning "busy" indicator. Look up the ASCII code for backspace. Try this test program to get the idea
5 BS$=CHR$(8):CLS:PRINT"Waiting...."; 10 FOR I=1TO4:PRINT BS$;MID$("/รต\-",I,1);:X=RND(1):NEXT I 20 IF INKEY$="" THEN 10 40 REM Now your randomizer is in a more random state Unexpectedly, if you use i% or say DEFINT I first, the animation runs more slowly, which might be useful to you. I actually ran this program in VirtualT, so it should work. Of course hack this up to work however makes the most sense to you. You could put the INKEY$ test inside the FOR/NEXT loop, for instance. On Tue, Jan 7, 2020 at 9:49 AM James Zeun <james.z...@gmail.com> wrote: > Ok holding down a key to 'roll dice' is a genius idea. > > I understood a bit of that line, but I've delved in to keypresses etc. So > this will be all new territory for me. But sounds exciting :-) > > On Tue, 7 Jan 2020, 3:27 pm Dan Higdon, <therealh...@gmail.com> wrote: > >> In my own random number based programs (for Traveller, not D&D, lol - >> Traveller subsector generation is fun) I usually have a "busy loop" that >> does something like D=RND(1) over and over until the user presses a key, >> and then takes the next RND(1) value as my roll. This is the computer >> equivalent of "shaking the dice cup", and lets the human's own reaction >> times help with randomization. >> Sort of like this: >> 100 d=rnd(1): c=inkey$: if c=="" then 100 >> If you only want to wait for a keypress, you can of course do: >> 100 d=rnd(1): if inkey$=="" then 100 >> I did a D&D (1e/2e) treasure table generator that used this trick. You'd >> type the treasure code letter, and it would update the on-screen horde. >> Space cleared the horde, ESC quite the program, and it "rattled the dice" >> in a busy loop waiting for input. maybe not the most power efficient >> program (not sure if ModelT "throttles down" while waiting for keyboard >> interrupts or not), but it's easy to use. Takes a bit to load though, >> because of the treasure tables. I didn't get to the point where it >> enumerated the gems and magic items, nor do I have "Print a horde report" >> working, since I don't have a ModelT compatible printer. >> >> On Tue, Jan 7, 2020 at 6:44 AM James Zeun <james.z...@gmail.com> wrote: >> >>> I already have a reasonable idea how the program should work. >>> >>> When run, it will ask the user the number of dice required. (Value A) >>> >>> Having established that value, the next INPUT shall be to determine the >>> type of dice in play. (Value B) >>> >>> With those two values, I will either use the randomiser to roll the dice >>> or if I can be a little fancy (as someone mentioned the randomiser isn't >>> very random). I might have the computer wait for the user to tap the >>> SPACEBAR or RETURN key twice. And use the time gap between the two as a >>> value to use in the equation. (Value C) >>> >>> I'm utter rubbish at math, so I might have to trouble someone for a >>> little help. >>> >>> An additional option would be to roll multiple dice of different types. >>> So after inputting the value for one dice. The program asks the user if >>> they'd like to add another. >>> >>> >>> >>> On Tue, 7 Jan 2020, 12:20 pm Charles Hudson, <clh...@gmail.com> wrote: >>> >>>> On January 6th James Zeun wrote: >>>> "It would be even cooler on a TRS80 M100." I apologize for my >>>> ignorance in that I know nothing about the D&D game, never having played >>>> it, but I applaud your willingness to undertake the task. Programming >>>> breaks down into two (usually sequential, but don't ever let yourself get >>>> dragged into the argument) tasks: strategy and implementation. The >>>> strategy, known as the "algorithm", is just the logical path ("steps") to >>>> accomplish the desired end. Implementation is using a language's syntax >>>> ("commands") to describe each step in sufficient detail such that the >>>> computer can carry them out. If you're going to do this on the Model 100 >>>> the you probably will want to use the built-in BASIC programming language. >>>> Hopefully you have the Model 100 manual, which has all of the syntax >>>> detailed, including the RND function, which will be essential to your >>>> implementation. Your strategy will be to determine /declare the number of >>>> dice in play and the number of sides (range of values, if D&D dice differ >>>> from the familiar 6-sided, dotted cube) on any given die, and then to >>>> create a random value for each die in play that is within the domain of >>>> legal possibilities for the game. Later you can expand the program to >>>> display these values, but generating them is the first task. I know >>>> I've seen this algorithm in one of my books - I like books, too - but when >>>> I find it I'll post it. >>>> >>>> -CH- >>>> >>>