"Behind the BANG!" is a new irregular blog series that looks behind the scenes of the mechanics of the game engine.
​

Over the lifetime of Celeste, bugs and exploits have been discovered from time to time, which of course need to be fixed. Sometimes they are only visual, sometimes gameplay technical. However, it is interesting in what way these bugs happen and what the background is. I would like to explain the origins of a few of these bugs (which are now already fixed).

No Splash Damage on Critical Hit
==============================
​

For a long time, critical damage was not counted for attacks that did splash damage. This refers not only to those units that are indirectly affected by the splash damage, but also the main target has never received critical damage. This meant that gear with bonus critical damage never had an effect on such attacks.

Why did this happen? Well, simply put, the logic for splash damage is written completely differently than for simple damage, so the "crit" flag was not checked at all. Theoretically we could have changed it so that all units that are affected by the splash damage also take critical damage, but we decided that only the main target is affected by critical damage. It is interesting that it was not fixed in the original game. Either no one ever noticed or the original developers never got around to fixing it.

Gate Transform on Smaller Wall Pieces
===================================
​

Anyone who works with walls will know how important gates are. You can easily transform a wall piece into a gate. But be careful! Before this fix, if you had marked several wall pieces and then tried to transform them into a gate, you would have been surprised. Some wall pieces, which should not be transformed, became gates and resources would have been spent without a gate being created.

You can see an example of this bug HERE.


But what happened? Now when selecting units, a list of units is created internally. This list is used in the command for the transformation into a gate.

Small example (5 wall pieces selected):

• [0]: Wall Piece
• [1]: Wall Edge
• [2]: Wall Piece
• [3]: Wall Edge
• [4]: Wall Edge

Now this list is iterated through one by one and it is checked whether the respective wall piece can be transformed into a gate. At each step the counter of the list is increased by 1.

The check should be positive for "Wall Piece" and negative for "Wall Edge". Those negative results must be sorted out:


[Check at counter = 0]

• [0]: Wall Piece [←] Check: Positive = Keep in List; Increment Counter
• [1]: Wall Edge
• [2]: Wall Edge
• [3]: Wall Piece
• [4]: Wall Edge

[Check at counter = 1]

• [0]: Wall Piece
• [1]: Wall Edge [←] Check: Negative = Remove Element in List; Increment Counter
• [2]: Wall Edge
• [3]: Wall Piece
• [4]: Wall Edge

[Check at counter = 2]

• [0]: Wall Piece
• [1]: Wall Edge
• [2]: Wall Piece [←] Check: Positive = Keep in List; Increment Counter
• [3]: Wall Edge

… but wait, what happened here now? Now by deleting the element the lower elements slide “up” by one index. Thus, the check for individual entries was effectively skipped here. This list is then passed to the transformation command, which then pays for those transformations that fail (for wall edge, for example). The fix was then also quite simple: go through the list from back to front. Thus the "shifting" problem was resolved. While I was writing this fix, it also occurred to me that you could theoretically transform unfinished wall pieces if you selected the wall pieces with already finished wall pieces . I fixed this by adding a check, if the wall piece is already finished (has been already built).

Incorrect Population Count Reduction on Certain Upgrades
====================================================
​

This bug really gave me a headache. For years there were problems with the pop count when it had to be updated after the completion of a technology. Theoretically simple thing, right? You would simply have to add up the pop count per unit of the relevant player. This was also implemented in the original logic, but it has a blemish. Behind the pop count, which is displayed to the player, there are two counters: Pop count of active units and the pop count of units that are being trained. Maybe you can see what I'm getting at: the pop count of active units has been corrected, but not of those that are currently being trained.

Small example: A player is training 10 Hippikons while researching the "Hippikon Champion" upgrade, which reduces the pop count per unit by one. With 10 hippikons, the "in training" pop count would have to be reduced from 30 to 20. However, that "in training" pop count value is not updated. Much worse, after training or canceling the unit, this value is only reduced by 2 each time. Means that at the end a residual value of 10 "in training" pop remains at the expense of the player.

Alright, after this bug became known I changed the logic to correct the "in training" pop count as well. I thought to myself: finally I have fixed this bug. But still I got messages that something is still wrong with the pop count . Unfortunately I could never find out in the video clips I received what caused these problems. Only after a hint from Psychosaurus (many thanks!) I was able to fix the second bug.

It turned out that when the pop count was updated, it also counted those units that had just been killed. These units no longer count towards the pop count when the death animation is played. These units are specially marked for this. However, this marking was not taken into account when recalculating the pop count. This caused the pop count to be much higher than it should be after the recalculation. Again a bug at the expense of the player.

This bug also exists in Age of Empires 3, but I don't know if it was fixed in the Definitive Edition.

Aura Effects WERE Broken
========================
​

