I am using the Tads3 built in interpreter for the purpose of testing my game.
When the game window is filled with a lot of text during a single turn (so much so that you need to scroll up or down), you get this at the bottom of the window: *** MORE **** [press the space bar to continue]
Which is sometimes functional but not always. If I don’t break up the blocks of text or round off/redirect the text with something like this:
"<.p>Press any key to continue. "; inputManager.getKey(nil,nil);
I experience some buggy-ness. The message (*** MORE **** [press the space bar to continue]) disappears but flashes when I press any key (even the space key). The window snaps between the input (bottom of the text block) and the top of the text block several times until I am able to press and hold the space key. This breaks up the snapping, but it also inserts several spaces into the input, which then need to be deleted.
Does someone know why this might be happening? Has anyone else experienced this, and is there a way to disable this function completely?
I thought it was just a bug on my end (which it may still be, I’m still very new at this), possibly linked to how I started scenes or used fuses. After poking around though, this window snapping bug seems to occur regardless of how the text is inserted, so long as there isn’t something breaking up or redirecting the end of the text block.
Could you elaborate on this? When you say “built in interpreter” do you mean the system prompt in Visual Studio, or something else? I used both frobtads and Qtads (basically alternating between the two) for testing and have not seen anything like this.
Yes, of course. Sorry, I may not be using the appropriate language, so please forgive me.
When using the TADS Workbench, you can build, compile, and run an exe of your game if the compiler is successful. I can compile and run it straight from the TADS workbench for testing, or I can export it into a windows exe. Both experience this issue.
Got it, and sorry. As a Linux Dev I’ve never used Workbench. Do you get a compiled .t3 file out of it also (beyond the windows exe)? If so, does the issue repeat when run under Qtads?
If it did, it might suggest a self inflicted bug, whereas if not, kinda points to Workbench wobbliness. The “more” functionality has been pretty rock solid for me, and I do mess with it a bit.
Wish I had more to offer. Might get better advice from a fellow Workbench Warrior.
You do. I’ve used workbench, and whenever you compile, even to build a stand-alone executable, you always get a standard .t3 file. The workbench doesn’t delete it after the executable is made.
I did a quick run with QTads, and the issue doesn’t seem to occur there. I’m guessing it must be some “workbench wobbliness”, as you suggest. That being said, I’m not completely convinced it’s not a bug on my end (I tend to mess with random bits and bobs that I probably shouldn’t lol).
Anyways… if any new info crops up pertaining to this issue, I’ll add it here. Otherwise, it’s not a huge deal and, as I mentioned in my first post, there are work arounds.
