Did you manage to figure out, how the "linking" of all the data types to the user types works? There are new entries for multiple data types, where you can select a user type, they seem to somehow be able to interact, maybe share information or something?
Not just yet, I was wondering what that linking function is for too. I thought it had something to do with having a "child" user type based off a "parent" user type. That is, I was expecting the parent to display the child as "linked". No link information appeared on the parent when I attempted this though.
Rollback Post to RevisionRollBack
Works AoS2CoderBoss Bars+Custom boss barsGXMLDialog XML parser Project WCoderRandNAligning dialog labels
I think someone mentioned that there is a trigger action to save a user type to a bank, so I'm guessing these data types are probably for saving Kerrigan's stats in the campaign, or maybe to more easily reference their Blizzard Allstars heroes with triggers or something.
I'm actually working on a minimalist tutorial on the basics of it. Though I'm not sure if it's going to be detailed enough to answer your question. Hopefully be able to post it up tonight, else I'll only be able to next week.
In a nutshell, you just need to add fields, the same way you would add them in a struct (record). Once you've declared the fields, just add instances, and set their values.
Each field allows you to determine it's:
Size (Default 1), Increasing it to more than one just makes it a larger array.
Editor Column: This needs to be a unique (non-zero) number, it determines where exactly the field appears in the instances table.
Modifiable: If you plan to modify your instances with script, then tick this, else it basically locks the data field such that it can't be modded.
Others properties are kinda useless IMO.
Make sure your user_type has "define default values" unchecked though, or it won't let you modify your instances. For ease of use, I recommend defining your default values after adding all your fields. This way, whenever you add a new instance, it will assume all the default values. If many of your instances have identical data in their fields, this will save you a lot of trouble.
Edit: But then again.. Its kinda redundant to have the field in the first place if all the data is the same.
Once you've keyed all the data in, you can read them with the new User Type trigger functions provided in the trigger editor. They're very straightforward to use.
Thanks much, you gave me enough info to figure them out and make it work. While for my studio's current project we probably won't be switching from variable arrays when we start our next one this new data type will be fantastic.
EDIT: One thing to note and honestly I have no clue why, while variable arrays can use 0 as a valid index entry the User Types seem to start at 1 and you can't use 0. For me since I'm so used to using arrays it's a little annoying, but that's probably because our entire system is setup to count 0 as part of the numerous loops to cycle through the array. At the onset of a new project it won't be as annoying.
My workaround to this, was to use instance Id's that are 0 indexed integers in the form of a string, and iterate the instances by the id, rather than the index. I then add an extra name field to serve as the true identifier
Edit: I believe the 0 index is reserved for the default instance
Is it me or those entire 'new' data types are piece of crap?
Unless they can be used directly from data module level (which i haven't tested) they are like reinventing the wheel for me.
The fact that they are in 'data' is fail right away. I thought those will be something like classes,or at least something similar in concept. Yet they are detached from triggers making them tied to given map/mod. So trigger libraries gained nothing.
I find them to be quite awkward in use. Go here, set this, change this there, go back here.... meh.
Also they are somehow against general coding standards. Where's the instance, where's the reference, are they destroyed or not, initialized or not. All so messy.
I waited for 1.5 just to be sooo disappointed :D
I don't know what limitations they have, system structure or laziness, but they could simply make class like type and it would be pure win.
Also i noticed they added structs and arrays passing to Galaxy but not for GUI?? Those could easily replace those pointless Data Types...
The actors seem interesting if I could figue out what half of them do. Still being able to change the cloak model is useful. And as I said the map part of the campaign data type might have more behind it than you believe.
Rollback Post to RevisionRollBack
Contribute to the wiki (Wiki button at top of page) Considered easy altering of the unit textures?
Comparing User Types and variable arrays, which would you say is better? I personally despise the data editor and am probably going to stick with the trigger editor for everything except making units and a few other things. I heard that they take up data space instead of script space, which would also be an added bonus. Also, are they automatically attached to units or do I have to use indexes for arrays?
that's cool. Will take a look. I knew it was possible to change the cloak model by changing the default cloak models object model file to the red cloak one, I guess having an actor for it will help. Too bad none of the modelers know how to make different colors yet...