Merge pull request #1590 from leetfin/master

Neutralize remaining instances of gendered language

doc/ideas/gameplay.md

@@ -144,7 +144,7 @@ A mode similar to *Trouble in Terrorist Town* and *Secret Hitler*. The game star
 
 ### Pure Battle Mode
 
-No buildings, just units. The game generates a map and players can choose a starting position. Then they have a few minutes and a set amount of resources to select an army composition and some techs. After the first phase is over they place their units on the battlefield and have to use what they assembled to destroy their opponent. Utilizing height advantages, microing and tactical positioning contrast the strategic decisions of creating the army. The player who destroys his opponent, inflicts the most resource damage to others or holds strategic positions wins the battle.
+No buildings, just units. The game generates a map and players can choose a starting position. Then they have a few minutes and a set amount of resources to select an army composition and some techs. After the first phase is over they place their units on the battlefield and have to use what they assembled to destroy their opponent. Utilizing height advantages, microing and tactical positioning contrast the strategic decisions of creating the army. The player who destroys their opponent, inflicts the most resource damage to others or holds strategic positions wins the battle.
 
 ### Micro-nerd Mode (or Mod)
 
@@ -373,7 +373,7 @@ Relics & Kings
    - e.g. they can have attack bonuses for special units or economic/military bonuses
    - special abilities for every relic could either be generated when the map is generated or when the relic is discovered based on the actual needs of the player
    - so the later you go out to get the relic the more it could get useful for you, because it could be better shaped on your personal military/economy but the risk is higher, that another player was going out before you
-   - if a player scouts the relic first and the ability gets generated in this moment, it will be for the player who scouted it first, so he knows, that this relic could help their own economy/military alot so the player will try to fight about this relic against the enemy heavily -> new gameplay aspect
+   - if a player scouts the relic first and the ability gets generated in this moment, it will be for the player who scouted it first, so they know, that this relic could help their own economy/military a lot so the player will try to fight about this relic against the enemy heavily -> new gameplay aspect
 
   - Relics could have ranged attributes
     - idea of the devs of AoE II

doc/media/original-metadata.md

@@ -2,7 +2,7 @@ Original Metadata
 =================
 
 All data relevant for the game (e.g. how much costs building the castle?
-What cultures exist? Can my priest overclock his "Wololo?")
+What cultures exist? Can my priest overclock their "Wololo?")
 are stored in a binary format in the file `empires2_x1_p1.dat`.
 
 The format is described in the [huge struct definition](/openage/convert/value_object/read/media/datfile/empiresdat.py).

doc/nyan/api_reference/reference_resistance.md

@@ -317,7 +317,7 @@ Resistance to the `MakeHarvestable` effect.
 Resource spot that should be made harvestable. Effects of type `effect.discrete.make_harvestable.type.MakeHarvestable` are matched to this resistance if they store the same `ResourceSpot` object in their `resource_spot` member. Additionally, the target needs to have a `Harvestable` ability that contains the resource spot.
 
 **resist_condition**
-Condition which must he fulfilled to make the resource spot harvestable.
+Condition which must be fulfilled to make the resource spot harvestable.
 
 ## resistance.discrete.send_to_container.type.SendToContainer
 

doc/reverse_engineering/game_mechanics/formations.md

@@ -123,7 +123,7 @@ The same rules apply, if more than two unit types are used. We will now have a l
 ..............
 ```
 
-Which unit type is sorted into the line first depends on the order in which the player selected the unit types (or how they are ordered inside the selection queue). In the first example of this section, the player selected the archers first and added the skirmishers to his selection. The second and above example would be the result of selecting longbowman first, archers second, skirmishers third and throwing axeman last.
+Which unit type is sorted into the line first depends on the order in which the player selected the unit types (or how they are ordered inside the selection queue). In the first example of this section, the player selected the archers first and added the skirmishers to their selection. The second and above example would be the result of selecting longbowman first, archers second, skirmishers third and throwing axeman last.
 
 #### Distance Between Units
 

doc/reverse_engineering/game_mechanics/monk_conversion.md

@@ -32,5 +32,5 @@ Units inside a building are not converted and will ungarrison. The same is true
 [Source](https://www.youtube.com/watch?v=_gjpDWfzaM0)
 
 * If a converted unit is "replaced" by the game, e.g. a villager changing to a farmer, the stats are not frozen anymore.
-* Converted siege units are only frozen in tech level until the new owner researches a technology that changes the units stats, e.g. chemistry. As soon as the research finishes, the units are replaced with ones that are on the same tech level as the player. Weirdly enough, Onagers are replaced if the player researches Heavy Scorpions but not if he researches Siege/Capped Rams.
+* Converted siege units are only frozen in tech level until the new owner researches a technology that changes the units stats, e.g. chemistry. As soon as the research finishes, the units are replaced with ones that are on the same tech level as the player. Weirdly enough, Onagers are replaced if the player researches Heavy Scorpions but not if they research Siege/Capped Rams.
 * The flaming projectile caused by chemistry research is tied to the tech level of the owner but the +1 damage is kept, if the unit is converted.

doc/reverse_engineering/game_mechanics/selection.md

@@ -8,7 +8,7 @@ This documents shows the methods of selecting and deselecting units.
 
 The player doesn't have to click directly on the sprite of a unit because there is a tolerance factor involved. The tolerance factor is roughly `1 unit width` horizontally and `1 unit height` vertically measured from the center of the unit. This means that clicking in the general area of a unit will be accepted as a valid selection most of the time.
 
-If two units' areas of tolerance overlap, the unit that is in the front seems to be preferred, but clicking directly on the sprite of one of the player's own units will select the unit that is pointed at. When the area of tolerance overlaps with an enemy (or ally) unit, the unit of the player will always be preferred, even if he clicks directly on the sprite of the enemy unit.
+If two units' areas of tolerance overlap, the unit that is in the front seems to be preferred, but clicking directly on the sprite of one of the player's own units will select the unit that is pointed at. When the area of tolerance overlaps with an enemy (or ally) unit, the unit of the player will always be preferred, even if they click directly on the sprite of the enemy unit.
 
 Relics and animals also have an area of tolerance regarding selection, while resource spots like trees, bushes, gold/stone mines as well as buildings don't.
 
@@ -25,7 +25,7 @@ All of these have a specific purpose and will now be explained further.
 
 ### Selection Box
 
-The selection box is the easiest way to select multiple units of any type in AoE2. When the player draws the box around the units he wants to select, the units inside the box will be added to the selection queue, **going from the top to the bottom of the box** until the limit of 40 units is reached.
+The selection box is the easiest way to select multiple units of any type in AoE2. When the player draws the box around the units they want to select, the units inside the box will be added to the selection queue, **going from the top to the bottom of the box** until the limit of 40 units is reached.
 
 The tolerance factor is also used here, which can result in units which are slightly outside of the selection box to be selected.
 

doc/reverse_engineering/game_mechanics/switching_villager_tasks.md

@@ -22,4 +22,4 @@ Note: This only happens if the builder was actively working on the construction
 
 ## Weird AoE2 Quirks
 
-* If the cheat `aegis` (villagers gather instantly from a resource) is used in a game and the role of a villager changes from "hunter" to "shepard", he will dump all of the resources he is carrying "into" the sheep.
+* If the cheat `aegis` (villagers gather instantly from a resource) is used in a game and the role of a villager changes from "hunter" to "shepard", they will dump all of the resources they are carrying "into" the sheep.

doc/reverse_engineering/game_mechanics/town_bell.md

@@ -48,4 +48,4 @@ As soon as the town bell is triggered, the algorithm searches for villagers that
 
 In the next step, the algorithm tries to find the nearest garrison for a villager by calculating the distances between the villager and all buildings on the second list. The closest distance calculated and the corresponding garrison are then saved. Afterwards the villager is put into a third list, which is sorted by the *closest distance to any garrison*. This step is repeated for every villager.
 
-Last but not least, the villagers are assigned to a garrison. Since the third list is sorted by closest distance, villagers that are the nearest to a building are guaranteed to get a place, which satisfies the condition that towers prefer the villagers close to them. If the villager is assigned to a building which is already full, the algorithm recalculates the distances to other garrisons and sorts him back into the list.
+Last but not least, the villagers are assigned to a garrison. Since the third list is sorted by closest distance, villagers that are the nearest to a building are guaranteed to get a place, which satisfies the condition that towers prefer the villagers close to them. If the villager is assigned to a building which is already full, the algorithm recalculates the distances to other garrisons and sorts them back into the list.

doc/reverse_engineering/game_mechanics/wolves.md

@@ -14,7 +14,7 @@ Line of sight depends on the selected difficulty of the game.
     Hard      12 tiles
     Hardest   12 tiles
 
-As soon as a unit moves into the LOS of a wolf, he will chase and attack the unit. However some unit types are ignored, including:
+As soon as a unit moves into the LOS of a wolf, they will chase and attack the unit. However some unit types are ignored, including:
 
 * King
 * Trade Cart

doc/reverse_engineering/networking/02-header.md

@@ -20,7 +20,7 @@ end
 ## Description
 
 *:network_source_id*<br/>
-The *:network_id* of the person who sent the packet. A *:network_id* is different for every game, but is not generated randomly for all players. When joining the lobby, every player gets assigned `last_network_id - 2` as his own *:network_id* where *last_network_id* is the ID of the person who joined before him.
+The *:network_id* of the person who sent the packet. A *:network_id* is different for every game, but is not generated randomly for all players. When joining the lobby, every player gets assigned `last_network_id - 2` as their own *:network_id* where *last_network_id* is the ID of the person who joined before them.
 
 *:network_dest_id*<br/>
 The *:network_id* of the person who should receive the packet. Is only used for sync packets and remains unused for most commands.

doc/reverse_engineering/networking/06-chat_message_spoofing.md

@@ -23,7 +23,7 @@ To construct a message the following parameters are needed:
 * Player number of the spoofed sender
 * Player number of the receiver(s)
 
-An attacker that is in game with other players will have no problems getting to know the player numbers. As the game is constantly synced, he can easily get the value for *:communication_turn*.
+An attacker that is in game with other players will have no problems getting to know the player numbers. As the game is constantly synced, they can easily get the value for *:communication_turn*.
 
 Deriving the valid Sender ID of the receiving player is more difficult and depends on the attacker's ability to capture network traffic. The easiest way to discover all Player IDs is by capturing a few packets of normal gameplay beforehand. The IDs of Players 1-8 have a fixed byte position in the data stream.
 

doc/reverse_engineering/networking/08-movement.md

@@ -74,7 +74,7 @@ end
 Always has the value `0x03`.
 
 *:player_id*<br/>
-The ID of the player who moves his units (`0x01` - `0x08`).
+The ID of the player who moves their units (`0x01` - `0x08`).
 
 *:zero*<br/>
 The two bytes following the *:player_id* are unused.