I just started using Box2d and libgdx. I followed this tutorial, https://github.com/libgdx/libgdx/wiki/Box2d And a ball would bounce if I run the following code I took from the tutorial.

// ...omit the rest of code
World world = new World(new Vector2(0, -10), true); 
BodyDef bodyDef = new BodyDef();
bodyDef.type = BodyType.DynamicBody;
bodyDef.position.set(100, 300);
Body body = world.createBody(bodyDef);
CircleShape circle = new CircleShape();
circle.setRadius(6f);
FixtureDef fixtureDef = new FixtureDef();
fixtureDef.shape = circle;
fixtureDef.density = 0.5f; 
fixtureDef.friction = 0.4f;
fixtureDef.restitution = 0.6f; // Make it bounce a little bit
Fixture fixture = body.createFixture(fixtureDef);
circle.dispose();
// ...omit the rest of code

I'm wondering how I can make the ball bounce like a basketball or volleyball? It's like the ball movement is in a space, move so slowly. I changed some properties such as density or friction, but it seems box2d doesn't care of air friction, so nothing changed at all. Could you tell me how I can make the ball movement to be a basketball or such stuff?

I read up a decent amount on conditioning in growlers before attempting it. I wanted to share my experience and see if others had had similar experiences.

The thinking, of course, is to minimize bottle-washing. From my research, the dangers were:

  • Large serving size
  • Poor carbonation
  • Bottle integrity, namely, the bottom falling out

I figured all of these could be mitigated through selection of the right beer. For instance, an English bitter has low gravity and low carbonation, and is conducive to a large serving size. One growler would fill three imperial pints handily, then be done.

I used high-quality growlers from a local beer specialty store, and bottled half a batch in five growlers, the remainder in 22 oz bottles. Here's the good:

  1. The carbonation was right, although a little less in the growlers than in the 22's. Actually, the growler beer is closer to an English bitter's level of carbonation than the 22's, which is a bit too lively.
  2. The taste is fine.
  3. The growlers held up well. I kept them in a tub so as to minimize the destruction possible with a 64 oz failure. I can't say that they'll be reliable batch after batch, but they worked just fine.

Here's the bad... Really just a quibble, but it might scuttle this effort for me:

  1. Growlers are fatter for the same height. That means that when you're pouring that third pint, you're going to get a cloudy, yeasty beer. The larger surface area on the bottom makes for a thinner, less cohesive yeast cake from conditioning, plus more "wash-off" as the final beer drains off the yeast cake. To add to that, your third pint is made up mostly of the bottom two inches of the bottle, where all the yeast is anyway. This works if you've got two friends over and you don't like one of them very much, but if you want to be hospitable, it means you need to bite the bullet and take the murky pint.

I could see brewing a different beer, like an intentionally cloudy wheat beer into growlers to mitigate this, but those beers classically require a higher level of carbonation, which would endanger the bottles, so I'm not willing to go there.

This worked out far better than people told me it would, but it's not what I'd call an unqualified success.

UPDATE

It's over a year later and I never really revisited carbonating in growlers since that first experiment. I now have moved on to kegging and never looked back. For people who keg their beer, there is still one very good use case for conditioning in growlers: overshooting the batch volume.

I have a mark on my primaries that will tell me exactly how much to fill in order to fit the results into a Corny keg (if racking right to keg). Sometimes I overshoot the mark. In these cases, when racking from 6 gallon primary to 5 gallon secondary or keg, I'll throw 4-5 Coopers Carbonation Drops into a sanitized growler, rack half a gallon into the growler, cap it, repeat if necessary, then proceed as usual. No beer is wasted.

But even then, a 2L soda bottle and a carbonator cap are far better than bottle conditioning.

I have a pile of bricks and pavers (left behind from the previous owner). My septic tank is exposed a little in one corner, right at the base of my porch steps. I was thinking of scraping the tank clean then throw the bricks right on that, and then have some overlap onto dirt/sand. Is this advised? I'll make sure the opening is easily accessible. Should I throw a layer of sand down first?

I'm not asking if Tor is secure, I'm asking if an observer can know you are using Tor? For example if a persons ISP or company network monitors traffic would they be able to determine with certainty that a person is using Tor or not? For example, the exit nodes certainly are known, though I'm uncertain if the first node the traffic gets passed to is (publicly known)? A sys admin would be able to perform a whois and find out that it's a tor relay node (if they really wanted to know), wouldn't they?

As @Manumit asks "If anyone can pitch in on the missing piece, is "obfs3, scramblesuit, fte, and obfs4" ample obfuscation then?"

This is the 3rd of my series of C/C++ puzzles; in case you missed the first 2 they are here: (1) m3ph1st0s's programming puzzle 1 (C++) (2) m3ph1st0s's programming puzzle 2 (C++): "Call hard!"

I must say that my puzzles are 100% original. If not, I will always state so in the text. My 3rd puzzle has 2 parts as follows:

Puzzle 3.1

This part (3.1) is not an original puzzle of mine, it is collected from some internet page I've read a while ago. I use it here as a starting point and a warm-up for you. Solve this one and then move on to the 2nd part.

Some one tried to print the "+" sign 20 times and came up with the following program:

#include <stdio.h>
int main() {
   int i;
   int n = 20;
   for( i = 0; i < n; i-- )
      printf("+");
   return 0;
}

