I should also note that by parsing to and from a CSV you can pass/return arrays to/from Functions in triggers, which is normally not possible. You simply return a CSV string representation of the array data you want to return, and then parse it in the returning function to the appropriate array variable. You can also do this to pass/return a struct Record in a standard CSV format you decide on, and then parse that CSV as well into the appropriate Record variable.
If anyone thinks examples for this would be useful, just let me know and I'll whip one together.
I've cleaned up the library a bit more, and fixed several bugs with it (my example didn't even work properly, which is what I deserve for writing all the Galaxy script without testing any of it last night).
Now it works properly, and as I would expect it to. A few parameters have been renamed to make it easier to understand what they are, and a new data table entry was added for the end index of the loop, though if you use many CSV_Parse Actions in a row, and have all of their zeroIndexWhenFinished parameters set to false, then the end index will automatically keep growing for the number of items parsed each time.
Little note to remember though is that the limit parameter on this Action is the limit for the number of items parsed; if fewer than that limit exist it will only iterated and increment the CSV_Index by the number of actual items parsed. To get around this, if desired, users can manually call the CSV_ResetIndex action and set the value to whatever they need it to be after the loop is finished.
Yeah, User Types are much better for this sort of thing since it won't take up variable space memory in your Triggers, but it at least makes the Triggers that you use that do this take up less space overall eventually by reducing the total number of Actions in the compiled Galaxy script. Some people are also scared of the Data Editor and prefer working in Triggers (I even used to be one of them even lol).
This could also be combined with User Types as well, as in you can store strings within User Types and parse those directly for otherwise complex User Type setups, or say for parsing a User Type into a Struct... I mean Record 😛) I should probably add the bit about the User Types, but I've already seen a few thorough looking tutorials on them.
I've written a little standalone CSV String parsing library in Galaxy, and I'm posting it here in-case anyone else finds it useful. To those who that already sounds useful, you can skip ahead below to the download and check it out. I think it should be useful if you're programming with Triggers or Galaxy code (though it's mainly designed for Triggers, and is much more efficient in terms of Trigger usage than normal Trigger loops by using no Auto-Generated variables, and only few overwritten local Data Tables values).
What is a CSV you ask, and why do I need to use them in SC2 Map Making? Well if you're asking that question, then chances are you don't need to use CSVs (an acronym for Comma Separated Value), however maybe you still do or what to just learn and improve your skills. For us map makers who make complex sets of triggers, that utilize tons of different variables that all need to be initialized to specific values (and thus might not be easily loop-able), it can be incredibly useful to be able to say have a string: "0,12,42,4,5,9043,text" and use that to populate an array of variables with those values.
Now it might be trivial and easy to do so in that example, and many others, but rewriting the same, or very similar code repeatedly can become very tedious and gets more error prone as you repeat the code. This library eliminates those issues by giving an easy set of Actions and Functions to parse a CSV string, these Actions and Functions are designed to work nearly identical to the standard Blizzard loops, such as Pick Each loops, however underlying this library is implemented in a much more memory efficient way that is also Thread Safe between Triggers.
Note: Currently the Parser doesn't support anything more complex than a basic CSV, nor can the loop be nested within itself as it will overwrite its own data table entries (though I might add functionality for nested loops in the future, as it shouldn't be difficult to do so with an added parameter to the Loop Actions).
Feedback, comments, bug reports, usage, all greatly appreciated! 😎
0
I should also note that by parsing to and from a CSV you can pass/return arrays to/from Functions in triggers, which is normally not possible. You simply return a CSV string representation of the array data you want to return, and then parse it in the returning function to the appropriate array variable. You can also do this to pass/return a
structRecord in a standard CSV format you decide on, and then parse that CSV as well into the appropriate Record variable.If anyone thinks examples for this would be useful, just let me know and I'll whip one together.
0
Update v1.1 is already out now!
I've cleaned up the library a bit more, and fixed several bugs with it (my example didn't even work properly, which is what I deserve for writing all the Galaxy script without testing any of it last night).
Now it works properly, and as I would expect it to. A few parameters have been renamed to make it easier to understand what they are, and a new data table entry was added for the end index of the loop, though if you use many CSV_Parse Actions in a row, and have all of their zeroIndexWhenFinished parameters set to false, then the end index will automatically keep growing for the number of items parsed each time.
Little note to remember though is that the limit parameter on this Action is the limit for the number of items parsed; if fewer than that limit exist it will only iterated and increment the CSV_Index by the number of actual items parsed. To get around this, if desired, users can manually call the CSV_ResetIndex action and set the value to whatever they need it to be after the loop is finished.
0
In reply to Phosphatidylinositol_:
Yeah, User Types are much better for this sort of thing since it won't take up variable space memory in your Triggers, but it at least makes the Triggers that you use that do this take up less space overall eventually by reducing the total number of Actions in the compiled Galaxy script. Some people are also scared of the Data Editor and prefer working in Triggers (I even used to be one of them even lol).
This could also be combined with User Types as well, as in you can store strings within User Types and parse those directly for otherwise complex User Type setups, or say for parsing a User Type into a
Struct... I mean Record 😛) I should probably add the bit about the User Types, but I've already seen a few thorough looking tutorials on them.As always I appreciate the feedback 😄
0
CSV Utility Library
I've written a little standalone CSV String parsing library in Galaxy, and I'm posting it here in-case anyone else finds it useful. To those who that already sounds useful, you can skip ahead below to the download and check it out. I think it should be useful if you're programming with Triggers or Galaxy code (though it's mainly designed for Triggers, and is much more efficient in terms of Trigger usage than normal Trigger loops by using no Auto-Generated variables, and only few overwritten local Data Tables values).
What is a CSV you ask, and why do I need to use them in SC2 Map Making? Well if you're asking that question, then chances are you don't need to use CSVs (an acronym for Comma Separated Value), however maybe you still do or what to just learn and improve your skills. For us map makers who make complex sets of triggers, that utilize tons of different variables that all need to be initialized to specific values (and thus might not be easily loop-able), it can be incredibly useful to be able to say have a string: "0,12,42,4,5,9043,text" and use that to populate an array of variables with those values.
Now it might be trivial and easy to do so in that example, and many others, but rewriting the same, or very similar code repeatedly can become very tedious and gets more error prone as you repeat the code. This library eliminates those issues by giving an easy set of Actions and Functions to parse a CSV string, these Actions and Functions are designed to work nearly identical to the standard Blizzard loops, such as Pick Each loops, however underlying this library is implemented in a much more memory efficient way that is also Thread Safe between Triggers.
Note: Currently the Parser doesn't support anything more complex than a basic CSV, nor can the loop be nested within itself as it will overwrite its own data table entries (though I might add functionality for nested loops in the future, as it shouldn't be difficult to do so with an added parameter to the Loop Actions).
Feedback, comments, bug reports, usage, all greatly appreciated! 😎
Changelog:
v1.0 - Release
v1.1 - Bug fixes and Clean Up