The Math/String option "strlen" which returns the length of a string in a value of its character count. The feature I suggest is the addition of strlen being able to retrieve strings from the LANGUAGE lump, making it look like this:
LANG_STRING is a string defined in the LANGUAGE lump that has a 28 character count. As such, since strlen is now aware that it has to retrieve from the LANGUAGE lump, it takes the string and returns the value properly, which is 28.
This is also a handy feature when you wish to have your game's script support multiple languages, but still be synched with the Delay(HudMessageTime).
For example, your LANGUAGE text could look like this:
@Edward850:
What I meant by that previous script is that the time the player would become unfrozen would adapt depending on the language that is used. Perhaps I should create a more advanced example of the strlen addition to better show my point.
In this LANGUAGE lump, you'll see two, more extensive strings:
[enu default]
INTERCOM1 = "I need help right this instant!";
INTERCOM2 = "Get over here now!";
[esn]
INTERCOM1 = "Necesito ayuda ahora!";
INTERCOM2 = "Ven aquí ahora mismo!";
You'll notice that there are larger differences in characters between the messages.
The script below is a type-on HudMessage using the LANGUAGE strings.
In this new script, a message from an intercom is typed-on the screen, followed by a delay that takes into account the difference in characters for the typed-on message, then a new message is typed-on and the delay is kicked in again, followed by a nearby lift lowering. As such the two delays "adapt" to the difference in characters for each string. This is the desired effect I want. The script's use of strlen is "adapting" to the two different LANGUAGE strings.
Okay, I see where I failed to explain. Let me try to explain what I mean.
When I say adapt, I mean the script adjusts to the new string based on the selected language. Let's use the previous LANGUAGE examples I provided.
[enu]
INTERCOM1 = "I need help right this instant!"; would have a strlen value of 31.
INTERCOM2 = "Get over here now!"; would have a strlen value of 18.
[esn]
INTERCOM1 = "Necesito ayuda ahora!"; would have a strlen value of 21.
INTERCOM2 = "Ven aquí ahora mismo!"; would also have a strlen value of 21.
Now when placed in the scripts, the delay would be different due to the different values of the strlen based on the selected language.
If English is selected, the script would look like this:
Due the the different return values of strlen based on the selected language the script adapts/adjusts/accommodates/alters/etc. to support the change in character count that derives from the differences in languages. Did I clear up the misunderstanding or should I try to approach this from a new angle?
You can't do this, as I explained before. Delays (or anything, really) should never be altered by external values outside of the playsim, especially if you are then calling a level altering event after it. As you cannot guarantee that the session will do the same thing in a different language, it won't work this way.
Take note: Floor_LowerByValue will be called at different times in different languages. You aren't thinking with portals with synchronization.
...
You do know that the user language isn't part of the playsim, right?
I suppose I should be honest. I have mostly been using the examples here to provide multiple language support, but this is really a secondary reason for my suggestion of this addition. The main reason I wish for strlen to be able to retrieve from LANGUAGES is so I can have hundreds of messages stored in that lump and not as variables within a level script. As such, it does tie in with the visual novel mod I teased on here the other day.
In the video I teased, I have all of the dialogue lines stored within the map script, each as their own variable. So, what I have are 40 lines of variables that have a line of dialogue attached to it. (In my new map that has not been shown, I already have 100 lines of dialogue.) I felt this method was archaic and unorganized, but WildWeasel suggested I use LANGUAGE, which works out conveniently, so much more so. However, during the process of a dialogue script, you'll see this:
SetFont("BIGFONT");
HudMessage(l:MUKULINE3; HUDMSG_TYPEON, 10, CR_WHITE, 10.1, 205.1, 0.5, 0.02, 0); //Lets the text type-on the screen, character by character.
Delay(HudMessageTime(HUDMSG_TYPEON, strlen(MUKULINE3), 0.02, 0.5, 0)); // Waits for each letter to be "typed"
HudMessage(l:MUKULINE3; HUDMSG_PLAIN, 10, CR_WHITE, 10.1, 205.1, 0); //Creates a plain message that becomes permanent and replaces the typed-on one.
// This code continues for each line of dialogue, adding up to hundreds or thousands of lines of code
// My teaser video contains 1051 lines of code for only two short conversations
However, the portion of the HudMessageTime that calls for strlen is unable to retrieve from LANGUAGES, forcing me to count individual characters in each line of dialogue (Which currently is at 100, but will easily triple soon enough). I hoped that an addition to strlen would alleviate my problem of having to count each character for every string and input it in place of the strlen. (Even using Word programs for word count, it takes a long time.)
While this may seem selfish, I still believe that allowing strlen to retrieve from LANGUAGES would be a great addition to ZDoom, especially since strlen is tied so closely to Print and HudMessage, which can make use of LANGUAGE retrieval. If another coder where to rely on LANGUAGE for their HudMessages (Especially if the strings are in great numbers like my situation), they would appreciate the ability to use strlen alongside their LANGUAGE scripts. It still is good to have support for multiple language mods, too, and though we have not fully seen one utilized, I am sure at one point that someone will require strlen with their LANGUAGE strings at one point.
I apologize if I was being round-about in my explanations and I should have owned up to the main reason I wanted it in the first place. It was also a folly on my part to induce a level altering event that's dependent on strlen on a look back. No coder in their right mind would do that and I was .
I have to say, I'd use this quite often myself if given the chance. I like the idea of being able to store long strings in LANGUAGE and snag their lengths for easier delay setting, but of course the multiplayer syncing issue is a problem.
As an alternative, what about always retrieving the length of the default language's string? It may not be perfect, but preferable given the circumstances, since otherwise his options boil down to "don't use LANGUAGE," which would be unfortunate given the mass amount of dialogue present in his mod.
(Note that I'm backing this up because I'd find a helluva lot of use out of it myself, if a certain future project is ever to be started).
Well, for the current moment, I've been manually documenting the character length for each string, then just replacing strlen with that number. It's a time consuming method, but it does offer the results I'm looking for. I believe that is what you meant, Xaser. I am hoping for this addition so I would no longer have to do the manual counting and I could rely on the simplicity of strlen.
With that said, I would close this, but Xaser brings up an interesting point that we could probably use a way to ensure the default string is retrieved if used for calculating timing.
Okay, well, I feel really embarrassed... I was able to achieve the effect I wanted by combining both strlen and strparam, thanks to Blzut3's mention of it. Basically, by doing "strlen(strparam(l:"MUKULINE3"))" I essentially get the "strlen(l:"MUKULINE3")" I suggested.
So, at this point, I am unsure of the fate of my suggestion, if it is even still necessary at all. However, if you all manage to find a use for this proposed feature or some branch of it, then by all means please carry on with this. I will continue to keep an eye on the activities here, though.
I thank everyone for their words and advice, the community here has been incredibly helpful to me.
I'd say the advice should be nhot to use string length and message duration for ANY playsim related event. But implementing measures to enforce it will probably cause more problems than it solves.
As for the suggestion, no. It'd require changes to the ACC compiler and wouldn't provide anything that can't already be done with some existing features.
Hmm, strlen(strparam(l:"...")) indeed seems to work but wouldn't that still cause sync issues in multiplayer?
Although this is a separate feature suggestion at this point (such that I"ll probably open my own thread here soon), a new cast type for "string from default language" to be used alongside strparam would do it. Seems like less of a pain to implement as well, but I'm saying this blindly of course.
It would cause sync issues if you use the value for gameplay timing. But what to do? The clear advice here is: Don't do that! You can do anything you like with the string length as long as it's only being used for positioning text or other HUD related things.
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.
The only problems arise when you use the length in delays or use it for some gameplay related effect. If all you use it for is to calculate text output coordinates I don't see any sync issues.
