Announcement

Collapse
No announcement yet.

Replication from the Mutator Class? How?

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

    #61
    I am sorry to see that no motion has been made here. I am going to be home a little early tomorrow, thursday and ill be home all day saturday trying to do three things:

    Help figure out the best way to replicate data from the server to a client, only once if possible, using only a mutator
    Figure out how to add an exec function to control my mutator on the fly in game.
    Sleep.

    The first two take priority.

    Comment


      #62
      I just went and did a little research here on this topic, and I found this interesting tidbit of code in UTPawn:

      Code:
      function bool DoJump( bool bUpdating )
      {
          // This extra jump allows a jumping or dodging pawn to jump again mid-air
          // (via thrusters). The pawn must be within +/- DoubleJumpThreshold velocity units of the
          // apex of the jump to do this special move.
          if ( !bUpdating && CanDoubleJump()&& (Abs(Velocity.Z) < DoubleJumpThreshold) && IsLocallyControlled() )
          {
              if ( PlayerController(Controller) != None )
                  PlayerController(Controller).bDoubleJump = true;
              DoDoubleJump(bUpdating);
              MultiJumpRemaining -= 1;
              return true;
          }
      I don't see anything in the PlayerController that depends on MaxMultiJump or MultiJumpRemaining, or anything that executes clientside that depends on either of those. I do however see that the Jump code won't execute another jump if you're going too fast..

      Am I misreading this?

      Comment


        #63
        Originally posted by Blade[UG] View Post
        ...I don't see anything in the PlayerController that depends on MaxMultiJump or MultiJumpRemaining, or anything that executes clientside that depends on either of those...
        Don't forget that on the owning client, the PlayerController is Role=ROLE_Authority and the pawn is Role=ROLE_AutonomousProxy, so non-simulated functions can be run.

        What's still the problem? I thought the only bug left was the one immortius found that was due to Owner not being replicated early enough, which the code in my last post should fix.

        Comment


          #64
          Sorry everyone, I haven't yet been able to try Mr Evil's tip. I got unexpectedly tied up this weekend and found no time to test. I do want to say thank you to Immortius for trying out the code and his other coding advice, and to Mr Evil and Bob for their coding help as well. I will hopefully be able to run through the fixes tonight and I will report how it goes.

          Comment


            #65
            I am following this thread because i want to have a general solution to the issue of how to replicate variables with the pawn, and possibly other situations. This solution is really not achieving that goal from what i have seen. The contextual solution of making new jump boots is great for the jumping mutator, but it doesn't really solve our issue, at least through my eyes.

            Comment


              #66
              Good point about the client not needing to know about the jump, but on a similar note, just messing around and testing code, I've found places it would help if I were able to have the health and location of all the pawns, not just the ones near the client. Any tips on getting that information replicated to the client? PRI has all of the names, but certainly not locations and AllPawns called from a client only has ones near them.

              Comment


                #67
                Originally posted by Bob_Gneu View Post
                I am following this thread because i want to have a general solution to the issue of how to replicate variables with the pawn, and possibly other situations. This solution is really not achieving that goal from what i have seen. The contextual solution of making new jump boots is great for the jumping mutator, but it doesn't really solve our issue, at least through my eyes.
                I agree with you on some aspects, but since I am not proficient enough with uscript or similar languages, I can't say that the way Epic implements this stuff is "wrong". While it should just be as easy as
                var() iMyServerVar;
                replicate var()iMyClientVar;

                it's unfortunately not.

                As immort pointed out, and I kinda learned from it as well, in UT2004, the xPawn has the "MaxMultiJump" variable replicated from within. This was kind of a "cheat" but obviously a worth while one when coming from the core code. The problem now is that we need to tell the server of our new value and the client of our new value, and since UTPawn doesn't have MaxMultiJump replicated from within, we have to find a function that the client does run, and pass the variable over to that function override.

                Some of the code however does seem repetitive. I don't understand why I need to put iMaxNumJumps in both GivenTo and ModifyPlayer. If they are both run serverside, the server should already know what the new iMaxNumJumps is after one of them is run. But since we can't rewrite it and tell them to do it the "right" way, we just have to adjust enough to work with it the way it is.

                Comment


                  #68
                  the only issue i am raising here is that this solution is very contextual. We have jumps and need to make sure the client knows about it, but in an instance where our variable is not something that an inventory cleanly maps i dont know if this is the best process. Maybe we should be looking to epic and their mailing list to see if we can track down a function that is available in the Info class that may serve our needs better. Setting the data every tick may not be optimal but it really seems to suit our need for a general solution better than this one.

                  Comment


                    #69
                    What is it that you're looking to do, Bob?

                    Comment


                      #70
                      Quite simply, i was assuming this thread was being used to keep track of all methods of replicating data that is not already replicated in order to ease that burden. I recognize that my tick method does not provide the optimal results, but i also recognize it to be more useful than what has been discussed. It is definitely possible to network like has been discussed, but since one of the first things said was that KewlAzMe wanted to keep it all in the mutator itself it seems a bit out of place to bother with a new inventory item and replicating that when we already have the player info replication method.

                      Comment


                        #71
                        The inventory item method is appropriate because it's not just a bit of data that needs to be replicated, but an action (modifying the player). If you wanted to, you could use ReplicationInfo to hold the value of iMaxNumJumps, then use the inventory merely to apply that value. It would make sense to do it that way if you had a lot of different data that you wanted central access to but was not all used just to modify the player.

                        You shouldn't use a ReplicationInfo to modify the player though, they should remain purely for information holding.

                        Comment


                          #72
                          What good is ReplicationInfo if you dont use it for replicating information?

                          Comment


                            #73
                            Originally posted by Bob_Gneu View Post
                            What good is ReplicationInfo if you dont use it for replicating information?
                            But replicating information is all it should do. If you start using it to effect changes to the world, you are failing to separate concerns. It may not seem particularly important for a little mutator like this, but once you get into a full-scale mod, you're going to produce unmaintainable code if you don't think about things like this.

                            Comment


                              #74
                              I am familiar with SoC and i understand your point although i am not sure how it applies to this discussion. We have an issue - we need to replicate a variable that is not currently replicated. the methods of doing that are... subclass the pawn, known to be a terrible practice, or use the Info class to pass the data around, which is breaking what you see as the concerns of the class. I would argue that the methods have been provided to do what we are doing so it was anticipated to work as such.

                              Comment


                                #75
                                Originally posted by Bob_Gneu View Post
                                I would argue that the methods have been provided to do what we are doing so it was anticipated to work as such.
                                The methods are provided to do that only in the same way that a paint set provides the ability to make graffiti. There are multiple ways of implementing most things in UScript, and your concerns as a developer should be to seek out the most efficient and most maintainable ways.

                                Comment

                                Working...
                                X