Announcement

Collapse
No announcement yet.

Kismet "Attach To Actor" only works on client side.

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

    Kismet "Attach To Actor" only works on client side.

    I have some emitters attached to a rotating InterpActor and everything works the way it should on client machine hosting the map, when someone joins the game the attachments aren't rotating on the other PC - they're fixed, unlike the machine hosting the map where they rotate like they should. I've tried to trigger from a pickup thinking it was a Level Startup issue, no luck with that.

    It must be something simple I'm overlooking?

    #2
    Setting the base via properties windows allows for proper replication of such things, why not attach permanently?

    Comment


      #3
      That makes more sense .. then I can use just the random / intermittent sequence to start-stop the emitters through Kismet instead of trying to run the entire thing (including the attachment) through the script.

      Thx Nick, I was hoping you'd answer.

      Comment


        #4
        Hi! I've also this problem by attaching a water volume on an interpactor ...no attachment properties here NickG

        Comment


          #5
          You can attach a UTDynamicWaterVolume, BloodK1ng...so...may I play your maps!?

          Comment


            #6
            Originally posted by NickG View Post
            You can attach a UTDynamicWaterVolume, BloodK1ng...so...may I play your maps!?
            Yeah I have a UTDynamicWaterVolume and a Postprocessvolume attached on an interpactor but water still bugged online (except on client side). I'll propably delete and redo volumes, I'm sure that problem is not on kismet side. (I meant Postprocessvolume have no attachment properties)

            Comment


              #7
              I see what you mean, the UTDynamicWaterVolume seems to have an additional copy on clients which either does not move from original position, or drags along at a separate position relative to base, depending on hardattach. I wonder if this is due to the dirty replication specifier or relevance. I would try a test of animating one from matinee (matinee has mostly reliable movement replication, at its expense) before redoing volumes. I also made this, and it seems to work all the way with proper movement on connected client:
              Code:
              class DynamicPPVolume extends PostProcessVolume
              showcategories(Advanced,Attachment,Collision,Volume);
              
              defaultproperties
              {
              	bStatic=false
              
              	bAlwaysRelevant=true
              	bReplicateMovement=true
              	bOnlyDirtyReplication=true
              	RemoteRole=ROLE_None
              }

              This is just a dynamic post process volume by using the same methods as other dynamic volumes. I can upload it for you if you might use it and don't like to make scripts. I gave up on the kismet DOF/motion blur stuff after not being able to get anything to take effect.

              Comment

              Working...
              X