grouping shapes chipmunk - cocos2d-iphone

I'm trying to make a character with arms with chipmunk+cocos2d using Constraints. I read chipmunk needs to group the shapes for no collition between the parts.
I did
cpGroup *group;
cpShapeSetGroup(myShape1, group);
cpShapeSetGroup(myShape2, group);
cpSpaceAddConstraint(space_, cpPivotJointNew(bodyPin, body, cpv(pinX, pinY)));
cpSpaceAddConstraint(space_, cpRotaryLimitJointNew(body, armBody, 45, 90));
but both shapes keep colliding
thanks a lot

That should have compiled with a warning. cpGroup is by default defined to be a unintptr_t type. So you should either give the group a unique integer identifier or cast a unique pointer (such as the game object that owns the shapes) to a uintptr_t.
What your code snippet above does is use the value of an uninitialized variable as the group. It should have worked though. Are you sure that shape1 and shape2 are the correct shapes?

Related

How are entities stored in unreal engine 3?

I am currently trying to create a hack for Borderlands 2. One of the features I am trying to create is a Kill All feature which will iterate through each entity saved to my vector entity struct and set their health to 0. This is easy for me to do on other games but I am having major trouble on this game.
I found a pointer that shows me the true health value of the entity I am looking it but I noticed that in certain regions of the map the addresses change vastly. For example, I may find 7-8 entity's near me that start with the same address (Ex. 0x79C8000+)
But after I leave to go to another area the entity's I find here are vastly different in memory location. (Ex. 0x01CD0000+)
And I understand that such a large map would require things like that to happen, especially if I move to far away from a certain region of entity's they are unloaded from the world and the address value is set to 0 and no longer correctly points to the entity's health when I move back to said region and they are loaded back in.
The things that bothers me is that there has to be an array that stores every entity that is CURRENTLY loaded in memory, regardless if its just an object entity and non NPC because I'm almost certain there is one because other people are able to find it.
Any ideas??

Column-Packed RowColumn Class for Motif Library (C)?

I recently asked this question: Horizontally-Drawn RowColumn Class for Motif Library (C)?
In my previous question, I was having trouble getting the xmRowColumnWidgetClass to draw horizontally (row-by-row) instead of vertically (column-by-column). After playing around with it, figured out how to switch to horizontal drawing with the following snippet:
XmNorientation, XmHORIZONTAL,
So the code that creates the xmRowColumnWidgetClass instance now looks like this:
rowColumn = XtVaCreateManagedWidget("rowcolumn",
xmRowColumnWidgetClass,
parentWidget,
XmNnumColumns, 3,
XmNorientation, XmHORIZONTAL,
XmNpacking, XmPACK_COLUMN,
XmNspacing, 6,
NULL);
However, my new problem is that for some reason the XmNnumColumns field is now referring to the number of rows, rather than the actual number of columns. Before adding the XmNorientation, XmHORIZONTAL part, the xmRowColumnWidgetClass instance was drawing the objects from left-to-right but it stayed to 3 columns like it was supposed to. Now, it is staying to 3 rows, occasionally creating a horizontal scrollbar which I do not want. I only want vertical scrolling.
So I need the children of the xmRowColumnWidgetClass instance to be drawn horizontally from top to bottom, but I need it to only put a maximum of 3 per row and thus keep it confined within a certain width.
I tried playing around with the XmNnumColumns field, but things that worked with more children did not work for less children, and vice versa. Sometimes it made it 4 or 5 columns rather than 3, and sometimes it made it 2 columns with the 3rd column completely empty. I encountered many issues like this even when experimenting with things like using XmNpacking, XmPACK_TIGHT rather than XmNpacking, XmPACK_COLUMN and other stuff.
If someone is able to find the official documentation of the xmRowColumnWidgetClass and link it, that would be be greatly appreciated.
To anybody familiar with this library:
How do I create a xmRowColumnWidgetClass instance that draws horizontally (row-by-row) while keeping it to a certain number of columns?
It should be able to handle any number of children and add as many rows as it needs to in order to keep it as exactly 3 columns.
Another group of examples of this library:
https://github.com/spartrekus/Motif-C-Examples
https://github.com/spartrekus/Motif-C-Examples/blob/master/rowcol.c
XmRowColumn was designed to implement the top menubar and all the other menu classes... You are searching for a grid like widget, and so you have to use XmForm read the related question for that.
In short: try the WtTable widget
Longer explanation follows:
The behaviour of XmRowColumn regarding "columns" becoming "rows" when you choose a horizontal configuration is very unfortunate. The alternative of using XmForm instead of XmRowColumn for this purpose is feasible, but however it requires manually setting the children constraints, and even then, it's quite possible that you won't be able to achieve the automatic sizing implemented in XmRowColumn.
By searching today, I found the WtTable widget and it works fine for my purposes. It's "almost" as automatic as XmRowColumn and it doesn't require to set any constraints manually. I tried it in my Motif code, and works fine.
Note however that I said "almost" as automatic. The "almost" is because you need to specify the number of columns and rows, and you need to specify the column and row for each child widget. However, all of this can be automated: you can create a convenience function that internally manages counters for columns and rows, so that you pass a widget to such function and it puts it in the cell it belongs automatically: you can even make that function create a new row in the WtTable when it's needed.

