Found typo, Emission Bursts & Emission Rate section, emission bursts section example for 'complete' Code: "emissionBursts": [{time": 0.0, "count": 10, "countRange": 0}] First 'time' should have a " character in front of it.
It's really nice when developers do something for modders. I mean team colored beams aren't in game, so you didn't have to fix it, but you did anyway. Thanks!
As a warning, though I fixed this bug internally, it was too late to make it into the next release build (77438). If we do a hot fix I may try to get it in, but most likely it won't be in until the next major PTE.
It seems like string type particles still mess with the linkIndex stuff. What I was doing: - linking emitter B to emitter A - linking C to emitter B - making emitter C be a string type. Expected Result: - expected same behaviour as if I set emitter C to a normal rectangle shaped emitter - i.e. particles spawned in emitter C get the correct coords from emitter B Actual Result: - particles get the right location relative to one another, however, they do not spawn in the same location as emitter B's particles. - the height of the particles seem to be correct (Z coord is fine) - the X and Y coords seem to be fixed to some location on the planet. I can provide the source if you would like. Right now the entire thing is a little mod to change the ping (for testing purposes).
I found another odd behaviour, this is using the beam spec shape: Code: { "emitters": [ { "spec": { "shader": "particle_transparent", "shape" : "beam", "sizeX": 1, "red": 20, "green": 0, "blue": 20, "baseTexture": "/pa/effects/textures/particles/flat.papa" }, "lifetime" : 1, "emitterLifetime": 0.1, "bLoop" : true, "offsetY" : [[0, 0], [1, 200]], "emissionBursts": 1, "beamSegmentLength": 10, "maxParticles": 25, "useWorldSpace": true, "endDistance": 3000 } ] } I would like to draw focus to the 'emitterLifetime', 'lifetime' and the 'bLoop' parameters. Expected behaviour: - I want this emitter to repeat 10 times a second, producing a beam that lasts for 1 second each time. Actual Behaviour: - The loop time for the emitter is given by max(emitterLifetime, lifetime) Is there something wrong with my expectations? Or is this a bug?
bLoop set to true means the system waits until emitterLifetime and then starts the emitter 'time' space again. So if you are bursting particles or what-not, it will do that all again. The thing is that if I just remove the "beam" shape from the emitter everything works as expected.
There can only be one beam alive per emitter, similar to how there can only be one trail alive per emitter. It's the same behavior as if you had maxParticles set to 1 on a normal emitter.
is it possible to have the particles conserve the initial velocity of whatever the emitter was? say I had a plane that was shot down, and I wanted the velocity of the particles to be dependant on the speed of the plane at the time. Is this possible now? If not, could it be implemented?
I don't think there is any way currently to get a dynamic 'current speed' from the entity that spawns the effect. However, you can sort of cheat it by observing that most aircraft only ever move 'forward' in your emitter space. Try adding 'velocityY': -1, and "velocity" : <max speed of aircraft> to what ever effect you want to make. The issue with this of course is that the effect particles will move even if the aircraft happens to be stationary. You can make a compromise by having the velocity of the particles being only a portion of the aircraft's max speed. That way it will look like the particles inherit some of the aircraft's motion, and also doesn't look too silly when the aircraft is destroyed while standing still.
Problem is, this isn't for an aircraft, and it's something where I'm taking a model of a unit when it dies, and trying to inherit the velocity the "real" model had when it was alive. (would be useful for crashing effects, or sinking and such).
Yeah, doesn't exist right now, but is something I'm looking to add. I got it mostly working today, but it needs a little more work. There is a hidden feature in the PTE related to this, emissionByDist.
Sometimes using particle_add (or particle_add_soft) shader resuts in "Missing technique xxx for particle group." error. Spoiler: Missing technique string for particle group. {"spec":{"shader":"particle_add","shape":"beam","red":1,"green":1,"blue":1,"alpha":[[0,0.0],[0.01,2],[0.1,1],[0.25,1],[0.3,0.25],[1,0]],"sizeX":[[0,0.25],[0.2,3.5],[0.5,1]],"baseTexture":"/pa/effects/textures/particles/rocket_trail_clip.papa"},"alpha":[[0,0],[0.25,1],[0.9,1],[1,0]],"offsetRangeX":[[0,0],[1,5]],"offsetRangeZ":[[0,0],[1,5]],"sizeX":[[0,0],[0.66,1.5],[1,0]],"emissionRate":600,"maxParticles":40,"beamSegmentLength":12,"lifetime":0.075,"emitterLifetime":0.2,"delay":0.1,"bLoop":false,"useWorldSpace":false,"rampV":550,"endDistance":10000} Spoiler: Missing technique alpha for particle group. {"spec":{"shader":"particle_add","red":1,"green":1,"blue":1,"alpha":[[0,0.0],[0.01,2],[0.1,1],[0.25,1],[0.3,0.25],[1,0]],"sizeX":[[0,0.25],[0.2,3.5],[0.5,1]],"baseTexture":"/pa/effects/textures/particles/rocket_trail_clip.papa"},"alpha":[[0,0],[0.25,1],[0.9,1],[1,0]],"offsetRangeX":[[0,0],[1,5]],"offsetRangeZ":[[0,0],[1,5]],"sizeX":[[0,0],[0.66,1.5],[1,0]],"emissionRate":600,"maxParticles":40,"beamSegmentLength":12,"lifetime":0.075,"emitterLifetime":0.2,"delay":0.1,"bLoop":false,"useWorldSpace":false,"rampV":550,"endDistance":10000} If I use particle_transparent shader or set dataChannelFormat to PositionAndColor there is no error.
I thought I'd added support for strings with particle_add, but it looks like I never got that in. It's sitting in a change list locally, never got checked in, opps! String support for particle_add_soft is a similar oversight. Basically soft particles came in kind of late so I only added support in places I actually used them, so a lot of permutations got left out. Technique alpha support is another situation where support got left out because I don't think a single effect of mine actually uses only alpha. It and "standard" (position only) particles exist for optimization purposes and were what we started with when rewriting the particle system to base the other types on, but ultimately they're not used and just add to confusion for you guys and extra upkeep work on my end.
I found an issue with muzzle effects. If I want sparks to fly out of the muzzle when the weapon fires, they will move with the acutal unit when it rotates and moves position. Eg., I have a gunship that shoots sparks when it fires something, then rotates to shoot something else, but the entire emitter rotates with it. I cant find a way to get around this, unless there is some property that fixes it.
