Gah - a solution with more questions. – EntropicLqd
Difference between revisions of "User:Rejecht"
From Unreal Wiki, The Unreal Engine Documentation Site
(→Players who are out can sometimes respawn) |
(→Players who are out can sometimes respawn) |
||
Line 29: | Line 29: | ||
While this solved the original problem, it also introduced another problem: | While this solved the original problem, it also introduced another problem: | ||
* This triggers LateEntryLives (which defaults to 1), forcing latecomers to become spectators (bOnlySpectator) at login, and some people losing hair because they now have a new unwanted behaviour. | * This triggers LateEntryLives (which defaults to 1), forcing latecomers to become spectators (bOnlySpectator) at login, and some people losing hair because they now have a new unwanted behaviour. | ||
− | This is because some players now get (NumLives == 2), and others get (NumLives == 1), depending on the circumstances in TeamGame.ScoreKill. | + | This is because some players now get (NumLives == 2), and others get (NumLives == 1), depending on the circumstances in TeamGame.ScoreKill. Login checks LateEntryLives against all players and boots the player to a spectator slot when it finds (NumLives (2) > LateEntryLives (1)). |
Other possible approaches to solve the first consequence: | Other possible approaches to solve the first consequence: |
Revision as of 17:29, 26 February 2012
Contents
About
Haphazard hobbyist programming sessions.
Nice to know
- NumLives is not the number of lives. NumLives is the number of deaths (the number of lives used).
- Errors found in Unreal Engine 2.5 may also be present in the UDK.
Game mechanical errors discovered in Unreal Tournament 2004
Players who are out can sometimes respawn
Triggers for this error:
- It must be a TeamGame.
- (MaxLives > 0) - Assume that this example has (MaxLives == 1)
- TeamGame.ScoreKill has the errors.
Consequences:
- The player can respawn despite having died the allotted MaxLives.
Cause:
- The ScoreKill logic in TeamGame does not always call Super.ScoreKill, which is the one handling the NumLives count and sets bOutofLives accordingly.
First attempt:
- OK, so let's just override ScoreKill and increment NumLives ourselves, before or after calling ScoreKill, since it expects (NumLives >= MaxLives).
First consequence of the first attempt: While this solved the original problem, it also introduced another problem:
- This triggers LateEntryLives (which defaults to 1), forcing latecomers to become spectators (bOnlySpectator) at login, and some people losing hair because they now have a new unwanted behaviour.
This is because some players now get (NumLives == 2), and others get (NumLives == 1), depending on the circumstances in TeamGame.ScoreKill. Login checks LateEntryLives against all players and boots the player to a spectator slot when it finds (NumLives (2) > LateEntryLives (1)).
Other possible approaches to solve the first consequence:
- Clamp the value in your ScoreKill.
- Set LateEntryLives to MAXINT in InitGame to override any ini setting, unless you want to use LateEntryLives.
ToggleScreenShotMode does not restore Handedness
Scope:
- PlayerController.ToggleScreenShotMode
Type:
- Save/Restore
Fix:
- Remember and restore Handedness.
TakeDrowningDamage
Scope:
- Pawn.TakeDrowningDamage
Type:
- Access Error
Fix:
- Check (Controller != None) before calling Super.TakeDrowningDamage in a subclass of pawn .
PlayTakeHit never played drowning sound
Scope:
- xPawn.PlayTakeHit
Type:
- Class Check Error
Corrections:
- Find: DamageType.IsA('Drowned')
- Replace With: DamageType == Class'Drowned'
Reminder:
- Do not use IsA with a class object (Class<DamageType> Class_DamageType).
- Use IsA with an instance of a class object.
(...) more to come.