ID:138267
 
If I try to do something like this:

usr << "3...\..."
sleep(10)
usr << "2...\..."
sleep(10)
usr << "1!

Instead of printing: "3...(wait a second)2...(wait a second)1!" it simply waits two seconds then prints the whole thing out at once. Which is not what I want to do! Bug or feature?

Z
On 12/8/00 9:14 pm Zilal wrote:
If I try to do something like this:

usr << "3...\..."
sleep(10)
usr << "2...\..."
sleep(10)
usr << "1!

Instead of printing: "3...(wait a second)2...(wait a second)1!" it simply waits two seconds then prints the whole thing out at once. Which is not what I want to do! Bug or feature?

Z

Not the intended use of this macro, would be my guess. BYOND is waiting for a carriage return before it outputs the line, and the macro was probably not intended to be used over several ticks (and given that anything in the game could output text and screw up what you are doing, it's not clear to me that BYOND should try to support this...)
In response to Deadron
Instead of printing: "3...(wait a second)2...(wait a second)1!" it simply waits two seconds then prints the whole thing out at once. Which is not what I want to do! Bug or feature?

Not the intended use of this macro, would be my guess. BYOND is waiting for a carriage return before it outputs the line, and the macro was probably not intended to be used over several ticks (and given that anything in the game could output text and screw up what you are doing, it's not clear to me that BYOND should try to support this...)

Yup. Guy T. was just discussing that it wouldn't output any text until it finished the loop and displayed a carriage return. I'm inclined to agree with you, Deadron, that this function should indeed work this way.

There's no real workaround, though. If Dantom wanted, they could probably add in support for a second \... macro (like \nobr) that would allow you to do this, but if someone's text were interrupted, it'd be your fault! =)

If you absolutely must have it do this, you could display it in a stat panel. But no one likes stat panels anymore, for some reason. And I've blessed you all with meters, even! Of any length and level of detail! Sigh. =)
I see! Well, I'd love a feature that could do this, even if it ended up making it so that, you know, pages from Spuzzum could end up right in the middle of whatever I was trying to output.

Maybe there could be some proc that would output text on a line over time without interruptions.

world << timedtext(0;"3...",8;"2...",8;"1!")

would write: "3...(sleep 8)2...(sleep 8)1!"

Obviously this isn't going to have too many uses, and what uses it will have will be mostly aesthetic. But the fact that there's apparently no way to hack this sort of thing makes me want to give it some consideration.

Z

Guy T ran into this recently too. I am thinking about forcing it to send the incomplete line at least by the end of the server tick (every 0.1s), which should suit your purposes. Just don't expect html tags that extend across the end of your partial output to work:)

--Dan
In response to Dan
On 12/9/00 10:17 pm Dan wrote:
Guy T ran into this recently too. I am thinking about forcing it to send the incomplete line at least by the end of the server tick (every 0.1s), which should suit your purposes. Just don't expect html tags that extend across the end of your partial output to work:)

Oh, goodie. If nothing else we could try it and if it causes too many problems, we could get rid of it.

Who am I talking about, "we"?

Z
In response to Dan
On 12/9/00 10:17 pm Dan wrote:
I am thinking about forcing it to send the incomplete line at least by the end of the server tick (every 0.1s), which should suit your purposes.

And you did! And ending a "say" verb with the \... macro wreaked havoc. Which isn't a terrble problem, I mean, I could make it so saying something with the \... macro wouldn't be allowed. But I don't know if it's worth it. I only requested the change for aesthetics purposes anyway... it wasn't going to have any effect on gameplay. I think we could survive with the \... macro in its former state until other people start requesting a change too (if they do).

Z
In response to Zilal
I think we could survive with the \... macro in its former state until other people start requesting a change too (if they do).

Well, considering I already did request this, I have to ask... what sort of havoc was wrought? :)
On 12/8/00 9:14 pm Zilal wrote:
If I try to do something like this:

usr << "3...\..."
sleep(10)
usr << "2...\..."
sleep(10)
usr << "1!

I was trying to do something similar.

In my case, I was trying to do lines of text which I wanted to continue from the previous line in my Look() process. It was something like:

usr << "Room Description"
msg = CalculateExits()
usr << msg
msg = CalculateSeenMobs()
usr << msg
msg = CalculateSeenObjects()
usr << msg

It was putting everything on seperate lines instead of using the nonbreak characters. What I ended up doing was using the addtext() process to combine everything into a single line of text, then sending it to the user. Not quite the same for what you were doing, but it was the only thing I could get to work -g-.

- -
Instead of printing: "3...(wait a second)2...(wait a second)1!" it simply waits two seconds then prints the whole thing out at once. Which is not what I want to do! Bug or feature?

Speaking of which, which is definitely a bug, if you leave an unterminated command like:

say \"<a href=

or

say \"<xmp>

it suppresses the carriage return. It's a viable workaround, granted, but it's also a bug.
Well if this is EXACTLY how you have the code it might be because there is no quotation mark after the 1! in this line...> usr << "1!
Just a guess


On 12/8/00 9:14 pm Zilal wrote:
If I try to do something like this:

usr << "3...\..."
sleep(10)
usr << "2...\..."
sleep(10)
usr << "1!

Instead of printing: "3...(wait a second)2...(wait a second)1!" it simply waits two seconds then prints the whole thing out at once. Which is not what I want to do! Bug or feature?

Z