Strangepete/Sandbox – User talk
Stringtable.xml
I'm assuming that a multiplayer mission using a mod with an included stringtable will localize the language appropriately for each player?
i.e. If Player1 sets her language to German and Player2 sets his to French, then a task dialog shown to a team they are both in, formatted using the stringtables of each player, will show each player the dialog in their set language?
If this is the case, perhaps a note about it, or would that be commonly understood?
I'm a noob. :-) -- Fred Gandt (talk/contribs) 00:40, 3 April 2014 (CEST)
My feeling is that it would be commonly understood...but on second thought, many things in this game are not transparent nor consistent, so it wouldn't hurt to reiterate this, and it would help a couple situations imo:
- its possible a scripter could assume a common stringtable language is set by server, not client.
- a reminder to scripters to not forget and try to use the results from variables set by stringtables on each client in expressions or other comparisons. save on headache time.
ill add a little note and try to keep it short and clear (2 things im terrible at)...at the top of 'usage'? or should it get its own header just below...maybe ill go its own with the hopes that it'll leave room for some neat or clever MP stringtable script example (anybody got tricks up their sleeve?). thanks for the input --Strangepete (talk) 16:02, 3 April 2014 (CEST)
- That second point is definitely worth a mention IMO.
- So if a scripted vehicle known to all clients issued a hint, it would do that just once, and the stringtable lookup would happen appropriately on each client, or would the vehicle's script run once on each client using the stringtables in each? I still have a lot to learn about this platform, and where and when things happen (i.e. what code runs on what machine) is an understanding that still eludes me. I have a feeling I read that local scripts can be forced to act as if global insofar that every client is informed of the change; in that case (if it exists), would the language localisation of the machine the script ran on be broadcast to all clients, or would each client be told to run the code for themselves (even though the scripted thing isn't local to them)?
- In other words: I am a noob and I don't really understand the platform yet - that's why I am reading this documentation. Although established developers may commonly understand how it all works, they're not the ones who need to read this - noobs like me are :-)
- Perhaps if the explanation of what code runs on which machine already exists in a useful format on this wiki, a short note linking to that might be enough?
- As for where on the page any explanation should be; I'd say a header within Usage like:
Usage
Scripts
This _foo != _bar; But not if global thing.
- Then use that header as the qualifier of any following examples illustrating the explanation. -- Fred Gandt (talk/contribs) 17:43, 3 April 2014 (CEST)
What you said, is the root difficulty: to come up with a clear or concise explaination, because it depends greatly on the where and how. a MP scripter has to have a deep understanding of what their code is passing when and how...which is why there is relatively little documentation in that realm - the general attitude is that you are expected to have a certain amount of experience under your belt before expecting to understand what is happening.
its a sorta catch-22, when you don't know what you need to know to learn what you want to know :D seems the best solution for that aspect is to just try and ensure all articles are properly crosslinked to related pages & concepts, reducing the need to hunt for info.
the stringtable is loaded by the preprocessor before the mission starts, the variables are set once locally. in places where they are hard-defined (configs, description.ext, mission.sqm(? still unfamiliar)) they are substituted in; localize just returns the same strings at but at runtime. scripts are not global so much as the commands, functions and public variables they set or use; some commands have global arguments and/or effects.
i think the main place you'd see issues with this is server-side scripts where global commands and public variables are used often.
my personal learning style is by example, so -i- would benefit from just source-code for 'Best Coding Practices/Common Pitfalls', showing how, where and why you'll screw up - but i can imagine that would not be helpful for many newbies, catch-22-style, again.
i'm not sure what the balance is between explaining in depth vs. prerequisite learning vs. document length. --Strangepete (talk) 01:51, 4 April 2014 (CEST)