NPC dialog source #173
Replies: 8 comments 17 replies
-
|
I can see why this feature would be desired; however, I'm not knowledgeable enough about how localization would work without the keys here. @exectails Would you mind explaining this in depth? Technically, the only issue that I could see using this method is that the packet size would increase due to sending long character strings. We would do well to make sure that they are zipped before being sent. And of course, whatever process that we use to convert keys into strings needs to be robust and maintained (which involves tools not part of Melia). |
Beta Was this translation helpful? Give feedback.
-
|
"Technically, the only issue that I could see using this method is that the packet size would increase due to sending long character strings." I wonder, if we could solve the issue of increased pocked size by rerouting packages containing NPC dialog requests to a local service/database that could be a part of our custom game "patch"? Anyway, I prefer that the dialogs are handled by the server. |
Beta Was this translation helpful? Give feedback.
-
|
About the increased packet size... I haven't gotten ahold yet of how the encoding of the envelopes are being done for ToS, but relatively, some games adapt to "allocate" (request to the buffer) to allocate a full size of the primitive. If it's an Uint8 then a full Uint8, if it's a string, then a full UTF-8 string (if the text encoding is being done with UTF-8)... Basically, it's a similar concept of, for example, the HTTP packet, by using padding. But I believe possibly this is not being done here. |
Beta Was this translation helpful? Give feedback.
-
|
Just let me say that, generally, you shouldn't worry too much about the cost of dialogues being sent to the client. You don't have thousands of players talking to NPCs all day. In the grand scheme of things, the dialog packets are a tiny part of the traffic and processing, even if they're sent in full. I also haven't noticed any issues with the client handling them so far, and it would be kind of ridiculous if it did have a problem with full dialogues. |
Beta Was this translation helpful? Give feedback.
-
Sure. There are various ways you can tackle localization, but my personal favorite is gettext. Here you use keys as well, but instead of something like "SOME_TEXT", which is then turned into "This is some text.", you actually write it out, and that becomes the default for when no translation is available. All strings that are to be localized need to be wrapped in a function call, for example To create a localization database for a project you use a specialized parser that basically runs over all the source code, and searches for these function calls, creating a file out of them that you can then, for example, give to translators. The special thing about gettext is that it supports plurals properly. And not only the 1 plural form we know from English, but even the 6 or so forms of plurals that exist in other languages, so something like "You have X items." can be translated in a proper way. var text = string.Format(LN("You have {0} item.", "You have {0} items.", itemCount), itemCount);Gettext will choose the correct plural form based on the amount and return the string, which is then used in the format to get the final result. Fun fact: Languages like Japanese and Korean actually don't have plurals, which might explain why they usually use 1:1 key-value translation systems, which make it hard to localize certain things, resulting in strings like "You have X item(s)." The one disadvantage to this system is the function wrapper around all strings. if select(L("It would not be strange if the world ended tomorrow.{nl}However, I just want to know. Why the goddesses disappeared.."), L("Ask about the disappearance of the goddesses"), L("Cancel")) ~= 1 then
return
end
if select(L("I'm not sure I understand it completely, but what I'm sure of is that the goddesses didn't disappear all at once."), L("Ask what happened"), L("Cancel")) ~= 1 then
return
end
if select(L("Goddess Vakarine left us shortly before Medzio Diena.{nl}Both Zemyna and Ausrine disappeared soon after.{nl}It's already been four years since."), L("I think you forgot to mention Goddess Laima"), L("Cancel")) ~= 1 then
return
end
msg(L("She has never appeared before.{nl}Although I've read somewhere that she does appear every now and then..."))
It does increase the packet size, but I think it's fine. Players don't spend so much time in dialogues that it would create a bottle neck. Many games don't send keys, but the full dialog. Though we could certainly compress it, provided that the dialog packets support it. I don't see any compression setup though. |
Beta Was this translation helpful? Give feedback.
-
|
I guess there's one more route one could go here, though it would be a little crazy. Technically, you could use actual dialog in the NPCs, which, under normal circumstances, should be equal to the current English localization, and then do a reverse lookup for the dictionary key, which you then send to the client. That way you can see the dialog, but still choose the translation on the client side. Though this option would be more work and could break just as easily as using the first option. |
Beta Was this translation helpful? Give feedback.
-
|
My opinion in this matter would be the following: We should adhere to the ICU Message Format and create a simple i18n Localization Library. What does this mean?
The structure of a JSON file:{
"language": {
"code": "en_US",
"name": "English (United States)",
"revision": "1.0.01",
},
"translations": {
"TUTO_GIRL_basic_02": "You have {itemCount, plural, =0 {no items.} =1 {one item.} other {# items.}}",
...
}
}
How we decide which Language to set.The translation system is bounded to the Session of the User. We load all existing When the User initialises a Session the Client will send which Language the user set his Locale to be (Eg.: French, English, etcetera). And basically, we maintain that information (The Language Code) set in a way that it's easy to access. How it would work in practice?msg(T("TUTO_GIRL_basic_02", UserSession.CurrentLocale, { itemCount }));The
Observation: When the User Logs in and sends a Language Code that doesn't exist in the Cache we also set the Which Libraries would be used?I found two libraries that might be interesting for us: But might need to be extended or to have modifications. As far as I remember, .NET natively supports ICU and Localization... We might also want to give a peek in these solutions. |
Beta Was this translation helpful? Give feedback.
-
|
Oh, and another note about custom messages... those can be broken as well. There's something we need for those to work properly, and if IMC were to remove that, we'd need client modifications to get them working again. |
Beta Was this translation helpful? Give feedback.
-
Yup, I noticed that. I meant to say that it would allow us to understand what all the messages are, without the need to look into the Client source.
This is also true. This is yet another reason whereas any Quest and/or NPC dialogue that is part of the Story/Creative material of Tree of Savior should be done as Third-Party. (As I mentioned before that we should not include any Quest by default in Melia). Those Quests could be an additional package stored somewhere else (Mediafire, or whatever as a SQL script). For Non-Quest NPC's such as Market or important Character NPCs, we could just create our own versions of the Dialogue. (Personal note: I don't want to create yet another Tree of Savior, here we have the advantage of doing things in our way). |
Beta Was this translation helpful? Give feedback.
-
Didn't consider that. That could also be problematic. I can't imagine IMC removing the feature of allowing the server to send messages... |
Beta Was this translation helpful? Give feedback.
-
It's not the feature itself I'm worried about, but a certain something within it, that IMC doesn't use anymore. I'm kind of paranoid about mentioning it, thinking they might go and remove it right away xD
I would agree, we shouldn't include official quests in the main repo, at least not if we decide to store the texts in the server. Though we could create entire custom quest lines for fun if we wanted to.
I understand the sentiment, the question is where it leads. A server emulator has a specific job, emulating official features. Not necessarily the content, but the features that would be necessary to implement the content. I would argue that the "default settings" for Melia should be in line with how the official server operates, but that we provide users with ways to customize the behavior. I don't think that an emulator should do a lot of custom stuff by default. |
Beta Was this translation helpful? Give feedback.
-
I feel you 😅
Indeed. 😋
I completely agree. Let me rephrase. We should definitely provide the features that'd make our users Champions 😄 but I don't think we need to provide the content for it.
Definitely. Item Drops, EXP ratio, yes. And we could provide also tweaked custom settings. Inside the examples folder 🤔 |
Beta Was this translation helpful? Give feedback.
-
|
If we're not going to include official content in the core repo, maybe we should think about whether we even want to include all those dummy NPCs we generated. Right now, it's difficult to even find an NPC that does something, because the few there are, are mixed in with all the dummies that exist for fields, cities, and dungeons. I find this kind of annoying every time I go in there. Having these dummies stand around the world makes it feel less empty, but if we want users to set up their own content, NPCs, quests, etc, then including the dummies, or official NPCs once they're implemented, in the core would just mean that they would have to get disabled before you can do anything. They also take up space. I once searched for a nice place for a custom NPC in Klaipeda, and those dummies were just everywhere. Does it make sense to have them? Or maybe they should at least be easy to disable? Or to enable? Like a script list with dummy NPCs, that you uncomment if you want to? |
Beta Was this translation helpful? Give feedback.
-
|
IMHO, everything that isn't static, should be a script. Items, NPCs, Skills, etc. Users should be able to manipulate certain things, even if the source code is lost and the authors are dead. L2 uses scripts for all of the dynamic content.
|
Beta Was this translation helpful? Give feedback.
-
|
I agree, scripts are important, and at least all the content should be scripted if possible Though that's not the exact topic of this discussion^^ |
Beta Was this translation helpful? Give feedback.
-
|
I suppose #184 will cover this discussion xD |
Beta Was this translation helpful? Give feedback.
-
|
I believe what exactly should be scripted is a separate discussion. While Lua vs C# is related, because C# would make it easier to script more, technically we can do absolutely anything from Lua as well. |
Beta Was this translation helpful? Give feedback.
-
|
News about the client telling the server about the selected language: apparently they did add packets for that, and @SalmanTKhan implemented them without telling anyone about it! D=< The "new" packets are
That means, aside from it being slightly more complicated, we could absolutely send dialog in the language selected by the player. |
Beta Was this translation helpful? Give feedback.
-
|
I just remembered one minor problem with using custom dialogues, NPC portraits don't work with them. I don't know if anyone would see those as vital, but it is kind of unfortunate. These are tied to the dialog elements that you would otherwise use, like |
Beta Was this translation helpful? Give feedback.
-
|
Actually, that's not entirely correct. There is a way to set the portrait, but that one is tied to the name. So if you want to see Dunkel's portrait for example, the name field during the dialog will always read "Equipment Merchant Dunkel". You can only control the name below the NPC in that case. Although that could potentially be fixed with a minor change in the client's Lua files... |
Beta Was this translation helpful? Give feedback.
-
I just realized we're not bound by this limitation anymore... We are free *__* |
Beta Was this translation helpful? Give feedback.
-
|
Over the past couple of months it's become more and more apparent to me that most people who're interested in Melia don't care very much about the official content, including the NPCs and quests. As such, it seems unlikely that we'll ever copy a lot of official complex and dialog heavy NPCs, where it might make sense to use the client-side localization system. And as I have mentioned previously, we should really stick to one system for consistency. That's why we're going to go with server-side dialog by default while keeping support for dialog keys for those who want to use them. |
Beta Was this translation helpful? Give feedback.
-
Our NPC's dialog code currently looks something like this:
We take advantage of the fact that the client has the dialogues for all NPCs, and just send localization keys. This has the advantage that it's pretty easy to create NPCs from logs, and we don't have to worry about localization, as long as there is an official translation for your language.
However, we also put ourselves at the mercy of the client. Any string can change at any time, just like their keys, and the script we wrote might not make any sense anymore after a few updates. That wouldn't be a problem if we sent the actual text, without relying on the client. It would also allow users to actually figure out what's going on in a script, instead of just guessing, based on structure and keys.
Typing all this out is certainly more work though, even if a Pale plugin could help with that, and I don't know if anyone will actually care about the dialog. It should be said though that writing the script would also be easier with actual text.
I thought I'd create a discussion for it, because I'm not sure which is better, and we should definitely stick to one.
Beta Was this translation helpful? Give feedback.
All reactions