entity newMonster creates a variable for us of the entity type. A variable is a just a label for a piece of memory. When we spawn in our new creature, we want to have a way to access him later in the script. We use variables to keep track of all sorts of information.
Right now newMonster is empty. We're going to spawn in a strogg marine, and store the resulting handle into the newMonster variable.
newMonster = sys.spawn("monster_strogg_marine"); does just that! We use the spawn command to tell the game to create a new entity of whatever type we tell it. Anytime we enter text between quotes, we call it a string. That string is the parameter-- you remember those from earlier? So we're telling the game to create us a Strogg Marine, and to put the handle to that Strogg Marine inside our variable called newMonster.
At this point, a Strogg Marine is created, but he's been placed at world location 0,0,0. That's no good, we want him to appear at the target_null we made earlier!
To move an entity to a different position in the map instantly, we use the setWorldOrigin event. This is an instant move, the entity will pop into position over the course of a single frame. We do that with newMonster.setWorldOrigin( ).
Up until now we've been calling all our functions on the SystemObject. Functions can be called on all sorts of objects though, the SystemObject is only the beginning. To learn more about these functions, check out the Script Events page.
The function setWorldOrigin needs a parameter though. Let's give it the origin of that target_null we made earlier. We can call a function on that target_null to get it's origin. So we will.
$targetMonster.getWorldOrigin() returns to us the entity's origin in the world as a vector. The $targetMonster part is special. We use that $ symbol to reference any entity that is in the map. In this example, we use $targetMonster because that's what we named the target_null. If you named yours differently, use that different name.
Will place the monster directly on the origin of that target_null.
Save your script file!
+
Let's go over this new stuff!
entity newMonster creates a variable for us of the entity type. A variable is a just a label for a piece of memory. When we spawn in our new creature, we want to have a way to access him later in the script. We use variables to keep track of all sorts of information.
Right now newMonster is empty. We're going to spawn in a strogg marine, and store the resulting handle into the newMonster variable.
newMonster = sys.spawn("monster_strogg_marine"); does just that! We use the spawn command to tell the game to create a new entity of whatever type we tell it. Anytime we enter text between quotes, we call it a string. That string is the parameter-- you remember those from earlier? So we're telling the game to create us a Strogg Marine, and to put the handle to that Strogg Marine inside our variable called newMonster.
At this point, a Strogg Marine is created, but he's been placed at world location 0,0,0. That's no good, we want him to appear at the target_null we made earlier!
To move an entity to a different position in the map instantly, we use the setWorldOrigin event. This is an instant move, the entity will pop into position over the course of a single frame. We do that with newMonster.setWorldOrigin( ).
Up until now we've been calling all our functions on the SystemObject. Functions can be called on all sorts of objects though, the SystemObject is only the beginning. To learn more about these functions, check out the Script Events page.
The function setWorldOrigin needs a parameter though. Let's give it the origin of that target_null we made earlier. We can call a function on that target_null to get it's origin. So we will.
$targetMonster.getWorldOrigin() returns to us the entity's origin in the world as a vector. The $targetMonster part is special. We use that $ symbol to reference any entity that is in the map. In this example, we use $targetMonster because that's what we named the target_null. If you named yours differently, use that different name.
Will place the monster directly on the origin of that target_null.
Save your script file!
Running the Script Anew
Now, if you've closed the game since you've run the Hello Stroggos example, just load it again and this script should work out fine. However, if you've still got the game running from before, you'll need to execute a Reload Script command in the console.
Once you've saved your script, drop the console in game and enter the command reloadScript. The game should pause for a few seconds, then show you this:
Most flags can be used by all *Def Types, but some are used only by certain *Def elements. The following is an example of a choiceDef and some of its flags to show the general set up:
choiceDef gametype_selection
+
Most flags can be used by all *Def Types, but some are used only by certain *Def elements. The following is an example of a choiceDef and some of its flags to show the general set up:
The path to the image to be displayed in the windowDef. Paths are referenced from q4base, so a typical path would be gfx/guis/mapname/imagename .
bind
-
Used in bindDefs. Sets the bind that will be changed when the player edits their key bindings.
+
Used in bindDefs. Sets the bind that will be changed when the player edits their key bindings.
bordercolor
Defines the color of the border on a windowDef. Colors are normalized RGB and alpha values. A bordercolor set to 1,1,0,1 would be yellow with no transparency. The bordersize flag must be set for a bordercolor to show. This flag can also reference the individual R,G,B and alpha values in the following way: bordercolor_x, bordercolor_y, bordercolor_z, bordercolor_w.
bordersize
Defines the size in pixels of the windowDef's border.
choices
-
Defines the choices to be shown in a choiceDef. Each choice is separated by a semicolon.
+
Defines the choices to be shown in a choiceDef. Each choice is separated by a semicolon.
choicetype
Takes values of 0 and 1. Choicetype 0 is a boolean value. Choicetype 1 is a multiple choice value.
comment
Used to mark a comment. This is often used in the Desktop to refer to gui parms that may be used by the GUI to operate on scripts.
Defines the color of the text in a windowDef. Colors are normalized RGB and alpha values. A forecolor set to 1,1,0,1 would be yellow with no transparency. This flag can also reference the individual R,G,B and alpha values in the following way: forecolor_x, forecolor_y, forecolor_z, forecolor_w.
high
-
Used in sliderDefs as the upper boundary for a slider cvar value.
+
Used in sliderDefs as the upper boundary for a slider cvar value.
listname
-
Used in listDefs only. Sets the name of the list to be displayed in the listDef. This listname value is referenced by the code and may or may not be different from the listDef's actual name.
+
Used in listDefs only. Sets the name of the list to be displayed in the listDef. This listname value is referenced by the code and may or may not be different from the listDef's actual name.
low
-
Used in sliderDefs as the lower boundary for a slider cvar value.
+
Used in sliderDefs as the lower boundary for a slider cvar value.
matcolor
Defines the color of the image displayed in the “background” flag for a windowDef. This flag can also reference only the R, G, B, and alpha values of a windowDef accordingly: matcolor_x, matcolor_y, matcolor_z, matcolor_w.
Defines the location, width and height of a windowDef as x1,y1,width,height. 0,0,640,480 would be a windowDef of 640 by 480 pixels whose top left corner is at coordinate 0,0. The first two values always represent the upper left corner of a windowDef.
rotate
-
Defines the angle that the image refenced by the windowDef will be rotated. This property can also be used in a transition statement to rotate an image in a windowDef over time.
+
Defines the angle that the image refenced by the windowDef will be rotated. This property can also be used in a transition statement to rotate an image in a windowDef over time.
This is a step by step guide to creating a simple fire effect.
Remember that once you have added a segment to an effect you can use binds with editfx_play and editfx_playlooping to test the effect. This document assumes that after adding one segment you start playing the effect looping on a ground surface in a test map. As the effect is changed in the editor, the looping effect in the world will update.
Open the FXEditor with the +editfx console command.
Click File>New or hit CTRL + N.
Right click inside the Segment window and click Insert>Sprite.
Click the Sprite Tab and in the material field (where it says '_material') enter a path to your fire image shader. In our case, it will be: gfx/effects/fire/fire4a
Go to the Motion Tab and clear out the existing Forward/Left/Up values. Replace them with a Forward range of 10 min, 50 max. Left of -5 min, 5 max, Up -5 min, 5 max. Make sure to give the Sprites a negative gravity value of -0.05 so they rise realistically.
Click the Size Tab and give your sprite particles a size range of 15 min, 30 max for both height and width. Make sure to check Linear Distribution
Go to the Rotate Tab and give the segment a 0 min, 360 max value for start rotation. On the dropdown box for Envelope, select a Linear table. Hint: Hit the L key with the dropdown box selected to hop to the first Table that starts with the letter L. For the end rotation values, set -90 min and 90 max. Make sure to select End Relative to Start.
Click the Alpha Tab and select an envelope for alpha fading. I recommend fastinslowout. This table is similar to cosine except the alpha ramps up quickly and fades slowly. Set a start value of 0, and an end value of 1. Make sure you check Blend Alpha and Color As the fire shader we are using is an additive blend.
The fire is starting to take shape. Go to the Emitter Tab and increase the count to 10 from 5.
Go to the Origin Tab. Add Left and Up min/max values of -15, 15 so that the sprites will not spawn in the exact same location. You can leave Forward at 0 so that all fire particles spawn on the same surface. Make sure the distribution is Sphere or Cylinder for even and realistic coverage.
Lets add some embers to our fire. Create a new Sprite segment and add this material to the Sprite Tab: gfx/effects/energy_sparks/spark3 Remember that you can right-click on a selected segment and click Rename so each segment you create has a more memorable name. Try renaming the fire segment to fire1 and this new embers segment to embers.
Go to the Motion Tab on the embers segment and set the Motion to 10 min 20 max for Forward. Set left/up values to be 0. This is in preparation for using Orbit and Offset. Give the embers segment the same gravity as the fire, -0.05.
Lets spawn the embers in a Cylinder origin all around the fire. Do this by setting values of -25 min, 25 max for Forward, Left and Up. Also select Cylinder distribution.
Setup the Alpha to use a Cosine table with a start value of 0 and an end value of 1.
Move to the Size Tab and set a min size of 0.5 and a max size of 2. Linear Distribution checked again, these values apply to both Height and Width.
Now lets adjust the Offset so that spawning embers will have random wiggly Orbits simulating real fire embers. On the Offset tab, set a min of -10 and a max of 10 for Forward, Left and Up.
Click the Orbit tab and enter 0 min 360 max for the Start values for Roll, Yaw and Pitch. Select a Linear Table Envelope and set the End values to -120 min, 120 max. Different Orbit values will lead to different results. Try setting values of -360 min, 360 max to see how the embers orbit faster and more randomly. You can also increase the Offset values for a similar effect. Remember that Offset determines the distance between the sprite and the rotate point while Orbit determines how many degrees to rotate the sprite around the rotate point.
Now that we have added some embers, lets add some smoke to our fire. We want our smoke to use roughly the same dynamic as the fire, so lets select the fire1 segment, copy and then paste it into our segment list. Then rename this segment to smoke1.
From the Origin Tab, we want to start the smoke a bit higher so that the particles start more towards the top of the flame, rather than at the base mixed with the fire. Set 25 min, 40 max for the Forward origin on the smoke segment.
The smoke looks a bit too white and opaque, so lets fix that now. Move to the Color Tab and set a medium greyish/brown color for the start value. Change the Envelope to Linear and set an end color of black. This will transition the smoke particles from grey to black.
Now move to the Alpha Tab and change the table from fastinslowout to cosine. This will make the smoke transitions smoother rather than start fast and fade slow. Change the end value to 0.6 while you are here as well to make the smoke less opaque.
With the smoke segment in place, we can turn our attention to some last minute details with the fire. In order to make more realistic looking fire you need to use more than one fire source image in your effect. Lets copy our fire1 segment and paste it again. This time, select the segment and hit CTRL + [ twice to move it down in the Z order with the other fire segment.
We can change the material to: gfx/effects/fire/fire2a on the Sprite Tab to see how adding a second fire image makes our fire look more realistic. The interplay between various additive materials is important to many effects.
At this point, our basic fire effect is complete. You can adjust size, lifetimes and origins to make larger and smaller versions of this effect.
To see some a more advanced fire effect, load effects/fire/column_128. This effect uses multiple fire images, embers and smoke to build up a more complex fire effect. It utilizes heathaze shaders to warp the image around the fire as well as an animated strip of fire. An animated strip is an advanced material that is one image consisting of different frames of images.
Effect Creation Walkthrough (last edited 2005-11-09 20:28:55 by MattVainio)
+
This is a step by step guide to creating a simple fire effect.
Remember that once you have added a segment to an effect you can use binds with editfx_play and editfx_playlooping to test the effect. This document assumes that after adding one segment you start playing the effect looping on a ground surface in a test map. As the effect is changed in the editor, the looping effect in the world will update.
Open the FXEditor with the +editfx console command.
Click File>New or hit CTRL + N.
Right click inside the Segment window and click Insert>Sprite.
Click the Sprite Tab and in the material field (where it says '_material') enter a path to your fire image shader. In our case, it will be: gfx/effects/fire/fire4a
Go to the Motion Tab and clear out the existing Forward/Left/Up values. Replace them with a Forward range of 10 min, 50 max. Left of -5 min, 5 max, Up -5 min, 5 max. Make sure to give the Sprites a negative gravity value of -0.05 so they rise realistically.
Click the Size Tab and give your sprite particles a size range of 15 min, 30 max for both height and width. Make sure to check Linear Distribution
Go to the Rotate Tab and give the segment a 0 min, 360 max value for start rotation. On the dropdown box for Envelope, select a Linear table. Hint: Hit the L key with the dropdown box selected to hop to the first Table that starts with the letter L. For the end rotation values, set -90 min and 90 max. Make sure to select End Relative to Start.
Click the Alpha Tab and select an envelope for alpha fading. I recommend fastinslowout. This table is similar to cosine except the alpha ramps up quickly and fades slowly. Set a start value of 0, and an end value of 1. Make sure you check Blend Alpha and Color As the fire shader we are using is an additive blend.
The fire is starting to take shape. Go to the Emitter Tab and increase the count to 10 from 5.
Go to the Origin Tab. Add Left and Up min/max values of -15, 15 so that the sprites will not spawn in the exact same location. You can leave Forward at 0 so that all fire particles spawn on the same surface. Make sure the distribution is Sphere or Cylinder for even and realistic coverage.
Lets add some embers to our fire. Create a new Sprite segment and add this material to the Sprite Tab: gfx/effects/energy_sparks/spark3 Remember that you can right-click on a selected segment and click Rename so each segment you create has a more memorable name. Try renaming the fire segment to fire1 and this new embers segment to embers.
Go to the Motion Tab on the embers segment and set the Motion to 10 min 20 max for Forward. Set left/up values to be 0. This is in preparation for using Orbit and Offset. Give the embers segment the same gravity as the fire, -0.05.
Lets spawn the embers in a Cylinder origin all around the fire. Do this by setting values of -25 min, 25 max for Forward, Left and Up. Also select Cylinder distribution.
Setup the Alpha to use a Cosine table with a start value of 0 and an end value of 1.
Move to the Size Tab and set a min size of 0.5 and a max size of 2. Linear Distribution checked again, these values apply to both Height and Width.
Now lets adjust the Offset so that spawning embers will have random wiggly Orbits simulating real fire embers. On the Offset tab, set a min of -10 and a max of 10 for Forward, Left and Up.
Click the Orbit tab and enter 0 min 360 max for the Start values for Roll, Yaw and Pitch. Select a Linear Table Envelope and set the End values to -120 min, 120 max. Different Orbit values will lead to different results. Try setting values of -360 min, 360 max to see how the embers orbit faster and more randomly. You can also increase the Offset values for a similar effect. Remember that Offset determines the distance between the sprite and the rotate point while Orbit determines how many degrees to rotate the sprite around the rotate point.
Now that we have added some embers, lets add some smoke to our fire. We want our smoke to use roughly the same dynamic as the fire, so lets select the fire1 segment, copy and then paste it into our segment list. Then rename this segment to smoke1.
From the Origin Tab, we want to start the smoke a bit higher so that the particles start more towards the top of the flame, rather than at the base mixed with the fire. Set 25 min, 40 max for the Forward origin on the smoke segment.
The smoke looks a bit too white and opaque, so lets fix that now. Move to the Color Tab and set a medium greyish/brown color for the start value. Change the Envelope to Linear and set an end color of black. This will transition the smoke particles from grey to black.
Now move to the Alpha Tab and change the table from fastinslowout to cosine. This will make the smoke transitions smoother rather than start fast and fade slow. Change the end value to 0.6 while you are here as well to make the smoke less opaque.
With the smoke segment in place, we can turn our attention to some last minute details with the fire. In order to make more realistic looking fire you need to use more than one fire source image in your effect. Lets copy our fire1 segment and paste it again. This time, select the segment and hit CTRL + [ twice to move it down in the Z order with the other fire segment.
We can change the material to: gfx/effects/fire/fire2a on the Sprite Tab to see how adding a second fire image makes our fire look more realistic. The interplay between various additive materials is important to many effects.
At this point, our basic fire effect is complete. You can adjust size, lifetimes and origins to make larger and smaller versions of this effect.
To see some a more advanced fire effect, load effects/fire/column_128. This effect uses multiple fire images, embers and smoke to build up a more complex fire effect. It utilizes heathaze shaders to warp the image around the fire as well as an animated strip of fire. An animated strip is an advanced material that is one image consisting of different frames of images.
Effect Creation Walkthrough (last edited 2005-11-09 20:28:55 by MattVainio)
Default is 0, controls when this segment should start in relation to when the effect is played. An effect can have different start times per segment to delay certain parts of an effect.
Count
-
How many particles to emit. This number is relative to the Particle Lifetime (defined in the Sprite properties). In an effect with Spawn Simultaneously checked, this number is always accurate. A count of 10 will mean 10 particles emitted simultaneously. Whereas, a count of 10 with a particle lifetime of 2 will mean 20 particles on screen at once. The count is the amount of particles to emit per time unit ( of 1 ) There is a relationship with how long each particle lasts and the count in this manner.
+
How many particles to emit. This number is relative to the Particle Lifetime (defined in the Sprite properties). In an effect with Spawn Simultaneously checked, this number is always accurate. A count of 10 will mean 10 particles emitted simultaneously. Whereas, a count of 10 with a particle lifetime of 2 will mean 20 particles on screen at once. The count is the amount of particles to emit per time unit ( of 1 ) There is a relationship with how long each particle lasts and the count in this manner.
Duration
Controls how long the segment should emit particles. In a looping effect, this can remain the default of 1 second. If the effect is not looping, the segment will play its Count number every second for the duration. So using the above example with a duration of 5, you will have 10 particles emitting every second for 5 seconds. (On looping: An effect is set to looping through the LevelEditor or the FX Entity Editor.)
This tab controls the lifetime of the sprite, the material used by the sprite and whether it should play any effects upon it’s lifetime ending. This tab is named Line for a line segment.
Live Forever
-
Useable only if Spawning simultaneously. The sprite will remain around constantly as long as the effect is visible.
+
Useable only if Spawning simultaneously. The sprite will remain around constantly as long as the effect is visible.
Lifetime
A min and max range possible for the lifetime of a sprite. Lifetime chosen randomly between min and max when the particle is spawned. Larger min/max ranges lead to more random particle lifetimes.
GUIs in Quake4 use Truetype fonts (*.ttf) converted into *.tga images along with a font data file (*.fontdat) that describes where within the *.tga every character resides. These *.tga files can be edited in any standard image editing software that allows Alpha Channel editing. The characters are all located in this Alpha Channel.
Quake 4 uses three font point sizes, which one it chooses to use is dependent on the Text Scale attribute of the specified windowDef. The three font point sizes are: 12, 24 and 48. Below is a chart relating to textscale and which point size will be used.
GUIs in Quake4 use Truetype fonts (*.ttf) converted into *.tga images along with a font data file (*.fontdat) that describes where within the *.tga every character resides. These *.tga files can be edited in any standard image editing software that allows Alpha Channel editing. The characters are all located in this Alpha Channel.
Quake 4 uses three font point sizes, which one it chooses to use is dependent on the Text Scale attribute of the specified windowDef. The three font point sizes are: 12, 24 and 48. Below is a chart relating to textscale and which point size will be used.
A single font can have more than one *.tga attached to it, depending on the export size of the character and how many characters are in the font. Example font file names from Quake 4:
Use generalized animations to do basic, repeatable functions in your GUIs. For example, if you're using popups in your menu, create a single animation or named event that brings the generic popup graphics up, and then set a desktop float that will be checked in an if statement to determine which message to show on top of it.
Organize your GUIs and use the parent-child relationship of nested windowDefs to keep things organized. For example, if you have several animation windowDefs, house them all under a parent windowDef marked "p_anims" or something similar.
If you plan to resize windowDefs through transitions frequently, it's helpful to create an invisible windowDef that is sized to the new size and then using this windowDef in your transition command accordingly, where "window1_newsize" is the invisible windowDef:
If your menus get large, it's helpful to create a few reset animations or named events that sets everything in a particular group of windowDefs back to a default value. For example, you may want to reset a screen of buttons back to an unhighlighted default state.
Use animations when you know you need something to happen over time steps. Use named events when you just want to set properties instantly.
Statements in a script in the GUI system are executed simultaneously. If you want certain steps to happen before others, you must use an animation.
Avoid calling named events or using the set "cmd" or consoleCmd statements in animations. If a frame gets dropped and your command or named event call is in that frame, it won't be executed and will break the GUI.
If your GUIEditor crashes when you try to load a GUI, it's probably because of an error in your scripting. The most common culprits are brace errors or bad if statements. Since the GUIEditor lacks an error feedback system, it's best to save different versions of your gui files in case one becomes corrupted. Try to remember which area you were working in and if possible use an advanced editor such as Ultra Edit so that you can compare files against each other to spot differences that might have caused the crash/corruption.
It's possible to use math statements in your Desktop header and element properties to achieve certain effects, such as dynamic placement. For examples of this, look at scoreboard.gui and mpmain.gui. But be careful! The GUIEditor has been known to corrupt Desktop headers with math statements in them if you open the Desktop scripting window in the editor. Saving a copy of your Desktop header to copy and paste in if this happens is usually helpful.
Example, A desktop header script such as this:
windowDef Desktop
+
If your menus get large, it's helpful to create a few reset animations or named events that sets everything in a particular group of windowDefs back to a default value. For example, you may want to reset a screen of buttons back to an unhighlighted default state.
Use animations when you know you need something to happen over time steps. Use named events when you just want to set properties instantly.
Statements in a script in the GUI system are executed simultaneously. If you want certain steps to happen before others, you must use an animation.
Avoid calling named events or using the set "cmd" or consoleCmd statements in animations. If a frame gets dropped and your command or named event call is in that frame, it won't be executed and will break the GUI.
If your GUIEditor crashes when you try to load a GUI, it's probably because of an error in your scripting. The most common culprits are brace errors or bad if statements. Since the GUIEditor lacks an error feedback system, it's best to save different versions of your gui files in case one becomes corrupted. Try to remember which area you were working in and if possible use an advanced editor such as Ultra Edit so that you can compare files against each other to spot differences that might have caused the crash/corruption.
It's possible to use math statements in your Desktop header and element properties to achieve certain effects, such as dynamic placement. For examples of this, look at scoreboard.gui and mpmain.gui. But be careful! The GUIEditor has been known to corrupt Desktop headers with math statements in them if you open the Desktop scripting window in the editor. Saving a copy of your Desktop header to copy and paste in if this happens is usually helpful.
The Origin tab can control more than the bounds in which sprites and lines spawn.
Example: An effect was needed where sprites moved outward from a center point. You could set values under Motion for Left and Up, but this would create a square shape when viewed from the top.
-
To get around this, apply motion only in the forward axis and use Origin to adjust where the forward axis is. This can be accomplished by Generating the normal from effect origin of an effect segment and selecting Spawn on Surface of a shape such as a cylinder or sphere. Depending on the size of the origin min/max bounds, the sprite particles will emit from what appears to be a bubble or from a point. If the origin bounds are very small, it will appear as though the sprites are emitting from a single point.
This same technique can be used with lines, and will give them a direction to point in. A good example is effects/weapons/machinegun/impact_default.fx. The side_streaks segment uses a cylinder origin with Spawn on Surface checked. Giving the Origin only a min value for in the forward axis ensures a consistent angle forward, while a range of left and up values ensure a random selection around the circumference of the cylinder. As the forward value grows larger in relation to the left and up values, the angle of the line segments grows steeper. As the forward value grows smaller in relation to the left and up values, the angle of the line segments grows shallower. (Note on the machinegun effect: Since the forward origin value is –0.2, Invert Normals is checked so the lines point the proper direction.)
A good way to achieve the angle you are looking for is to make sure your particle count is high temporarily so it’s easier to see what is going on. Remember that once you find your angle, you can adjust the numbers down to decimal values so that the angle is projected from a single point.
Example: Forward value of 5, Left and Up min/max values of –10/10. This will generate a cylinder 5 units tall with a diameter of 10 units. If you wish this effect to emit from a point, drop the values to: Forward 0.05 and Left/Up min/max –0.1/0.1
+
To get around this, apply motion only in the forward axis and use Origin to adjust where the forward axis is. This can be accomplished by Generating the normal from effect origin of an effect segment and selecting Spawn on Surface of a shape such as a cylinder or sphere. Depending on the size of the origin min/max bounds, the sprite particles will emit from what appears to be a bubble or from a point. If the origin bounds are very small, it will appear as though the sprites are emitting from a single point.
This same technique can be used with lines, and will give them a direction to point in. A good example is effects/weapons/machinegun/impact_default.fx. The side_streaks segment uses a cylinder origin with Spawn on Surface checked. Giving the Origin only a min value for in the forward axis ensures a consistent angle forward, while a range of left and up values ensure a random selection around the circumference of the cylinder. As the forward value grows larger in relation to the left and up values, the angle of the line segments grows steeper. As the forward value grows smaller in relation to the left and up values, the angle of the line segments grows shallower. (Note on the machinegun effect: Since the forward origin value is –0.2, Invert Normals is checked so the lines point the proper direction.)
A good way to achieve the angle you are looking for is to make sure your particle count is high temporarily so it’s easier to see what is going on. Remember that once you find your angle, you can adjust the numbers down to decimal values so that the angle is projected from a single point.
Example: Forward value of 5, Left and Up min/max values of –10/10. This will generate a cylinder 5 units tall with a diameter of 10 units. If you wish this effect to emit from a point, drop the values to: Forward 0.05 and Left/Up min/max –0.1/0.1
If you do a new translation, please add your group page here.
The first level list for the group must only contain the names of the pages in that group. No English original names, no comments - better put that stuff onto a 2nd-level list item below the 1st-level one. Moin has functions to make use of the group pages, but they do only work if the 1st-level list is "clean". There should be no other 1st-level lists on the pages.
Any time you want to reference an entity in script, you need to use it's handle. Handles can be accessed directly, via the $ operator, or through entity variables. Check out the examples
+
Any time you want to reference an entity in script, you need to use it's handle. Handles can be accessed directly, via the $ operator, or through entity variables. Check out the examples
Using $ to grab handles
Use a dollar sign $ before the name of an entity to tell the scripting system that this is an entity. If you don’t use the $, the game won’t know what you’re talking about.
![/!\](wiki/modern/img/alert.png "/!\"){kind=small}
This part is important, and a bit confusing at first. 
![[1 attachments]](wiki/modern/img/moin-attach.png "[1 attachments]"){kind=small}