Dma: I've found that the best way to test xEmitters is to bind a key to:
and using the command:
to control the properties for all xEmitters that you will spawn. This allows you to test the results without exiting the game.
The Display -> Skin property sets the texture of the emitter. (Do these only emit sprites? How lame!) Display
- 1 Properties
- 2 Enums
- 3 Events
- 4 Links
- 5 Discussion
- bool bForceAffected
- This causes the particles to be affected by passing objects (including players). This only has an effect with highest physics details.
Pclbeam - Particle Beam Properties
These are used if mSpawningType is PT_Beam.
- float mBendStrength
- float mWaveAmplitude
- float mWaveFrequency
- bool mWaveLockEnd
- float mWaveShift
Pclemitter - General Particle Emitter Properties
- bool bSuspendWhenNotVisible
- Suspends emission of particles if the xEmitter is not visible. Useful for level optimization.
- float mLifeRange
- The particles will live for a random duration that falls between these two values.
- float mDelayRange
- Emission of particles will be delayed by a random duration that falls between these two values.
- float mRegenRange
- The xEmitter regeneration cycles on and off for durations controlled by the following two variables:
- float mRegenOnTime
- Emission ON cycle lasts for a random duration that falls between these two values.
- float mRegenOffTime
- Emission OFF cycle lasts for a random duration that falls between these two values.
- Name mChildName
- The Tag to give to child particles (or name? needs checking)
- int mMaxParticles
- Sets a limit on the number of particles emitted (please clarify!).
- bool mRegen
- Enables or disables regeneration. Note: changing this in UnrealEd somehow breaks the real time preview of the effect, and if you still want to see it in the editor you might have to re-create your emitter from scratch. IIRC Checker from DE pointed that out.
- enum mParticleType
- Sets the type of particle to emit:
- float mRegenDist
- bool mRegenPause
- Effectively pauses emitter regeneration. It remains ready for use but does not emit anything. Existing particles are unaffected.
- Name mSourceActor
- ExSpawningTypes mSpawningType
- Describes the manner in which particles are spawned.
- Particles make a line. No idea what determines its length and direction though.
- StaticMeshActor SourceStaticMesh
Pclmovement - Particle Movement Properties
- float mSpinRange
- The particles will have a random spin between the two values. Useful to have a slowly rotating snowflake or to make particles look more chaotic.
- float mSpeedRange
- The particles will have a random scalar speed somewhere between these two values. The direction is determined by the rotation of the xEmitter, its dirDev, and its physics/owner (see PHYS_Trailer).
- float mMassRange
- The particles will have a random "mass" somewhere between these two values. This determines the effect that gravity has on the particles. In fact, negative values make the particles float upwards. This basically controls the gravity.
- float mAirResistance
- Sets the effect that air resistance has on the particles.
- float mAttraction
- Attractive force between particles
- float mColElasticity
- Bounciness of particle collision. (0-1)
- bool mCollision
- Enables collision for particles
- bool mColMakeSound
- ? Enables the CollisionSound notification event. ?
- vector mDirDev
- Possible range of deviation in direction from the spawn location.
- float mOwnerVelocityFactor
- The owner's velocity is added to the particle velocity after being scaled by mOwnerVelocityFactor.
- vector mPosDev
- Possible range of deviation from the spawn location.
- bool mPosRelative
- Position is relative to the emitter, if the emitter moves, the particles move. (?? cursory experience with spheres/trailers someone else is welcome to verify).
- vector mSpawnVecA
- vector mSpawnVecB
- float springD
- float springK
- float springMaxCompress
- float springMaxStretch
Pclvisuals - Visual Particle Properties
- color mColorRange
- StaticMesh mMeshNodes
- if using meshes as particle nodes
- float mSizeRange
- EAttenFunc mAttenFunc
- Attenuation function.
- float mAttenKa
- Attenuation constant A.
- float mAttenKb
- Attenuation constant B.
- bool mAttenuate
- Enable particle attenuation.
- bool mDistanceAtten
- float mGrowthRate
- The rate at which the particles grow during their life. Think of a fountain/starburst, start with a small size, and add a high growth rate for the right effect.
- Texture mLifeColorMap
- int mNumTileColumns
- The number of Columns in the texture.
- int mNumTileRows
- The number of Rows in the texture.
- Texture mPosColorMapXY
- Texture mPosColorMapXZ
- bool mRandMeshes
- bool mRandOrient
- Orients each object randomly. i.e. _\|/_
- bool mRandTextures
- Choose a random texture for each instance of this emitter
- bool mTileAnimation
- Animate the particle from the set of tiles throughout life
- bool mUseMeshNodes
- bool bCallPreSpawn
- Call the PreSpawned event.
- bool blockOnNet
- int Expire
- int mAtLeastOneFrame
- Box mBounds
- int mbSpinningNodes
- xEmitter mChildEmitter
- vector mDir
- int mHeadIndex
- float mInvTileCols
- vector mLastPos
- vector mLastVector
- int mNumActivePcl
- int mNumSprings
- int mNumUpdates
- int mpAttenFunc
- float mPauseTimer
- pointer mpIterator
- pointer mpParticles
- ptr to tarray
- pointer mpSprings
- ptr to Spring class
- float mRegenBias
- float mRegenTimer
- int mRenderableVerts
- plane mSphere
- float mT
- float mTexU
- float mTexV
- float mTime
- float mTotalTiles
- float mWavePhaseA
- float mWavePhaseB
- int SystemHandle
These functions work using mAttenKa and mAttenKb.
- Linearly interpolates in and out according to the following formula: (please verify, just a guess)
x(t) = mAttenKa + t(mAttenKb - mAttenka)
- Called if bCallPreSpawn is true. Used for detail level stuff, among other things.
- I suppose that this is called if mColMakeSound is true.
xEmitters and Glass
xEmitters seem to have problems with visibility through glass. It appears that the xEmitter will display through one translucent surface, but not through two.
In other words, a sheet would be fine (having only one face), but a box (having a bottom and a top face) would block its visiblity. (does this hold with other types of see-through surfaces like grates, or do these all count as the same sort of thing in UT2k3 anyway?)
GRAF1K: Assuming you're talking about masked sheets when you say grates, I Don't Know™. ;-) But, I'm 99.9% sure that masked sheets are treated as merely selectively translucent surfaces, making it the same.
Foxpaw: I tried this in an attempt to answer your question, and found that I couldn't hide the xemitter no matter what I did. I made an x-shaped map with an xemitter in each leg, then isolated one with a sheet, one with double sheets, and one with a box (not sealed) and one with a box. (sealed off to form it's own zone) All the "blocking" things had a smoke texture with an alpha channel on it so I could see through it. In my experiment, the xemitters were visible behind all of the blocking devices.
Having said that, I suspect that the issue of the visibility is actually due to the "line of sight" being blocked, and not due to the actual number of faces between the two objets. A sheet doesnt block anything, so you could see it through the sheet, but a box blocks your line of sight, thus blocking the xemitter. Or at least, that's what I would think.
RDGDanClark: I think it has something to do with a property setting somewhere in the xEmitter. I pulled up CTF-ComArray, and if you're familiar with that map, it uses xEmitters under the superstructure much the same way I tried to do with my map. On ComArray, you can see the xEmitter through everything; glass, grates, any texture with an alpha channel. I copied/pasted the xEmitter into my map and it worked fine through my glass floors. I'll start playing around with all the settings and post what I find.
AlphaOne: Does bForceAffected actually work? I tried it with the Emitter class (not XEmitter) and nothing happens.
AlexAC: on the subj of bForceAffected it does work a little on norm emitters, well they are affected by redemer shots, and xemitters react darn well to rockets, players and stuff i assume the setting is also bForceAffected.
Karp: Is there anybody able to complete this list?
Tarquin: Well... someone (not me, I'm too much of a grouch) could ask Rachel to come and help us on this page, maybe import some of what she wrote on UnrealOps. Or we could see what the UDN says, and write up the properties we've found there. Or we could each pick one property, play with it in UEd and try to work out what effect it has & write it up here. All three would be good :)
Bob_The_Beheader: Dumb question...I guess... but what is the difference between the xEmitter and the Emitter classes?
Tarquin: see Particle System.