Abaqus Python 'Getclosest' command

I'm using the getclosest command to find a vertex.
ForceVertex1 = hatInstance.vertices.getClosest(coordinates=((x,y,z,))
This is a dictionary object with Key 0 and two values (hatInstance.vertices[1] and the coordinates of the vertex) The specific output:
{0: (mdb.models['EXP-100'].rootAssembly.instances['hatInstance-100'].vertices[1], (62.5242172081597, 101.192447407436, 325.0))}
Whenever I try to create a set, the vertex isn't accepted
mainAssembly.Set(vertices=ForceVertex1[0][0],name='LoadSet1')
I also tried a different way:
tolerance = 1.0e-3
vertex = []
for vertex in hatInstance.vertices:
x = vertex.pointOn[0][0]
print x
y = vertex.pointOn[0][1]
print y
z = vertex.pointOn[0][2]
print z
break
if (abs(x-xTarget)) < tolerance and abs(y-yTarget) < tolerance and abs(z-zTarget) < tolerance):
vertex.append(hatInstance.vertices[vertex.index:vertex.index+1])
xTarget etc being my coordinates, despite this I still don't get a vertex object
For those struggeling with this, I solved it.
Don't use the getClosest command as it returns a dictionary object despite the manual recommending this. I couldn't convert this dictionary object, specifically a key and a value within to a standalone object (vertex)
Instead use Instance.vertices.getByBoundingSphere(center=,radius=)
The center is basically a tuple of the coordinates and the radius is the tolerance. This returns an array of vertices
If you want the geometrical object you just have to access the dictionary.
One way to do it is:
ForceVertex1 = hatInstance.vertices.getClosest(coordinates=((x,y,z,))[0][0]
This will return the vertices object only, which you can assign to a set or whatever.
Edit: Found a solution to actually address the original question:
part=mdb.models[modelName].parts[partName]
v=part.vertices.getClosest(coordinates=(((x,y,z)),))
Note the formatting requirement for coordinates ((( )),), three sets of parenthesis with a comma. This will find the vertex closest to the specified point. In order to use this to create a set, I found you need to massage the Abaqus Python interface to return the vertex in a format that uses their "getSequenceFromMask" method. In order to create a set, the edges, faces, and/or vertices need to be of type "Sequence", which is internal to Abaqus. To do this, I then use the following code:
v2=part.verticies.findAt((((v[0][1])),))
part.Set(name='setName', vertices=v2)
Note, v[0][1] will give you the point at which the vertex lies on. Note again the format of the specified point using the findAt method (((point)),) with three sets of parenthesis and a comma. This will return a vertex that uses the getSequenceFromMask method in Abaqus (you can check by typing v2 then enter in the python box at the bottom of CAE, works with Abaqus 2020). This is type "Sequence" (you can check by typing type(V2)) and this can be used to create a set. If you do not format the point in findAt correctly (e.g., findAt(v[0][1]), without the parenthesis and comma), it will return an identical vertex as you get by accessing the dictionary returned using getClosest (e.g., v[0][0]). This is type 'Vertex' and cannot be used to create a set, even though it asks for a vertex. If you know the exact point where the vertex is, then you do not need the first step. You can simply use the findAt method with the correct formatting. However, the tolerance for findAt is very small (1e-6) and will return an empty sequence if nothing is found within the tolerance. If you only have a ballpark idea of where the vertex is located, then you need to use the getClosest method first. This indeed gets the closest vertex to the specified point, which may or may not be the one you are interested in.
Original post:
None of these answers work for a similar problem I am having while trying to create a set of faces within some range near a point. If I use getClosest as follows
f=mdb.models['Model-1'].parts['Part-1'].faces.getClosest(coordinates=((0,0,0),), searchTolerance=1)
mdb.models['Model-1'].parts['Part-1'].Set(faces=f, name='faceSet')
I get an error "TypeError: Keyword error on faces".
If I access the dictionary via face=f[0], I get error "Feature Creation Failed". If I access the tuple within the dictionary via f[0][0], I get the error "TypeError: keyword error on faces" again.
The option to use .getByBoundingSphere doesn't work either, because the faces in my model are massive, and the faces have to be completely contained within the sphere for Abaqus to "get" them, basically requiring me to create a sphere that encompasses the entire model.
My solution was to create my own script as follows:
import numpy as np
model=mdb.models['Model-1']
part=model.parts['Part-1']
faceSave=[]
faceSave2=[]
x=np.arange(-1,1,0.1)
y=np.arange(-1,1,0.1)
z=np.arange(-1,1,0.1)
for x1 in x:
for y1 in y:
for z1 in z:
f=part.faces.findAt(((x1,y1,z1),))
if len(f)>0:
if f[0] in faceSave2:
None
else:
faceSave.append(f)
faceSave2.append(f[0])
part.Set(faces=faceSave,name='faceSet')
This works, but it's extraordinarily slow, in part because "findAt" will throw a warning to the console whenever it doesn't find a face, and it usually doesn't find a face with this approach. The code above basically looks within a small cube for any faces, and puts them in the list "faceSave". faceSave2 is setup to ensure that duplicate faces aren't added to the list. Accessing the tuple (e.g, f[0] in the code above) contains the unique information about the face, whereas 'f' is just a pointer to the 'findAt' command. Strangely, you can use the pointer 'f' to create a Set, but you cannot use the actual face object 'f[0]' to create a set. The problem with this approach for general use is, the tolerance for "findAt" is super small, so, you either have to be confident where things are located in your model, or have the step size be 1e-6 in np.arange() to ensure you don't miss a face that's in the cube. With a tiny step size, expect the code to take forever.
At any rate, I can use a tuple (or a list of tuples) obtained via "findAt" to create a Set in Abaqus. However, I cannot use the tuple obtained via "getClosest" to make a set, even though I see no difference between the two objects. It's unfortunate, because getClosest gives me the exact info I need effectively immediately without my jumbled mess of for-loops.
#anarchoNobody:
Thank you so much for your edited answer!
This workaround works great, also with faces. I spent a lot of hours trying to figure out why .getClosest does not provide a working result for creating a set, but with the workaround and the number of brackets it works.
If applied with several faces, the code has to be slightly modified:
faces=((mdb.models['Model-1'].rootAssembly.instances['TT-1'].faces.getClosest(
coordinates=(((10.0, 10.0, 10.0)),), searchTolerance=2)),
(mdb.models['Model-1'].rootAssembly.instances['TT-1'].faces.getClosest(
coordinates=((-10.0, 10.0, 10.0),), searchTolerance=2)),)
faces1=(mdb.models['Model-1'].rootAssembly.instances['Tube-1'].faces.findAt((((
faces[0][0][1])),)),
mdb.models['Model-1'].rootAssembly.instances['Tube-1'].faces.findAt((((
faces[1][0][1])),)),)
mdb.models['Model-1'].rootAssembly.Surface(name='TT-inner-surf', side1Faces=faces1)
```

Sorting a 2D vector of objects

I am working on a little puzzle game ( Gem Puzzle).
I have a puzzle Piece object for each piece on the board that has the following attributes:
Position Pcorrect_;
Position Pactuel_;
bool estvide_;
(the 3rd attribute is irrelevant for this question)
The Position is simple structure consisting of:
unsigned ligne;
unsigned colonne;
Each Piece is stored in a vector of a vector.
std::vector<std::vector<Piece>> board_;
The Pieces eventually get mixed around so the correct attribute (location) does not match the actual attribute (location).
I am stuck on a method that should sort the board.The actual position has to match the current position for each piece of the board.
Is there an elegant way of doing this with a sort function ?My current approach is using 4 loops and lots of conditions which is probably the wrong way of doing it.
if you use C++11, you can create a tuple and sort it.
You can define a custom comparison, like in this example:
http://www.hongliangjie.com/2011/10/10/sortin-tuples-in-c/

How to create a game save file format in c++ using STL

I just learned about the i/o part of the STL, more specifically fstream. Although I can now save binary info and classes I've made to the hard drive, I am not sure how to define how the info should be read.
I saw the answer for making a file format from this post:
Typically you would define a lot of records/structures, such as
BITMAPINFOHEADER, and specify in what order they should come, how they
should be nestled, and you might need to write a lot of indices and
look-up tables. Such files consists of a number of records (maybe
nestled), look-up tables, magic words (indicating structure begin,
structures end, etc.) and strings in a custom-defined format.
What I want to know specifically is how to do this with the STL and C++...
Since the format is meant simply for the use of a game I would think it would be much easier though. The format should:
Be traversable (I can look through it and find the start of structure and maybe check its name
Be able to hold multiple classes and data in a single file
Have identifiable starts and ends to sections: such as the space in text files
Maybe have it's own icon to represent it??
How do I do this in c++ ?
The first stage in determining how to structure your save-file is determining what information needs to be stored. Presumably, you have a list of entities, each of which with generic information (probably derived from one of a few base classes), such as position, velocity etc.
One of the best things you can do to implement a map format is to have a save-parser for each class (some can just derive from the base class' save-parser). So for instance, if you have a player class, which derives from CBaseNPC, you could most-likely simply derive from CBaseNPC, override the parser, calling the base-class function, and adding any other necessary fields, for example, if we had (pseudocode):
void CBaseNPC::Save() {
SaveToFile( health );
SaveToFile( armor );
SaveToFile( weapons );
SaveToFile( position );
SaveToFile( angles );
}
Then for your player class:
void CPlayer::Save() {
CBaseNPC::Save();
SaveToFile( achievement_progress );
}
Obviously, this is just a simple example, and no doubt your saving parsers will have more fields etc. to deal with.
Dealing with the structure of the file itself, the main thing you need to worry about is delimiters, how will your main load-parser recognise what each field corresponds to?
I suppose the best way to explain this would be with an example, the following could be a simple start to a save-file:
Map: {mapname}
Gametime: {gametime}
===Player===
Health: {health}
Armor: {armor}
Weapons: {wep1 (wep1Ammo), wep2 (wep2Ammo), wep3 (wep3Ammo)}
Position: {x, y, z}
Angles: {yaw, pitch, roll} // Could be quaternion instead.
AchievementProgress: {arbritraryData}
===Player===
===NPC-npc_name===
Health: {health}
Armor: {armor}
Weapons: {wep1 (wep1Ammo), wep2 (wep2Ammo), wep3 (wep3Ammo)}
Position: {x, y, z}
Angles: {yaw, pitch, roll} // Could be quaternion instead.
===NPC-npc_name===
===Entity-item_name===
Position: {x, y, z}
Angles: {yaw, pitch, roll}
Model: {modelname}
===Entity-item_name===
Here we have used the "===" string as a delimiter for the start of a class's parameters, and a new line as the delimiter for the parameters within each class.
It is then a relatively simple matter of structuring your parser so it reads in the map name, and loads it. Then sets the game-time to the value specified in the save-file.
It then looks through the file until it finds a "===" reads the string it encounters, and looks it up from a dictionary (possibly an std::map or std::unordered_map) to determine the class to create (or edit) with the information in the file. Once it has determined the class type, it can then proceed to call the Load() function from that class, which will retrieve all the information contained. The parser then looks for the next instance of the "==={string encountered}===" and closes that class. It then proceeds following the same procedure with the next class encountered.
Sorry for the length of this post, and I'm sure it could be made briefer and there are probably some things I have missed, I just wrote this off the top of my head, so there may be erroneous things here, but I hope it puts you on the right path to getting a workable save-file format. :)
If you still have any problems or questions regarding my post, please comment, I'll do my best to answer promptly.