I was on a long car trip so naturally I brought one of my calculators and computer. I was bored of Minecraft so I remembered a game my friend showed me called Petals Around the Rose. Not really a game.... more of a puzzle. Riddle type thing.

So the puzzle/riddle/game is that the one person knows the rule and anyone else playning doesn't. The people that don't know the rule take turns rolling dice and guess values according to what they think the rule is. Then the person who knows the rule says the actual value. The first to figure out the rule wins.

But on my calc version, I suppose you could pass the calc around, but I'm having trouble getting an input( command to not erase everything I real( ed on the screen. Is there a way to do that?

Screenie


So I want to know if there is a way to keep the dice on the screen when you're inputting the number. Thanks for all help in advance!

Are you not able to StorePic before the input and RecallPic afterwards? Another option would be to write your own custom Input routine using getKey; since you're just accepting digits and positive integers (right?), it should be relatively straightforward.

Do you mean at the same time or do you need to store the dices, then input and then display the dices again?

If it is the first, you need to do a custom Input routine. Look at Ti-Basic developer, they have pretty nice solutions.
If you need to display the dices later, this is pretty easy:
:Input "whatever you need", somevar:DispGraph
and you get your dices back.

Well there is always the getkey loop with a numpad reader like this:

Code:

That's what I used to input stuff without leaving half-res mode on the CSE, I believe the same trick would work on the monochrome calcs

Where is the user inputted number after that?

In Ans of course...

I just had an idea:
You can display your dices at the top half of the graphscreen.
Then do

Code:


And here you go, both at the same time on screen. To exit this mode to normal do ":Full" and its back.

mr womp womp: Oh, I'm stupid. It was the last command in that thing. So you could toss a ->variable on the end of that and it would work. But it doesn't look like that code displays anything while it's inputting. Would it be better to use an arrow-key inputting method to let the user see what they're inputting? I think yours is still better though. I'll try it and see what happens.

EDIT:: So this code you gave me only does 1 digit... I can only enter 0-9 when I need to be able to answer two digit numbers. Does what I'm describing sound right?

Nik: Does the real( command do what it does on the graphscreen? I thought it did what it does wherever you were at the moment. Because I can use the real( command and Output( at the same time and it still works. That would mean that I am in the homescreen. Maybe Kerm knows more on this. Actually... Kerm knows more about this.

Code:

There you go m8, stores it to A, you press enter when you're finished entering your number

Thanks so much. I'll make sure to give you credit in the archives page for this.

EDIT:: Here's the code in case lirtosiast (or anyone ) sees anything that can be optimized. I'll look too:


Code:

Code:

Well, in a for( loop, if the increment is 1, you don't need to put it, and since you're only using A for this loop, you could remove "A" all together from the program, making your program overwrite 1 less var (I value that ), and slightly (unrecognizably) faster. Here is the code once these tiny modifications have been made...

Code:


Code:

Here, you could get rid of the U variable as well...

Code:

Those are good optimizations. I won't use the first one because the top secret answer needs A.

But the second one. definitely will use.

That part with those many output commands...
Well, Output( Wraps text to a new line if it is too long to fit in one, so you only need to add enough spaces to make words wrap correctly and put it I an single line with a single "Output(1,1," command.
At the end that T=U if-statement to display if it is correct or incorrect becomes:

Code:


Thats all I see after the first scanning of your program.

I like where you went with that. I certainly wouldn't have thought of it, but when your answer is incorrect I made it display the correct answer and using this optimization you would end up using more code to get that to work.

As for the zillions of outputs.... I didn't know that the text wrapped. Thanks

Ok, now the whole optimized chunk in all:

Code:

56 bytes vs 65 bytes, mine wins!
But well, in my first version I mixed quite a bit up...

If you really want to try that hard, you could go as far as the custom input routine to prevent having to strip the string... however, I think this is pretty extreme considering you only save a few bytes... Anyway, your's is 61 bytes since the Enters count as bytes mine is 50, counting the Enters... SOOOOOO I WIN!! (the custom input routine that I modified didn't change in size, but it would need to be modified for my new code to work )

Code: