..because the library wasn't actually USING the holding callback at all. And it had/has its own CON_Aim hackery anyway. No need for the control-library internal CON_Aim stuff then (I could imagine this might just lead to issues at some point).
Otherwise the situation could arise where you used a ControlUseStart object (the wallkit) but noholdingcallbacks was still set to true (because e.g. you used a hammer before). Then you would not be able to move the preview.
This is described in a comment to the referenced bug.
"menu" is an error prone name in one of the most frequently used/overloaded objects of the planet. Actually, there was a bug in some other thing which disappeared now. So I guess something, somewhere uses the name "menu", too.
Anyway, this is more consistent (because the other control stuff is in this.control, too) and less error prone. So it's a good change regardless of whether it actually fixes an existing bug.
Structures can use the definition call ConstructionPreview(Previewer Object, Overlay, Direction) to add any overlay to the previewer. It will be coloured accordingly.
Extracted the buy menu of the flagpole to a library, so that other objects can implement a buy menu without having to duplicate the code. An overview of the changes follows:
Library_Base:
- Moved auto-sell functionality to Library_Vendor
- Moved buy and sell functionality to Library_Vendor
- Removed the old engine menu for buying and selling
Library_Vendor:
- Added proplist for accessing local variables, avoiding variable clashes
- Added interfaces GetBuyValue, GetBuyableItems, GetBuyableAmount, ChangeBuyableAmount, GetSellValue
- Changed DoBuy: it uses the interface functions, instead of hardcoded base material
- Changed / merged the existing sell functionality and the flagpole sell functionality in DoSell:
* does not sell items if QueryOnSell returns true
* sell sound only audible to seller
* the sold object tries selling its contents first (for example a bow, if it ever were sellable. This may not hold in the settlement games, but adventures would allow it)
* the sold object ejects any contents before it is removed. These are usually unsellable objects. Previously they would just be removed together with the object. It has to be tested whether this places the items on the ground or at the center of the sold object
* removed the "sell all" functionality on right-click for the moment.
- Still has some functions from the old base selling: CanStack and GetSellableContents, for the auto-sell functionality
- Fixed a logical error in AllowBuyMenuEntries
- Distinguish between buyer/seller and payer more, so that the logic can easily be changed in one line later
- Allow for runtime overloads of interface functions
- Changed inconsistent variable naming to a more consistent one
- Added namespaces to all sounds, the "UnCash" sound still does not exist
- Added localization strings for insufficient wealth
- Fixed property name error (missing 'e')
- Buy menu is active by default
Flagpole:
- Replaced the custom sell functionality (how many of these do we have actually??) with the sell functionality from Library_Vendor
- Buying menu is allowed if the rule is active
System.ocg/Object.c
- global functions Buy and Sell ask the target if it is a vendor, instead of whether it is a base, and do the callback there.
- renamed the argument so that it is no longer called "base", but "vendor"
This is solved via another entry in the production menu (below the products), which is updated by an effect, that is being told the menu ID/target by the interaction menu through a callback.
This setup allows for very intrusive changes to the interaction menu with only few lines of code!
The players have no notion about the midpoint of an object and are thus confused when clearly standing in front of something and not being able to interact with it.
(Yes that happened in a Let's Play and yes, that's why the interaction menu also uses Find_AtRect.)
Because it's an interaction. It should use the interaction interface and not some self-made hack. Previously, setting down a carry heavy object would always be executed even if aborted with Space+S.
We are looking for free objects. So for OCF_InFree and not for Not(OCF_InFree). Now Clonks are e.g. unstuck when the landscape adjusts to a construction site.
A single player now receives four times more wave bounty than before, scaling up to four players. It's still challenging but I believe now doable.
Enemies should no longer jump off airships when being shot at.
Fixed a typo in the airship appendto script.
Fixed a possible null pointer when changing weapons.
The player interface is now similar to how picking up works. This should increase acceptance. Also it was pretty fucked up before. The action bar is gone.
The script logic is now outsourced into a new library similar to the other stuff.
Objects can overload the selector for the new interaction (see "call elevator case").
Additional issues hit and resolved when working on this:
Shifting a cursor did not cancel certain actions (and there was no callback for that). This is now solved by adding two new callbacks.
Issues hit and not resolved:
Certain interactions (calling an elevator case, flipping a construction) are in some control library. They should be in the respective objects (and shown via callbacks etc.). Meh.
The internal interface (declaring interactions etc) has a few places where proplists are just translated because the properties are called differently. This is also a fuckup (i.e. a.interaction_object = b.Object) where the properties should just have been called the same in all places from the beginning.
The name "Action Bar" is pretty misleading now as it is no bar. But that's not something visible to the players. todo: cleanup.
..by not using proplist access too much. I noticed the Playground would start lagging (debug build) and the profiler told me it was the mosquitos.
Before, 83% of the time in Mosquito::Activity was spent in MoveToTarget. After the change, only around 70% (multiple runs).
Is this a sensible way to measure the change?
Previous:
[14:30:22] 00186ms Mosquito.Activity
[14:30:22] 00155ms Mosquito.MoveToTarget
Afterwards:
[14:37:37] 00238ms Mosquito.Activity
[14:37:37] 00172ms Mosquito.MoveToTarget
This doesn't work for intros, though, because they use simple messages. We should unify the systems to only have one dialogue system that uses new-style-menus and implement required features in those menus..
David Dormagen