Im writing a function that uses OS.read_string_from_stdin() arguments. To test if it is working every time i make changes i have to export project (windows) and run the project-console.exe and then i am able to enter into the console my string. The end product will be console-application (dedicated-server).

Is there a better way to debug the stdin() input in godot?

Debugger window has only stdoutput. No way to enter things..

This is really frustrating.. compile takes a second to finish but still i have to press like 4 buttons in 3 windows to export 🙁 .. it gets annoying fast.. also i cant catch errors or test breakpoints in exported project..

ANSWER: xyz Use console version of the editor

Also on another note when im capturing the stdin() inside the console-application (when im writing text) it shows in the console window, but if something else uses print() command, then my stdin() input is blown away with the previously mentioned print() function.

The stdin() varriable stays, just the visual input text is not visible anymore. How can i keep the visual text while other functions print() to console?

Also while im at it, is there a way to redefine print() function, such as that it stays the same but it checks the global flag (bool) if its true then it prints, otherwise it does not. I have a lot of print statements that i want to hide (option for user) and to do that with if statements before each print function, is gonna be a wild ride..

  • xyz replied to this.

      xyz jesus.. at first i didnt get what you meant. I long time ago set the shortcut to the exe and forgot about that it had console version, Thanks!

      But still i need answers for other questions

      • xyz replied to this.

          xyz unfortunately it does not help me. Ok let it block, i just need my input to stay on screen.. it stays in memory so why not on screen?

          • xyz replied to this.

              xyz that is my question... idk.. thats why im asking, how to keep it on screen (console) at the bottom where the input usually shows up or somehting.. you can see it in the video i posted.. after i type something, then i trigger something else that prints to console my input is scrolled up with the triggered print statements .. and if i press enter/return then the input show up correctly because its stored in memory..

              So i need a way to keep it on screen not just in memory.. otherwise user will get spooked and will call ghost busters

              • xyz replied to this.

                  kuligs2 then i trigger something else that prints to console my input

                  What is this "something else" you trigger? If you don't want it triggered, then don't trigger it.

                  What exactly you're trying to accomplish with all this?

                      xyz idk how else explicitly to write this.. im trying to create console application. It runs, does its thing, prints out something to stdout(), it donest matter.. what matter is that user needs to interact with it, so in order to make it "palatable" for users, i need the console app to keep my stdin input on screen no matter what the console app is doing in the bg..

                      Im asking if its even possible.. and if it is how to do it?

                      • xyz replied to this.

                          kuligs2 As I said, if you don't want anything printed - don't print it. What's the purpose of calling print() if you don't want to see it?

                            kuligs2 If you have a bunch of prints scattered around the code and want to disable them all at once, you can disable stdout in projects settings in Application/Run.

                                xyz Prints are needed - its information about what going on. They happen as the code gets executed. Code execution is done from peers (outside) on demand basis.. i have no control when someone sends something to the console app and then the print out happens..

                                Its like any other linux app that prints out things and you can still enter commands and see your input and it can execute.. idk..

                                If its not possible this way then be it..

                                • xyz replied to this.

                                    xyz I wanted to do this when you launch app you specify the verbosity..

                                      kuligs2 So you want to print stuff, but you don't want to print stuff. Makes sense 😃
                                      How do peers get access to your console? And what Godot has to do with all this? You need to be more specific if you want specific solutions.

                                          xyz Do you want to make me this application that i need? 😃

                                          I dont understand how print() works, i thought it just a bg operation, and while im capturing stdin in another thread that it could be overlayed on top of the console output.. but if its all in the same domain (it seems like it) then this is not possible the way im seeing it.

                                          One way would be to do with https://docs.godotengine.org/en/stable/classes/class_semaphore.html like the main _process() does its thing and when its done then it lets the stdin thread do its thing... idk, in no genius when it come to these things.. i just wanted to create a straight forward user friendly understandable interaction with the console application that im working with.. once its done ill post it here.. dont want to spill the beans..

                                          • xyz replied to this.

                                              kuligs2 So you're using threads that print stuff to stdout? You should have mentioned that in the question.
                                              But it seems that you really don't know what you want.
                                              If you want to suspend threads that write to stdout until the current stdin readout is done, you can do this via mutexes or semaphores. You can even implement a custom print function that'll be muted if certain global condition is met.
                                              If all your code is in the main thread then OS.read_string_from_stdin() will stop the execution until input is finalized (that's the blocking we mentioned earlier), but judging from what we've heard so far, this in not the case.

                                              But the first step is to decide on the exact behavior and modalities of your input/output. Until that is clearly known, all we can say is: yeah, whatever 🙂

                                                  xyz i want both, print() functions working alongside with stdin(). Like i tried to tell you previously, i want so that the stdin input varriable/string does not get scrolled away while im inputting it in and while other thread print() functions are printing to stdout.

                                                  Im not sure if its even possible..

                                                  This is not trivial but a quality of life.. if its even possible..

                                                  Yeah i tried the mutex things but i dont understand how print() works, and when and how do i lock it up or what not.. I tried the example from the docs, but it dint work and threw me wierd kinds of errors and i didnt wanted to bother learning what mutex is..

                                                  Atm everything works if nothing is printing to stdout.. my stdin input stays on screen while im inputting..

                                                  • xyz replied to this.

                                                      kuligs2 i want both, print() functions working alongside with stdin(). Like i tried to tell you previously, i want so that the stdin input varriable/string does not get scrolled away while im inputting it in and while other thread print() functions are printing to stdout.

                                                      Consoles are sequential and there is only one cursor. I'm sure you're aware of that 🙂

                                                      What you're talking about sounds like separate input and output widgets.

                                                      Something could possibly be patched with cursor movement escape sequences...
                                                      Do you have an example of a console application doing exactly what you want?

                                                          xyz Well that was my question, i guess you answered it, that the "cursor" is only one.. I was not aware of that, as im not in the know so to speak.. im just a hobbyist..

                                                          I dont have an example for what i want to achieve, need to dig around some linux cmd apps to make sure it exists as i thought.. Now that im thinking.. i think it might not exist.. i know when you tail for example log output the cursor is blocked, right? you need to end the tail command to input new command. Maybe im confusing the behavior that i want with some other application

                                                          • xyz replied to this.

                                                              kuligs2 Why do you need console i/o in the first place? Just run the thing with a graphical interface. You're running a 3D engine anyways.