I've recently looked at using joints, and I want to support them in my inkscape --> orx converter.
It looks like you create joints that attached to child objects.
But what about the case where you need a loop of joints (think of a tank tread, or a rubber band)?
I did a quick test, and having a A --> B --> C --> A parent/child doesn't work.
Comments
Sorry, I thought I already replis to your question, but somehow I failed.
In theory, you should be able to to circular chains of joints.
However you can't do it directly using the ChildList property, which means there's at least one joint that you'll have to add manually between two bodies (orxBody_AddJointFromConfig).
That also means you are responsible for deleting that one joint.
Why not simply have joints have a BodyA and BodyB parameters? Is it to support joints always having parents for the sake of auto-deletion when the parent body is deleted?
Well, I'm not sure how it would work actually, could you give me an example on how you'd see that? If that works, I could probably update orx to support it.
Mostly I'm interested in making sure that the map converter can handle these sorts of structures w/o any compiled code necessary for the programmer.
If the joint is creating the objects, it brings another issue: it's not very handy to hold onto a joint reference when everything is object-centric.
That also means it cannot be part of a hierarchy as objects can only trigger the creation of other objects.
The whole object-definition vs instantiated-object thing just sort of gelled. I guess in my mind I was thinking of an .ini as a singular scene description rather than a set of templates you could selectively instantiate from. In hindsight, this is obvious
The crux of the problem is the requirement of hierarchy for auto-instantiation of joints vs the potentially cyclic nature of the joints themselves.
How about this:
[JointGroupTemplate]
ChildList = Object1 # Object2 # Object3
JointList = Joint1 # Joint2 # Joint3
Assume "-->" means "join"
In the above example, Joint1 --> (Object1, Object2), Joint2 --> (Object2, Object3), Joint3 --> (Object3, Object1).
Considerations / Restrictions:
* All child objects must have bodies.
* JointGroupTemplate must NOT have a body; would be it's own template type.
* The number of joints must be either N or N - 1 where N is the number of children. N would mean cyclic, and N-1 would be open.
Lastly, if you simply want a single relation ObjectA -> ObjectB, you need to introduce a common parent which is most likely not wanted.
You can already represent the open chain, it's only the case of closed/cyclic chain that can't be represented at the moment.
However, I think we can already support this although it's a bit of a workaround: by adding a track on the first parent and last child, we could add the extra-joint provided that the necessary command exists. If it's not the case, it's easy to add such a command.
Actually, a single track on the last child would be sufficient, but it'll be a more complex one involving recursion, not sure it's worth it.
Does changing ChildList to ObjectList, and making [JointGroupTemplate] a sort of factory (which would require a factory concept) alleviate this problem? Would having some sort of generic instantiation grouping template that isn't itself an object be useful? Perhaps even specifying another object template as the group's shared parent? Or is that weird?
Those sound like pretty heavy modifications for adding support to a single case (which is the last link of a cyclic chain).
True.
I could simply have my mapgen produce the described config section, and then write game code to manually instantiate objects & joints.
I was hoping for a fully data-driven solution, but custom (yet generic) code is fine.
A good start would be the post I made on the orx-dev group.
Operators are commands as well. You can try them by opening the console (by pressing the backquote [`] key in game), and then type (no spaces after the commas in the vector!):
The result will then be (3, 4, 5).
If you want to use spaces when typing vector parameters, you have to surround them with double quotes ["]: Which will give (4, 10, 18).