The problem was that the call to Actmap.*.StartCallLadderOverloaded happend parallely with the ladder search effect and finished after the search effect call was finished, starting a wall jump animation after the Clonk grabbed the ladder.
Extracted the basic functionality for HUDs from GUI_Controller to a library. This way, if you want to create a new HUD, you only have to include the library and all the desired components. Previously you had to copy the script from GUI_Controller, too. This holds of course only if you want to actually remove components from the HUD, and not just add to it.
Currently the GUI_Controller is referenced as the ID for the HUD, will change this to a callback.
This fix might be dangerous, I do not know it. I have no real idea what this line was supposed to do. But it certainly prevented the release use command from getting to the used item in certain corner cases (right between loading and aiming).
I tested a bunch of vehicle and they work fine so far. So maybe this line was useless and harmful after all.
The script players was not treated correctly by the goals, so joining it automatically would break stuff. While I still like the implications of an automatic script player, it was too much of a hassle for now.
Find_AnimalHostile works around the main issue as it allows just using Find_AnimalHostile and automatically have the animal work for both neutral owners and as pets. It does not allow for the distinction of hostile neutral and friendly neutral, though.
This makes the selection of the Q slot slightly more awkward because you select the target slot in between. Or to say otherwise: it is kind of like it was before.
Will construct the construction without the needed material. I often needed to test stuff with construction sites and always had to script-create all the material which is tedious.
All GetCarry* callbacks receive a parameter whether they are held in this slot and can then return a different display mode!
I also took the opportunity to restructure many scripts in a similar way.
As suggested by Zapper in this posting: http://forum.openclonk.org/topic_show.pl?pid=31073#pid31073.
This way is probably the only way item usage will ever work on Q. For now, this reverses the previous changes. Q will again react on key down.
This makes a very fundamental change with quick switch: The switching action is now performed on the key release instead of the key press. Let's see if this performs badly for players.
This will prepare the quick switch system according to Maikel's suggestion (http://forum.openclonk.org/topic_show.pl?pid=31070). The highlighting method is open to discussion. Currently, font colour and style are similar to the interaction key above the action bar icon. But it is very well possible that this will look bad when the key name is very long.
* Player enters circular region
* Game starts (after player joins)
* Player joins
* Player removed
* All goals fulfilled
* Clonk death
* Construction of structure
* Production of item
This makes it more accessible in the editor. Otherwise, there would be "libraries/constructor" folders in the object creator with the construction site as the only contained definition.
Certain ladders (in an expansion pack) should not be climbable, but this depends on the clonk that wants to climb on the ladder. Added the clonk as a second parameter to the callback, in order to not mess up the callback structure of other external packs.
The hammer will now only construct definitions that have the callback "IsHammerBuidable". This will exclude all C4D_Structure objects that are not buildings and can't be build in a meaningful way.
Also, with the carry heavy branch I want to test adhoc built lorries (lorries as construction sites). Sven suggested this.
The problems here were:
- the foundry cannot take 400 water from ice if it has a fill limit
- the pump cannot pump anything into the object if it has no fill limit
Both the initial “selected” and “last” inventory slots were initialized
to 0, making Q useless. Many melees give more than one item to the
player, filling up from the first slot. Having Q switch to the second
slot initially is better than doing nothing, which will never happen
later on.
.. so that small resolutions do not lead to even smaller scrollbars next to the power information. It's still not very aesthethic when it's multiline (because it's just so much text) but now it doesn't look horribly broken at least.
The trees actually seeded at a very wrong place in case the property "Confinement" was not set: The area.x, area.y, area.w, area.h coordinates were specified as global coordinates, but were used as offset coordinates in PlaceVegetation.
This leads to the trees seeding underground, too, unfortunately.
The trees actually seeded at a very wrong place in case the property "Confinement" was not set: The area.x, area.y, area.w, area.h coordinates were specified as global coordinates, but were used as offset coordinates in PlaceVegetation.
This leads to the trees seeding underground, too, unfortunately.
Added a callback QueryRebuy(int for_player, object base) in the vendor library. If an object that will be sold returns true in that function then the object will not be added to the base material of the selling player.
Currently the only objects that are sellable are Diamond, GoldBar, Nugget, Ruby. They cannot be rebought, just as in the previous implementation.
The existing Seed() places plants with a random chance. This makes testing the placement tiresome, so the actual placing part was moved to the new function DoSeed().
The functionality of taking construction materials from a clonk and lorries was extracted to a separate function and moved from the constructor to the construction site. This is a little bit of an esthetic decision, but it is also useful for my project that has a spacebar-interaction which takes construction materials from the clonk without the need to open the inventory menu.
In certain overloads of the object I want to be able to not eject contents, or eject only certain objects. The default behaviour of ejecting ALL contents whenever someone buys something is annoying in certain structures, such as a marketplace.
Conflicts will be merged in the next commit:
planet/Objects.ocd/Items.ocd/Tools.ocd/Pipe.ocd/PipeLine.ocd/Script.c
planet/Objects.ocd/Items.ocd/Tools.ocd/Pipe.ocd/Script.c
Added tests for adding to the queue and clearing the queue. The other tests are dummies for now. Found out that the parameter 'abort' in ClearQueue() was never used.
This special case is a relic, because I do not know whether this is actually a use case that is required in a scenario. All unit tests in the producers test pass now.
- Crosshair doesn't work with a dpad anymore. Supporting dpads adds
unnecessary complexity, as a gamepad user with dpad will never be
competitive with mouse users.
- Crosshair isn't bound to item usage anymore, but will always show
when the analog stick is outside of a deadzone.
Future planned feature: Also use the actual strength to allow
distance input in addition to direction. This is used heavily by
Knüppeln.c4s.
The callback happens in every call to MergeWithStacksIn() now, instead of RejectEntrance(). Otherwise the following use case does not work: Liquid enters crew/building and fills the contained barrels. Added a unit test for that use case. Stackable unit tests still pass.
The function RejectEntrance() has two more callbacks to the object it should enter:
- CollectFromStack(object stack): The object can grab items from the stack, before the stack tries to merge with stacks in the object. This is necessary for barrels, so that a large liquid stack can fill an empty barrel.
- RejectStack(object stack): This is called after the stack is merged. Currently, the stack merging counts as handled only if the stack is removed. This callback allows the object to still reject the stack, for example if it accepts only one item, such as the barrel does.
The previous name suggested that the object actually gets put into another object. In fact it merges the stack count with other stacks, and it does not only try to (and reverts the state if it fails), but it actually changes other objects even if the function returns false.
This got removed by accidet (checking if the object was added to another stack seemed logical). However, this whole function does not really make sense. It returns true if the object got removed only. That means that the object would not enter the other object anyway.
Removed the UpdateStackDisplay(), because that happens in TryAddToStack() if the count changes, anyway.
Maikel de Vries