User types are extremely useful in liason with triggers. They allow you to create records of variables via data instead of triggers, which is significantly easier than having to painstakingly key them in one by one within the trigger GUI.
Grr....I would really liked to have map wipe on the arcade. Now even the monobatltles are in the custom section (allthou they should be in melee custom)
I wish all the melee maps would stay in their own section....
Actually, it is. If you want to swap a ton of textures for one model, you would do 1 declaration with tons of adaptions before, because multiple declarations seem to stop working at some point. But if you need a prefix, you need to make a new declaration for each texture to swap, which doesn't work.
I've run into problems with Texture Select by ID some time during the beta, thanks for letting me know it's prefixes, I'll see if I can fix it (I didn't before because it was a custom model and just a single case, working on a new map and don't have much texture selects yet)
Most of the new data types don't seem too useful. Quite a few of them are linked to user types I believe, which you can't really use in data, only triggers. I guess those are there for the campaign for some reason, maybe to save data easily or something...
User Types are really fucking useful though.
Actor type: Scene
Used to change particular settings of the scene via Actor Events. Is used by modifying the existing Scene type actor that is called something like SYSTEM_*. For example you can change the global Halo Color for the map or the thickness of the Halo among other small things.
Actor type: Site Operation (Rotator)
Makes actors spin around like a propeller when applied. Can also be combined so you get overlapping rotation movements. You can set the axis they spin around and the speed.
I tried to get Light Actors to work but I'm pretty sure they aren't usable at all until HotS comes out, or I just took the wrong approach in using them.
Also last but not least they added a lot of options to already existing data types, for example they added stuff to specify Pathing Validators and stuff like that. Also little things were changed about "Launch Missile" effects. There is really a lot of stuff added, so I definitely approve of this thread :)
The new attach offset actor message and the rotator site operation are really nice. You can easily put together a unit consisting of multiple models, attached to each other with an offset and rotation and probably add some spinning propellers or something, without the need to add any new actors. This used to require tons of actors, usually one actor and 2 site operations per added model, more, if you wanted them to rotate. Now I equipped the default marine with an attached rotating "fan" (being another marine :D) pointing in his direction from 5 yards away with only creating the one single rotator site operation as a new object.
Hmmm... Never noticed those events >.> Could have used those. Well, can use em now =D
And yea, many little changes were done to the existing data types that are really awesome, but the new data types don't seem to add much, apart from User Types which are awesome
User types are extremely useful in liason with triggers. They allow you to create records of variables via data instead of triggers, which is significantly easier than having to painstakingly key them in one by one within the trigger GUI.
I'm in the process of trying to understand how the User Types work exactly. It seems to me they could be used to avoid using a huge variable array of for example: upgrades, behaviors, or units (and many more). I'm having some issues figuring out exactly how to implement it though. Any chance you could post some images of how you are using them?
Does anyone know if the Hero, Hero statistics, and Hero abilities data types are incomplete? Unless I'm wrong about their purpose (to make hero creation easier), they don't seem to be working.
I didn't find any way to link them to a unit or to place a hero direcly yet. My guess would be, that they are incomplete, but it might be some not-so-intuitive link to existing data types we don't know about yet.
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:
ID
Variable Type
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.
Has anyone figured out how to use them? Or which ones are even useful?
Some of them look promising, but when I quickly skimmed over some of them I couldn't how to take advantage of these new data types.
@Kirle: Go
User types are extremely useful in liason with triggers. They allow you to create records of variables via data instead of triggers, which is significantly easier than having to painstakingly key them in one by one within the trigger GUI.
Grr....I would really liked to have map wipe on the arcade. Now even the monobatltles are in the custom section (allthou they should be in melee custom)
I wish all the melee maps would stay in their own section....
Anyone knows whats up with the imported textures now?
None of the imported textures shows up on the units, even though the Texture Selecy by ID still looks correct
Strange - in the beta they all worked correctly. Now, my imported textures won't work, either.
€ in a different map, they do.
You think the process needs to be redone? Reimport textures and do the texture select by ID steps all over again?
Or might there be an other solution?
Strange enough, the imported buttons & models still work..
Nope, the map that worked was an older map as well.
€ It seems, they force you to use a prefix now -.-
Well.. thats not a big issue?
Also, is it just me, but does it take a lot more time open a map now? It loads for 120 seconds before the map is opened.. before it took maybe 20.. :s
Actually, it is. If you want to swap a ton of textures for one model, you would do 1 declaration with tons of adaptions before, because multiple declarations seem to stop working at some point. But if you need a prefix, you need to make a new declaration for each texture to swap, which doesn't work.
I've run into problems with Texture Select by ID some time during the beta, thanks for letting me know it's prefixes, I'll see if I can fix it (I didn't before because it was a custom model and just a single case, working on a new map and don't have much texture selects yet)
Most of the new data types don't seem too useful. Quite a few of them are linked to user types I believe, which you can't really use in data, only triggers. I guess those are there for the campaign for some reason, maybe to save data easily or something...
User Types are really fucking useful though.
I stumbled on:
Actor type: Scene
Used to change particular settings of the scene via Actor Events. Is used by modifying the existing Scene type actor that is called something like SYSTEM_*. For example you can change the global Halo Color for the map or the thickness of the Halo among other small things.
Actor type: Site Operation (Rotator)
Makes actors spin around like a propeller when applied. Can also be combined so you get overlapping rotation movements. You can set the axis they spin around and the speed.
I tried to get Light Actors to work but I'm pretty sure they aren't usable at all until HotS comes out, or I just took the wrong approach in using them.
Also last but not least they added a lot of options to already existing data types, for example they added stuff to specify Pathing Validators and stuff like that. Also little things were changed about "Launch Missile" effects. There is really a lot of stuff added, so I definitely approve of this thread :)
That's what I stumbled on so far.
The new attach offset actor message and the rotator site operation are really nice. You can easily put together a unit consisting of multiple models, attached to each other with an offset and rotation and probably add some spinning propellers or something, without the need to add any new actors. This used to require tons of actors, usually one actor and 2 site operations per added model, more, if you wanted them to rotate. Now I equipped the default marine with an attached rotating "fan" (being another marine :D) pointing in his direction from 5 yards away with only creating the one single rotator site operation as a new object.
@Kueken531: Go
Interesting. Make a video pls!
I most likely wont haave too much use for it currently, but it doesnt sounds cool.
@Kueken531: Go
Hmmm... Never noticed those events >.> Could have used those. Well, can use em now =D
And yea, many little changes were done to the existing data types that are really awesome, but the new data types don't seem to add much, apart from User Types which are awesome
I'm in the process of trying to understand how the User Types work exactly. It seems to me they could be used to avoid using a huge variable array of for example: upgrades, behaviors, or units (and many more). I'm having some issues figuring out exactly how to implement it though. Any chance you could post some images of how you are using them?
Bring on the lists.
Edit: Holy Global Configuration actor Batman!
Contribute to the wiki (Wiki button at top of page) Considered easy altering of the unit textures?
https://www.sc2mapster.com/forums/resources/tutorials/179654-data-actor-events-message-texture-select-by-id
https://media.forgecdn.net/attachments/187/40/Screenshot2011-04-17_09_16_21.jpg
Does anyone know if the Hero, Hero statistics, and Hero abilities data types are incomplete? Unless I'm wrong about their purpose (to make hero creation easier), they don't seem to be working.
I didn't find any way to link them to a unit or to place a hero direcly yet. My guess would be, that they are incomplete, but it might be some not-so-intuitive link to existing data types we don't know about yet.
@alderis: Go
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:
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.