I have an idea about how to do this, but I'm wondering if anyone has any other ideas to throw around. Is there a way to do this through the data editor? I want to either make an omni light become brighter and dimmer continuously over a few seconds, or to make the light get bigger and smaller continuously over a few seconds. I only have ideas through triggers, though.
You can use actor events to change opacity and scale. I'd be willing to bet that changing both in tandem might give you the closest thing to a "pulse" effect.
You can use a timer to loop the process so that it keeps pulsing, or just use triggers to send the actor messages.
There are a few takes on a color swap here, which is very similar-
I found a small tutorial here, but I'm still have a bit of trouble understanding what I'm doing. I've decided to use only a scale change, a gradual one from 1/1/1 to 0.5/0.51 over a duration of 3 seconds, and then back (total of 6 seconds).
What kind of message types should I be using? Should I set the msg type to "actor creation," and then set a timer below that? I don't really know where to begin with this.
Do the ">" characters designate terms? What is the "timer name"? What is "timer expired"? I don't see it in either the event or term lists. Why 2 As and 2 Bs? Is it because the scale moves from 1.0-0.5 and then 0.5 to 1.0? What is the "set visibility" function and what role does it play here? Why do I begin with an "actor creation" event and not any other? Am I using the "set scale" events at all for this effect? I'm trying to understand exactly what I'm doing and why I'm doing it.
">" is meant to be "=>" but the useless forum code seems to decide it's something else. They're how terms are displayed.
"Timer Name" is a term. Terms are basically conditions for event+ effects. You want to check that the right timer is ending as the system alternates 2 timers to flick the light on and off again. Think of it like a trigger that runs for 1 sec, then at the end runs a second trigger for 1s, which in turn runs the first again.
You need 4 "timer expired" events, 2 per timer. You need 2 because you want to start the second timer AND set the visibility each second. "Timer Expired" is the event, name might be slightly different but it's definitely "Timer" with something final sounding as the second word.
You begin with actor creation because that's the data equivalent of "map initialization". Not setscale no, set visibility shows or hides a unit.
You could use Unit Birth as the event to start the first timer if it is for a unit, Behaviour.(x).On or several other events depending on the conditions you want it to start blinking under. Actor Creation is easier if you want it to automatically do something since all the stuff leading to actor creation should already be in place (any Create action leading to this actor which does not necessarily have to be on the same actor eg leviathan creates the tentacle actors from the main unit actor's events).
The Set Visibility action is if you want the light to instantly go off while Set Scale is if you want it to diminish in size and brightness over a more smooth period. The Set Scale action can go as low as 0.01 in size, for even smaller you need to adjust the scale of the model used by the actor.
Without the term for the Timer Expired event you would find it triggering when either timer expired so you would find major lag because each time a timer expires it would be creating two new ones. You need two timer systems because you are distinguishing between the turning off and turning on of the light when a timer expires. You could only use one timer system and the Pass Chance term but that would result in the light change being random and not cyclic like the two timer system is.
What is happening is when the actor is created it initiates the timer system with the once off starting of A, when it expires B Starts, when it expires A starts again, etc. This results in two states going A,B,A,B,A,B in a repeating cycle. Each time a part of this cycle ends there is an action that you desire (in this case something to change the light of the actor) attached to it.
Instead of A and B imagine the timer names are Off and On.
I have this so far, but whenever I place the doodad, it lags and crashes the editor. When I am able to test the map, the light is just a regular blue omni light. Can someone take a look and tell me what's wrong with it?
Also, I used the visibility msg just to see if I can pull off a working doodad while following Eiviyn's directions, but I plan to use a scale change instead. It will scale from 1 to 0.5, and then back to 1 again for a smooth pulsing effect. Can I just change the visibility msg to scale change instead? Or is there another event or term that must be added?
I also deleted the sound event that is normally associated with the light.
Am I adding A + B to the timer name or the timer set in the "custom" field? Or is that just for clarity on the forums? Also, what do all of those "source names" and "sub names" do?
Eiviyn and DrSuperEvil: thank you for those explanations.
That is because you have not given the timers a name (read my third paragraph from my last post) so the terms are not filtering out the other timers and you have not given them a time so they are instantly expiring. By test do you mean visible in the editor or in game because not all actor events appear ingame as they do in the editor.
Yes you can just swap the set visibility action with the set scale action.
All timer names are custom.
Check this map out, look at the far left unit where the light changes (actually was a problem for what I intended to do).
Thank you. The names (A or B) for both the timer sets and timer names was definitely the problem. It works beautifully now. I tried to examine your test map, but could not figure out precisely which actor I should be looking at, as there are so many custom ones.
Is there a way to attach an actor to an actor through events? I have a Haven crate actor/model that is based on the 1x1 Braxis destructible unit and would like to attach this pulsing light to the center of it. An actor creation event, msg type "create," name "actor," and content "lightomniblue2" does not work within the main actor. I have a screenshot of it here. What's the proper procedure to linking actors for one unit?
In my custom map the actors called stick were what you were after. You do know lights work just as good when they are a Model actor right? The Doodad actors like Unit actors do not like being attached to each other. Rather just make the box a Model actor that is attached onto the light doodad actor. With the model set the host subject to your light doodad actor and give your light the event Actor Creation>Create (with your box actor under the name field).
Rollback Post to RevisionRollBack
Contribute to the wiki (Wiki button at top of page) Considered easy altering of the unit textures?
The problem is that this box needs to be selectable, like any other destructible or unit. The idea is that these boxes are kind of like power-ups with some kind of item inside of them (though they are not really items, as I do not want an inventory system in my map). When they are clicked, a description states what the item is and the benefits that it gives. Is there a way for a model to have a footprint and a selectable property, along with a description when the box is selected? These descriptions will pretty much read like the campaign pick-ups (Grenade: Adds +3 grenade ammo, etc.).
Thank you for clarifying where I should be looking in your map. I have it in my reference folder, along with another test map of yours.
I could always just use triggers to "attach" the light (or fake it) for every one of these crates, but I'd like to make it a little easier of a process and to learn how to use these actor events.
Then why you using a Doodad actor as your omnilight? Plan B, make your box a Unit actor and have the omnilight as a Model actor attached to it. As you will only use one model that needs changing at any one time you wont need any communication between actors. You will need to make a unit under the Units data type and give it a name which is the description. Make sure the No Tooltip flag is disabled. With the pickup I recommend using a Battery ability (http://www.sc2mapster.com/wiki/galaxy/data/abilities/battery/) that applies the effect to the target and then causes the caster to suicide.
When I switch the actor type from "doodad" to "model," I get a placeholder model instead of the pulsing light. I will also look into the Battery ability; thanks for the link.
I have an idea about how to do this, but I'm wondering if anyone has any other ideas to throw around. Is there a way to do this through the data editor? I want to either make an omni light become brighter and dimmer continuously over a few seconds, or to make the light get bigger and smaller continuously over a few seconds. I only have ideas through triggers, though.
@booseek: Go
You can use actor events to change opacity and scale. I'd be willing to bet that changing both in tandem might give you the closest thing to a "pulse" effect.
You can use a timer to loop the process so that it keeps pulsing, or just use triggers to send the actor messages.
There are a few takes on a color swap here, which is very similar-
http://www.sc2mapster.com/forums/development/data/14005-solved-actors-how-to-change-color-pereodically/
Just look for Set actions for Scale and Opacity instead of Tint Color.
I will look into this tomorrow. Thanks for the quick reply.
Opacity does not affect lights while scale does. Try the Set Visibility event incase that works as well.
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
Thanks for the reply. Is there a guide on actor events anywhere?
Nope and I have alot of other stuff to add to the wiki before I will get round to that part.
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
I found a small tutorial here, but I'm still have a bit of trouble understanding what I'm doing. I've decided to use only a scale change, a gradual one from 1/1/1 to 0.5/0.51 over a duration of 3 seconds, and then back (total of 6 seconds).
What kind of message types should I be using? Should I set the msg type to "actor creation," and then set a timer below that? I don't really know where to begin with this.
Actor Creation
Set Timer (A) 1 sec
Timer Expired
> Timer Name (A)
Set timer (B)
Timer Expired
> Timer Name (A)
Set visibility 0
Timer Expired
> Timer Name (B)
Set timer (A)
Timer Expired
> Timer Name (B)
Set visibility 1
nfi what that stupid black crap is when you type "=>".
Do the ">" characters designate terms? What is the "timer name"? What is "timer expired"? I don't see it in either the event or term lists. Why 2 As and 2 Bs? Is it because the scale moves from 1.0-0.5 and then 0.5 to 1.0? What is the "set visibility" function and what role does it play here? Why do I begin with an "actor creation" event and not any other? Am I using the "set scale" events at all for this effect? I'm trying to understand exactly what I'm doing and why I'm doing it.
I really appreciate the continued help.
">" is meant to be "=>" but the useless forum code seems to decide it's something else. They're how terms are displayed.
"Timer Name" is a term. Terms are basically conditions for event+ effects. You want to check that the right timer is ending as the system alternates 2 timers to flick the light on and off again. Think of it like a trigger that runs for 1 sec, then at the end runs a second trigger for 1s, which in turn runs the first again.
You need 4 "timer expired" events, 2 per timer. You need 2 because you want to start the second timer AND set the visibility each second. "Timer Expired" is the event, name might be slightly different but it's definitely "Timer" with something final sounding as the second word.
You begin with actor creation because that's the data equivalent of "map initialization". Not setscale no, set visibility shows or hides a unit.
You could use Unit Birth as the event to start the first timer if it is for a unit, Behaviour.(x).On or several other events depending on the conditions you want it to start blinking under. Actor Creation is easier if you want it to automatically do something since all the stuff leading to actor creation should already be in place (any Create action leading to this actor which does not necessarily have to be on the same actor eg leviathan creates the tentacle actors from the main unit actor's events).
The Set Visibility action is if you want the light to instantly go off while Set Scale is if you want it to diminish in size and brightness over a more smooth period. The Set Scale action can go as low as 0.01 in size, for even smaller you need to adjust the scale of the model used by the actor.
Without the term for the Timer Expired event you would find it triggering when either timer expired so you would find major lag because each time a timer expires it would be creating two new ones. You need two timer systems because you are distinguishing between the turning off and turning on of the light when a timer expires. You could only use one timer system and the Pass Chance term but that would result in the light change being random and not cyclic like the two timer system is.
What is happening is when the actor is created it initiates the timer system with the once off starting of A, when it expires B Starts, when it expires A starts again, etc. This results in two states going A,B,A,B,A,B in a repeating cycle. Each time a part of this cycle ends there is an action that you desire (in this case something to change the light of the actor) attached to it.
Instead of A and B imagine the timer names are Off and On.
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
I have this so far, but whenever I place the doodad, it lags and crashes the editor. When I am able to test the map, the light is just a regular blue omni light. Can someone take a look and tell me what's wrong with it?
Also, I used the visibility msg just to see if I can pull off a working doodad while following Eiviyn's directions, but I plan to use a scale change instead. It will scale from 1 to 0.5, and then back to 1 again for a smooth pulsing effect. Can I just change the visibility msg to scale change instead? Or is there another event or term that must be added?
I also deleted the sound event that is normally associated with the light.
Am I adding A + B to the timer name or the timer set in the "custom" field? Or is that just for clarity on the forums? Also, what do all of those "source names" and "sub names" do?
Eiviyn and DrSuperEvil: thank you for those explanations.
That is because you have not given the timers a name (read my third paragraph from my last post) so the terms are not filtering out the other timers and you have not given them a time so they are instantly expiring. By test do you mean visible in the editor or in game because not all actor events appear ingame as they do in the editor.
Yes you can just swap the set visibility action with the set scale action.
All timer names are custom.
Check this map out, look at the far left unit where the light changes (actually was a problem for what I intended to do).
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
Thank you. The names (A or B) for both the timer sets and timer names was definitely the problem. It works beautifully now. I tried to examine your test map, but could not figure out precisely which actor I should be looking at, as there are so many custom ones.
Is there a way to attach an actor to an actor through events? I have a Haven crate actor/model that is based on the 1x1 Braxis destructible unit and would like to attach this pulsing light to the center of it. An actor creation event, msg type "create," name "actor," and content "lightomniblue2" does not work within the main actor. I have a screenshot of it here. What's the proper procedure to linking actors for one unit?
In my custom map the actors called stick were what you were after. You do know lights work just as good when they are a Model actor right? The Doodad actors like Unit actors do not like being attached to each other. Rather just make the box a Model actor that is attached onto the light doodad actor. With the model set the host subject to your light doodad actor and give your light the event Actor Creation>Create (with your box actor under the name field).
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
The problem is that this box needs to be selectable, like any other destructible or unit. The idea is that these boxes are kind of like power-ups with some kind of item inside of them (though they are not really items, as I do not want an inventory system in my map). When they are clicked, a description states what the item is and the benefits that it gives. Is there a way for a model to have a footprint and a selectable property, along with a description when the box is selected? These descriptions will pretty much read like the campaign pick-ups (Grenade: Adds +3 grenade ammo, etc.).
Thank you for clarifying where I should be looking in your map. I have it in my reference folder, along with another test map of yours.
I could always just use triggers to "attach" the light (or fake it) for every one of these crates, but I'd like to make it a little easier of a process and to learn how to use these actor events.
Then why you using a Doodad actor as your omnilight? Plan B, make your box a Unit actor and have the omnilight as a Model actor attached to it. As you will only use one model that needs changing at any one time you wont need any communication between actors. You will need to make a unit under the Units data type and give it a name which is the description. Make sure the No Tooltip flag is disabled. With the pickup I recommend using a Battery ability (http://www.sc2mapster.com/wiki/galaxy/data/abilities/battery/) that applies the effect to the target and then causes the caster to suicide.
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
When I switch the actor type from "doodad" to "model," I get a placeholder model instead of the pulsing light. I will also look into the Battery ability; thanks for the link.
Check the Art - Model field because changing one data type to another always messes up the fields. I usually make my model actors from scratch.
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
i just thought i would say there is a tutorial that seems to cover the basics of actors here