Quoting and answering myself here:
Holger wrote:About the problem of being unable to use a "horizontal impact" (hitting horizontally):
> IMO, there are several solutions possible, but they require some
> modifications or additions in the game engine.
> 1. You could add an option "Deadly when [hitting player]". IMO, it's the best
> solution, but I don't know if it is easy to implement.
I think this option is indeed missing! Currently, there are the two obvious options "deadly when touching" and "deadly when running into", and the not-so-obvious "deadly when colliding with". The third option includes two different conditions: A player reaches a tile where he would "hit" the next tile with this condition, and the CE tries to move to a tile which is occupied by a player. Especially the second case is currently also true when the CE was never moving, but *would* move to the player's tile. It is debatable if this should really count as a "collision", as the CE was never moving at all before.
Adding a "deadly when hitting player" option (that includes that the CE was moving before hitting the player) would be very, very useful, and would add to the existing "deadly when" options in an orthogonal manner.
I've just added exactly this! Seems very useful (and missing so far) indeed!
From the ChangeLog file:
Code: Select all
* added condition "deadly when <getting hit by>" for custom elements
that behaves a bit like the existing "deadly when <colliding with>",
but with the following differences:
- it only kills players or friends when it was moving before it hits
- it does not kill players or friends that try to run into it
> 2. The problem doesn't exist for the rocks and the bombs, because they
> are falling down, and I can use the "Can fall" and "Can smash [player]"
> options to do exactly what I need. So, another solution could be to define
> an optional direction for the falling elements. If I could have an option like
> "Can fall [left]", I could use "Can smash player" when the CE smashes the
> player at his right side. If the default direction is "down", the compatibility
> with existing levels is probably assured.
That's right! And I think that a concept of "can fall <up/down/left/right>" would really be useful!
This may be added later, as it requires quite some non-trivial engine changes.
> 3. A variant of the previous solutions could be to enable the "Can smash
> player" option even if the "Can fall" option is not enabled. Currently, in this
> case, "Can smash" is ignored. If "Can smash player" is ticked but not "Can
> fall", you could assume that the CE can smash the player from any
> direction.
I also agree here! Selecting "can smash" could be used for all actions that result in an "impact" action/condition, not only those related to "falling", but also those related to "moving".
I think it may be best to keep this for a potentially enhanced falling direction as described above, to be able to distinguish between "hitting" (which can result from a moving object" and "smashing" (which can result from a falling object, even if it may "fall" upwards, if this is possible one day!).
> 4. As previously suggested, recognizing the player in the change page
> conditions will certainly be sufficient to program what I need. But you have
> explained that it's not easy to do.
Finally, also this should work, to make things more orthogonal. I still have to check if this would be easy to add or if it might need more effort.
Just added this, too! This was especially missing, as people normally could expect to be able to use player elements in change pages just as normal elements, but this was not possible here and there so far. The extensions are as follows (again from the ChangeLog file):
Code: Select all
* fixed the following change conditions where a player element is used
as the "element that is triggering the custom element change":
- touching <element>
- hitting <element>
- explosion of <element>
- move of <element>
(the last two conditions already worked partially, but only for the
first player, and not for the "Murphy" player when using "move of")
Unfortunately, I cannot give an "estimated time of arrival" for one of these fixes, but I'll try to work on this as soon as possible!
As I know, I am too late with these additions (as usual), as you were already able to achieve what you wanted to do without them (which is good, as it shows that the current engine is flexible enough if the level or CE creator is creative enough! ;-) ), but here they are! I hope they will make life a bit easier at least for future level and CE designers! :-D
A pre-release to test these two new features will be available soon!