User talk:Strangepete/Sandbox

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)

---

Eeep! I had a feeling it would be complex. And yes, that whole "WTF!?" thing when starting to learn a new platform/language is a real problem (like trying to look up how to spell a word you don't know how to spell!), and as you say - interlinking helps a lot (which is why I'm tidying up examples and bulking out "see also"s as I read). So I guess a less-is-more approach with links to further reading would save confusing the hell into people wanting simply to "make it work". A couple of examples of what definitely fails and a couple of what definitely works, then let the enthusiastic learners figure it out for themselves.

I've seen this problem before on a platform called "Second Life" which encourages creation of objects which can be scripted. For many (including myself), learning the scripting language (LSL) is/was their first experience of any kind of coding, and the bulk of the documentation available was written by experts. Their examples and descriptions were often so technical that only experts could be expected to understand them, rendering the documentation a little less than useful for noobs.

Although I have learned a number of languages since and am confident to tackle any new platform, I remember clearly what it was like trying to understand why the code I'd written didn't work as expected, only to find out that there was an undocumented bug, or it had been discussed for years on an issue tracker but no one had bothered to mention that in the wiki >.O

As such, I have grown to appreciate concise but full disclosure in documentation with as little jargon and expectation as possible. And also (like you) appreciate greatly high quality examples detailing best practice, clean, elegant code; not necessarily the cleverest hacks - just honest reliable workhorse stuff that gets the job done.

And at the end of the day, it's a wiki and can and most likely will be updated as time goes on. It doesn't have to be perfect/finished before publishing. I'm currently at the stage where I have probably spent more time reading this wiki than I have playing Arma, so am not much use (yet), but I'm working on it.

Anyhow, it looks really good so far, and as a reader I thank you for making the effort to write it up :-) -- Fred Gandt (talk/contribs) 03:28, 4 April 2014 (CEST)

Wikilinked syntax-highlighting

You might be interested to see the Second Life wiki (randomly chosen function) which has wikilinked and syntax-highlit code examples. Drop Strife Onizuka a message there (He pretty much runs the show) if you want to know how it's done. If you need but haven't got an account, and you do want to chat with him, let me know and we'll find a way to get you two talking.  -- Fred Gandt (talk/contribs) 23:59, 6 April 2014 (CEST)