In chipmunk I have 3 types of objects: A, B and C. I need A and B not to collide. I also need B and C not to collide. On the other hand I need A and C to collide. For A and B not to collide I set their collisionGroup to be the same.If I set B and C the same collisioGroup this time A and C will have the same collisiongroup thus causing A and C not to collide. I've tried to set collisionMask/collisionCategories but that didn't help either. Any idea how to accomplish this?
Here's how I solved the problem.
A.collisionGroup=#"beams"
A.collisionCategory=#[#"beam"];
A.collisionMask=#[#"box"];
B.collisionGroup=#"beams"
B.collisionMask=#[#"none"];
C.collisionCategory=#[#"box"];
C.collisionMask=#[#"beam"];
To make it clear. I assign the same collision group to A and B so that they don't collide under any circumstances. This is because collision group overrides any behaviors defined with collisionMask and collisionCategory. Then I set up so that A collides only with C and C collides only with A. I do it by cross setting each other's collisionMask and CollisionCategory. One more and a very import thing to consider is if you don't want B also to collide with C you have to set collisionMask of B to something else otherwise B will collide with anything that is not in the same collision group. Phew, that's it.
Related
I am given the above system for atomic propositions {a,b,c}.
I'm then meant to say if certain LTL formulae hold (such as ♢☐c).
I understand what the LTL formulae mean (eventually forever c holds) but I have no idea how to read the diagram and relate it to the LTL.
I assume it's like a flow chart in that we start from the top left, /{a} and can go through the different states. But what does each of it mean divided by a?
Looks like FSM/transduser rather than a Kripke structure. Input/output or more generally precondition/postcondition is a common notation for FSM and its kin. precondition/postcondition (a and b and ...) / (x and y and...). So a in the state q1. In next states either only b in q4 or b and c or q3. Might be of course or instead of and in precondition, otherwise the system might halt..
I formerly use eclipse and open many projects in a single work space, for example, I have project A, B and C. Both B and C will be dependent on A, thus when I change code in A, I can get usage information in B and C immediately.
Then I transferred to use IDEA, which is awesome, yet projects are independent and they are dependent in pom declaration, the side effect is I cannot get usage of B and C immediately, I need to open B and C, then build A, and check whether some change such as access level adjustment broke codes in B and C.
So what is the best practice to resolve such issues?
PS: For me it's not good to add B and C as module to A.
I'm doing a self-educational research on finite state machines. And currently stumbled upon interesting but non-trivial task to accomplish. It is really hard to define state machine for the rules of game of chess.
Though the rules seem simple the game itself is hard to approach using FSM. I was thinking about encoding game state as a state of board, where each square is either empty or contains some piece. But it becomes hard to define transitions, because the transition should be aware of facts that concern the neighborhood of the subject cell. It is also hard to define transitions for cases like en-passant or castling, especially when castling is blocked by some other piece. The same way it is hard to define move limitations for pieces that are blocked by other pieces and are not capable to jump them, i.e. pawns, bishops, rooks, queens.
How would you approach this problem? Or maybe there are some extensions to FSM that I'm not aware of. I'm pretty sure that there are a lot of similar applications where FSM will be impractical to use. How would you deal with this problem in general case.
Thank you in advance,
In your approach each state would be a matrix of fields, where each field has a specific state, which is a composition of the color and the chess piece that is placed on it and chess pieces themselves are a composition of the color of the chess-piece and it's type (pawn, rook, etc.). So you can easily define rules by utilizing these matrices:
Example for pawn:
Initial state:
C D E
5 (W , (X , ?)) (B , (P , B)) (W , (P , B))
4 (B , (P , W)) (W , (X , ?)) (B , (P , W))
Now we can evalute rules for moving the two white figures based on this rule:
A pawn can move straight forward, if it's not blocked by another figure, or it can beat the figure that is placed diagonally one block away from it. Building the transition-table for the above state with a white move next can be done in the following way:
S1->(a)X (just the standard way to define a transition)
a would be the figure, we want to move and S2 the resulting state
X are the reachable state.
a = Pawn at C4
we have two options evaluating the field:
C5 is free, so we can move the pawn to that field
D5 is held by a black pawn, so we can beat it and move to that field
a = Pawn at E4
E5 not free, we can't move ahead
D5 is held by a black pawn, which we can beat
Translating this into math shouldn't be too hard. The state transition-table for each state would include all possible moves for all figures. The resulting machine would be a NFA.
Another option would be to define transitions as a pair of the chess piece you want to move and where you want to move it. That'd allow you to construct a DFA.
I would like to express the following constraint in linear temporal logic.
If A happens, then B must happen directly before it.
I tried "B R !A" (!A remains true until B becomes true; B may never becomes true), but it is not correct as A may or may not happen after B happens.
Can any logic expert help me on this problem? Thank you very much!
Well, if X is read as next, i.e. Xp means in the next time step, p is the case, then Xp → q would be what you are looking for.
Or in your letters: XA → B
(X is sometimes replaced with an N or a circle, but is always present in LTL.)
You could use PT-LTL for this. Its past time LTL.
The formula would be
A -> X B, here X means previously.
You can use JavaMOP for implementation of PTLTL monitors.
I'm looking for an algorithm to help me build 2D patterns based on rules. The idea is that I could write a script using a given site of parameters, and it would return a random, 2-dimensional sequence up to a given length.
My plan is to use this to generate image patterns based on rules. Things like image fractals or sprites for game levels could possibly use this.
For example, lets say that you can use A, B, C, & D to create the pattern. The rule is that C and A can never be next to each other, and that D always follows C. Next, lets say I want a pattern of size 4x4. The result might be the following which respects all the rules.
A B C D
B B B B
C D B B
C D C D
Are there any existing libraries that can do calculations like this? Are there any mathematical formulas I can read-up on?
While pretty inefficient concering runtime, backtracking is an often used algorithm for such a problem.
It follows a simple pattern, and if written correctly, you can easily replace a rule set into it.
Define your rule data structures; i.e., define the set of operations that the rules can encapsulate, and define the available cross-referencing that can be done. Once you've done this, you should have a clearer view of what type of algorithms to use to apply these rules to a potential result set.
Supposing that your rules are restricted to "type X is allowed to have type Y immediately to its left/right/top/bottom" you potentially have situations where generating possible patterns is computationally difficult. Take a look at Wang Tiles (a good source is the book Tilings and Patterns by Grunbaum and Shephard) and you'll see that with the states sets of rules you might define sets of Wang Tiles. Appropriate sets of these are Turing Complete.
For small rectangles, or your sets of rules, this may only be of academic interest. As mentioned elsewhere a backtracking approach might be appropriate for your ruleset - in which case you may want to consider appropriate heuristics for the order in which new components are added to your grid. Again, depending on your rulesets, other approaches might work. E.g. if your ruleset admits many solutions you might get a long way by randomly allocating many items to the grid before attempting to fill in remaining gaps.