PauseUse can be called between ControlUseStart and ControlUseStop/Cancel. In this case ControlUseStop set aim_stop=1 but didn't actually stop reloading (which is somewhat fine). However, this led to PauseUse being called when e.g. tumbling or climbing.
And this again would lead to CON_Use being reissued even though the mouse button was not held down, leading to the Clonk being in aim mode.
The functional change here is that you will not continue reloading after tumbling/climbing when you are not holding down CON_Use anymore, which is consistent with other stuff.
Related to #1970 and 5fc07df757
This replaces the very hacky implementation just for the dynamite with a more general solution (and e.g. also works with the grenade launcher).
When the damage times the total component value was much lower compared to the total HitPoints (e.g. with basements), the damage could sometimes not be repaired.
This is fixed now.
var a = {B=1}; var b = new a {B=1}; would include "B" twice in the list of properties.
This lead to an actual issue when calculating component value for repairing buildings
The GIDL is now C4D_Living and C4D_StaticBack, preventing it from moving. At first I thought that adding an underground vertex would be sufficient, but that still made the idol move/shake when hit.
The old icon overlay was behind the numbers in the inventory menu anyway. Now the object uses a bar similar to loam. And it also updates its description.
When turning empty, the (new) barrel is also no longer play-colored inside.
The powder barrel could of course just use actual gunpowder and be an extra-slot item (like the bow / dynamite box / etc.).
This reverts commit 8698aa25cf.
Tackling #1970. The implementation in the reverted commit was incorrect (i.e. only one out of two "GetStackCount" were replaced with GetInteractionMenuAmount, leading to weird behaviour). If you want to replace it, please do it in a way that no call to IsInfiniteStack will be required. And this hack would probably require so much more bloat code that nothing would be gained (i.e. what happens when you put two infinite arrow stacks in one container?).
The bug report complains about the "display stopping at 999" *in some situations*, which was due to Stackable_Max_Display_Count. It's gone now. And that it was not limited to 999 in all situations (like the code would have suggested) is probably due to the things I described above.
# Conflicts:
# planet/Objects.ocd/Libraries.ocd/LiquidControl.ocd/Liquid.ocd/Script.c
# planet/Objects.ocd/Libraries.ocd/Stackable.ocd/Script.c
The shield and bow both use fx.aim_weapon, but the ranged weapons AI thinks that a shield works the same way as a bow and tries to fire it - in order to prevent this, the AI now also checks whether the equipped item is a IsRangedWeapon. This _could_ have an impact on the vehicle AI, but the unit test worked fine.
While saving the landscape, solid masks are temporarily removed. This
did not work for half solid masks, resulting in permanent solid masks
after restoring the save game.
Instead, the lorry asks a container whether it should eject its contents. This is done via the callback LorryEjectionOnEntrance(object lorry) in the object that is being entered.
The old callback NoLorryEjection(object lorry) is obsolete.
Removing liquid collection from the lorry is a side effect, but it is not bad. The lorry behavior was weird anyway, because you could for example put lava and wood in it, without the wood burning etc.
The unit test does not really pass for now (it never did before, because it is not finished yet and used for testing the different transfer function behavior only)
Most scancodes are two hex digits long, e.g. "$24" (J). However, there
are also a couple keys like Backspace ("$e") and Escape ("$1") with a
single-digit scancode. These previously weren't restored correctly.
The matching had a few issues:
Items with the same symbol were supposed to be stacked, but the "symbol" changed from ID to object at some point. So same-type objects were no longer correctly matched.
Items with different text (e.g. amount) but everything else the same should be stacked. But simple proplist equality is obviously not sufficient to determine whether the contents of the proplist changed.
The order of the items is generally more stable now. I hope this doesn't introduce other issues.