i.e. you need a type what Event should activate thes Area and you need a bounding of this area and you need some callbacks like onEnterControlArea and onLeaveControlArea.
Maybe anyone could say if we could drop the downwards compatibility with the OCFs or how we could find a way how to define it in the definition-script.
Are these areas supposed to be added to an object (definition?) via script?
InteractionArea.......baybe you could find a shorter word
The examples you gave are not really convincing as both are very special. Let me give another example for an InteractionArea - NPCs. But this has been always successfully done with Entrance-Areas so I don't understand why we need a more generalized model to handle events like Entrance and Collection zones.
I am against over-generalization that
- no one uses: we don't code interfaces for special cases whose features are not used in 99% of all cases. The interfaces should be defined to fit the normal requirements. Now with the old Entrance-zone code, one can still code something special like the NPCs I mentioned. And...
- 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.
So, to sum it up, I don't see much sense in this patch.
> 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.
>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).
right. one can replace entrance-areas, you need no 20 different callbacks to close/open entrances/collections, you just reset the array of Areas
>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.
yes i thaught it would be better to discuss before I implement something that should have p.e. an oher name or sth.
>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
Ah, ok.
>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).
OT: I'd also like to see Vertices with that feature. :] @flipping
>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.......)
>What if you want to invent an object that collects not the OCF_Collectible but the OCF_Vehicle? [...]
Like what? Thats my whole point: I think interfaces should be designed to fit the normal requirements. As long as there is a back door for special requirements like your example (-> Timer call or effect), it's fine.
On the other hand, more flexible mouse behavior could be useful. Hardcoded tree chopping for example is not the most elegant solution.
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.
int OCF
with array Criteria
in the fashion of FindObject. The problem where Carli felt offended and left the discussion was the issue with the timer. Most findobject loops are NOT not called each and every frame - because of thoughts about speed. Now of course it is possible to add another parameter to the control zone. But I am still against this because with that we hide the real complexity from the developer so that he does not directly see anymore how expensive this really is. Additionally, he has less control over how will be searched - e.g. he always needs to specifiy a box and can not specify a maximum distance or a point.
And for what? For not having to write this
for(var obj = FindObjects(mycriteria)) { dosomething(obj); }
in a timer call or effectbut this
AddControlZone(boxx, boxxy, boxwidth, boxheight, mycriteria, "dosomething", "dosomething_orperhapsnot");
The actual gain is in my opinion a very small or none.
You could replace the object CrossCheck with a more flexible solution where you would define areas and conditions. Currently, this includes collection, incineration, fight check and tumble check (clonks hit by rocks). Many objects such as arrows, traps, floor switches, monsters, etc. emulate the behavior by script. It's not terribly important, because scripts can do just the same thing as the engine here, so it would be an optimization. I'm also not sure whether a leave callback is needed, as it involves a lot of bookkeeping and is rarely needed.
Entrance areas are different because they do not actively search for objects, but are usually being searched for. They're also special because they would need engine internal support if you want to allow mouse interaction with them.
So, imo, if you want to implement ControlAreas, you should focus on areas that are actually controlled. They would have attributes like the mouse cursor set when you hover the mouse over them and callbacks for mouse clicks, drag+drop, etc.
A generalization of collection areas as an optimization may be implemented, too, but I wouldn't call them ControlArea. They might derive from a common Area class, of course, and may even share some script functions (finding areas by point, rect, etc.). Another question is whether we should allow non-rectangular areas.
- 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
>- there are callbacks when new objects enter or leave the area
Sounds like unnecessary overhead.
>Here some things where you can use it:
None of your examples sound as if the current situation there would be improved with areas.
>Sounds like unnecessary overhead.
it could'nt be more overhead than in the alternative solutions (helper objects, one frame timer)
>None of your examples sound as if the current situation there would be improved with areas.
^^same like above
>>None of your examples sound as if the current situation there would be improved with areas.
>it could'nt be more overhead than in the alternative solutions (helper objects, one frame timer)
So the reason you want to implement this is because it doesn't make things worse??
Edit: It might be easier to use for the c4script developers and streamlined in the engine code (=faster, more reliable), especially for those fast objects that are out of the area before the frame ends. Big "might" here as it strongly depends on the quality of the implementation of the Area code in the engine. Anyway, I would like to see an example of how the interface would look like.
>^^same like above
No. Neither the elevator, a trap, a goal nor an AI would ever need a 1-Frame-Timer there. If you really had a 1-frame-timer somewhere your area system could be as fast. But I cannot imagine any situation now where it would be really faster. (Except for use as a collection area where it would be easier with those areas)
-- post edited
it's an easy raytracing algorithm to calculate the continous collision of two spheres (gwX uses spheres as vertices, in OC we do really need lines, you're right)
Be x0(t)=p0+v0*t the position of object one; be x1(t)=p1+v1*t the position of object two. The distance of the two is D(t)=||x0(t)-x1(t)||. The minimum distance is at d/dt D(t) = 0. Derive and resolve t (excluding any special cases of zero velocity and such here):
D(t) = sqrt((p0x-p1x+(v0x-v1x)*t )^2 + (p0y-p1y+(v0y-v1y)*t )^2)
d/dt D(t) = 1/sqrt((p0x-p1x+(v0x-v1x)*t )^2 + (p0y-p1y+(v0y-v1y)*t )^2) * (2*(p0x-p1x+(v0x-v1x)*t )*(v0x-v1x) + 2*(p0y-p1y+(v0y-v1y)*t )*(v0y-v1y)) = 0
(p0x-p1x+(v0x-v1x)*t )*(v0x-v1x) + (p0y-p1y+(v0y-v1y)*t )*(v0y-v1y) = 0
(p0x-p1x)*(v0x-v1x) + (p0y-p1y)*(v0y-v1y) = -t * ((v0x-v1x)^2+(v0y-v1y)^2)
t = -((p0x-p1x)*(v0x-v1x) + (p0y-p1y)*(v0y-v1y)) / ((v0x-v1x)^2+(v0y-v1y)^2)
This gives you the time t at which the distance of the two objects is minimal. Clamp t to 0-1 (for the duration of 1 frame) and check if D(t) is smaller than the sum of the two sphere's radius.
(math not double checked, but you should get the point)
Question is, of course, whether all this is really necessary. The inaccuracies of doing a simple per-frame overlap check are rarely noticed.
> Question is, of course, whether all this is really necessary. The inaccuracies of doing a simple per-frame overlap check are rarely noticed.
The problem with it is the complexity of implementation, not necessarily performance issues, right? I'd actually like if we get this right, at least optionally. Correct me if I'm wrong, but I can imagine that currently quite a few object packs implement such a more accurate check themselves. I might also be possible to stop people complaining about (not) being hit by fast moving objects this way.
>Correct me if I'm wrong, but I can imagine that currently quite a few object packs implement such a more accurate check themselves.
Yupp, but less for simulating being hit by a mass (with tumbling and stuff) and more for doing some own damaging. So these objects are actually C4D_Vehicle and wouldn't really benefit from an increased accuracy there ( - still, some objects don't. Would be cool to have cannons as a deadly weapon against clonks as well :) )
> So these objects are actually C4D_Vehicle and wouldn't really benefit from an increased accuracy there
But they would if they could define a custom Area as proposed.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill