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.
It was no longer used. It's also just a stretched dot. Consider using an actual stretched dot instead (i.e. round GFX and Stretch = XYZ).
The sprite was also a little unclean.
Yes, someone just had the "slow-mo" switch on. I also replaced the usage of the "RaindropSmall" particle (which was a stretched dot) with an actual stretched dot.
This does not change behavior at all, as nil-objects were later ignored in the check. Now the check is not even executed.
This does make it more likely that refactoring will keep the ignoring behaviour in place, though.
Loosely related to PR #61 - has nothing to do with the solution, though.
Improved the barrel fuse effect in two ways:
1) The fuse is not at the center of the poweder keg anymore, making it more prominent
2) When carried by a clonk the effect is at the keg instead of the clonk center
I'm not sure how exactly that issue happens, but in the attached video
it looks like C4D_StaticBack was accidentally set again. As the XOR
operation can do that, I'm changing it to always set the C4D_StaticBack
bit to 0.
The old code did some obviously wrong things like calling functions
expecting relative coordinates with GetX()/GetY(). It also sometimes ran
into an infinite loop in Cloud->Place(). I fixed those issues and
cleaned up the rest to be nicer, hopefully without changing
functionality.
The previous behaviour of only checking the background broke existing
maps and triggered some (performance?) bug in the mass mover. It is
still available by setting AutoScanSideOpen=2, for symmetry with
Top/BottomOpen.