This bug was discovered during the development of the Romans. The Roman Engineer has a special building: the Millarium. The Millarium provides a passive speed boost for all military units in the nearby area. Theoretically, you could build several of these buildings to benefit from this effect multiple times. Fortunately, there is a flag called "modify exclusive" to prevent this effect from stacking, which can be applied to the effect definition. Only there's one problem with this system: it's broken.

In August 2020, PF2K pointed out a strange bug to me: The Palintonon from the Romans can move when unpacked if a Millarium is nearby. Very strange... Well, what do the Millarium and the unpacked state have in common from the Palintonon? Theye both apply a "modify" effect.

• Millarium: +5% Speed (modify exclusive)
• Unpacked palintonon: -100% Speed

So far, so good. But how does "modify exclusive" work anyway? Modify effects are added or multiplied together until one of the effects has the "modify exclusive" flag or the entire list has been processed.

The important thing here is that a different order also gives a different result. Example:

1. Modify Effect: +20% Speed
2. Modify Effect: +50% Speed (+ modify exclusive flag)
3. Modify Effect +30% Speed

This means that the 1st and 2nd speed effect will be applied (+20% and +50%).

Different with this order:

1. Modify Effect: +50% Speed (+ modify exclusive flag)
2. Modify Effect: +20% Speed
3. Modify Effect +30% Speed

Here only the +50% effect is applied, because while working through the list the "modify exclusive" flag was already detected at the 1st element.

It is the same with the Millarium and the unpacked Palintonon:

1. Unpacked Palintonon: -100% Speed
2. Millarium: +5% Speed (modify exclusive)

… would be fine, because both -100% Speed and +5% gets applied.

With

1. Millarium: +5% Speed (modify exclusive)
2. Unpacked palintonon: -100% Speed

... only the +5% speed is applied. Therefore, then unpacked palintonon can move.


In summary, this means that it depends on which effect is applied first. If a millarium was built near an unpacked palintonon first, then this bug would not be triggered.

The fix for this bug was to add a new flag called "no stack". In contrast to "modify exclusive" only the same effects are sorted out. So the development of the Romans could be continued in order. In Age of Empires 3: DE the bug was also identified and fixed in the same way.

Units Ejecting Over Cliffs
======================​

Unloading units is a mechanic that is not so easy to implement. For an unload command, a suitable position must be found. However, the logic behind this is different for water units and land units. The obstruction system plays an important role here. But what is this obstruction system anyway?

The Obstruction System
=====================
Obstructions in AOEO can be compared to a hitbox. It describes which areas are occupied and how. This can be used to prevent units from moving over these obstructions or to prevent buildings from being built on these areas. The obstruction system is also very important for pathfinding to calculate efficient movement paths. A distinction is made between object obstruction and terrain obstruction. For terrain obstruction, you can think of it as a multilayer grid.

​

So there is land terrain obstruction and water terrain obstruction. For terrain obstruction, you can think of it as a multilayer grid. So there is land terrain obstruction and water terrain obstruction. Land units therefore cannot move on water terrain obstruction. Likewise, water units cannot move on land terrain obstruction. For terrain obstructions there is another special category: cliff terrain obstruction.

​

Ejecting units over cliffs
======================
Now, one would assume that units cannot be unloaded over cliffs. But this was not the case until our fix. In fact it is still the case in Age of Empires 3, as it is not seen as a bug. For water units, there may be a distance of up to 12 meters between the Merchant Transport and the unloading point.

​

Now, for water units, the closest possible point between the unit and the unloading point is calculated, minus water terrain obstructions and cliff terrain obstructions. Heard correctly, cliff terrain obstructions were included in the calculation for whatever reason. With a distance of 12 meters you could (if you tried hard enough) unload the units over cliffs.

​

How was this bug fixed now? Actually quite simple: The cliff terrain obstruction is simply no longer included in the calculation of the unloading point. Therefore, a point would be calculated on the cliff, which is then invalid and the units can no longer be unloaded.

Unloading land units from land units (e.g. Ox Cart) is a bit different. Here it is calculated if there is an obstruction between the selected unloading point and the landing unit (which transports the units). Here the distance is only 3 meters (compared to the 12 meters for water units), but still sufficient to unload units over cliffs:

​

For the obstruction check, however, only the existence of an enemy building (e.g. wall) to the unloading point was checked. For the fix, this check was extended with the cliff terrain obstruction. Since then no units can be unloaded over cliffs.

Example 1
Example 2

What do you think about the blog? Let us know in the comments below!

========
Previous Behind the BANG! blogs:

• Caravans
• Prioritize!

========

All current and future content will stay 100% free and accessible to everyone.

========
Thank you so much for reading, and we will see you all next time!

Project Celeste Development Team
========
The Romans are here! Watch the Overview Trailer.

Project Celeste is completely free and always will be. However, we gladly accept donations for our overhead costs, which are larger than we have budgeted. If you want to support us, you can do so HERE.

Read every Romans related blog HERE.
Read every Indians related blog HERE.

Tell your friends! Join our Discord HERE.
========

​