I2 & Playmaker - Changing Key Names
6 years 11 months ago #2710
by Dakk
I2 & Playmaker - Changing Key Names was created by Dakk
I am new to I2 and am using Playmaker. The major issue I am having is that the Keys have to be typed into the PM actions- if the Key/Term changes it will un-link and will need to be manually typed in again. This is a big problem for a larger project. It's simple to search and replace in code- but (AFAIK) PM does not allow for this- so changing a key/term string in I2 means finding every reference to that term in PM and changing it manually.
Here are the options I can see, but looking for a better one:
1. Live with never changing a Key/Term. This seems ok, except that translators will get this sheet and misleading/old Key names will be confusing. It will also be confusing for me and lead to bugs.
2. Create global string vars for each key in PM. Not practical.
3. Create a dedicated layer of abstraction between I2 and PM- Set up an array of the Keys and access them in PM by index and never change the order. Can change the Key string this way, but order for PM must stay the same (the order for I2 doesn't matter).
Option 3 seems the best, and is what I have implemented, but it is not ideal. I'm new to I2 and feel like I am missing something, and there is a better way to do this.
Thanks,
Here are the options I can see, but looking for a better one:
1. Live with never changing a Key/Term. This seems ok, except that translators will get this sheet and misleading/old Key names will be confusing. It will also be confusing for me and lead to bugs.
2. Create global string vars for each key in PM. Not practical.
3. Create a dedicated layer of abstraction between I2 and PM- Set up an array of the Keys and access them in PM by index and never change the order. Can change the Key string this way, but order for PM must stay the same (the order for I2 doesn't matter).
Option 3 seems the best, and is what I have implemented, but it is not ideal. I'm new to I2 and feel like I am missing something, and there is a better way to do this.
Thanks,
Please Log in or Create an account to join the conversation.
6 years 11 months ago #2711
by Frank
Are you Give I2L 5 stars!
Are you Please lets us know how to improve it!
Replied by Frank on topic I2 & Playmaker - Changing Key Names
Hi,
Managing Keys its always a pain, I2 Localization has tools to help you deal with that, but at the end, the major thing its to do proper planning from the beginning.
Unless your project its entirely dynamic. Most of the localizations are going to be handled not in PM but by adding a Localize component to a label and setting the term in that component.
If you need to change a term's name, there is a tool that allows merging/renaming terms
inter-illusion.com/assets/I2Localization...l/CombiningKeys.html
That tool parses every component in every scene and updates the term/terms to the new name.
As you say, that's not acceptable, terms shouldn't be changed, but your game development should have a flow to handle this in case its really needed.
There is a similar implementation for normal C# code.
inter-illusion.com/assets/I2Localization...riptsforsaverac.html
That creates variables pointing to the terms, that way even if the term changes, the variables are kept. However, that works for normal scripts, there is no implementation for PM.
That could work, but I don't think you really need this. Keys are meant to be treated as Indices.
Originally I thought of having numbers instead of Keys (e.g. Term 32, instead of "MY_TERM_HELLO"), given that the Key is just that, a way to reference the translation in the Localization database.
Adding another index, its just adding a key that references the key that references the translation. Its another layer of abstraction, but doesn't solve the problem, eventually you will want to modify the new indices, and then you will have an index that reference another index that references a key that points to the translation.
In most games, you will only change terms using PM in a handful places, everywhere else, you will be using the normal Localize component.
So, my suggestion for now, its to enforce that translators don't modify the name of the key for those terms. And if you need to modify other terms, use the Rename tool.
Said that, for PM I should be able to extend the Rename tool to also search inside PM nodes and update the keys there. I will add that to my todo list and try having that as soon as possible.
Hope that helps,
Frank
Managing Keys its always a pain, I2 Localization has tools to help you deal with that, but at the end, the major thing its to do proper planning from the beginning.
Unless your project its entirely dynamic. Most of the localizations are going to be handled not in PM but by adding a Localize component to a label and setting the term in that component.
If you need to change a term's name, there is a tool that allows merging/renaming terms
inter-illusion.com/assets/I2Localization...l/CombiningKeys.html
That tool parses every component in every scene and updates the term/terms to the new name.
1. Live with never changing a Key/Term
As you say, that's not acceptable, terms shouldn't be changed, but your game development should have a flow to handle this in case its really needed.
2. Create global string vars for each key in PM. Not practical.
There is a similar implementation for normal C# code.
inter-illusion.com/assets/I2Localization...riptsforsaverac.html
That creates variables pointing to the terms, that way even if the term changes, the variables are kept. However, that works for normal scripts, there is no implementation for PM.
3. Create a dedicated layer of abstraction between I2 and PM- Set up an array of the Keys and access them in PM by index and never change the order.
That could work, but I don't think you really need this. Keys are meant to be treated as Indices.
Originally I thought of having numbers instead of Keys (e.g. Term 32, instead of "MY_TERM_HELLO"), given that the Key is just that, a way to reference the translation in the Localization database.
Adding another index, its just adding a key that references the key that references the translation. Its another layer of abstraction, but doesn't solve the problem, eventually you will want to modify the new indices, and then you will have an index that reference another index that references a key that points to the translation.
In most games, you will only change terms using PM in a handful places, everywhere else, you will be using the normal Localize component.
So, my suggestion for now, its to enforce that translators don't modify the name of the key for those terms. And if you need to modify other terms, use the Rename tool.
Said that, for PM I should be able to extend the Rename tool to also search inside PM nodes and update the keys there. I will add that to my todo list and try having that as soon as possible.
Hope that helps,
Frank
Are you Give I2L 5 stars!
Are you Please lets us know how to improve it!
To get the betas as soon as they are ready,
check this out
Please Log in or Create an account to join the conversation.
6 years 11 months ago #2712
by Dakk
Replied by Dakk on topic I2 & Playmaker - Changing Key Names
Hi Frank,
Thanks for the quick response.
I am using the localize script when applicable and it is easy and works great!
Due to a lot of meta-game, inventory and complicated UI- a lot of elements' keys need to be set as variables in my situation even though they are not actually "dynamic" in the traditional sense. A lot of it is driven by complicated UI elements/buttons being duplicated many times and then a pm script is populating them with unique text- this is mostly just an ease of workflow- I can change a single instance of a complicated layout, and then many instances of the layout get auto-populated- for a shop button for instance, or a common popup that is re-used in many places. If I was super organized and didn't change the design- I could "hard code" each button/element, but as much as I iterate, it would be a daunting amount of work to go through element by element and fix things when the design changes. I suppose nested prefabs with overrides could solve some case, but not all.
My thought with the layer of abstraction from PM index into the I2 Term list- was that this intermediary layer could get a bit "sloppy" (unused or empty indexes etc..) as long as it never re-orders- and there shouldn't be a reason to re-order it as long as I can just append to the end. The downside, is that it is an extra layer to maintain, and an index is less intuitive on the PM side than just using a Key that represents the term to translate.
The search and replace of PM scripts would definitely solve my issue and is probably the cleanest way!
Thanks for the help!
Thanks for the quick response.
I am using the localize script when applicable and it is easy and works great!
Due to a lot of meta-game, inventory and complicated UI- a lot of elements' keys need to be set as variables in my situation even though they are not actually "dynamic" in the traditional sense. A lot of it is driven by complicated UI elements/buttons being duplicated many times and then a pm script is populating them with unique text- this is mostly just an ease of workflow- I can change a single instance of a complicated layout, and then many instances of the layout get auto-populated- for a shop button for instance, or a common popup that is re-used in many places. If I was super organized and didn't change the design- I could "hard code" each button/element, but as much as I iterate, it would be a daunting amount of work to go through element by element and fix things when the design changes. I suppose nested prefabs with overrides could solve some case, but not all.
My thought with the layer of abstraction from PM index into the I2 Term list- was that this intermediary layer could get a bit "sloppy" (unused or empty indexes etc..) as long as it never re-orders- and there shouldn't be a reason to re-order it as long as I can just append to the end. The downside, is that it is an extra layer to maintain, and an index is less intuitive on the PM side than just using a Key that represents the term to translate.
The search and replace of PM scripts would definitely solve my issue and is probably the cleanest way!
Thanks for the help!
Please Log in or Create an account to join the conversation.
Time to create page: 0.188 seconds