I cant imagine anyone that should expect ConsolePrint() . . Go to ide instead of ...console
I believe none has test it yet. Even I, notice it from this guy's example. I dont use console at all ATM
But anyway
ConsolePrompt() prompts in debug window not in console
Re: ConsolePrompt() prompts in debug window not in console
Generally speaking about these similar kind of issues where you have sticked to "odd" behavior instead of the natural behavior due to compatibility reasons, I would suggest that you would in one of the future Hollywood releases update all these "odd" behaviors to natural ones in one same Hollywood version.
Although this does give some extra maintenance possibly for peoples scripts, it is then at least done in one same Hollywood version, instead of needing to worry every now and then. For example, number 10 had actually been very good place to start this, and then continue every 5 versions fixing all the new oddities away.
For it is also that basically wrong kind of behaviors are actually giving some maintenance too, although for only to new scripts, but when more and more of these start stacking, they will start taxing in development time, especially since nowadays Hollywood has a lots of commands, and often times I am in situation where I know what I want to do, but I don't know the command to do so, and then I go to the manual and start guessing what the commands name could be, so if in this case I would want one that prints to Console, I could be looking for a command named something like this, and even think I found it, and only at point I actually test notice that the command doesn't do what I wanted, and had wasted some time just to find out it doesn't do what I expected, and will be then back to beginning to figure out what command actually does print to Console window.
So while you are saving time in fixing old codes and keeping them working, you at same time are slowing down new development and hindering figuring things out.
Also, make it so that they can choose at beginning of program to keep the old behavior instead of the new one, and this way fixing will be easy, in that they can choose to stick to the old behavior (supposing this is not too much work of course)
Although this does give some extra maintenance possibly for peoples scripts, it is then at least done in one same Hollywood version, instead of needing to worry every now and then. For example, number 10 had actually been very good place to start this, and then continue every 5 versions fixing all the new oddities away.
For it is also that basically wrong kind of behaviors are actually giving some maintenance too, although for only to new scripts, but when more and more of these start stacking, they will start taxing in development time, especially since nowadays Hollywood has a lots of commands, and often times I am in situation where I know what I want to do, but I don't know the command to do so, and then I go to the manual and start guessing what the commands name could be, so if in this case I would want one that prints to Console, I could be looking for a command named something like this, and even think I found it, and only at point I actually test notice that the command doesn't do what I wanted, and had wasted some time just to find out it doesn't do what I expected, and will be then back to beginning to figure out what command actually does print to Console window.
So while you are saving time in fixing old codes and keeping them working, you at same time are slowing down new development and hindering figuring things out.
Also, make it so that they can choose at beginning of program to keep the old behavior instead of the new one, and this way fixing will be easy, in that they can choose to stick to the old behavior (supposing this is not too much work of course)