Announcement

Collapse
No announcement yet.

Possible bug with ONSVehicle class? (NO -- misread an || as an && :P)

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

    Possible bug with ONSVehicle class? (NO -- misread an || as an && :P)

    Hi. I am new to these forums. Please forgive me if this is in the wrong place.

    This snippet of code is trying to figure out which WeaponPawn to move the player to when they attempt to enter a vehicle. This is a minor coding bug (I think), but since I found it, I just thought it would be a nice thing to post anyway.

    THe problem is in the first if-statement. The two instances of " EntryRadius" should be "WeaponPawns[x].EntryRadius", I believe.

    Code:
    if (ClosestWeaponPawn != None || VSize(P.Location - (Location + (EntryPosition >> Rotation))) < EntryRadius)
        {
            // WeaponPawn slot is closest
            if (ClosestWeaponPawn != None && ClosestWeaponPawn.Driver == None)
                return ClosestWeaponPawn;          // If closest WeaponPawn slot is open we try it
            else                                   // Otherwise we try to find another open WeaponPawn slot
            {
                for (x = 0; x < WeaponPawns.length; x++)
                {
                    if (WeaponPawns[x].Driver == None)
                        return WeaponPawns[x];
                }
            }
        }
    As it is now, the EntryRadius for the *ONSVehicle* itself will be used. In code not far from this snippet, the correct WeaponPawns[x].EntryRadius is used, so there seems to be an inconsistency.

    I don't think this is causing any noticeable problems in the game(???)... but just in case it might be somehow causing subtle problems (or might later on cause some), I thought I would point it out.

    In particular, this would cause trouble for new large vehicles, which have weapon pawns that are not particularly close to the main entry point of the vehicle.

    The code could be useful as is (maybe it is even intentional) for allowing players to be more sloppy about where they enter vehicles and still allowing them to get whatever turret slots have not been filled, but this is going to be a problem on the larger vehicles if the player attempts to enter a turret and can not because the game thinks he is too far away from the *vehicle's* EntryPoint.

    #2
    The way entry is handled is that the vehicle is attempted first, if it cannot fit a player, then it checks to see if any of it's weapons are empty and if so has the player enter them. So yes the weapon pawn entry radius's are not used.

    Comment


      #3
      True, but that bit of code that checks for whether there is a driver or not is just above this bit of code and has a return statement in it that returns the vehicle itself if there is no driver. In that case, the snippet of code posted here will never be executed anyway.

      Code:
          // Always go with driver's seat if no driver
          if (Driver == None)
          {
      	Dist = VSize(P.Location - (Location + (EntryPosition >> Rotation)));
      	if (Dist < EntryRadius)
      		return self;
      	for (x = 0; x < WeaponPawns.length; x++)
      	{
              	Dist = VSize(P.Location - (WeaponPawns[x].Location + (WeaponPawns[x].EntryPosition >> Rotation)));
      		if (Dist < WeaponPawns[x].EntryRadius)
      			return self;
      	}
      
      	return None;
          }

      Here is the snippet of code just before the one I posted. As you can see, the check here is done against the WeaponPawn's EntryRadius! Thus the extra check in the snippet I posted seems to do nothing really but further limit the possibility of the player being able to enter the gun when already enough checks have been gone through (the function that contains all of this would not even have been called if the player was not at least near the vehicle to begin with I am assuming).
      Code:
          // Check WeaponPawns to see if we are in radius
          ClosestDist = 100000.0;
          for (x = 0; x < WeaponPawns.length; x++)
          {
              Dist = VSize(P.Location - (WeaponPawns[x].Location + (WeaponPawns[x].EntryPosition >> Rotation)));
              if (Dist < WeaponPawns[x].EntryRadius && Dist < ClosestDist)
              {
                  // WeaponPawn is within radius
                  ClosestDist = Dist;
                  ClosestWeaponPawn = WeaponPawns[x];
              }
          }
      This is followed by my original posted code:

      Code:
          if (ClosestWeaponPawn != None || VSize(P.Location - (Location + (EntryPosition >> Rotation))) < EntryRadius)
          {
              // WeaponPawn slot is closest
              if (ClosestWeaponPawn != None && ClosestWeaponPawn.Driver == None)
                  return ClosestWeaponPawn;          // If closest WeaponPawn slot is open we try it
              else                                   // Otherwise we try to find another open WeaponPawn slot
              {
                  for (x = 0; x < WeaponPawns.length; x++)
                  {
                      if (WeaponPawns[x].Driver == None)
                          return WeaponPawns[x];
                  }
              }
          }
      
      	// No slots in range
      	return None;
      The code I posted in the first post works practically for most vehicles and does what we want it to do in the game for such vehicles. But it could create trouble for custom vehicle scripters if they don't realize this quirk. . It means they must always make the circular EntryRadius large enough to completely encompass all the entry points (+ a bit of distance) on the vehicle including for all weapon pawns. This could be difficult for vehicles that have form-factors that are not very square or circular! (Trains would be an example, and I am actually working on such a system).

      Comment


        #4
        Yeah, it's kind of FUBARED

        I'm not sure why they went with this method.

        Comment


          #5
          Code:
              // Check WeaponPawns to see if we are in radius
              ClosestDist = 100000.0;
              for (x = 0; x < WeaponPawns.length; x++)
              {
                  Dist = VSize(P.Location - (WeaponPawns[x].Location + (WeaponPawns[x].EntryPosition >> Rotation)));
                  if (Dist < WeaponPawns[x].EntryRadius && Dist < ClosestDist)
                  {
                      // WeaponPawn is within radius
                      ClosestDist = Dist;
                      ClosestWeaponPawn = WeaponPawns[x];
                  }
              }
          
              if (ClosestWeaponPawn != None || VSize(P.Location - (Location + (EntryPosition >> Rotation))) < EntryRadius)
              {
                  // WeaponPawn slot is closest
                  if (ClosestWeaponPawn != None && ClosestWeaponPawn.Driver == None)
                      return ClosestWeaponPawn;          // If closest WeaponPawn slot is open we try it
                  else                                   // Otherwise we try to find another open WeaponPawn slot
                  {
                      for (x = 0; x < WeaponPawns.length; x++)
                      {
                          if (WeaponPawns[x].Driver == None)
                              return WeaponPawns[x];
                      }
                  }
              }
          
          	// No slots in range
          	return None;
          Correct me if im wrong, but I see no problems with that. The first part checks to see if you are in range of the weapon pawn's entrance. The if statement passes if you were in range to a weapon pawn, or you are in range of the EntryPositions for the vehicle (in case you do have a funky design, and you want to enter the vehilce through the drivers seat, and enter a turret (if there's a driver already))

          How is that a bug?

          Comment


            #6
            I wish UT had the Halo system of entering and exiting vehicles: climb into the closest seat, complete with animation and delay. UT has some magical "instantly teleport into place" system. :bulb:

            Comment


              #7
              Because it *already* decided you were close enough to the turret.

              Do not confuse the coding cutting you some slack, with the code RESTRICTING you further (as a player).

              The code in question does nothing but restrict the player's chances of getting into the turret further by requiring him to also be close to to main vehicle entrance. Pretty silly if you ask me!

              If the code made it *easier* to get in, that would be more understandable. This does nothing but make it harder.

              Comment


                #8
                I think what they were really going for was easier filling of the vec.

                No matter what direction you approach from, you're guarenteed entry to the vehicle... even if you on the opposite side of the only available seat.

                Most vec's have no difficulty grabbing players, unless they are extrordinalrily large. Where you sit there complaing epic's code makes it so turrets outside of the radius can't be filled without getting close to the vec... epc is wondering how you vec could be so large/out of perportion, that a single entry radius cannot provide needed entry points.


                A more difficult (and probably better in the long run solution) would be to have all turrets with their own entry sphere, and then if a person enters at a turret, and it's empty, he sits there, else it pases him to the next...

                Actually, that might not be that hard to do...

                Comment


                  #9
                  Most really big vehicles have only one or two entrances. Teh Levi, for example, has just once hatch, not five. For such vehicles, it would make sense to appoint the real entrypoint and let the vehicle sort out in which seat the player ends up once inside. People are probably packed in the center like sardines in a can, with the first holding the wheel and the rest grabbing some terminal with which to control the plasma turrets.

                  That is, if you would actually want to waste your team's time in a Levi plasma turret...

                  Comment


                    #10
                    No matter what direction you approach from, you're guarenteed entry to the vehicle... even if you on the opposite side of the only available seat.
                    False.

                    Read the code. It does NOT cut the player more slack. The checks to see if you are close enough to the weapon pawns are done BEFORE the extra (more restrictive) check against the main entry of the vehicle itself.

                    The extra check does *not* enable easier entry. It merely offers one more chance to screw the player over by NOT letting them enter.

                    In other words, if you read the code, you will see the sequence goes like this:

                    1. Figure out that there are players near the vehicle who want entry. (Implied. This is not shown in code above, but would be the event that ends up causing the function containing the code above to be called in the first place).
                    2. If there is no driver, make this player the driver. Period. Do this by returning the vehicle as the pawn to enter itself. The return cuts the rest of the function short.
                    3. Now figure out which specific part of the vehicle they want to enter. They can't have the main driver's seat even if they want it. We already determined that slot is taken already by someone else.
                    4. Assuming we have decided to make the player enter a specific weapon pawn, do yet another (more restrictive) check to make sure they are close to the main vehicle entry even though we already decided they are close enough to the weapon pawn we are thinking about letting them enter! This does not improve their chances of entering. It only offers yet another branch out of the function returning none (the last line of code in the final snippet, which is the branch taken when the first if-statement in that snippet fails).

                    Comment


                      #11
                      OK I miss read that code previously.

                      It might make more sense to have the player try against the vecpawn first, but I think epic was trying to force people to take driver (as well you'll notic epic pawns have entry radius's large enough to reach all sides fo the vec they are attached to...)

                      Comment


                        #12
                        Originally posted by PNutButterSnake
                        4. Assuming we have decided to make the player enter a specific weapon pawn, do yet another (more restrictive) check to make sure they are close to the main vehicle entry even though we already decided they are close enough to the weapon pawn we are thinking about letting them enter! This does not improve their chances of entering. It only offers yet another branch out of the function returning none (the last line of code in the final snippet, which is the branch taken when the first if-statement in that snippet fails).
                        False.

                        If you actually look at the code, you will notice an IF statement, containg an OR operator. Thus as it can pass the weapon pawn you were trying to enter to it, OR it can check if you are within the entry radius to the vehicle IF the weapon pawn returns NONE (which it can, if you are too far away from the weapon pawn, and there is a driver already).
                        Code:
                        if (ClosestWeaponPawn != None || VSize(P.Location - (Location + (EntryPosition >> Rotation))) < EntryRadius)
                            {
                                // WeaponPawn slot is closest
                                if (ClosestWeaponPawn != None && ClosestWeaponPawn.Driver == None)
                                    return ClosestWeaponPawn;          // If closest WeaponPawn slot is open we try it
                                else
                        Originally posted by Hsoolien
                        A more difficult (and probably better in the long run solution) would be to have all turrets with their own entry sphere, and then if a person enters at a turret, and it's empty, he sits there, else it pases him to the next...
                        This is what this part of the code does....
                        Code:
                        // Check WeaponPawns to see if we are in radius
                            ClosestDist = 100000.0;
                            for (x = 0; x < WeaponPawns.length; x++)
                            {
                                Dist = VSize(P.Location - (WeaponPawns[x].Location + (WeaponPawns[x].EntryPosition >> Rotation)));
                                if (Dist < WeaponPawns[x].EntryRadius && Dist < ClosestDist)
                                {
                                    // WeaponPawn is within radius
                                    ClosestDist = Dist;
                                    ClosestWeaponPawn = WeaponPawns[x];
                                }
                            }
                        
                            if (ClosestWeaponPawn != None || VSize(P.Location - (Location + (EntryPosition >> Rotation))) < EntryRadius)
                            {
                                // WeaponPawn slot is closest
                                if (ClosestWeaponPawn != None && ClosestWeaponPawn.Driver == None)
                                    return ClosestWeaponPawn;          // If closest WeaponPawn slot is open we try it
                                else                                   // Otherwise we try to find another open WeaponPawn slot
                                {
                                    for (x = 0; x < WeaponPawns.length; x++)
                                    {
                                        if (WeaponPawns[x].Driver == None)
                                            return WeaponPawns[x];
                                    }
                                }
                            }
                        
                        	// No slots in range
                        	return None;

                        Comment


                          #13
                          /me rides and hides in utter complete shame.

                          No, *I* misread that damned || as an &&.

                          I am semantically dyslexic sometimes! Sorry guys.

                          Thanks CMan .

                          Comment


                            #14
                            Hey no problem, this board was put up for people to get help

                            Comment

                            Working...
                            X