Announcement

Collapse

The Infinity Blade Forums Have Moved

We've launched brand new Infinity Blade forums with improved features and revamped layout. We've also included a complete archive of the previous posts. Come check out the new Infinity Blade forums.
See more
See less

Particle damage

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Particle damage

    Can particles in xEmitter be set up to damage players?

  • #2
    No. It's just a fact. Were the particle code to call an UnrealScript function every time a particle collided with something it would be so ridiculously slow that nobody would use it. So rather than implementing a feature that nobody would use they just didn't and spent the time they saved coming up with new and unusual ways to get even more polygons on the screen.

    Comment


    • #3
      that's not to say you couldn't code for it when it collided with a certain actor type, such as Pawn. Although you may go into it more coding than it's worth. The problem you would have is that you would actually have to extend the emitter (im guessing) and then tell it what to do. As it stand now post #2 is accurate.

      Comment


      • #4
        Originally posted by Sir_Brizz
        The problem you would have is that you would actually have to extend the emitter (im guessing) and then tell it what to do.
        The real problem is that the emitter is native code, and therefore it's behavior can't be altered from UnrealScript.

        The best way to do this is probably to have some class that spawns objects in a predicable way (like has it's own random number generator). With a little careful replication work you could get this behaving properly over a network with no client-side lag on object (particle) appearance, and minimal bandwidth overhead. It would have a significant processing overhead though - you wouldn't want more than one or two dozen live at any one moment.

        Comment


        • #5
          eugh...i forgot that was native code...

          needless to say you COULD get something working, but you probably would be unhappy with the end result and have wasted all that time...

          Comment


          • #6
            What you might consider is creating a volume that coincides with the area covered by the particles you're referring to, and take off x amount of life for every x number of ticks your in the volume. easy to process, and a very similar effect. That is, if this is what you were going for.

            Comment


            • #7
              Yeah, you could even randomize the delay a bit to make it seem more like random particles hitting you. That only works if you have high enough particle density though.

              Comment


              • #8
                Originally posted by MeanFish
                What you might consider is creating a volume that coincides with the area covered by the particles you're referring to, and take off x amount of life for every x number of ticks your in the volume. easy to process, and a very similar effect. That is, if this is what you were going for.
                Volume? That's tatic.
                How am I supposed to make the dynamicaly spawned particles collide then?

                The only way I came up with is to spawn invisibile actors that have same speed and fly path as particles. This way I could maybe simulate particle collision....

                Comment


                • #9
                  No, there's really two primary options here:

                  1. if you particle density is low enough (no more than a few dozen particles live at a time), don't use particles. Instead use some sort of random-but-predictable spawning method to spawn actors with the same location/velocity on the client and server at the same time.

                  2. If the particle densities are higher than that, use a regular particle system, and in the same location as the particles are flying place a custom physics volume. Have the code of this volume use a random timer to damage players inside the volume. The damage won't match up with particle collisions, but nobody will be able to tell.

                  Comment


                  • #10
                    The second one sounds like a good idea but i have
                    a 3rd one:
                    Put timer() in xEmitter and with a bigger collision damage anyone in its radius.

                    Comment


                    • #11
                      Doesn't that create a potential for massive slowdowns?? Meaning if there are 12 emitters in the level and you have your timer running at .5 second intervals on each of them that is alot of calculation per second...let alone if there is more than 12 emiters (i wouldn't know in what case though)....

                      Comment


                      • #12
                        Those xEmitters are supposed to last only a few seconds, and not be many arround.

                        Comment


                        • #13
                          Isn't the effect on the inside of the bombing run goals an xEmitter?

                          Comment


                          • #14
                            Yes. Your point?

                            Comment


                            • #15
                              Whoa, 2.5 year bumpage!

                              EDIT: Har, har, deleting your post...

                              Comment

                              Working...
                              X