I know how I can listen on collisions:
collision.on('collision', function(e){
//e is one element involved in my collision
});
But how to I get both bodies involved? Only one body is passed to this function.
I think the answer you're looking for might already be here. And the good news is you were already onto the right thing :) Looking at the Famo.us source code (line 122), the Collision class emits pre/collision/post events along with a collisionData object which contains the source and target bodies of the collision.
Here's an existing answer which demonstrates how to access this data in the collision event.
famo.us access to collisionData upon collision event
Hope this helps
I'm not 100% sure about what you're trying to achieve, but in order to get two (or more) Physics Bodies to collide with each other you should apply() the same collision object.
I like to think of collision objects as managers, which control who gets to collide with who. I've known some game engines to picture this differently, with collisions being purely events or types.
The most simplistic example I could give:
physics.attach(collision, myFirstFamousPhysicsBody);
physics.attach(collision, mySecondFamousPhysicsBody);
Note: I flagged this as a duplicate and the moderators felt it was a different question, although you marked the answer pointing to a correctly answered duplicate.
Answer:
The target and source returned are the Body objects you attached to create collision.
collision.on('collision', function(e) {
var targetBody = e.target;
var sourceBody = e.source;
});
Related
I have made a LazyRow that i now want to be able to get the scrollposition from. What i understand Scrollablerow has been deprecated. (correct me if im wrong) The thing is that i cant make a scrollablerow so i thought lets make a lazy one then. but i have no clue how to get scrollposition from the lazyrow. i know how to get index but not position if that eaven exists. here is what i have tried.
val scrollState = rememberScrollState()
LazyRow(scrollState = scrollstate){
}
For LazyScrollers, there are separate LazyStates.
I think there's just one, in fact, i.e. rememberLazyListState()
Pass that as the scroll state to the row and then you can access all kinds of info. For example, you could get the index of the first visible item, as well as its offset. There are direct properties for this stuff in the object returned by the above initialisation. You can also perform some more complex operations using the lazyListState.layoutInfo property that you get.
Also, ScrollableRow may be deprecated as a #Composable, but it is just refactored, a bit. Now, you can use the horozontalScroll() and verticalScroll() Modifiers, both of which accept a scrollState parameter, which expects the same object as the one you've created in the question.
Usually, you'd use LazyScrollers since they're not tough to implement and also are super-performant, but the general idea is that they are used with large datasets whereas non-lazy scrollers are okay for small sized lists and stuff. This is because the lazy ones cache only a small fraction of the entire list, making your UI peformant, which is not something regular scrollers do, and not a problem for small datasets.
They're like equivalents of RecyclerView from the View System
Now, before I start, I want to say that I am aware that there are no standard way to implement an ECS. However, there is one method that I am interested in, but confused about one particular thing.
Say you have an Entity with a TransformComponent (contains a position), and a RenderComponent (contains a Sprite), and along with this you have a RenderSystem separate from the Entity.
The RenderSystem will handle the rendering of all components with a RenderComponent, and will not care what entity it is attached to. But since a Sprite requires a position, the RenderSystem will need the TransformComponent as well.
Now comes the part I am confused about, if all components are stored in their own vector of that component type, how will I get all entities that have both a TransformComponent as well as a RenderComponent? I do not want to use the naive method of looping through all entities in every system, pulling out entities that have both these components, but rather have every component in a vector of the component type.
Also, how would the systems know 2 components belong to the same Entity? Will the components have an EntityID attached to it?
Edit: I just realized something, if RenderSystem loops through all RenderComponents and gets the entity, then checks if that entity also contains the TransformComponent, then it can render it. But that kinda ruins the whole "Systems don't care about the entity", this also requires that the component has an EntityID which I am still unsure if it should have. Someone please clarify all this for me.
This part is call Entity Handler, and it's something which can need a lot of work.
The simplest form that i know is something like that:
Move every Components into one big array (cache is King).
You'll need an enum for each Component:
enum E_Component {
Velocity,
Position,
...
};
And now your Entity is just an index and an array of component index.
struct Entity {
unsigned index;
unsigned components[NB_COMPONENTS]; // -1 if nothing
};
So if a System need to update the velocity component, all you need to do is to loop through your entities, check if there is a velocity component and update it.
==> System don't care about entities, only about components.
There is a lot of better way to do it, take a look at this article
I'm working on a project that has evolved so many times, I've really started thinking about writing a generic class that controls other nested generic classes.
The issue is, I have so many ways I could go about it that I've become completely overwhelmed. I've reviewed vectors and template class examples, but I truly have no idea how to begin.
Let me explain,
I need to be able to use this template to create an object that I control directly.
The main, top level object, is the robot I'm working on documented here (Probably not helpful to read, included as reference):
Github: MiddleMan5/Onyx-BeagleBone which pulls from:
Github: MiddleMan5/Project-Onyx-Quadruped
(New member 2-link restriction)
Which has the C++ Assembly.h file I'm working on making generic:
"Assembly File"
Now I'm sorry if my syntax is a little rusty, I'm very new to C++ in a general sense. I have great difficulty with pointers, object vectors, etc.
I'm really just looking to be guided in a general direction of study, and less a "Fix my code!" answer.
Bear with me as I may mar C++ terms:
I want to be able to create any type of robot configuration and manipulate EITHER it's individual assembly's End Effectors, or the entire chassis as a point particle physics object (if the robot is mobile).
This would allow me to use the same template to create a robot arm as well as my intended Quadruped. (Which is, in reality, a solid mobile mass that has a center and 4 "Arms"
Each initialized Robot must contain only one Body that in-itself contains at least one Base, one Joint, and one End Effector.
The creation of Top-Level object should fail if any of these things should fail to be included before Body.assemble creates the now-active robot. (Body.assemble creates Chassis Onyx)
I can now move the entire structure by saying something like Onyx.Leg(1).move(X,Y) or Onyx.rotate(X,45); //Move all legs to satisy final body rotation angle
Documented in my Brainstorming file here: Please at least skim.
This file contains diagrams and the "definitions" I'm using to prototype pseudo-code.
I only want one "Robot".h and "Robot".cpp to define actions, movements, sizes, shapes, etc. and one Main.cpp to provide entry into the code. (Maybe I'm asking a bit much) but logically to me, this seems do-able.
Includes:
Main.cpp
|_
| Onyx.h
|_Onyx.cpp //Body.move, body.rotate, body.raise
|_Assembly.h To create the body as a combination of assemblies
Onyx as a quadruped looks like this:
ONYX Complete Diagram Example:
EE EE
|| __ ||
| | | |
0__0+__+0__0
_||_
__0+_ _+ <- 0__
0 \/ 0 <-\
| | <- - "Leg" and Body are two attached assemblies inside one complete containing Robot chassis
|| || <-/
EE EE
Should be controlled like:
Onyx.EE1.moveTo(x,y);
or:
Onyx.moveTo(x,y);
Where I could further define gaits and parameters that would allow the robot ro take steps to move it's entire chassis to location (X, Y)
and has definitions for joints, links, and bases as such:
|Joint: Takes X and Y coordinates, rotates Link. ----0----
|__ End Effector: A joint combined with an attached Link. --------EE
|__ Base: A joint created that can be fixed statically through a link to another base joint
| |__ Can be attached actively to a link and a joint
| |__ Can be used as a static reference to an assembly (Such as a leg) and attached to a joint on a different plane
|
|__ Primary Joint: the joint(s) that attach directly to the Body's base(s)
|Link: A length of physical mass between a joint.
|__Segment: two or more attached in-line links (multiple links combined at different angles can specify independent shapes or masses).
Segments are useful for attaching spaced Bases. (Attach.Base(Segment1_2(End)); Segments can be attached either by their additive L1 or L2
I really am frustrated because the project has very quickly become way to complicated for me to even understand. This is why I was looking at creating a template. But it doesn't seem like accessing an object's object's method (Onyx.leg.move) is even possible in C++. Am I wrong?
If you actually read through to the end I want to give you a hand. Any advice you have on areas of study (Or advice to make my question clearer) would be GREATLY valued.
Thank You
Edit:
Okay, I went ahead and created a Class 'Assembly', which has methods to access a private subclass 'assemble' which attaches a "Leg with links n" to the assembly (god I need a different name) with subclass's Base, Link, and End_Effector. I guess I'm going to have to write individual methods and method handlers for each subclass of a subclass. This seems way to ugly and complicated with plenty of room to make errors.
The pseudo-flow as follows:
Assembly Onyx //Creates Robot: Onyx
Onyx.assemble(4, 3, 2); //Adds 4 legs each with 3 joints which includes 2 axis
for(i; 0 ---> 3)
Onyx.numleg_numL_length(i,1,114); //Defines L1 of Leg1 as 114mm
Onyx.numleg_numL_length(i,2,140); //Defines L2 of Leg1 as 114mm
and on and on and on and on.
Please tell me there's a simple trick that allows me to assign multiple variables to a named class instead of this infinite chain of methods functions and subclasses
Is there a way to get all of the PointerIDs that might be used in the CoreWindow::PointerPressed??
I know that I can get the ID for the Mouse by using:
// This is wrong, see the comment below.
MouseCursorID = CoreWindow::GetForCurrentThread()->PointerCursor->Id
EDIT:
The above block of code gets the 'Resource Id' for CoreCursor. It IS NOT the same thing as the pointer ID!
So how would one go about finding the different Ids for the various pointers? I am especially interested in this because I want to be able to discern input from two different mice, and being able to identify them before receiving events would be a great help.
They will appear as necessary in the various pointer event arguments -- see PointerEventArgs.
You don't know ahead of time how many theoretical pointers there might be. What's the reason that you want to know?
As part of an attempt to port a fairly large/complex existing application to the Ember world, I'm generating and compiling named Handlebars templates dynamically, and associating views with them, using the technique:
var template = Ember.Handlebars.compile("some handlebars stuff");
Ember.TEMPLATES["myTemplate"] = template;
var view = Ember.View.create({
templateName: "myTemplate"
});
One of the things I'd like to do is be able to recompile new/different Handlebars template markup which overwrites the template named "myTemplate" and have it be accessible to views at that name.
I'm getting unexpected results trying to do this - a couple fiddles that illustrate the problems:
First fiddle - Shows what happens if you wait before rendering a view after the named template contents have changed.
Second fiddle - Shows what happens if there's no delay before rendering a view after the named template contents have changed.
There's obviously some magic under the hood that I'm not understanding. Can anyone shed some light on this?
UPDATE:
I went through the source code for Ember.View and the container module, and came to realize that I could solve the problem in the First fiddle by overriding the "template" computed property in a way that skips the container cache lookup. I've put up another fiddle here to demonstrate the solution I found.
This seems to be working the way I'd like it to - but - it feels like I might be fighting with the framework and "unhooking" from the container in a way that might bite me later. Is there a better, more Ember-esque way to accomplish what I'm trying to do? Will the hack I found break things?
UPDATE 2
I've also discovered that it's also possible to simply call
view2.get('container').reset();
before appending view2 in the First fiddle. Seems cleaner/safer, but is it "legal"? I've updated the First fiddle to illustrate this.
(in the second fiddle, both views show the second template)
This is because view1.appendTo($("#target")); just schedules the append, actual view rendering does not happen until end of the run loop. Before that happens, you've set Ember.TEMPLATES["myTemplate"] = template2;
(in the first fiddle, both views show the first template)
Pretty sure this is because ember container caches template fx, but not 100% on that. Checking...
I'm going to call this one answered. As I mentioned in my second comment, I'm using the solution shown in this fiddle in my project, along these lines:
mYiew.get('container').reset();
There's some discussion about the container not being intended to be used as an API here: https://github.com/emberjs/ember.js/commit/5becdc4467573f80a5c5dbb51d97c6b9239714a8 , but there doesn't seem to be any mention of using the container from Views for other use cases.
Also, a View's container can be accessed directly (at ".container") - meaning the devs haven't made it "hard" to get to the way they have for an Application's ".__ container __". This might suggest something about how they intend it to be used.
Since a View having the ability to clear its cache whenever it wants to doesn't seem to me to be unreasonable or a bad practice, I'm using the above mentioned solution...at least until someone sets me straight with a better idea (or a cache API).