The fact that it did not have the expected result is obvious - the program never ends. Fix it! Easy? Now fix the program by changing ONLY ONE CHARACTER - non-space character of course! For this challenge there are 3 solutions. Find all 3 of them. Just to make it clear: the program must output 20 "+" signs and must end fast. Before criticizing me on what "fast" means, I'll say it means at most a couple of seconds (which by the way is too much but just to make it crystal clear).

Puzzle 3.2

EDITED It was pointed to me earlier that the solution for the 3.2.2 puzzle might be compiler-dependent. In order to eliminate any possible discussion on the subject, I'll modify the idea and improve it on a next puzzle when I'll take extra care not to generate controversy. However, in order to keep this puzzle going, I'll make a small modification for 3.2.2 (the solution will be easier but cleaner).

When I first saw the puzzle I found it pretty awesome. I did manage to solve it but not immediately since it requires some careful attention. If you are here it means you too solved it. If you did so by writing a program to replace all possible characters with all possible values and test every solution, you are lost. Hard working guy though. Now having corrected the program that writes 20 "+" signs:

3.2.1: Insert one single letter and nothing more in the code so that the result is valid and outputs the same thing in all 3 corrected programs. Needless to say, the letter must be before the enclosing } of main (I say that because I don't want to hear people who just put a letter after the program and somehow their compiler was very friendly).

EDITED (see bellow) - For these final questions consider that the counter i starts from -1 instead of 0.

3.2.1.5: Repeat all previous problems with the condition that the output is at least 19 "+" signs (but still a finite output). Changing spaces is allowed. Now you might have found more solutions than in the first case. Some of these will most definitely fit for the 3.2.2 question.

3.2.2: Choose another value to initialize the variable n so that the resulting output will remain the same for at least one corrected programs in 3.2.1.5(not necessarily for all of them).

LAST EDIT1: changing the program so that it outputs 21 "+" signs is still a good solution, as the original text did not say "exactly" 20 signs. However, the infinite output is forbidden. Obviously this doesn't mean let's all start outputting hundreds of "+"signs since it's not forbidden. But eliminating a beautiful 21 output would not be in the spirit of this competition.

LAST EDIT2: considering LAST EDIT1 and accepting space changing it seems that now we have 5 possible solutions, four of which have already been pointed out in the responses. The last challenge however hasn't been touched and I must make it clear once more: n must be assigned another value, solutions that assign 20 to n by some tricks won't do it (like n=20L). Also I prefer to see the 3rd solution that does not change spaces.

LAST EDIT3: I've edited the last questions, please read!

The challenge is to solve both parts of the puzzle. The first one to do it wins.

I hope it's all clear, if not please post any questions and I'll edit as quickly as possible. Cheers. emphasized text

I was listening to Killswitch Engage and decided to look Adam D's rig up. He's used multiple amps and guitars, but is sparse with pedals. When reading this I started wondering how they achieve cleans and different distortion tones while on stage.

  1. They use wireless transmitters for their live events, bu how do bands normally switch between cleans/distortions? Do they have multiple amps per gig?

  2. Is it possible to have, let's say, 3 separate amp heads and hook them up to a single cabinet using a bypass to us on,y one head a time?

I would like to know if I am connected to the network as a validator, how I my node will be protected of DDoS attacks.

I have been testing a trend following strategy. The results shows massive drawdowns which makes the equity curve very unstable. I just wanted to know what are some ways in which I can reduce the volatility (increase smoothness) of the equity curve? Better exits? Better entries?

Can anyone shed some light on #5 from https://www.salesforce.com/us/developer/docs/apexcode/Content/apex_triggers_order_of_execution.htm that talks about execution of duplicate rules which is in beta. Thanks.

The OP_EVAL BIP says that "Avoiding a block-chain split by malicious OP_EVAL transactions requires careful handling of two cases:

  1. An OP_EVAL transaction that is invalid for new clients/miners but valid for old clients/miners.
  2. An OP_EVAL transaction that is valid for new clients/miners but invalid for old clients/miners"

The later p2sh and CHV BIPS list only condition (1).

It sounds to me backward compatibility (avoiding situation 1) is more important than forward compatibility (avoiding condition 2).

Question: what would be the disadvantage of making OP_EVAL/p2sh/CHV a totally new opcode, so that any "old client" would immediately reject any transaction using the new opcode?

This would ensure that situation 1 never happens since all OP_EVAL/p2sh/CHV transactions are invalid for old clients/miners. Old clients/miners would reject new transactions they haven't been taught about, which is pretty much what you expect to happen when you upgrade your software -- old software might not be able to read data files created by newer software.

You might say "well, then we have to force all the clients to upgrade instead of just the miners"... but the alternative is basically transferring trust from the clients to the miners, so avoiding a client upgrade doesn't come "for free" even though it might seem like it at first.

Right now the clients do all their own validity checking of the blockchain and do not rely on the miners' validity checks at all. If 75% of the hashpower decided to change the validity rules they couldn't -- the clients don't rely on their checks. The clients (exchanges included!) would promptly proceed to ignore the mutinying miners. But OP_EVAL/p2sh/CHV end that clear separation: with "forward compatibility" we are asking people who use these new transactions to consent to a state of affairs in which old clients receiving coins from them will (unknowingly) transfer validity-check responsibility to the mining pool. Nobody seems to be talking about that.