by Xaser » Thu Oct 03, 2013 1:55 pm
That still leaves a rather large hole in a potential dialogue system I'm planning on writing, myself. The plan is to be able to write a generic dialogue library that takes a string as input (preferably from LANGUAGE since that's where these things tend to live), displays a nicely formatted dialog box, and returns a delay value that could then immediately be used inside Delay() (if desired) as a means to abstract away a lot of the timing pain that usually comes with these sorts of things. I can't think of any way to do this with LANGUAGE strings (without murderating multiplayer sync, of course) without some sort of mapping on the ACS side between strings and numeric delays, which of course defeats the purpose.
[Granted, I might extend the system to support voice eventually, at which point the text length would be moot since the time to play the audio would be the metric at hand. And that certainly isn't measurable in-engine (unless someone's willing to add
that, which of course seems less likely). An irrelevance to the suggestion, but a related one.]
This is probably pretty much the same thing the OP is doing, so I'm basically repeating things. To ask a different question to Graf, independent of the LANGUAGE scenario: Is it considered not sync-safe to do the same thing with a dynamic string that's guaranteed to be in-sync between players (e.g. level name as
strlen(strparam(n:PRINTNAME_LEVELNAME)))? I'm not seeing the harm in this case unless there's something going on behind-the-scenes that I don't know about. Which is of course totally plausible.
Either way, it'd be super-great to not have to manually type in a number somewhere. I can imagine the user unfriendliness that would occur if someone else wanted to add lines of dialogue and extend my system.
That still leaves a rather large hole in a potential dialogue system I'm planning on writing, myself. The plan is to be able to write a generic dialogue library that takes a string as input (preferably from LANGUAGE since that's where these things tend to live), displays a nicely formatted dialog box, and returns a delay value that could then immediately be used inside Delay() (if desired) as a means to abstract away a lot of the timing pain that usually comes with these sorts of things. I can't think of any way to do this with LANGUAGE strings (without murderating multiplayer sync, of course) without some sort of mapping on the ACS side between strings and numeric delays, which of course defeats the purpose. :P
[Granted, I might extend the system to support voice eventually, at which point the text length would be moot since the time to play the audio would be the metric at hand. And that certainly isn't measurable in-engine (unless someone's willing to add [i]that[/i], which of course seems less likely). An irrelevance to the suggestion, but a related one.]
This is probably pretty much the same thing the OP is doing, so I'm basically repeating things. To ask a different question to Graf, independent of the LANGUAGE scenario: Is it considered not sync-safe to do the same thing with a dynamic string that's guaranteed to be in-sync between players (e.g. level name as [b]strlen(strparam(n:PRINTNAME_LEVELNAME))[/b])? I'm not seeing the harm in this case unless there's something going on behind-the-scenes that I don't know about. Which is of course totally plausible.
Either way, it'd be super-great to not have to manually type in a number somewhere. I can imagine the user unfriendliness that would occur if someone else wanted to add lines of dialogue and extend my system. :(