Hello. I’m still banging my head against sound tags.
This is my current dilemma, if someone is kind enough to offer some insight:
I’m trying to incorporate a sound tag into a RealTimeDaemon. When the RealTimeDaemon triggers, it prints an additional blank line. I know this is happening because the sound tag is in double quotes, so it’s printing the sound tag. Removing the sound tag and its respective quotes removes the issue.
Here is what I’m working with once the event is called, for reference.
So, is there is a way to implement sound tags without the tag being sandwiched between double quotes? How would you go about implementing sound tags into a RealTimeDaemon? The issue is not present on regular, turn-based Daemons or Fuses.
I was seeing things wrong when I suggested making the object a RealTimeEvent. Sorry, I was just whizzing by at the time. The object containing the method to be called doesn’t have to be any special class.
There doesn’t appear to be anything out of order in your code, and just by eliminating the ambience_Creaking_Wood object from the code, the sound worked fine in my test project. Is the boolean getting set to or left at true when you try to test this invocation? If the isPlaying value definitely starts off false, your code should work (removing RealTimeEvent from the class list), as it did for me.
And this is assuming that the string representing the sound file matches spelling exactly and the file is located where the program can find it…
I primarily use sound tags within double quote strings, but I’ve also used them in single quote strings with extraReport and tadsSay.
Or any chance you’ve tampered with the realtime event manager?
Sorry, I left out the ambience_Creaking_Wood object. But yes, the boolean is set to false. The sound plays as it should, there’s just additional spacing for some reason. The daemon cuts off whatever is being typed and skips to a new line as the event triggers.
I haven’t tampered with the realTimeManager, but I’m sure there must something wonky in my code somewhere as I’m not able to reproduce the issue on a new project. I’m not sure what could possibly be causing it, so I’ve got a lot to sift through.
Do you mean unexpected time delay? Or like extra blank text lines? If the latter, that might not be too surprising because of how realtime events normally behave (the interrupted and reappearing command line). That behavior can probably be suspended, but it might take some considerable modifications to the realtime event manager… I’m curious about it now, although I may not find time to hunt down the answer.
Yeah, this is the basic expected behavior. I assume it’s because the typical realtime event would print text. I think you could override this for a realtime event that only controls sounds, but it might involve some tweaking at a pretty low layer…
If you have any aspirations of altering the realtime behavior (not reprinting the command line if the realtime event is only firing a sound tag), I’d take a look at the methods of the inputManager object in input.t.
At the very least, you could check out the getInputLineExt method, at the point where you have case InEvtTimeout: the code sends a command-interrupt signal to the output manager which will be part of the process whereby realtime events cause a second command line to be printed.
Conceivably you could create a subclass of realtime events (or perhaps a subclassed instance of the realtime event manager, I’m not sure) that don’t call for this interrupt-and-reprompt sequence.
Just spitballing here as I haven’t used adv3 or htmltads, but it seems odd you would have to print text to trigger a sound event? Could you perhaps print the event to a hidden banner window or something?
Well, you don’t have to print text, but as far as I know you can only execute sound through outputting a string (some kind of say function) that processes the HTML tag in it, even if the rest of the string is blank. It’s been a long time since I was tinkering with it, but my memory is telling me that trying to print sounds to banner windows didn’t work… or at least sufficiently obtuse that I abandoned the attempt.
Not sure if you’re pursuing the idea of playing sounds on a realtime basis without reprinting the command line. A couple of things come to mind:
If you’re not using realtime for anything other than kicking off sounds:
It might work to modify the inputManager.processRealTimeEvents method to call realTimeManager.executeEvents but then to return nil instead of timeout.
If you want to preserve normal printed realtime event behavior but add the option to suppress it for sound-only output:
You might be able to subclass the realTimeManager, and potentially subclass realtime events as well to subscribe to this new manager instead of the old one. In inputManager.processRealTimeEvents, you may be able to simply make a call to myRealTimeManager.executeEvents directly after the call to the old one, and not track any timeout info in relation to the second manager.
I don’t know if that will work or not, but I couldn’t help looking at the library source a little longer…
I haven’t had an extended chance to sit down and fight with my code yet, but I am absolutely pursuing the idea. You’ve given me lots to work with, and I really appreciate it! Hopefully when I have the time, I can sit down and try to figure something out with this great info.
From what I have done so far, I can confirm that banners don’t work. I’ve fought a little bit with InEvtTimeout to no avail. But browsing tadsio.h has helped and I’m getting more familiar with how real time events are processed.
I do not aim to use real time for anything other than kicking off sounds. I attempted to modify the inputManager.processRealTimeEvents method as you suggest, and while returning nil instead of timeout suppresses the printing behavior, it also no longer reads the sound, and nothing plays.
