I think they should be added in the init script or when the door is opened/closed

InteractionArea.......baybe you could find a shorter word

> The examples you gave are not really convincing as both are very special.

It might prove useful for objects like the submarine where the collection area changes when it turns (although we could also think about always flipping entrance&collection depending on an object's dir).

> But this has been always successfully done with Entrance-Areas

I would certainly not be sad if we get rid of this hack.

> we don't code interfaces for special cases whose features are not used in 99% of all cases.

If there is somebody doing the work (and maintaining it), why not? As long as it doesn't get in the way for others I don't see a problem there.

> makes the standard usage more complicated: Defining Entrance=10,10,80,80 is certainly easier than defining a control zone with the right callbacks and coding, even if there is some pre-defined door-Entrance-object from which objects can inherit.

Nobody says that the Entrance definition in the DefCore needs to go away. It can just do something different internally, such as creating a default InteractionArea.

> So, to sum it up, I don't see much sense in this patch. I approve that you show so much motivation to improve OpenClonk but before you take the trouble to implement stuff, you should wait for some feedback on that. Just an advice to not waste time.

There is no implementation yet. Just a patch marking locations in the code where changes need to be applied to make this happen. So what you describe here is actually just what Carli did. Also, I think that having a patch before having discussed things in every detail is not necessarily bad - it gives a basis for the discussion, and it might help making clear one's ideas.

>I am against over-generalization that

It is not an over-generalizing.
But an area which calls a certain callback when an object with a fixed OCF enters the area and it makes a callback whether the object should enter this container is, i think, a bit too specialized. What if you want to invent an object that collects not the OCF_Collectible but the OCF_Vehicle? You have to work with one-frame-timers, helper objects etc.

For downwards compatibility we could, like Clonk-Karl said, generate dummy-Areas, one for Collection, one for Entrance (but my plan was to replace them.......)

Multiple Entrances would certainly be used. The amount of code needed to work around their lack is astounding. Multiple Collection areas are not really needed, the submarine works just fine with RejectCollect. And if somebody gets around to convert the Collection area to a property, or implements flipping them as ck suggested, even the submarine doesn't need special area code in it's script.

On the other hand, more flexible mouse behavior could be useful. Hardcoded tree chopping for example is not the most elegant solution.

I kinda like the idea. So I've thought about a concrete concept:
You can define such areas (the name doesn't matter. Areas in Clonk are called 'zones', so ControlZone, ActionZone, TriggerZone, InteractionZone, whatever. I call them ControlZone) with:
int AddControlZone(int iX, int iY, int iWidth, int iHeight, int OCF, string EntryCallback, string ExitCallback);
The return value is the zone's unique id (unique for every object) to manipulate the zone via Set/ChangeControlZone(int ID, int iX, int iY, int iWidth, int iHeight, int OCF, string EntryCallback, string ExitCallback); and RemoveControlZone(int ID);

I think the function is almost self-explanatory. Whenever an object with the matching OCF enters the zone, the entry callback is called, whenever it exits, the exit callback (both optional parameters, you may leave out the exit callback e.g.).
CollectionZones would be replaced with CollectionZone.c4d. Objects may inherited this interface and create the zones via Add/SetCollectionZone(int iX, int iY, int iWidth, int iHeight); (private function of CollectionZone.c4d) or, if you want to stick to the 'DefCore' solution, CollectionZone.c4d may define its own Initialize where reading out the values from the object's proplist. The entry callback of CollectionZone.c4d calls RejectCollect and Collection aftering entering.
This may replace at least CollectionZones and TransferZones. Beyond that a good amount of findobject-loops would become obsolete. Sample applications are scenario script progress, your homing missile launcher (or the fireball spell? But moving ControlZone may overcomplicate everything).

At all, not a must-have but nice to have.

/edit
Of course, this is no solution to replace EntranceZone or similar.

you're right. I'll wait for some ideas that make sense to implement (f.e. an exactly idea of collection areas etc.) but it makes no sense to merge entrance with collection

Summary:
- Entrance will stay Entrance
- Collection, traps, grabbing areas, incineration, fight check, tumble check etc. will get a new interface called Area
- an Area can be accessed as an array of objects
- there are callbacks when new objects enter or leave the area (only regarded when callbacks available, also notice objects that "fly through" by an enter and an exit in one frame)
- the object in the area can ask whether it is in such area (f.e. when you press double-down) and cann invoke a callback for the area (f.e. "i pressed double down")

Here some things where you can use it:
- waiting for clonks at the elevator
- traps
- goals where you have to bring an object to a certain place
- AIs where the enemy detects who is in his range
and much more