Difference between revisions of "Unreal v227 Manual/New mod authoring tools"

From Oldunreal-Wiki
Jump to navigation Jump to search
(Created page with "{{Stub|reason=Add the info!}} {{Navbox 227 Manual}} {{Infobox 227 Manual |title=Unreal v227 Manual |image= |previous= |next=Changelog }}")
 
 
(22 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{Stub|reason=Add the info!}}
{{Navbox 227 Manual}}
{{Navbox 227 Manual}}
{{Infobox 227 Manual
{{Infobox 227 Manual
|title=Unreal v227 Manual
|title=Unreal v227 Manual
|image=
|image=
|previous=
|previous=[[Unreal v227 Manual/Server admin tools|Server admin tools]]
|next=[[Unreal v227 Manual/Changelog|Changelog]]
|next=[[Unreal v227 Manual/Frequently Asked Questions|Frequently Asked Questions]]
}}
}}
Here we're going to take a look at the new features introduced by the v227 patch regarding mod authoring and editing.
__TOC__
== UnrealEd 2.0 ==
=== Introduction and history ===
'''UnrealEd 2.0''' is the second version of UnrealEd. '''Unreal''' being the first game to use the ''Unreal Engine'' (in it's very first iteration) the included editor, ''UnrealEd'' (1.0), by the original developers' own admission, was an unsupported beta software developed in Visual Basic. The lack of certain tools prevented level-designers to achieve complex maps.
UnrealEd 2.0, originally introduced for UT99, is a rebuilt editor written in C++ later ported back to ''Unreal'' by Smirftsch in order to provide better tools for the community. Subsequent releases of patch 227, with extra involvement from the OldUnreal community, heavily improved the tools, stability and ease of use enough to deem it an almost different version: UnrealEd 2.1, similar in its looks, but significantly improved, with many bugs corrected, new functions and overall better stability.
UnrealEd 2.0 was introduced in Unreal by Patch 227f and replaced by UnrealEd 2.1 in 227h. All information on UnrealEd 2.0 works with 2.1, except for most known bugs and problems which have been fixed. UnrealEd 2 refers collectively to UnrealEd 2.0 and 2.1.
=== Interface ===
[[File:Unrealed2.jpg|350px|thumb|right|UnrealEd 2.x features a new and nicer interface]]
The interface was completely redesigned from UnrealEd 1.0 and is a lot more polished. First, the Browser isn't a sidebar anymore, but a set of dockable windows. When a browser is docked, it can be accessed from other docked windows without opening a new browser, keeping everything at hand. Only the main buttons have been kept on the left side, and the width of this sidebar reduced to two icons. This leaves plenty of extra space for the viewports themselves. These viewports are configurable, lockable and can be set to cover the entire screen if needed. The interface is very easy to configure and very comfortable, and was reused with almost no changes in UnrealEd 3.0 (the version that shipped with ''Unreal Tournament 2003'' and ''Unreal Tournament 2004'') and 4.0 (the version that shipped with ''Unreal Tournament 3'') on later engines.
=== Features ===
The first appreciable features are located in the left-panel list of tools in UnrealEd: Sheer, Stretch and Scale have been ported from UnrealEd 1.0. A new button at the very end of the list allows you to align all 2D cameras on the camera of the 3D Viewport (if you have several 3D viewports, it will align all cameras on the camera of the last 3D viewport created). You can also now align textures on the X and Y axes just as well as with the Align To Floor tool by right-clicing a surface and choosing '''Align Selected => Align to wall around X/Y axis'''.
Among other things, UnrealEd 2 features a Vertex Editing tool which greatly increases the possibilities for designers by allowing them to move not only one vertex at a time but as many as they want.
The 2D shape editor is no longer a buggy beta implementation and can be used to create almost any shape without problems.
One notable feature is the possibility to use OpenGL and several versions of Direct3D rendering in the 3D viewport, which means you won't get surprised by how a map looks in the game compared to what the software rendering shows, as was sometimes the case in UnrealEd 1.0. Although the D3D implementations are not fully supported and might not be fully working, especially if you're using and ATI graphic card, they can be used without a lot of troubles. From 227g onwards, the OpenGL support is fully stable and supported.
=== Plug-Ins ===
Though there is no "plug-in" as you might know, UnrealEd 2.0 and 2.1 can both be enhanced and expanded by adding new buttons, new functions, new tools. On the provided screenshot at the top of the page, you may notice purple builder brushes. These are custom builder brushes, the Tarquin tools. A lot of tools have been created over time for UT99's UnrealEd 2.0 and are completely compatible with Unreal 227's UnrealEd 2.1: Quick camera alignment, new stairs builders, round shape creator, easy Skybox, etc...
== Static Meshes ==
StaticMeshes are instanciated pieces of geometry which receive a basic lighting based on the light at each vertices of their triangles. They are only loaded once from your drive and, as a result, they are less memory-intensive. They are also invulnerable to BSP errors, HOMs and ther BSP-based problems, as well as not influencing BSP Cuts and supporting higher triangle counts without much problems. However, unlike their Unreal Engine 2 counterparts, they cannot be used as extensively, as the engine (Unreal Engine 1) will slow down drastically. It's still advised to use BSP for the simpler brushes. They were implemented in v227g.
In UnrealEd, they are displayed in the 2d viewports as green wireframe objects. When a Static Mesh is imported or created, it can be viewed in the Mesh Browser, where it has no animation or frame, provided the "''Show StaticMeshes''" bow is ticked. By default, the second option of the contextual menu when right-clicking in a viewport is the "'''add''' ''static-mesh'' '''here'''" option.
=== Advantages and Disadvantages over Semi-Solid Geometry ===
Because the Static Mesh is loaded as an actor, it needs to be loaded only once from the hard drive, and is then kept in memory, which means it is faster than an equivalent BSP object. Static Meshes are also invulnerable to BSP errors, HOMs and BSP Holes. It is not affected by BSP cuts and does not create them. They are easy to convert from format to format, can be edited in UnrealEd without problems. Other advantages are the end of U/V mapping limits which were common with Unreal Meshes (limited to one tile), the possibility to use either a simplified or a per polygon collision instead of the basic cylindrical collision radius of other meshes, and their adaptability: polygon flags can be set and adjusted in-editor from the mesh browser. They are faster to load and more efficient, as a loaded mesh stays in memory for the next time it will be needed.
However, they have also several disadvantages: Lighting is calculated differently from brushes, and in the same way it is calculated for meshes, which means complex shadows will usually not affect them, though they can still cast some. They may be glitchy in software mode and clutter the 3D Viewport if you don't use OpenGL or Direct3D rendering. Some bugs may also happen when a brush's pivot is inside a wall, corrupting lighting. It may force you to manually offset the pivot.
=== Supported conversions ===
UnrealEd 2.1 allows you to import .obj files as StaticMeshes. You can also create StaticMeshes from BSP by selecting some brushes, right-clicing on them and choosing '''Convert => To StaticMesh'''. StaticMeshes can only be additive constructions; if you convert subtracted brushes to static-meshes, they will be flipped and appear as additive and hollowed once converted.
You can convert static meshes between:
* Brush -> Static Mesh
* Static Mesh -> Brush
* Any meshes + Brush -> Static Mesh
* Export (Static) Mesh as Wavefront '''.OBJ'''
* Import Static Mesh as Wavefront '''.OBJ'''
Because Meshes and Brushes can be converted directly into each other, it is possible to create a map with all its meshes inside UnrealEd without using any third-party 3D Software such as Maya or 3Ds Max. However, when doing so, the engine will triangulate - convert all surfaces into sets of triangles - the mesh itself, and may end up with some inefficient results regarding lighting, needing reworking by the designer.
=== Static Meshes as Movers ===
Any Static-Mesh can be added as any type of mover: when right-clicking on the Add Mover button in the toolbar, all Mover types can be added as brushes or meshes, using either the '''Mover''' or the '''Mover [mesh]''' option.
=== Simple collision model ===
Static meshes support simple collision model. To create one for a static mesh you do:
* Add a static mesh to a level and move it to origin (1 scaling, 0 location and rotation).
* Add simple brush shapes to cover up the parts you want to collide.
* Now make sure red builder brush is at origin with 1 scaling and intersect the whole brush collision model you created.
* Then right click on the static mesh actor and select "Create collision model".
Now if you enable "''Show skeleton''" in mesh browser you should see the simple collision model on the static mesh.
To make game use it you can set on static mesh properties:
* bUseSimpleBoxCollision - Meaning box collision checks (like pawn movement) should collide with the simple collision model.
* bUseSimpleLineCollision - Meaning the same as above but for simple trace lines (like most projectiles or AI sight checks).
Using this gives performance advantage with complex static meshes as well as prevents you from getting stuck on complex parts of the mesh.
Other options in the mesh browsers include the '''Materials''' list, allowing you to instantly replace the textures of the static-mesh and the bFlipNormal boolean, which lets you instantly invert all the faces, so that all polygons visible from outward become visible from inward and vice-versa.
== Jumpers (UJumpPad, UJumpPadEnd, UJumpDest) ==
[[File:Jumper.png|350px|thumb|right|Correct way to set up a Jumper]]
Jumpers are often the shortest way to move a player (after, maybe, a teleporter). It's an actor with a radius that throws the player in a given direction toward a given navigation point.
A jumper requires three actors: <tt>'''UJumpPad'''</tt> (NavigationPoint > LiftExit > UJumpPadEnd > UJumpPad), <tt>'''UJumpDest'''</tt> (NavigationPoint > LiftCenter > UJumpDest), and <tt>'''UJumpPadEnd'''</tt> (NavigationPoint > LiftExit > UJumpPadEnd).
* Put the <tt>UJumpPad</tt> at the center of the pad.
* Put the <tt>UJumpDest</tt> at the point the Jumper is aiming.
* In the <tt>UJumpPad</tt>'s properties, under the "LiftExit" tab, put something in "LiftTag" property (e.g. MyJumpPad, so LiftTag=MyJumpPad).
* Put this same name in the <tt>UJumpDest</tt>'s properties, "LiftCenter" tab, in the "LiftTag" field (LiftTag=MyJumpPad).
The point where the <tt>UJumpDest</tt> is will be the highest point of the pawn's trajectory in the air. If you rebuild and test your map at this point, you will notice that the jumper is working. If you do right-click => View => Show path in the title bar of the 3D viewport, you will see that a path connects the <tt>UJumpPad</tt> and the <tt>UJumpDest</tt>. But if you add further pathnodes, the <tt>UJumpDest</tt> won't be connected to the other paths. In order to allow bots to play normally:
* Add a <tt>UJumpPadEnd</tt> at the end of the jump, at the point where the players are supposed to '''land'''.
* In it's properties, LiftExit => LiftTag, put the same thing as you did previously for you UJumpPad and UJumpDest (LiftTag=MyJumpPad).
* Add other pathnodes, rebuild and test.
The <tt>UJumpPad</tt> has an "UJumpPad" tab in its properties with a few parameters you can use to fine-tune it's behavior. The most important one is "JumpSound", where you can enter a sound that will be played when a player walks on the jumper (the sound of the jump boots is perfect for that). Other parameters include:
* bForceFullAccuracy: aims perfectly at the UJumpDest, but may modifiy the speed of the jump
* JumpZHeightModifier: allows the mapper to modify the height of the jump: a negative value will make the trajectory less high, while a higher value will send the player higher in the sky
* JumpVelocityModifier: allows you to modify the speed of the player in much the same way.
The Jumper will work online. Bots can use the Jumpers provided you set up a <tt>UJumpPadEnd</tt> for them. Otherwise, strange behavior may happen (as they land outside of the paths). As the Jumper is a 227 feature, it can only be used on a 227 server or on a 227 installation of Unreal. It will make your map incompatible with previous versions of Unreal.
Bots seem to be quite incompetent with jumpers and will rarely use them, even when correctly set up. If you are in doubt, check the jumper in UnrealEd: If everything is set up as it should, the UJumpPad should be linked to the UJumpDest by a yellow line when selected. This was added in '''227i'''.
== Emitter System ==
The Unreal 227 '''Particle Emitter''' (XParticleEmitter > XEmitter) system is a potent tool introduced in v227a for mappers and modders. It allows the addition of a great deal of advanced effects into both environments and actors.
{{Navbox|title=Note!|body=When creating Emitter subclasses for usage in UScript code, subclass the classes prepended with an '''X''', such as ''XMeshEmitter'' etc. For placement in maps, use classes without the X such as ''Emitter'', ''SpriteEmitter'' etc. Triggered emitters should use ''Network'' classes.|color=Red}}
The Particle Emitter classes come in various flavors: [[#Emitter|Normal]], [[#Sprite Emitter|Sprite]] (adds rotation support), [[#Mesh Emitter|Mesh]], [[#Weather Emitter|Weather]] and [[#Beam Emitter|Beam]]. Since 227f, it is also possible to combine multiple emitters into one connected system using the Combiner properties.
=== Emitter ===
This is simplest form of particle emitter with the best in-game performance which can be used for most effects.
'''EmGeneral:'''
*''bDisabled'' - Emitter is disable, no more spawning new particles.
*''bRespawnParticles'' - Respawn particles that have died.
*''bAutoDestroy'' - Auto-destroy emitter actor after all particles have died (can be used for temp effects).
*''bAutoReset'' - Auto-reset emitter after all particles have died and AutoResetTime has passed.
*''bSpawnInitParticles'' - Spawn initial particles, or else wait for possible auto-reset (only when bRespawnParticles is false).
*''MaxParticles'' - Maximum amount of particles.
*''ParticlesPerSec'' - Amount of particles to spawn per second (0 = auto assign the value).
*''LifetimeRange'' - How long time particles should live.
*''StartupDelay'' - Delay in seconds before Emitter activates (can be used for triggered emitters to delay an effect).
'''EmVisibility:'''
*''bStasisEmitter'' - Similar to Actor bStasis, but stop hide particles once player isn't seeing the emitter's zone.
*''bBoxVisibility'' - If enabled, visibility box will be used.
*''VisibilityBox'' - Only update when any parts of this box radius is within player camera sight.
*''bDistanceCulling'' - If enabled, use distance culling.
*''CullDistance'' - If player camera is beyond this distance, don't render.
*''bNoUpdateOnInvis'' - When not rendering emitter actor, do not update the particles either.
'''EmCorona''':
*''CoronaColor'' - Corona color range.
*''CoronaTexture'' - Corona texture.
*''bCheckLineOfSight'' - Should coronas disappear when behind some wall?
*''bParticleCoronaEnabled'' - Whatever if particle coronas are enabled.
*''CoronaFadeTimeScale'' - The time it will take for coronas to fade in/out when falling out of sight or back in sight.
*''CoronaMaxScale'' - Maximum corona scaling.
*''CoronaScaling'' - The scale of the coronas.
*''MaxCoronaDistance'' - Maximum distance coronas should appear in.
*''CoronaOffset'' - Offset of the coronas in the particles.
*''bCOffsetRelativeToRot'' - Whatever if corona offset should be relative to particle rotation.
'''EmRevolution''':
*''bRevolutionEnabled'' - Particle revolving should be enabled.
*''RevolutionOffset'' - Revolving offset for the particles.
*''RevolutionsPerSec'' - Revolving speed.
'''EmVisuals''':
*''ParticleTextures'' - Random/Animation sprite frames for particles.
*''bUseRandomTex'' - Should use random frame or else animate the textures.
*''ParticleStyle'' - The style of the particles.
*''StartingScale'' - Starting scale of the particles.
*''TimeScale'' - Time scaling of the particles (timescale 0-1).
*''PartSpriteForwardZ'' - The particles render forward Z (render trick).
*''ParticleColor'' - The color of the particles.
*''ParticleColorScale'' - Color time scaling.
'''EmFade:'''
*''FadeInTime'' - Fade in time scale (0-1).
*''FadeOutTime'' - Fade out start time (0-1).
*''FadeInMaxAmount'' - Max. scale glow when fully faded in (0-2).
'''EmPosition:'''
*''SpawnPosType'' - Should use Box/Sphere/Cylinder spawn offset?
*''BoxLocation'' - Box spawning offset for particles.
*''SphereCylinderRange'' - Sphere/Cylinder offset range.
*''bRelativeToRotation'' - Spawning offset should be in relative to actor rotation.
*''bUseRelativeLocation'' - All particles location/rotation/velocity should be relative to actor?
'''EmTrigger:'''
*''TriggerAction'' - Emitter actor triggering action.
*''SpawnParts'' - If spawn particles, then how many?
'''EmSpeed:'''
*''SpeedScale'' - Particles speed scale in relative time (0-1).
*''ParticleAcceleration'' - Particles acceleration range.
*''SpawnVelType'' - Whatever it should use Box/Sphere/Cylinder velocity for the particle.
*''BoxVelocity'' - Box velocity for particles.
*''SphereCylVelocity'' - Sphere/Cylinder range.
*''bVelRelativeToRotation'' - Velocity should be relative to actor rotation?
*''bCylRangeBasedOnPos'' - Sphere/Cylinder velocity range should be relative to particle spawn offset?
'''EmCollision''':
*''ParticleCollision'' - Collision type: Nothing/Walls/All Actors/Projectile target actors.
*''ParticleExtent'' - Particle collision size.
*''ParticleBounchyness'' - Bounchyness of the particles (when hitting wall/actor).
'''EmSound:'''
*''ImpactSound'' - Particle impact sound (when hitting wall/actor).
*''SpawnSound'' - Particle spawn sound.
*''DestroySound'' - Particle destroy sound.
'''EmMeshPos:'''
*''UseActorCoords'' - Use this mesh actor's vertex points positions.
*''VertexLimitBBox'' - Box limitation of which vertexes it should only emit in.
*''SingleIVert'' - Single vertex number it should emit on.
*''bUseMeshAnim'' - Whatever if it should use animated frame rather than first static frame (slower option).
'''EmCombiner:'''
*''ParticleSpawnTag'' - Combiner emitter which should spawn an own particle at newly spawned particles position.
*''SpawnCombiner'' - Instanced version of a spawn combiner emitter.
*''ParticleKillTag'' - Combiner emitter which should spawn an own particle at a newly destructed particle position.
*''KillCombiner'' - Instanced version of a kill combiner emitter.
*''ParticleWallHitTag'' - Same as above except spawn at the point where particles hit a wall.
*''WallHitCombiner'' - Instanced version of a wallhit combiner emitter.
*''ParticleLifeTimeTag'' - Same as above except spawn particles constantly at the living particles.
*''LifeTimeCombiner'' - Instanced version of a lifespan combiner emitter.
*''ParticleLifeTimeSDelay'' - The time delay how often lifespan particles should be spawned.
*''CombinedParticleCount'' - When this emitter actor is being used as combiner emitter, spawn this many particles on my combining emitter actor.
*''IdleCombiner'' - An emitter that is simply idle and doesn't interact with other emitters (useful for multi-emitter effect on trigger).
*''ParticleTrail'' - Trail that should appear for each particle.
'''EmForces:'''
*''ForcesTags'' - The tags of the emitter force actors that should be applied on our particles.
'''EmPhysX:'''
*''bEnablePhysX'' - Enable PhysX simulation for particles (Movement - PhysicsData must also be set).
=== Sprite Emitter ===
Basically the same as Emitter, but supports rotating particles.
'''EmRotation:'''
*''RotationsPerSec'' - How fast the particles should rotate.
*''InitialRot'' - The initial rotation of the particles.
*''RotNormal'' - For specific particle direction.
*''ParticleRotation'' - Type of direction the particles should have (i.e.: face the direction they are flying or face normal direction).
*''RotateByVelocityScale'' - If non-zero, RotationsPerSec is scaled by current velocity multiplied by this value.
=== Mesh Emitter ===
This emitter's particles are rendered as meshes and can even be animated.
'''EmMesh:'''
*''ParticleMesh'' - Display mesh of the particle.
*''bRenderParticles'' - Should render mesh in "bParticles".
*''bParticlesRandFrame'' - Should particles mesh use random texture animation frame.
*'''EmRotation:'''
*''ParticleRotation'' - Particles rotation type.
*''bRelativeToMoveDir'' - Particles should have rotation relative to movement direction.
*''RotationsPerSec'' - Rotation rate of particles.
*''InitialRot'' - Initial rotation of the particles.
*'''EmAnim:'''
*''bAnimateParticles'' - Particles should animate.
*''ParticleAnim'' - Particle animation sequence.
*''PartAnimRate'' - Particle animation rate.
*''bPartAnimLoop'' - Particle should loop animation.
=== Weather Emitter ===
[[File:Riot.jpg|350px|thumb|right|A WeatherEmitter used to spawn rain in a realistic fashion (map [http://hellkeeper.net/maps.php DmRiot]).]]
Allows the introduction of weather effects such as rain, snow, falls of dust, hail and so on. This actor is specifically designed to spawn falling sprites. It holds significant advantages over other emitters regarding weather conditions, such as not spawning a huge amount of sprites over the entire affected zone, but only in a limited radius around the player to mimic weather without being too much of a strain on the engine.
This is a '''directional''' actor: when added to the map, its rotation is shown by a red arrow and is very important to determine many things. For a Weather Emitter, the direction of the arrow is the direction into which weather effects "''fall''". Though usually, it will be directed to the ground, more or less inclined (to imitate, for example, falling rain), it is possible to have rain "falling" from the ground to the sky if you need such an effect.
A regular '''Particle Emitter''' is assigned a ''radius'' or a ''box'' - by the mapper - in which particles are spawned. The '''Lifetime''' of the particles spawned are used to determine how far they travel before being destroyed. This is an intuitive way of doing things, but its drawback when using effects on large areas is that a great number of particles will have to be spawned to cover the entire zone. Even modern computers may be brought to their knees given a sufficiently lush emitter covering huge... tracts of land. For rain, snow or such effects, which may cover ''entire maps'' and always be visible somewhere, this is simply not an option, as the number of particles would be so high playing the game would be like watching grandma's slideshow - if the engine does not simply give up on trying before crashing.
The '''WeatherEmitter''', on the other hand, tackles this issue in an efficient way: instead of spawning particles all over the map, a weather emitter is assigned a volume or an entire zone. When a player enters the zone, ''particles are spawned '''only around them''' in order to give them the illusion that rain is actually falling''. Picture players running around, each one surrounded by their own cube of falling particles visible only to them: because all players see rain falling around, they believe the whole map is covered rainy. In fact, '''only a few hundred particles are spawned''' around them. When sufficiently far away from the zone or volume in which rain is spawned, the player will see nothing; when running towards the rainy zone, they will see rain slowly appearing in the distance and gain density and opacity, exactly as one would while getting closer and closer to a window.
When added to the map, the '''WeatherEmitter''' is displayed as a small cloud with rain drops falling out from it. The first step in creating realistic weather conditions is to rotate it so that it is oriented in the direction the rain, snow or whatever you want to spawn, is falling. If you activate RealTime Preview, you may notice that it already spawns the traditional pawn actor texture.
All the properties of the WeatherEmitter are in the ''XWeatherEmitter'' tab of its properties. All property names are quite self-explanatory, and a quick look at the XWeatherEmitter code can give you hints if needed. The WeatherEmitter is very easy to use and can pretty much be used with its default properties when provided with a rain texture.
[[File:WeatherSpawning.png|350px|thumb|right|Sprites are spawned by the WeatherEmitter in a cube around the player.]]
'''EmWeather:'''
*'''AppearArea''': Default: all 0; This property lets you define a volume with Min and Max coordinates on all axis. The defined box will be the volume '''in which it is raining'''. A player standing outside of the volume will be able to see rain falling inside the volume. As explained above, there will not be a constant stream of particles spawned all over the box; particles will be created in the parts of a cube around the player which are inside the volume or zone in which the rain is spawned. See the illustration. '''For this parameter to be active, ''AppearAreaType'' must be set to EWA_Box'''.
*'''ApearAreaType''': Default EWA_Zone; Decides the spawning of particles either in the entire zone where the WeatherEmitter is located (determined by portals and zoneinfos) with EWA_Zone, or in a determined volume specified in '''AppearArea'''.
*'''FadeOutDistance''': Default 0- 650; Rain is spawned in a cubic volume around the player. The particles spawned very close to the player are almost totally opaque; the particles at the limit of the volume are almost totally translucent. Between these two extremes, particles are more or less opaque depending on the distance between them and the player. These Min and Max settings decide the distance at which the particles ''start'' to become translucent (min) and are ''totally'' invisible (max).
*'''LifeTime''': Default, 0.4 - 0.7 : the lifetime of a single particle in seconds.
*'''ParticleCount''': Default, 250; how many particles are spawned.
*'''ParticleColor''': Default: all 0; Colours of the particles: X is Red, Y is Green and Z is Blue. You set mins and maxs to all in order to have several colours or several variations of one colour.
*'''PartStyle''': Default STY_Translucent: Style of particles. Like most sprites, it should mostly remain on Translucent, but Masked may be useful.
*'''PartTextures''': The texture used on sprites. You can add up to 8 different textures to spawn multiple different sprites.
*'''Position''': Default: X: -50;200, Y -200;200, Z -50;400: this is the series of parameters that determines the size of the cube around a player (see illustration).
*'''Size''': Default 0.15-0.2; The size of particles, 1 being the full size of the texture.
*'''Speed''': Default 300-500; The speed of particles. The default values are good for rain. You might want to slow it down dramatically for snow or dust.
*'''WallHitEmitter''': spawns the particles of another emitter on impact. See below.
*'''WallHitEvent''' and '''WaterHitEvent''': Default, HIT_DoNothing; behaviour of the particles when hitting solid surfaces or water. ''HIT_DoNothing'' does nothing : the particle goes through the object. ''HIT_Destroy'' kills the particle on impact. ''HIT_Bounce'' will make particle bounce... Which can be very fun when the WeatherEmitter is strongly inclined. Otherwise, the fact that particle keep the same speed while bouncing makes it useless to simulate raindrops bouncing in the floor or such effects. ''HIT_Script'' calls a scripted event you may have created.
*'''WeatherType''' Default EWF_Rain:  how are the particles moving, what type of behaviour is it trying to mimic: ''EWF_Rain'' will rain the particles down, and the particles will be perpendicular to the direction of the WeatherEmitter. ''EWF_Snow'', once its speed is properly scaled down (say 30-50), sends particles slowly tumbling down with a slight swinging movement. ''EWF_Dust'' spawns particles with regular initial speed, but particles slow down until they reach total stilness. ''EWF_Neighter'' rains particles down much like EWF_Rain, but particles will always be facing the camera, not oriented accordingly to their velocity.
Note that no good texture for this effect does exist in stock Unreal packages. However, Rain textures can be as simples as a small white dash on a black background, which will give good result when made translucent and spawned to a nice speed (see DmRiot at the beginning of the page). Snow and Dust textures might be harder to create from scratch.
You can create interesting effects with WallHitEmitter. Its main use is for splashing effects for raindrops. By entering an emitter's tag in the WallHitEmitter field, each particle will spawn a particle of the target emitter on contact with walls or floors. If you use this effect on a large zone, make sure the source emitter has a high MaxParticles to limit the number of raindrops devoid of splash: think of this as stripping the target emitter of one of its particles to spawn it on the contact point: once too many particle shave been "stolen" from the target emitter, there is no longer anything to steal, and so remaining drops hitting the ground will not spawn anything.
The source emitter itself will keep emitting its own particles: it will not be deactivated while its particles are spawned by the WeatherEmitter. It might be a good idea to put the source emitter in a distant and hidden part of the map.
This effect can kill a map's performances by more or less doubling the number of particles on the screen. Be careful.
====Volumes Without Rain====
Regardless of the AppearAreaType you are using, you might have problems with rain going through walls, ledges, ceilings, and so on. You can fix this by adding an XRainRestrictionVolume. This actor defines a volume inside which rain particles will not pass. It will block weather effects from all WeatherEmitters, but can be set to only affect one WeatherEmitter by matching its tag to the WeatherEmitter's tag. Its only interesting properties are BoundsMax and BoundsMin which define the minimum and maximum boundaries of the volume.
By setting the XRainRestrictionVolume actor's bDirectional property to true, the actor can be made directional, and rotated in any way you want, unlike the WeatherEmitter iself, whose emission volume is always pefectly perpendicular to the grid. This allows the use of volumes which are not aligned on the grid, while attempting to something like this by zoning out the wanted parts would result in a large number of zones with odd angles.
=== Beam Emitter ===
=== Trail Emitter ===
=== Particle Forces ===
[[File:ParticleForcesSetting.png|350px|thumb|right|Notice the two blue lines linking the emitter to the two forces (map [http://hellkeeper.net/maps.php DmExar]). Notice that you can give the same tag to several forces and link them all at once in the emitter.]]
'''Particle Forces''' are new actors introduced by 227, designed to interact with a Particle Emitter.
'''EmForces:'''
*''KillParticleForce'' - Kills any nearby particles.
*''ParticleConcentrateForce'' - Concentrate all particles to fly toward this actor.
*''VelocityForce'' - Force particles to fly toward some specific direction.
ParticleForces are added to the map and linked to a ParticleEmitter. When an emitter is linked to a force, the behavior of its particles is modified whenever they enter the radius of the ParticleForce. KillParticle destroys particles. ParticleConcentrate acts a magnet, and the surrounding particles will be drawn towards the particle emitter or an offset point relative to it. VelocityForce modifies the speed at which the particles are moving.
To use a ParticleForce, add it to the map in the vicinity of a working emitter, and make sure you have activated the RealTime Preview. The classes you need to select in the ActorBrowser are the subclasses of '''XParticleForces*'''. When added to the map, it will affect nothing: to link it to an emitter, give the ParticleForce a tag, and in the properties of the emitter, under emForces, add the new tag to the list of ForcesTag. If you did it correctly, a line appears when the emitter (not the force) is selected, linking the forces to the emitter itself.
You can use a great number of forces on a single emitter by entering all their tags in the emForces list of the emitter. You can also give several forces the same tag without problem. You can also link several emitters to the same forces and have interesting interactions. '''Remember, however, that too many particles kills performance, so do not go overboard with them.'''
[[File:ParticleForces.jpg|350px|thumb|right|The three ParticleForces: from left to right, ''Velocity Particle'', ''ParticleConcentrate'' and ''KillParticle''.]]
All ParticleForces have the ''XParticleForces'' properties which are generic properties not dependant on the way the force itself acts.
* '''bEnabled''': Default True; Is the force active? You should not need to change this, except for testing purpose.
* '''bUseBoxForcePosition''': Default False; is set to False, the particles will be affected by the force when entering the spherical radius around the Force determined by the '''EffectingRadius''' property. If set to True, the particles will be affected when entering the box specified by the settings of '''EffectingBox'''.
* '''EffectingBox''': Default: all max to 200, all min to -200; Allows you to enter the boudaries of a box in which the particles will be affected instead of a radius. '''bUseBoxForcePosition''' must be set to true for this to have an impact.
* '''EffectingRadius''': Default 300; The size of the sphere in which the particles will be affected by the force. '''bUseBoxForcePosition''' must be set to False for this to have an impact.
* '''EffectPartLifeTime''': Default Min 0, Max 1; This property determines which particles are affected by the force: 0 is the moment a particle is spawned and 1 is the moment it is destroyed. A particle's lifetime is always ranged on such a 0-1 scale. If this property is set to Min 0.5, Max 1, only the particles that have lived half their lives will be affected. If you set it to Min 0, Max 0.5, particles will be affected from the moment they are spawned until they reach the middle of their lives.
==== ParticleConcentrateForce ====
[[File:BSetsAccelerationFalse.jpg|350px|thumb|right|bSetsAcceleration:'''False''']]
[[File:BSetsAccelerationTrue.jpg|350px|thumb|right|bSetsAcceleration:'''True''']]
The ParticleConcentrateForce sucks particles in its zone of effect towards a single point - by default, itself - and is the only ParticleForce to have its properties divided between two tabs, ''ParticleConcentrateForce'' and ''ParticleDistanceDrain''.
*'''bSetsAcceleration''': Default False; This property determines how the particles are affected. When set to False, the particles will acquire speed as they are drawn towards the force, race beyond the center of attraction and then continue there journey at their original speed in the new direction they have acquired from being accelerated towards the "magnet". If set to True, the particles will be affected by the force and acquire speed as they are drawn toward the force. This will not be ''speed'', but ''acceleration'', which means their absolute speed will keep on increasing. Eventually they will race out of the ParticleConcentrate's radius, but keep their speed '''and continue their curved journey at an increased pace.
*'''CenterPointOffset''': Default, none; By default, the particles are sucked towards the position of the ParticleForce itself. This property allows you to offset the center of attraction.
*'''DrainSpeed''': Default 200; Speed of the attraction. The higher the value, the more powerful the attraction.
==== ParticleDistanceDrain ====
*'''bActorDistanceSuckIn''': Default False; If set to true, the closer the particles are to the center of attraction, the stronger the force becomes. This pretty much cancels most of the properties of ''ParticleConcentrateForce'' and ''XParticleForces''.
*'''MaxDistance''': Default 0; Distance beyond which particles become totally unaffected by the force - this property is a radius setting specific to the ParticleConcentrateForce using the '''bActorDistanceSuckIn''' mode.
==== KillParticleForce ====
This ParticleForce is pretty simple: when an particle enters its radius, its lifetime is reduced. It has only one property under ''KillParticleForce'':
*'''LifeTimeDrainAmount''': Default 4; number of seconds by which the lifetime of the particle is reduced. If the number is superior to the remaining lifetime of the particle, it is destroyed immediately.
==== VelocityForce ====
[[File:InstantChangeFalse.png|200px|thumb|left|bChangeAcceleration: '''True'''; bInstantChange: '''False''']]
[[File:InstantChangeTrue.png|200px|thumb|right|bChangeAcceleration: '''True'''; bInstantChange: '''True''']]
When a particle enters the radius of the VelocityForce, its speed changes. The VelocityForce has only three properties under ''VelocityForce'':
*'''bChangeAcceleration''': Default, False; Changes the acceleration of the particle instead of its speed.
*'''bInstantChange''': Default, False; If set to True, the speed will be instantly used. If false, the velocity will be added to the current speed of the particle.
*'''VelocityToAdd''': Default: none; Velocity that will be added to the particle.
Because the two boolean values '''bChangeAcceleration''' and '''bInstantChange''' affect different variables of the particle's speed (its velocity and its acceleration), it is possible to have them interact. If InstantChange is True and Change Acceleration is false, any particle entering the radius of the VelocityForce will instantly lose any previous direction and speed and use the velocity specified in VelocityToAdd. If ChangeAcceleration is True and InstantChange is false, the particle will keep its current velocity but also drift away along the lines of VelocityToAdd. If Both are true, the particles entering the radius will keep their speed but also immediately start drifting away.
=== Triggering an Emitter ===
To add a triggerable emitter, create and set your emitter as desired. In emGeneral, set bDisabled to TRUE, so that it is not on by default, and make sure emTrigger has TriggerAction set to ToggleDisabled. Your effect is now set on and off by the triggering of the emitter via normal triggers. If you want your emitter to be on by default, simply put bDisabled to FALSE, so that the first triggering of the emitter will set it off.
You can also make your emitter emit only once after it is triggered. Set bDisabled to TRUE, and in the emitter properties, still in emGeneral, set bRespawnParticles to FALSE, so that after emitting the number of particles specified in MaxParticles, the emitter stops emitting. I recommend setting bAutoDestroy to true afterwards, so that the actor is destroyed in the game and does not use memory - useful if you have many such triggerable effects.
=== Spawning by bursts ===
If you want all the particles to be emitted at once when the emitter goes on - at the beginning of the game by default, or when triggered if set up this way -, simple set ParticlesPerSec to a huge number greatly superior to the MaxParticles value. If you want to emit 200 particles in one huge burst, set ParticlesPerSec to something like 5000. This will insure the game spawns your 200 particles as quickly as if it had to spawn these 5000 particles in the same second. As soon as one particle is destroyed, however, another one will be spawned, which means you will have several successive bursts. If your lifetime has a wide range (for example Max = 15 and Min = 5), the second burst will be much less immediate and may take some time, as the engine waits for one particle to die to spawn another one. If you want your bursts to be evenly spaced and of the same duration, make sure the difference betweent he Min and Max values of your particles' lifetime is very small or non-existent (same Min and Max). If you set bRespawnParticles to False with this template, your entire emitter will drop its entire load of particles in one go and then be useless - remember to set it to bAutoDestroy.
== Vegetation Generator ==
[[File:UIVegetationGenerator.png|350px|thumb|right]]
[[File:VegetationGenerated.jpg|350px|thumb|right|An area populated with plant meshes spawned by an UIVegetationGenerator]]
The Vegetation Generator spawns plant meshes around it at the beginning of the game to populate an area. A number of plants can be added to its list, the number and intensity of meshes specified, and various effect set up. On startup, the generator spawns random meshes from the list around itself at random locations and is then destroyed. It allows the designer to populate an area without adding each plant by hand. It slows down the launching of the map, however, and the plants are randomly spawned and cannot be precisely controlled.
The properties of the Vegetation Generator are divided into two main parts: the properties of the Vegetation Generator's own properties, as seen under UIVegetationGenerator, and the parameters for each plant added to the list in UIVegetationGenerator=>Plants. Up to 16 plants can be added and given specific parameters. Plants must be subclasses of the UIFlora class under Decoration. UIFlora actors are plants that make noise when stepped on.
*'''EffectArea''': where the plants are spawned around the UIVegetationGenerator actor.
*'''NumberOfErrors''': Number of meshes that can be spawned outside geometry.
*'''NumPlants''': Number of plants to choose in the list.
*'''Plants''': List of plants to spawn, and their specific parameters. See below.
*'''SelectionMethod''': Determines how plants are chosen. If set to SELECT_Linear, the generator will pick one plant from Plant1, then one from Plant2, and run down the list until it reaches the maximum number of plants it has to spawn. If set to SELECT_Random, the generator will randomly pick a plant everytime it adds a new one.
*'''VegetationIntensity''': This determines the number of plants to spawn per plant chosen in the list.
In order to determine the number of plants actually spawned, two values are important: NumPlants and VegetationIntensity. Simply put, NumPlants decides how many plants are chosen in the list, and VegetationIntensity decides how many of each selected plant is spawned. If NumPlants is 1 and VegetationIntensity is 5, the generator will spawn 5 plants of the type chosen by the generator (if SelectionMethod is SELECT_Linear, this means 5 plants of the [0] type).
If you have NumPlants = 3 and VegetationIntensity = 10, the generator will spawn 3*10=30 plants, equally distributed between plant types [0], [1] and [2] (again, assuming SelectionMethod is SELECT_Linear), even if you have specified 7 different types of plants.
Each plant can have specific properties determined in the Plants list.
== Visibility Notify ==
[[File:VisNotify.JPG|350px|thumb|right]]
Used to fix Network Replication with specific mirrors or WarpZones. By default, stuff reflected from mirror (that are normally behind a wall) or seen through WarpZones, are not considered as relevant actors in online games and will appear invisible.
In order to use it, place two (Actor -> Info ->) VisibilityNotify actors on both ends, set up a CollisionRadius/Height that covers up visible area of the both rooms and give them both '''same tag'''.
== Projectors ==
[[File:ProjectorsInUse.jpg|350px|thumb|right|Two projectors (one selected) used to display posters in [http://hellkeeper.net/maps.php DmRiot].]]
A '''Projector''' is exactly what its name suggests: something which projects images. Maps the texture it contains over all surfaces in its field of view. It can be used for light rays, posters, magical symbols glowing on stone arches and so on. A projector is assigned a texture, a ''field of view'' (FOV), and displays the texture in the desired direction. By adjusting its FOV, it will project the texture in a cone-like fashion (as a real light-projector), which means the projected image will be larger the further away the receiving surface is from the projector.
The actual actor used as projector is '''MapProjector''', a subclass of '''Projector'''. The other subclasses of the main projector class are intended for decals created by projectiles (think rocket blasts), shadows of decoration and the shadow of the player himself if real-time shadow is used. These actors are not meant for use in a map and cannot be placed.
The '''MapProjector'''  actor (from now on referred to as Projector) looks like a small white camera on a grey circle. After adding it to the map, you can see that it is directional and already has a zone of action: the white rectangular box before it. By moving the projector until the rectangle ends inside a wall, you can see it already projects the basic pawn icon.
By default, projectors project the same Pawn actor icon as most new 227 actors. The first step to create a nice projector is to change this. Select whatever you want in the texture browser, or import what you need, and in the MapProjector's properties, in the '''Projector''' tab, set your image in the appropriately named ProjectTexture. Immediately, the white box of projection (from now on referred to as the Projection Box) changes to match the size of your texture.
Notice that there are two tabs that will be relevant when dealing with MapProjectors' properties: '''MapProjector''' and '''Projector'''.
*'''OnlyAttachStaticActors''': Default, True: Determines whether or not the projection is displayed on moving actors going through the projection box. If set to False, the mover will receive the projection. If set to True, only non-moving objects will receive projections from this projector, and moving actors will be ignored. '''Notice however that [[Weapons|weapons]], [[Items|items]] and players will never be affected by projectors.''' This property is also not valid for movers based on brushes: only Static-Mesh-based movers are affected.
*'''IgnoreAttachActorTag''': Allows you to enter the tag of an actor that will not receive the projection. It can be a moving or still Static-Mesh or mesh, but it will have no incidence on Brushes.
To make things clear, a brush will always receive the projection, except if it is a brush-based mover - in which case it will never be subject to projection - Meshes and Static-Meshes will receive projection, except if the IgnoreAttachActorTag of the projector matches their tags. Movers made with static-meshes will need OnlyAttachStaticActors to be set to true to receive projection during their movement.
[[File:ProjectorFieldOfView.jpg|350px|thumb|right|Three projectors with the same with different '''FOVs'''.]]
[[File:ProjectorStyles.png|350px|thumb|right|Three projectors with different '''ProjectorStyles'''.]]
Most properties of the projector are in the '''projector''' tab. Here are properties to set the texture, the projection box and the size of the projection.
*'''bGradualFade''' makes the projection more or less opaque as the surface is more or less close to the projector. The texture is totally opaque at the projector level and gradually fades until the end of the projection box is reached (where the texture is 100% translucent).
*'''bProjectActors''': If set to true, allows the projection on meshes.
*'''bProjectBSP''': If set to true, allows the projection on BSP surfaces.
*'''bProjectBSPBackFaces''' and its corollary '''bProjectMeshBackFaces''' allow the projection on surfaces oriented in the same way as the projector. Usually, when you project a texture, the surface receiving the projection has an opposite direction to that of the projector: they are facing each other. Think of someone pointing a flashlight behind you: your back will be facing the flashlight and receiving the projection. Your face, however, is facing the same direction as the flashlight and thus remains in the shadow. When activating these two properties, even your face will be lit by the light, as if it went through you. it basically makes the projection appears on ''all'' surfaces between the projector and the end of projection box, not only the surfaces looking "at" the projector.
*'''bUseBetterActorAttach''': by default, this property is activated and allows the projector to use an accurate system for its projection. When set to false, it will use a slightly less accurate but less resource-intensive system. Performance gain, however, is negligible.
*'''FOV''': Field of Vision. By default, this setting is set to 0, and the projection box has the same width and height along its whole length. When the FOV goes up, the projection bow becomes a cone with a larger base. (see illustration).
*'''MaxDistance''': Maximum reach of the projection box in Unreal units.
*'''ProjectorScale''': Scale of the texture at the level of the projector actor, with 1 is the full size, 0.5 half the size and 2 double-size. This is the size at the projector level only, not the size of the projection (except if the Field of View is 0).
*'''ProjectStyle''': Style of display of the texture. STY_None and STY_Normal will simply display the texture as it is in the texture browser. STY_Masked uses the Alpha mask if set in the texture. STY_Translucent makes the dark parts of the texture transparent and the light parts opaque. STY_Modulated makes the dark parts of the texture opaque and the light parts transparent (the opposite of Translucent). STY_AlphaBlend uses the Alpha channel for special blending.
*'''ProjectTexture''': The texture that is projected.
[[File:ProjectionBoxes.jpg|350px|thumb|right]]
Some considerations:
* If a projector seems to be non-functional for no reason after loading a map in the editor, simply select the MapProjector.
* Even with RealTime Preview enabled, the white zone-of-effect box will not move around in the 3D viewport until you actually release the CTRL key to move the actor.
* '''Projectors do not have occlusion testing''': All surfaces facing the projector will have the texture mapped unto them, even if there is an obstacle in the way. Be careful when adjusting the MaxDistance setting of a projector to avoid finding projections repeated on objects behind a wall.
* Projectors may not work in Software mode. Use OpenGl for optimal results.
== DynamicZoneInfo ==
[[File:DynamicZoneInfo.png|350px|thumb|right]]
'''Dynamic ZoneInfo'''s are simply ZoneInfos that can be moved and spawned at will while playing. They come in handy to create effects such as rising water or temporary flooded or altered areas. They are not limited by portals and BSP, but act within a defined volume around the DynamicZoneInfo actor.
*'''bMoveForcesTouchUpdate''': forces the update of actors touching the zone when the DynamicZoneInfo moves or is altered.
*'''BoxMax''' and '''BoxMin''': define the size of the zone around the DynamicZoneInfo actor if the ZoneAreaType is DZONE_Cube.
*'''bUseRelativeToRotation''': the zone shape should be relative to dynamic zoneinfo's rotation.
*'''CylinderSize''': defines the ''height'' of the cylinder if the ZoneAreaType is DZone_Cylinder.
*'''MatchOnlyZone''': Write name of a BSP zoneinfo actor here to make the dynamic zoneinfo only effect inside that zone.
*'''SphereSize''': radius of the sphere if ZoneAreaType is DZONE_Sphere, or radius of the cylinder if ZoneAreaType is DZONE_Cylinder.
*'''ZoneAreaType''': zone of effect of the DynamicZoneInfo : Cube, Cylinder, Sphere, or SCRIPT to call Uscript events (warning : very slow).
The DynamicZoneInfo has subclasses equivalent to the ZoneInfo's subclasses: Nitrogen, Teleport, Water, Lava, Tar and Slime zones. They are similar to the static versions but have the benefits of movement and on-the-fly creation, as the DynamicZoneInfo.
== OGG Vorbis Music ==
Unreal v227j supports OGG music. Previously, you had to convert OGG tracks into the WAV format, then make ImpulseTracker files out of them, with the expected disadvantages such as loss quality, huge filesize etc etc... In contrast, plain OGG files high quality music files with a relatively small filesize.
In order to use your OGG music file in your map, follow these steps:
* Launch UnrealEd
* Go to the Music Browser
* File > Import... (File format: OGG (*.ogg))
* Open your file
* Save the music file and make use of it.
OGG tracks could also have loops set on them. In order to enable such support, make sure your OGG file has a comment along the lines of "|LOOP:0-100|", where 0 is the looping start point (% of the song) and 100 the looping end point (% of the song). Then just test it by listening to the song on UnrealEd.
== New commandlets ==
There are several new additions to the Unreal commandlet roster. The novelties can be found in the [[Commandlet]] page.
== Further reading (Wiki only section) ==
{{For|further information and questions about UnrealEd 2.0|Unreal v227 Manual/Frequently Asked Questions}}
A lot of articles and tutorials have been written for UnrealEd 2.0 by the very large UT99 community, but over the years, much of this content has been lost.
* [[Mapping|This wiki]] has several mapping tutorials.
* [http://www.hourences.com/tutorials/ Some tutorials] by Hourences can be found at the bottom of his page.
* And of course there's [https://wiki.beyondunreal.com the BeyondUnreal Wiki].
* [https://www.oldunreal.com/phpBB3/viewtopic.php?f=51&t=9337 Smirftsch's words about considerations to bear in mind when using StaticMeshes]
* [https://www.oldunreal.com/phpBB3/viewtopic.php?f=51&t=8998 Creavion's words about considerations to bear in mind when using all the new features]
* [https://www.oldunreal.com/phpBB3/viewtopic.php?f=33&t=3059 Creavion's hints, tips and tricks about the new features]
<!-- DEAD LINK * [http://www.birrabrothers.com/drac/ued2.html Drac] Has a complete set of tutorials for everything concerning Ued 2.0. -->
<!-- DEAD LINK * [http://lode.planetunreal.gamespy.com/ Lode] might be useful, especially his famous light tutorials. -->
Unfortunately, as they moved to newer versions of the Unreal Engine, a lot of writers just dropped their UEd 2.0 tutorials. In case you need more help, explanations or advice on how to do a particular thing or how to use a tool, ask on [https://www.oldunreal.com/phpBB3/ the OldUnreal forums].

Latest revision as of 00:29, 11 July 2022

Unreal v227 Manual
Main pageNew maps and itemsNew menu optionsVideo renderersAudio renderersServer admin toolsNew mod authoring toolsFrequently Asked Questions
Unreal v227 Manual
<- Previous Server admin tools
Next -> Frequently Asked Questions

Here we're going to take a look at the new features introduced by the v227 patch regarding mod authoring and editing.

UnrealEd 2.0

Introduction and history

UnrealEd 2.0 is the second version of UnrealEd. Unreal being the first game to use the Unreal Engine (in it's very first iteration) the included editor, UnrealEd (1.0), by the original developers' own admission, was an unsupported beta software developed in Visual Basic. The lack of certain tools prevented level-designers to achieve complex maps.

UnrealEd 2.0, originally introduced for UT99, is a rebuilt editor written in C++ later ported back to Unreal by Smirftsch in order to provide better tools for the community. Subsequent releases of patch 227, with extra involvement from the OldUnreal community, heavily improved the tools, stability and ease of use enough to deem it an almost different version: UnrealEd 2.1, similar in its looks, but significantly improved, with many bugs corrected, new functions and overall better stability.

UnrealEd 2.0 was introduced in Unreal by Patch 227f and replaced by UnrealEd 2.1 in 227h. All information on UnrealEd 2.0 works with 2.1, except for most known bugs and problems which have been fixed. UnrealEd 2 refers collectively to UnrealEd 2.0 and 2.1.

Interface

UnrealEd 2.x features a new and nicer interface

The interface was completely redesigned from UnrealEd 1.0 and is a lot more polished. First, the Browser isn't a sidebar anymore, but a set of dockable windows. When a browser is docked, it can be accessed from other docked windows without opening a new browser, keeping everything at hand. Only the main buttons have been kept on the left side, and the width of this sidebar reduced to two icons. This leaves plenty of extra space for the viewports themselves. These viewports are configurable, lockable and can be set to cover the entire screen if needed. The interface is very easy to configure and very comfortable, and was reused with almost no changes in UnrealEd 3.0 (the version that shipped with Unreal Tournament 2003 and Unreal Tournament 2004) and 4.0 (the version that shipped with Unreal Tournament 3) on later engines.

Features

The first appreciable features are located in the left-panel list of tools in UnrealEd: Sheer, Stretch and Scale have been ported from UnrealEd 1.0. A new button at the very end of the list allows you to align all 2D cameras on the camera of the 3D Viewport (if you have several 3D viewports, it will align all cameras on the camera of the last 3D viewport created). You can also now align textures on the X and Y axes just as well as with the Align To Floor tool by right-clicing a surface and choosing Align Selected => Align to wall around X/Y axis.

Among other things, UnrealEd 2 features a Vertex Editing tool which greatly increases the possibilities for designers by allowing them to move not only one vertex at a time but as many as they want.

The 2D shape editor is no longer a buggy beta implementation and can be used to create almost any shape without problems.

One notable feature is the possibility to use OpenGL and several versions of Direct3D rendering in the 3D viewport, which means you won't get surprised by how a map looks in the game compared to what the software rendering shows, as was sometimes the case in UnrealEd 1.0. Although the D3D implementations are not fully supported and might not be fully working, especially if you're using and ATI graphic card, they can be used without a lot of troubles. From 227g onwards, the OpenGL support is fully stable and supported.

Plug-Ins

Though there is no "plug-in" as you might know, UnrealEd 2.0 and 2.1 can both be enhanced and expanded by adding new buttons, new functions, new tools. On the provided screenshot at the top of the page, you may notice purple builder brushes. These are custom builder brushes, the Tarquin tools. A lot of tools have been created over time for UT99's UnrealEd 2.0 and are completely compatible with Unreal 227's UnrealEd 2.1: Quick camera alignment, new stairs builders, round shape creator, easy Skybox, etc...

Static Meshes

StaticMeshes are instanciated pieces of geometry which receive a basic lighting based on the light at each vertices of their triangles. They are only loaded once from your drive and, as a result, they are less memory-intensive. They are also invulnerable to BSP errors, HOMs and ther BSP-based problems, as well as not influencing BSP Cuts and supporting higher triangle counts without much problems. However, unlike their Unreal Engine 2 counterparts, they cannot be used as extensively, as the engine (Unreal Engine 1) will slow down drastically. It's still advised to use BSP for the simpler brushes. They were implemented in v227g.

In UnrealEd, they are displayed in the 2d viewports as green wireframe objects. When a Static Mesh is imported or created, it can be viewed in the Mesh Browser, where it has no animation or frame, provided the "Show StaticMeshes" bow is ticked. By default, the second option of the contextual menu when right-clicking in a viewport is the "add static-mesh here" option.

Advantages and Disadvantages over Semi-Solid Geometry

Because the Static Mesh is loaded as an actor, it needs to be loaded only once from the hard drive, and is then kept in memory, which means it is faster than an equivalent BSP object. Static Meshes are also invulnerable to BSP errors, HOMs and BSP Holes. It is not affected by BSP cuts and does not create them. They are easy to convert from format to format, can be edited in UnrealEd without problems. Other advantages are the end of U/V mapping limits which were common with Unreal Meshes (limited to one tile), the possibility to use either a simplified or a per polygon collision instead of the basic cylindrical collision radius of other meshes, and their adaptability: polygon flags can be set and adjusted in-editor from the mesh browser. They are faster to load and more efficient, as a loaded mesh stays in memory for the next time it will be needed.

However, they have also several disadvantages: Lighting is calculated differently from brushes, and in the same way it is calculated for meshes, which means complex shadows will usually not affect them, though they can still cast some. They may be glitchy in software mode and clutter the 3D Viewport if you don't use OpenGL or Direct3D rendering. Some bugs may also happen when a brush's pivot is inside a wall, corrupting lighting. It may force you to manually offset the pivot.

Supported conversions

UnrealEd 2.1 allows you to import .obj files as StaticMeshes. You can also create StaticMeshes from BSP by selecting some brushes, right-clicing on them and choosing Convert => To StaticMesh. StaticMeshes can only be additive constructions; if you convert subtracted brushes to static-meshes, they will be flipped and appear as additive and hollowed once converted.

You can convert static meshes between:

  • Brush -> Static Mesh
  • Static Mesh -> Brush
  • Any meshes + Brush -> Static Mesh
  • Export (Static) Mesh as Wavefront .OBJ
  • Import Static Mesh as Wavefront .OBJ

Because Meshes and Brushes can be converted directly into each other, it is possible to create a map with all its meshes inside UnrealEd without using any third-party 3D Software such as Maya or 3Ds Max. However, when doing so, the engine will triangulate - convert all surfaces into sets of triangles - the mesh itself, and may end up with some inefficient results regarding lighting, needing reworking by the designer.

Static Meshes as Movers

Any Static-Mesh can be added as any type of mover: when right-clicking on the Add Mover button in the toolbar, all Mover types can be added as brushes or meshes, using either the Mover or the Mover [mesh] option.

Simple collision model

Static meshes support simple collision model. To create one for a static mesh you do:

  • Add a static mesh to a level and move it to origin (1 scaling, 0 location and rotation).
  • Add simple brush shapes to cover up the parts you want to collide.
  • Now make sure red builder brush is at origin with 1 scaling and intersect the whole brush collision model you created.
  • Then right click on the static mesh actor and select "Create collision model".

Now if you enable "Show skeleton" in mesh browser you should see the simple collision model on the static mesh. To make game use it you can set on static mesh properties:

  • bUseSimpleBoxCollision - Meaning box collision checks (like pawn movement) should collide with the simple collision model.
  • bUseSimpleLineCollision - Meaning the same as above but for simple trace lines (like most projectiles or AI sight checks).

Using this gives performance advantage with complex static meshes as well as prevents you from getting stuck on complex parts of the mesh.

Other options in the mesh browsers include the Materials list, allowing you to instantly replace the textures of the static-mesh and the bFlipNormal boolean, which lets you instantly invert all the faces, so that all polygons visible from outward become visible from inward and vice-versa.

Jumpers (UJumpPad, UJumpPadEnd, UJumpDest)

Correct way to set up a Jumper

Jumpers are often the shortest way to move a player (after, maybe, a teleporter). It's an actor with a radius that throws the player in a given direction toward a given navigation point.

A jumper requires three actors: UJumpPad (NavigationPoint > LiftExit > UJumpPadEnd > UJumpPad), UJumpDest (NavigationPoint > LiftCenter > UJumpDest), and UJumpPadEnd (NavigationPoint > LiftExit > UJumpPadEnd).

  • Put the UJumpPad at the center of the pad.
  • Put the UJumpDest at the point the Jumper is aiming.
  • In the UJumpPad's properties, under the "LiftExit" tab, put something in "LiftTag" property (e.g. MyJumpPad, so LiftTag=MyJumpPad).
  • Put this same name in the UJumpDest's properties, "LiftCenter" tab, in the "LiftTag" field (LiftTag=MyJumpPad).

The point where the UJumpDest is will be the highest point of the pawn's trajectory in the air. If you rebuild and test your map at this point, you will notice that the jumper is working. If you do right-click => View => Show path in the title bar of the 3D viewport, you will see that a path connects the UJumpPad and the UJumpDest. But if you add further pathnodes, the UJumpDest won't be connected to the other paths. In order to allow bots to play normally:

  • Add a UJumpPadEnd at the end of the jump, at the point where the players are supposed to land.
  • In it's properties, LiftExit => LiftTag, put the same thing as you did previously for you UJumpPad and UJumpDest (LiftTag=MyJumpPad).
  • Add other pathnodes, rebuild and test.

The UJumpPad has an "UJumpPad" tab in its properties with a few parameters you can use to fine-tune it's behavior. The most important one is "JumpSound", where you can enter a sound that will be played when a player walks on the jumper (the sound of the jump boots is perfect for that). Other parameters include:

  • bForceFullAccuracy: aims perfectly at the UJumpDest, but may modifiy the speed of the jump
  • JumpZHeightModifier: allows the mapper to modify the height of the jump: a negative value will make the trajectory less high, while a higher value will send the player higher in the sky
  • JumpVelocityModifier: allows you to modify the speed of the player in much the same way.

The Jumper will work online. Bots can use the Jumpers provided you set up a UJumpPadEnd for them. Otherwise, strange behavior may happen (as they land outside of the paths). As the Jumper is a 227 feature, it can only be used on a 227 server or on a 227 installation of Unreal. It will make your map incompatible with previous versions of Unreal.

Bots seem to be quite incompetent with jumpers and will rarely use them, even when correctly set up. If you are in doubt, check the jumper in UnrealEd: If everything is set up as it should, the UJumpPad should be linked to the UJumpDest by a yellow line when selected. This was added in 227i.

Emitter System

The Unreal 227 Particle Emitter (XParticleEmitter > XEmitter) system is a potent tool introduced in v227a for mappers and modders. It allows the addition of a great deal of advanced effects into both environments and actors.

Note!
When creating Emitter subclasses for usage in UScript code, subclass the classes prepended with an X, such as XMeshEmitter etc. For placement in maps, use classes without the X such as Emitter, SpriteEmitter etc. Triggered emitters should use Network classes.

The Particle Emitter classes come in various flavors: Normal, Sprite (adds rotation support), Mesh, Weather and Beam. Since 227f, it is also possible to combine multiple emitters into one connected system using the Combiner properties.

Emitter

This is simplest form of particle emitter with the best in-game performance which can be used for most effects.

EmGeneral:

  • bDisabled - Emitter is disable, no more spawning new particles.
  • bRespawnParticles - Respawn particles that have died.
  • bAutoDestroy - Auto-destroy emitter actor after all particles have died (can be used for temp effects).
  • bAutoReset - Auto-reset emitter after all particles have died and AutoResetTime has passed.
  • bSpawnInitParticles - Spawn initial particles, or else wait for possible auto-reset (only when bRespawnParticles is false).
  • MaxParticles - Maximum amount of particles.
  • ParticlesPerSec - Amount of particles to spawn per second (0 = auto assign the value).
  • LifetimeRange - How long time particles should live.
  • StartupDelay - Delay in seconds before Emitter activates (can be used for triggered emitters to delay an effect).

EmVisibility:

  • bStasisEmitter - Similar to Actor bStasis, but stop hide particles once player isn't seeing the emitter's zone.
  • bBoxVisibility - If enabled, visibility box will be used.
  • VisibilityBox - Only update when any parts of this box radius is within player camera sight.
  • bDistanceCulling - If enabled, use distance culling.
  • CullDistance - If player camera is beyond this distance, don't render.
  • bNoUpdateOnInvis - When not rendering emitter actor, do not update the particles either.

EmCorona:

  • CoronaColor - Corona color range.
  • CoronaTexture - Corona texture.
  • bCheckLineOfSight - Should coronas disappear when behind some wall?
  • bParticleCoronaEnabled - Whatever if particle coronas are enabled.
  • CoronaFadeTimeScale - The time it will take for coronas to fade in/out when falling out of sight or back in sight.
  • CoronaMaxScale - Maximum corona scaling.
  • CoronaScaling - The scale of the coronas.
  • MaxCoronaDistance - Maximum distance coronas should appear in.
  • CoronaOffset - Offset of the coronas in the particles.
  • bCOffsetRelativeToRot - Whatever if corona offset should be relative to particle rotation.

EmRevolution:

  • bRevolutionEnabled - Particle revolving should be enabled.
  • RevolutionOffset - Revolving offset for the particles.
  • RevolutionsPerSec - Revolving speed.

EmVisuals:

  • ParticleTextures - Random/Animation sprite frames for particles.
  • bUseRandomTex - Should use random frame or else animate the textures.
  • ParticleStyle - The style of the particles.
  • StartingScale - Starting scale of the particles.
  • TimeScale - Time scaling of the particles (timescale 0-1).
  • PartSpriteForwardZ - The particles render forward Z (render trick).
  • ParticleColor - The color of the particles.
  • ParticleColorScale - Color time scaling.

EmFade:

  • FadeInTime - Fade in time scale (0-1).
  • FadeOutTime - Fade out start time (0-1).
  • FadeInMaxAmount - Max. scale glow when fully faded in (0-2).

EmPosition:

  • SpawnPosType - Should use Box/Sphere/Cylinder spawn offset?
  • BoxLocation - Box spawning offset for particles.
  • SphereCylinderRange - Sphere/Cylinder offset range.
  • bRelativeToRotation - Spawning offset should be in relative to actor rotation.
  • bUseRelativeLocation - All particles location/rotation/velocity should be relative to actor?

EmTrigger:

  • TriggerAction - Emitter actor triggering action.
  • SpawnParts - If spawn particles, then how many?

EmSpeed:

  • SpeedScale - Particles speed scale in relative time (0-1).
  • ParticleAcceleration - Particles acceleration range.
  • SpawnVelType - Whatever it should use Box/Sphere/Cylinder velocity for the particle.
  • BoxVelocity - Box velocity for particles.
  • SphereCylVelocity - Sphere/Cylinder range.
  • bVelRelativeToRotation - Velocity should be relative to actor rotation?
  • bCylRangeBasedOnPos - Sphere/Cylinder velocity range should be relative to particle spawn offset?

EmCollision:

  • ParticleCollision - Collision type: Nothing/Walls/All Actors/Projectile target actors.
  • ParticleExtent - Particle collision size.
  • ParticleBounchyness - Bounchyness of the particles (when hitting wall/actor).

EmSound:

  • ImpactSound - Particle impact sound (when hitting wall/actor).
  • SpawnSound - Particle spawn sound.
  • DestroySound - Particle destroy sound.

EmMeshPos:

  • UseActorCoords - Use this mesh actor's vertex points positions.
  • VertexLimitBBox - Box limitation of which vertexes it should only emit in.
  • SingleIVert - Single vertex number it should emit on.
  • bUseMeshAnim - Whatever if it should use animated frame rather than first static frame (slower option).

EmCombiner:

  • ParticleSpawnTag - Combiner emitter which should spawn an own particle at newly spawned particles position.
  • SpawnCombiner - Instanced version of a spawn combiner emitter.
  • ParticleKillTag - Combiner emitter which should spawn an own particle at a newly destructed particle position.
  • KillCombiner - Instanced version of a kill combiner emitter.
  • ParticleWallHitTag - Same as above except spawn at the point where particles hit a wall.
  • WallHitCombiner - Instanced version of a wallhit combiner emitter.
  • ParticleLifeTimeTag - Same as above except spawn particles constantly at the living particles.
  • LifeTimeCombiner - Instanced version of a lifespan combiner emitter.
  • ParticleLifeTimeSDelay - The time delay how often lifespan particles should be spawned.
  • CombinedParticleCount - When this emitter actor is being used as combiner emitter, spawn this many particles on my combining emitter actor.
  • IdleCombiner - An emitter that is simply idle and doesn't interact with other emitters (useful for multi-emitter effect on trigger).
  • ParticleTrail - Trail that should appear for each particle.

EmForces:

  • ForcesTags - The tags of the emitter force actors that should be applied on our particles.

EmPhysX:

  • bEnablePhysX - Enable PhysX simulation for particles (Movement - PhysicsData must also be set).

Sprite Emitter

Basically the same as Emitter, but supports rotating particles.

EmRotation:

  • RotationsPerSec - How fast the particles should rotate.
  • InitialRot - The initial rotation of the particles.
  • RotNormal - For specific particle direction.
  • ParticleRotation - Type of direction the particles should have (i.e.: face the direction they are flying or face normal direction).
  • RotateByVelocityScale - If non-zero, RotationsPerSec is scaled by current velocity multiplied by this value.

Mesh Emitter

This emitter's particles are rendered as meshes and can even be animated.

EmMesh:

  • ParticleMesh - Display mesh of the particle.
  • bRenderParticles - Should render mesh in "bParticles".
  • bParticlesRandFrame - Should particles mesh use random texture animation frame.
  • EmRotation:
  • ParticleRotation - Particles rotation type.
  • bRelativeToMoveDir - Particles should have rotation relative to movement direction.
  • RotationsPerSec - Rotation rate of particles.
  • InitialRot - Initial rotation of the particles.
  • EmAnim:
  • bAnimateParticles - Particles should animate.
  • ParticleAnim - Particle animation sequence.
  • PartAnimRate - Particle animation rate.
  • bPartAnimLoop - Particle should loop animation.

Weather Emitter

A WeatherEmitter used to spawn rain in a realistic fashion (map DmRiot).

Allows the introduction of weather effects such as rain, snow, falls of dust, hail and so on. This actor is specifically designed to spawn falling sprites. It holds significant advantages over other emitters regarding weather conditions, such as not spawning a huge amount of sprites over the entire affected zone, but only in a limited radius around the player to mimic weather without being too much of a strain on the engine.

This is a directional actor: when added to the map, its rotation is shown by a red arrow and is very important to determine many things. For a Weather Emitter, the direction of the arrow is the direction into which weather effects "fall". Though usually, it will be directed to the ground, more or less inclined (to imitate, for example, falling rain), it is possible to have rain "falling" from the ground to the sky if you need such an effect.

A regular Particle Emitter is assigned a radius or a box - by the mapper - in which particles are spawned. The Lifetime of the particles spawned are used to determine how far they travel before being destroyed. This is an intuitive way of doing things, but its drawback when using effects on large areas is that a great number of particles will have to be spawned to cover the entire zone. Even modern computers may be brought to their knees given a sufficiently lush emitter covering huge... tracts of land. For rain, snow or such effects, which may cover entire maps and always be visible somewhere, this is simply not an option, as the number of particles would be so high playing the game would be like watching grandma's slideshow - if the engine does not simply give up on trying before crashing.

The WeatherEmitter, on the other hand, tackles this issue in an efficient way: instead of spawning particles all over the map, a weather emitter is assigned a volume or an entire zone. When a player enters the zone, particles are spawned only around them in order to give them the illusion that rain is actually falling. Picture players running around, each one surrounded by their own cube of falling particles visible only to them: because all players see rain falling around, they believe the whole map is covered rainy. In fact, only a few hundred particles are spawned around them. When sufficiently far away from the zone or volume in which rain is spawned, the player will see nothing; when running towards the rainy zone, they will see rain slowly appearing in the distance and gain density and opacity, exactly as one would while getting closer and closer to a window.

When added to the map, the WeatherEmitter is displayed as a small cloud with rain drops falling out from it. The first step in creating realistic weather conditions is to rotate it so that it is oriented in the direction the rain, snow or whatever you want to spawn, is falling. If you activate RealTime Preview, you may notice that it already spawns the traditional pawn actor texture.

All the properties of the WeatherEmitter are in the XWeatherEmitter tab of its properties. All property names are quite self-explanatory, and a quick look at the XWeatherEmitter code can give you hints if needed. The WeatherEmitter is very easy to use and can pretty much be used with its default properties when provided with a rain texture.

Sprites are spawned by the WeatherEmitter in a cube around the player.

EmWeather:

  • AppearArea: Default: all 0; This property lets you define a volume with Min and Max coordinates on all axis. The defined box will be the volume in which it is raining. A player standing outside of the volume will be able to see rain falling inside the volume. As explained above, there will not be a constant stream of particles spawned all over the box; particles will be created in the parts of a cube around the player which are inside the volume or zone in which the rain is spawned. See the illustration. For this parameter to be active, AppearAreaType must be set to EWA_Box.
  • ApearAreaType: Default EWA_Zone; Decides the spawning of particles either in the entire zone where the WeatherEmitter is located (determined by portals and zoneinfos) with EWA_Zone, or in a determined volume specified in AppearArea.
  • FadeOutDistance: Default 0- 650; Rain is spawned in a cubic volume around the player. The particles spawned very close to the player are almost totally opaque; the particles at the limit of the volume are almost totally translucent. Between these two extremes, particles are more or less opaque depending on the distance between them and the player. These Min and Max settings decide the distance at which the particles start to become translucent (min) and are totally invisible (max).
  • LifeTime: Default, 0.4 - 0.7 : the lifetime of a single particle in seconds.
  • ParticleCount: Default, 250; how many particles are spawned.
  • ParticleColor: Default: all 0; Colours of the particles: X is Red, Y is Green and Z is Blue. You set mins and maxs to all in order to have several colours or several variations of one colour.
  • PartStyle: Default STY_Translucent: Style of particles. Like most sprites, it should mostly remain on Translucent, but Masked may be useful.
  • PartTextures: The texture used on sprites. You can add up to 8 different textures to spawn multiple different sprites.
  • Position: Default: X: -50;200, Y -200;200, Z -50;400: this is the series of parameters that determines the size of the cube around a player (see illustration).
  • Size: Default 0.15-0.2; The size of particles, 1 being the full size of the texture.
  • Speed: Default 300-500; The speed of particles. The default values are good for rain. You might want to slow it down dramatically for snow or dust.
  • WallHitEmitter: spawns the particles of another emitter on impact. See below.
  • WallHitEvent and WaterHitEvent: Default, HIT_DoNothing; behaviour of the particles when hitting solid surfaces or water. HIT_DoNothing does nothing : the particle goes through the object. HIT_Destroy kills the particle on impact. HIT_Bounce will make particle bounce... Which can be very fun when the WeatherEmitter is strongly inclined. Otherwise, the fact that particle keep the same speed while bouncing makes it useless to simulate raindrops bouncing in the floor or such effects. HIT_Script calls a scripted event you may have created.
  • WeatherType Default EWF_Rain: how are the particles moving, what type of behaviour is it trying to mimic: EWF_Rain will rain the particles down, and the particles will be perpendicular to the direction of the WeatherEmitter. EWF_Snow, once its speed is properly scaled down (say 30-50), sends particles slowly tumbling down with a slight swinging movement. EWF_Dust spawns particles with regular initial speed, but particles slow down until they reach total stilness. EWF_Neighter rains particles down much like EWF_Rain, but particles will always be facing the camera, not oriented accordingly to their velocity.

Note that no good texture for this effect does exist in stock Unreal packages. However, Rain textures can be as simples as a small white dash on a black background, which will give good result when made translucent and spawned to a nice speed (see DmRiot at the beginning of the page). Snow and Dust textures might be harder to create from scratch.

You can create interesting effects with WallHitEmitter. Its main use is for splashing effects for raindrops. By entering an emitter's tag in the WallHitEmitter field, each particle will spawn a particle of the target emitter on contact with walls or floors. If you use this effect on a large zone, make sure the source emitter has a high MaxParticles to limit the number of raindrops devoid of splash: think of this as stripping the target emitter of one of its particles to spawn it on the contact point: once too many particle shave been "stolen" from the target emitter, there is no longer anything to steal, and so remaining drops hitting the ground will not spawn anything. The source emitter itself will keep emitting its own particles: it will not be deactivated while its particles are spawned by the WeatherEmitter. It might be a good idea to put the source emitter in a distant and hidden part of the map.

This effect can kill a map's performances by more or less doubling the number of particles on the screen. Be careful.

Volumes Without Rain

Regardless of the AppearAreaType you are using, you might have problems with rain going through walls, ledges, ceilings, and so on. You can fix this by adding an XRainRestrictionVolume. This actor defines a volume inside which rain particles will not pass. It will block weather effects from all WeatherEmitters, but can be set to only affect one WeatherEmitter by matching its tag to the WeatherEmitter's tag. Its only interesting properties are BoundsMax and BoundsMin which define the minimum and maximum boundaries of the volume.

By setting the XRainRestrictionVolume actor's bDirectional property to true, the actor can be made directional, and rotated in any way you want, unlike the WeatherEmitter iself, whose emission volume is always pefectly perpendicular to the grid. This allows the use of volumes which are not aligned on the grid, while attempting to something like this by zoning out the wanted parts would result in a large number of zones with odd angles.

Beam Emitter

Trail Emitter

Particle Forces

Notice the two blue lines linking the emitter to the two forces (map DmExar). Notice that you can give the same tag to several forces and link them all at once in the emitter.

Particle Forces are new actors introduced by 227, designed to interact with a Particle Emitter.

EmForces:

  • KillParticleForce - Kills any nearby particles.
  • ParticleConcentrateForce - Concentrate all particles to fly toward this actor.
  • VelocityForce - Force particles to fly toward some specific direction.

ParticleForces are added to the map and linked to a ParticleEmitter. When an emitter is linked to a force, the behavior of its particles is modified whenever they enter the radius of the ParticleForce. KillParticle destroys particles. ParticleConcentrate acts a magnet, and the surrounding particles will be drawn towards the particle emitter or an offset point relative to it. VelocityForce modifies the speed at which the particles are moving.

To use a ParticleForce, add it to the map in the vicinity of a working emitter, and make sure you have activated the RealTime Preview. The classes you need to select in the ActorBrowser are the subclasses of XParticleForces*. When added to the map, it will affect nothing: to link it to an emitter, give the ParticleForce a tag, and in the properties of the emitter, under emForces, add the new tag to the list of ForcesTag. If you did it correctly, a line appears when the emitter (not the force) is selected, linking the forces to the emitter itself.

You can use a great number of forces on a single emitter by entering all their tags in the emForces list of the emitter. You can also give several forces the same tag without problem. You can also link several emitters to the same forces and have interesting interactions. Remember, however, that too many particles kills performance, so do not go overboard with them.

The three ParticleForces: from left to right, Velocity Particle, ParticleConcentrate and KillParticle.

All ParticleForces have the XParticleForces properties which are generic properties not dependant on the way the force itself acts.

  • bEnabled: Default True; Is the force active? You should not need to change this, except for testing purpose.
  • bUseBoxForcePosition: Default False; is set to False, the particles will be affected by the force when entering the spherical radius around the Force determined by the EffectingRadius property. If set to True, the particles will be affected when entering the box specified by the settings of EffectingBox.
  • EffectingBox: Default: all max to 200, all min to -200; Allows you to enter the boudaries of a box in which the particles will be affected instead of a radius. bUseBoxForcePosition must be set to true for this to have an impact.
  • EffectingRadius: Default 300; The size of the sphere in which the particles will be affected by the force. bUseBoxForcePosition must be set to False for this to have an impact.
  • EffectPartLifeTime: Default Min 0, Max 1; This property determines which particles are affected by the force: 0 is the moment a particle is spawned and 1 is the moment it is destroyed. A particle's lifetime is always ranged on such a 0-1 scale. If this property is set to Min 0.5, Max 1, only the particles that have lived half their lives will be affected. If you set it to Min 0, Max 0.5, particles will be affected from the moment they are spawned until they reach the middle of their lives.

ParticleConcentrateForce

bSetsAcceleration:False
bSetsAcceleration:True

The ParticleConcentrateForce sucks particles in its zone of effect towards a single point - by default, itself - and is the only ParticleForce to have its properties divided between two tabs, ParticleConcentrateForce and ParticleDistanceDrain.

  • bSetsAcceleration: Default False; This property determines how the particles are affected. When set to False, the particles will acquire speed as they are drawn towards the force, race beyond the center of attraction and then continue there journey at their original speed in the new direction they have acquired from being accelerated towards the "magnet". If set to True, the particles will be affected by the force and acquire speed as they are drawn toward the force. This will not be speed, but acceleration, which means their absolute speed will keep on increasing. Eventually they will race out of the ParticleConcentrate's radius, but keep their speed and continue their curved journey at an increased pace.
  • CenterPointOffset: Default, none; By default, the particles are sucked towards the position of the ParticleForce itself. This property allows you to offset the center of attraction.
  • DrainSpeed: Default 200; Speed of the attraction. The higher the value, the more powerful the attraction.

ParticleDistanceDrain

  • bActorDistanceSuckIn: Default False; If set to true, the closer the particles are to the center of attraction, the stronger the force becomes. This pretty much cancels most of the properties of ParticleConcentrateForce and XParticleForces.
  • MaxDistance: Default 0; Distance beyond which particles become totally unaffected by the force - this property is a radius setting specific to the ParticleConcentrateForce using the bActorDistanceSuckIn mode.

KillParticleForce

This ParticleForce is pretty simple: when an particle enters its radius, its lifetime is reduced. It has only one property under KillParticleForce:

  • LifeTimeDrainAmount: Default 4; number of seconds by which the lifetime of the particle is reduced. If the number is superior to the remaining lifetime of the particle, it is destroyed immediately.

VelocityForce

bChangeAcceleration: True; bInstantChange: False
bChangeAcceleration: True; bInstantChange: True

When a particle enters the radius of the VelocityForce, its speed changes. The VelocityForce has only three properties under VelocityForce:

  • bChangeAcceleration: Default, False; Changes the acceleration of the particle instead of its speed.
  • bInstantChange: Default, False; If set to True, the speed will be instantly used. If false, the velocity will be added to the current speed of the particle.
  • VelocityToAdd: Default: none; Velocity that will be added to the particle.

Because the two boolean values bChangeAcceleration and bInstantChange affect different variables of the particle's speed (its velocity and its acceleration), it is possible to have them interact. If InstantChange is True and Change Acceleration is false, any particle entering the radius of the VelocityForce will instantly lose any previous direction and speed and use the velocity specified in VelocityToAdd. If ChangeAcceleration is True and InstantChange is false, the particle will keep its current velocity but also drift away along the lines of VelocityToAdd. If Both are true, the particles entering the radius will keep their speed but also immediately start drifting away.

Triggering an Emitter

To add a triggerable emitter, create and set your emitter as desired. In emGeneral, set bDisabled to TRUE, so that it is not on by default, and make sure emTrigger has TriggerAction set to ToggleDisabled. Your effect is now set on and off by the triggering of the emitter via normal triggers. If you want your emitter to be on by default, simply put bDisabled to FALSE, so that the first triggering of the emitter will set it off.

You can also make your emitter emit only once after it is triggered. Set bDisabled to TRUE, and in the emitter properties, still in emGeneral, set bRespawnParticles to FALSE, so that after emitting the number of particles specified in MaxParticles, the emitter stops emitting. I recommend setting bAutoDestroy to true afterwards, so that the actor is destroyed in the game and does not use memory - useful if you have many such triggerable effects.

Spawning by bursts

If you want all the particles to be emitted at once when the emitter goes on - at the beginning of the game by default, or when triggered if set up this way -, simple set ParticlesPerSec to a huge number greatly superior to the MaxParticles value. If you want to emit 200 particles in one huge burst, set ParticlesPerSec to something like 5000. This will insure the game spawns your 200 particles as quickly as if it had to spawn these 5000 particles in the same second. As soon as one particle is destroyed, however, another one will be spawned, which means you will have several successive bursts. If your lifetime has a wide range (for example Max = 15 and Min = 5), the second burst will be much less immediate and may take some time, as the engine waits for one particle to die to spawn another one. If you want your bursts to be evenly spaced and of the same duration, make sure the difference betweent he Min and Max values of your particles' lifetime is very small or non-existent (same Min and Max). If you set bRespawnParticles to False with this template, your entire emitter will drop its entire load of particles in one go and then be useless - remember to set it to bAutoDestroy.

Vegetation Generator

UIVegetationGenerator.png
An area populated with plant meshes spawned by an UIVegetationGenerator

The Vegetation Generator spawns plant meshes around it at the beginning of the game to populate an area. A number of plants can be added to its list, the number and intensity of meshes specified, and various effect set up. On startup, the generator spawns random meshes from the list around itself at random locations and is then destroyed. It allows the designer to populate an area without adding each plant by hand. It slows down the launching of the map, however, and the plants are randomly spawned and cannot be precisely controlled.

The properties of the Vegetation Generator are divided into two main parts: the properties of the Vegetation Generator's own properties, as seen under UIVegetationGenerator, and the parameters for each plant added to the list in UIVegetationGenerator=>Plants. Up to 16 plants can be added and given specific parameters. Plants must be subclasses of the UIFlora class under Decoration. UIFlora actors are plants that make noise when stepped on.

  • EffectArea: where the plants are spawned around the UIVegetationGenerator actor.
  • NumberOfErrors: Number of meshes that can be spawned outside geometry.
  • NumPlants: Number of plants to choose in the list.
  • Plants: List of plants to spawn, and their specific parameters. See below.
  • SelectionMethod: Determines how plants are chosen. If set to SELECT_Linear, the generator will pick one plant from Plant1, then one from Plant2, and run down the list until it reaches the maximum number of plants it has to spawn. If set to SELECT_Random, the generator will randomly pick a plant everytime it adds a new one.
  • VegetationIntensity: This determines the number of plants to spawn per plant chosen in the list.

In order to determine the number of plants actually spawned, two values are important: NumPlants and VegetationIntensity. Simply put, NumPlants decides how many plants are chosen in the list, and VegetationIntensity decides how many of each selected plant is spawned. If NumPlants is 1 and VegetationIntensity is 5, the generator will spawn 5 plants of the type chosen by the generator (if SelectionMethod is SELECT_Linear, this means 5 plants of the [0] type).

If you have NumPlants = 3 and VegetationIntensity = 10, the generator will spawn 3*10=30 plants, equally distributed between plant types [0], [1] and [2] (again, assuming SelectionMethod is SELECT_Linear), even if you have specified 7 different types of plants.

Each plant can have specific properties determined in the Plants list.

Visibility Notify

VisNotify.JPG

Used to fix Network Replication with specific mirrors or WarpZones. By default, stuff reflected from mirror (that are normally behind a wall) or seen through WarpZones, are not considered as relevant actors in online games and will appear invisible.

In order to use it, place two (Actor -> Info ->) VisibilityNotify actors on both ends, set up a CollisionRadius/Height that covers up visible area of the both rooms and give them both same tag.

Projectors

Two projectors (one selected) used to display posters in DmRiot.

A Projector is exactly what its name suggests: something which projects images. Maps the texture it contains over all surfaces in its field of view. It can be used for light rays, posters, magical symbols glowing on stone arches and so on. A projector is assigned a texture, a field of view (FOV), and displays the texture in the desired direction. By adjusting its FOV, it will project the texture in a cone-like fashion (as a real light-projector), which means the projected image will be larger the further away the receiving surface is from the projector.

The actual actor used as projector is MapProjector, a subclass of Projector. The other subclasses of the main projector class are intended for decals created by projectiles (think rocket blasts), shadows of decoration and the shadow of the player himself if real-time shadow is used. These actors are not meant for use in a map and cannot be placed.

The MapProjector actor (from now on referred to as Projector) looks like a small white camera on a grey circle. After adding it to the map, you can see that it is directional and already has a zone of action: the white rectangular box before it. By moving the projector until the rectangle ends inside a wall, you can see it already projects the basic pawn icon.

By default, projectors project the same Pawn actor icon as most new 227 actors. The first step to create a nice projector is to change this. Select whatever you want in the texture browser, or import what you need, and in the MapProjector's properties, in the Projector tab, set your image in the appropriately named ProjectTexture. Immediately, the white box of projection (from now on referred to as the Projection Box) changes to match the size of your texture.

Notice that there are two tabs that will be relevant when dealing with MapProjectors' properties: MapProjector and Projector.

  • OnlyAttachStaticActors: Default, True: Determines whether or not the projection is displayed on moving actors going through the projection box. If set to False, the mover will receive the projection. If set to True, only non-moving objects will receive projections from this projector, and moving actors will be ignored. Notice however that weapons, items and players will never be affected by projectors. This property is also not valid for movers based on brushes: only Static-Mesh-based movers are affected.
  • IgnoreAttachActorTag: Allows you to enter the tag of an actor that will not receive the projection. It can be a moving or still Static-Mesh or mesh, but it will have no incidence on Brushes.

To make things clear, a brush will always receive the projection, except if it is a brush-based mover - in which case it will never be subject to projection - Meshes and Static-Meshes will receive projection, except if the IgnoreAttachActorTag of the projector matches their tags. Movers made with static-meshes will need OnlyAttachStaticActors to be set to true to receive projection during their movement.

Three projectors with the same with different FOVs.
Three projectors with different ProjectorStyles.

Most properties of the projector are in the projector tab. Here are properties to set the texture, the projection box and the size of the projection.

  • bGradualFade makes the projection more or less opaque as the surface is more or less close to the projector. The texture is totally opaque at the projector level and gradually fades until the end of the projection box is reached (where the texture is 100% translucent).
  • bProjectActors: If set to true, allows the projection on meshes.
  • bProjectBSP: If set to true, allows the projection on BSP surfaces.
  • bProjectBSPBackFaces and its corollary bProjectMeshBackFaces allow the projection on surfaces oriented in the same way as the projector. Usually, when you project a texture, the surface receiving the projection has an opposite direction to that of the projector: they are facing each other. Think of someone pointing a flashlight behind you: your back will be facing the flashlight and receiving the projection. Your face, however, is facing the same direction as the flashlight and thus remains in the shadow. When activating these two properties, even your face will be lit by the light, as if it went through you. it basically makes the projection appears on all surfaces between the projector and the end of projection box, not only the surfaces looking "at" the projector.
  • bUseBetterActorAttach: by default, this property is activated and allows the projector to use an accurate system for its projection. When set to false, it will use a slightly less accurate but less resource-intensive system. Performance gain, however, is negligible.
  • FOV: Field of Vision. By default, this setting is set to 0, and the projection box has the same width and height along its whole length. When the FOV goes up, the projection bow becomes a cone with a larger base. (see illustration).
  • MaxDistance: Maximum reach of the projection box in Unreal units.
  • ProjectorScale: Scale of the texture at the level of the projector actor, with 1 is the full size, 0.5 half the size and 2 double-size. This is the size at the projector level only, not the size of the projection (except if the Field of View is 0).
  • ProjectStyle: Style of display of the texture. STY_None and STY_Normal will simply display the texture as it is in the texture browser. STY_Masked uses the Alpha mask if set in the texture. STY_Translucent makes the dark parts of the texture transparent and the light parts opaque. STY_Modulated makes the dark parts of the texture opaque and the light parts transparent (the opposite of Translucent). STY_AlphaBlend uses the Alpha channel for special blending.
  • ProjectTexture: The texture that is projected.
ProjectionBoxes.jpg

Some considerations:

  • If a projector seems to be non-functional for no reason after loading a map in the editor, simply select the MapProjector.
  • Even with RealTime Preview enabled, the white zone-of-effect box will not move around in the 3D viewport until you actually release the CTRL key to move the actor.
  • Projectors do not have occlusion testing: All surfaces facing the projector will have the texture mapped unto them, even if there is an obstacle in the way. Be careful when adjusting the MaxDistance setting of a projector to avoid finding projections repeated on objects behind a wall.
  • Projectors may not work in Software mode. Use OpenGl for optimal results.

DynamicZoneInfo

DynamicZoneInfo.png

Dynamic ZoneInfos are simply ZoneInfos that can be moved and spawned at will while playing. They come in handy to create effects such as rising water or temporary flooded or altered areas. They are not limited by portals and BSP, but act within a defined volume around the DynamicZoneInfo actor.

  • bMoveForcesTouchUpdate: forces the update of actors touching the zone when the DynamicZoneInfo moves or is altered.
  • BoxMax and BoxMin: define the size of the zone around the DynamicZoneInfo actor if the ZoneAreaType is DZONE_Cube.
  • bUseRelativeToRotation: the zone shape should be relative to dynamic zoneinfo's rotation.
  • CylinderSize: defines the height of the cylinder if the ZoneAreaType is DZone_Cylinder.
  • MatchOnlyZone: Write name of a BSP zoneinfo actor here to make the dynamic zoneinfo only effect inside that zone.
  • SphereSize: radius of the sphere if ZoneAreaType is DZONE_Sphere, or radius of the cylinder if ZoneAreaType is DZONE_Cylinder.
  • ZoneAreaType: zone of effect of the DynamicZoneInfo : Cube, Cylinder, Sphere, or SCRIPT to call Uscript events (warning : very slow).

The DynamicZoneInfo has subclasses equivalent to the ZoneInfo's subclasses: Nitrogen, Teleport, Water, Lava, Tar and Slime zones. They are similar to the static versions but have the benefits of movement and on-the-fly creation, as the DynamicZoneInfo.

OGG Vorbis Music

Unreal v227j supports OGG music. Previously, you had to convert OGG tracks into the WAV format, then make ImpulseTracker files out of them, with the expected disadvantages such as loss quality, huge filesize etc etc... In contrast, plain OGG files high quality music files with a relatively small filesize.

In order to use your OGG music file in your map, follow these steps:

  • Launch UnrealEd
  • Go to the Music Browser
  • File > Import... (File format: OGG (*.ogg))
  • Open your file
  • Save the music file and make use of it.

OGG tracks could also have loops set on them. In order to enable such support, make sure your OGG file has a comment along the lines of "|LOOP:0-100|", where 0 is the looping start point (% of the song) and 100 the looping end point (% of the song). Then just test it by listening to the song on UnrealEd.

New commandlets

There are several new additions to the Unreal commandlet roster. The novelties can be found in the Commandlet page.

Further reading (Wiki only section)

If you're looking for further information and questions about UnrealEd 2.0, you might want to check Unreal v227 Manual/Frequently Asked Questions.

A lot of articles and tutorials have been written for UnrealEd 2.0 by the very large UT99 community, but over the years, much of this content has been lost.

Unfortunately, as they moved to newer versions of the Unreal Engine, a lot of writers just dropped their UEd 2.0 tutorials. In case you need more help, explanations or advice on how to do a particular thing or how to use a tool, ask on the OldUnreal forums.