Develop Reference

Box2d - dynamic body sometimes falls through static body

I have a side-scrolling platformer type game with procedurally generated terrain, see below. The pink circle is a dynamic body for the player, the green area is a single static body and each of the tiles is a fixture.
The player can move left and right and jump, via linear impulses. Now, most of the time this works fine, but every so often when I'm jumping around the player body suddenly falls partially through the ground body and gets stuck:
I can't discern any pattern to this, it just seems to happen at random. The degree to which the player falls through also varies quite a bit, sometimes you just clip a little bit into the terrain and other times you fall through 15 or 20 tiles.
I've found threads on here with similar problems of bodies ignoring collisions, one suggestion was to increase the velocityIterations and positionIterations arguments of the World.step() method. I've been trying that and it doesn't seem to matter. Another suggestion was to set the player body as a bullet. Again, tried it and it did nothing. So, any other ideas?

You should be doing something to coalesce your boxes so that you can cover the filled areas with a fewer number of objects. As is, it’s very inefficient and each gap is an opportunity for something to go wrong and allow for getting stuck inside as you report.
You definitely should look into computing the boundary and forming chain shapes on that boundary. This approach also means you won’t need to coalesce the boxes. You’ll want to still find a way to handle getting to the wrong side of the chain shapes but that’s still a cleaner approach, and besides, TOI calculations on chains will work way better than tons of separate little boxes.
Consider this, when you have a fast moving object slamming into a group of static boxes, even if the object is marked as bullet the system will try to ensure for each box that the object is about to penetrate that it will not penetrate them individually, and sequentially compute that, but this may still leave the dynamic object penetrating them in the end because they are all separate boxes! A chain shape is one single shape and will not have this problem, but you should still have some backup plan for if the dynamic object does somehow make its way to the wrong location.
Because of these nuances it is potentially useful to both have your static geometry wrapped in chain and space-filled with fixtures, and you can detect “stuck” states by looking for very obvious patterns in events (if on every single dt you get huge impulses from multiple static objects onto one dynamic object) and handle it accordingly.

JavaFX - Sequential Transition modify at runtime

I have been exploring the Sequential Transition from JavaFX, and it seems a perfect fit for what I need. So, I am working on a JavaFX desktop application that essentially shows some pictures, text, and plays some video and audio files. Now, since some of those items are presented sequentially, I have decided to use the sequential transition. Now, I just run into a problem that I have tried to address but it does not seem to work as expected. Let's imagine that the sequence in which those items are presented is predefined in a Map. When those items are presented to the user, he/she needs to provide an answer, and if that is correct you can think that the item can be categorized as Done. However, in some of the cases I need that the user repeats some of the items for learning purposes. And that has to be done 'on-the-fly' since I have another window in which someone else decides which items must be repeated. As you can see, this requires some modification of the sequential transition at runtime. Is there any suggestions on how to address this challenge?
Thanks,

As the documentation for SequentialTransition states:
It is not possible to change the children of a running SequentialTransition. If the children are changed for a running SequentialTransition, the animation has to be stopped and started again to pick up the new value.

Minecraft Plugin: Get Block Type at specific coordinates

I am just learning how to create inventory GUIs in Minecraft. I am adding one to my call of duty zombies game that I have already built just to make it a little bit better. My problem is that when people buy team upgrades I need the inventory options to change to reflect what they have bought and what they have not bought.
The way I was planning to do this was to simply check for scoreboard tags that are assigned to them when they purchase an item. However, I couldn't find a way to do this.
My next thought was to have it so that when they buy each upgrade it sets a block at specific coordinates to a certain material. for this example lets just say cords (100, 50, 200) and type Sandstone. If the block was sandstone then it will open up a whole separate UI that i would make allowing them to buy upgrade two. This process would repeat until all upgrades were bought with the block at cords 100, 50, 200 changing as upgrades were bought.
I have really a few questions.
Is there a better way to do this and if so please explain.
Even if there isn't a good way I would still like to know how in a plugin to set a block at specific coordinates not relative to the player to a certain block type.
Even if there isn't a good way I would also still like to know how to check what type of block is at a specific set of coordinates not relative to the player.
I didn't think code examples were necessary here but if you need any please let me know and I can edit them in.
Thanks in advance for any help you can provide,
~Stone

There is no good way to do this, but i can anser your questions,
In the World there is a method called getBlock(x,y,z) you can then call the setType method on that block, example:
p.getLocation().getWorld().getBlock(0,0,0).setType(Material.AIR);
As in the second anser you can also get the type, Example:
if(p.getLocation().getWorld().getBlock(0,0,0).getTyp() == Material.AIR){
//Check for air in the players world at 0,0,0
}

How do I make a change set in RTC (eclipse) re-editable?

I've submitted for review a change set. Unfortunately i forgot to refresh my sandbox first, so that means I did not include some changes in that set.
So i lost the option to add changes to my change set.
I don't want to discard that change set because it contains important changes. I also don't want to have to deliver 2 change sets, because they contain atomic logic (logic that can't be split).
I'm having a feeling that the "reverse" option would get my change set back into an editable state, but i really have no idea what to do here.
To sum up: i need to make my change set editable again, so that i can merge it with another one.
Anyone know how i would do this?
Thx, you guys rule!

I don't think you can revert back to a mutable state for your change set, if that change set was "completed" before being submitted for review.
In that case, a "reverse" (ie doing a new changeset cancelling the previous changeset), followed by a new changeset in which you redo your work and re-submit it for review might be the only solution.
However, following this example of code review in RTC, change sets should be ket mutable during the review (for the original programer to check-in new revisions of his files based on the feedback of the reviewers).

You should create the new change set.
I say this for two reasons:
1) The aesthetic argument for only having one change set per work item quickly breaks down in practice - it's easy to forget a change, and you may have to make amendments due to bugs or review comments.
2) Having multiple change sets makes your changes easier to understand. Each change set can contain a logical set of changes, so a single work item may have three change sets: "Refactor code", "Update copyrights", and "Changes from review". That way, when someone annotates the files in future, they'll get something at a finer granularity than the initial work item.
Regarding the "atomic logic" argument: it probably isn't an issue unless your team is in the habit of delivering/discarding individual change sets. On the RTC project, we regularly split logically discrete changes across multiple change sets and multiple components.
If you're concerned that you may deliver change sets that logically depend on changes in other components (as I occasionally do), I suggest you chime in on bug 150421. Bug 153907 describes a similar problem, but requires a much more complex solution (making it less likely to be implemented without customer pressure).

I runned into the same issue, and decided to create a patch, discard my changes and then create a new changeset.

Best way to implement game playback?

I'm creating a grid based game in Java and I want to implement game recording and playback. I'm not sure how to do this, although I've considered 2 ideas:
Several times every second, I'd record the entire game state. To play it back, I write a renderer to read the states and try to create a visual representation. With this, however, I'd likely have a large save file, and any playback attempts would likely have noticeable lag.
I could also write every key press and mouse click into the save file. This would give me a smaller file, and could play back with less lag. However, the slightest error at the start of the game (For example, shooting 1 millisecond later) would result in a vastly different game state several minutes into the game.
What, then, is the best way to implement game playback?
Edit- I'm not sure exactly how deterministic my game is, so I'm not sure the entire game can be pieced together exactly by recording only keystrokes and mouse clicks.

A good playback mechanism is not something that can be simply added to a game without major difiiculties. The best would be do design the game infrastructure with it in mind. The command pattern can be used to achieve such a game infrastructure.
For example:
public interface Command{
void execute();
}
public class MoveRightCommand implements Command {
private Grid theGrid;
private Player thePlayer;
public MoveRightCommand(Player player, Grid grid){
this.theGrid = grid;
this.thePlayer = player;
}
public void execute(){
player.modifyPosition(0, 1, 0, 0);
}
}
And then the command can be pushed in an execution queue both when the user presses a keyboard button, moves the mouse or without a trigger with the playback mechanism. The command object can have a time-stamp value (relative to the beginning of the playback) for precise playback...

Shawn Hargreaves had a recent post on his blog about how they implemented replay in MotoGP. Goes over several different approaches and their pros and cons.
http://blogs.msdn.com/shawnhar/archive/2009/03/20/motogp-replays.aspx

Assuming that your game is deterministic, it might be sufficient if you recorded the inputs of the users (option 2). However, you would need to make sure that you are recognizing the correct and consistent times for these events, such as when it was recognized by the server. I'm not sure how you handle events in the grid.
My worry is that if you don't have a mechanism that can uniformly reference timed events, there might be a problem with the way your code handles distributed users.
Consider a game like Halo 3 on the XBOX 360 for example - each client records his view of the game, including server-based corrections.

Why not record several times a second and then compress your output, or perhaps do this:
recordInitialState();
...
runs 30 times a second:
recordChangeInState(previousState, currentState);
...
If you only record the change in state with a timestamp(and each change is small, and if there is no change, then record nothing), you should end up with reasonable file sizes.

There is no need to save everything in the scene for every frame. Save changes incrementally and use some good interpolation techniques. I would not really use a command pattern based approach, but rather make checks at a fixed rate for every game object and see if it has changed any attribute. If there is a change that change is recorded in some good encoding and the replay won't even become that big.

How you approach this will depend greatly on the language you are using for your game, but in general terms there are many approaches, depending on if you want to use a lot of storage or want some delay. It would be helpful if you could give some thoughts as to what sacrifices you are willing to make.
But, it would seem the best approach may be to just save the input from the user, as was mentioned, and either store the positions of all the actors/sprites in the game at the same time, which is as simple as just saving direction, velocity and tile x,y, or, if everything can be deterministic then ignore the actors/sprites as you can get their information.
How non-deterministic your game is would also be useful to give a better suggestion.
If there is a great deal of dynamic motion, such as a crash derby, then you may want to save information each frame, as you should be updating the players/actors at a certain framerate.

I would simply say that the best way to record a replay of a game depends entirely on the nature of the game. Being grid based isn't the issue; the issue is how predictable behaviour is following a state change, how often there are new inputs to the system, whether there is random data being injected at any point, etc, You can store an entire chess game just by recording each move in turn, but that wouldn't work for a first person shooter where there are no clear turns. You could store a first person shooter by noting the exact time of each input, but that won't work for an RPG where the result of an input might be modified by the result of a random dice roll. Even the seemingly foolproof idea of taking a snapshot as often as possible isn't good enough if important information appears instantaneously and doesn't persist in any capturable form.
Interestingly this is very similar to the problem you get with networking. How does one computer ensure that another computer is made aware of the game state, without having to send that entire game state at an impractically high frequency? The typical approach ends up being a bespoke mixture of event notifications and state updates, which is probably what you'll need here.

I did this once by borrowing an idea from video compression: keyframes and intermediate frames. Basically, every few seconds you save the complete state of the world. Then, once per game update, you save all the changes to the world state that have happened since the last game update. The details (how often do you save keyframes? What exactly counts as a 'change to the world state'?) will depend on what sort of game information you need to preserve.
In our case, the world consisted of many, many game objects, most of which were holding still at any given time, so this approach saved us a lot of time and memory in recording the positions of objects that weren't moving. In yours the tradeoffs might be different.