Simple improvements that fun pimps should make to the firearms in 7d2d

[BFT2020]

26 minutes ago, Urban Blackbear said:

Also, I'll give a cookie to anyone who can post the formula for the area of a circle without googling it first.

pi*r^2 or pi*(d/2)^2 or (pi * d^2) / 4

 

Me good at math  😁

[meganoth]

30 minutes ago, Urban Blackbear said:

We need to make it even more complicated. We need a found ammo type and a self-manufactured ammo type that each have their own failure rates. then we need to program the game to simulate getting powder blow-back in your face.

 

Also, I'll give a cookie to anyone who can post the formula for the area of a circle without googling it first.

 

Why should I allow you to store a cookie in my browser? 😁

[theFlu]

32 minutes ago, Urban Blackbear said:

Also, I'll give a cookie to anyone who can post the formula for the area of a circle without googling it first.

xkcd had a few useful ones recently, the infamous circle included: https://xkcd.com/2509/

[Urban Blackbear]

28 minutes ago, theFlu said:

xkcd had a few useful ones recently, the infamous circle included: https://xkcd.com/2509/

 

I saw that one. It was pretty funny.

[meganoth]

On 9/8/2021 at 2:17 PM, theFlu said:

Go ahead and file that bug report then. It's a little while ago, but I did tests with it early on.. set up a 2x2 wall, aimed at the cross between them, and destroyed one of the blocks based on the dot. Didn't hit the three other blocks once. I think it also worked with the crossbow, the bolts that remain landed exactly on the dot.

 

EDIT add: A good use for the dot is to land sneak attacks.. it shows the distance to target with its size, so you can be relatively sure you're not aiming at a door frame or some such nonsense ..

 

@theFlu I tested the crosshairs with and without laser dot right now.

 

I used an AK47 without laser sight and shot >150 bullets at a wood block. I made it so the center of the crosshair was NOT on the block, but a large part of the crosshair area was on the block. I.e. if the target area was random inside the crosshair it should have hit the block at least about 1/3rd of the time. Actual result: I hit the block just once in over 150 tries and that might have been a mistake because of moving the mouse slighty.

 

Three possible explanations:

1) The crosshair randomizing does not work on inanimate blocks, just on zombies

2) The crosshair randomizing does not work at all

3)  randomizing works with a steep probability curve from the center outward so that you still hit a small center circle in 99% of cases.

 

The next test could invalidate explanation 2. I tried zombies from the zombie spawner, (note to others who want to test that, '*' on the numblock turns off zombie AI). I filled an area with Arlenes in a distance of ~20-25 blocks and tried to shoot at the arlenes in a straight line through that mass. The crosshair was big enough so that less than one third of the crosshair area was filled with the arlene.   

 

And I actually got a miss from time to time, but that was about 1 in 10. In fact I could shoot a perfect line through that mass of zombies when I expected to kill a lot of bystander zombies if the shots were really random inside the whole crosshair area

 

Next I used the Ak with laser sight at a much smaller distance (because, as we all know, laser sight at long distance doesn't work) and I saw what you meant. The laser dot moved around but stayed largely in the center area most of the time and almost never reached the edges. It seemed consistent with what I saw in the previous experiment to make the small center area much more probable to be hit. 

 

So I think you are right, accuracy is simulated with a swaying pointer, but that it is somewhat shy of using the whole crosshair area and largely stays in the center. Except for headshots you can practically ignore the miss chance even at a distance and even headshots will hit most of the time except at really long range. With or without laser sight.

 

Next I redid the experiment with laser sight on the inanimate wood block and actually had a hard time seeing the laser dot at all when pointing slightly away from the block. The experiment was difficult because hitting the button when the dot moved onto the block is difficult when the dot is scarcely ever on the block and then very fast away again.

 

So explanation 1 above is very probably wrong as well. There is some randomness due to the simulated sway but the dot is so seldom outside the "inner circle" that accuracy can be ignored. Actually I feel that worthy of a bug report.

 

 

 

 

[Maharin]

On 9/8/2021 at 1:00 PM, meganoth said:

 

Why should I allow you to store a cookie in my browser? 😁

 

The cookie wasn't going to be hidden in your browser...

[theFlu]

14 minutes ago, meganoth said:

I tested the crosshairs with and without laser dot right now.

Excellent, not only because you seem to have landed on the same page I were, but because your testing sounds pretty comprehensive. For instance I haven't tried shooting "past" blocks, just at selected spots on a solid wall - basically the same test, but aiming past it could've had an unexpected effect.

 

And yeah, the pointer/aim is pretty dead center most of the time when testing - it moves a lot more when the player is moving. The crosshairs should reflect that by closing in if that's the case, but I'm just guessing that they haven't honed the system to that level yet. As in, haven't decided how random the aim should be etc.

 

Could be worth a bug report, I'd assume it's a known issue though; you can't really not see it if you're testing it at all, should come up in dev testing already.

[meganoth]

9 minutes ago, theFlu said:

Excellent, not only because you seem to have landed on the same page I were, but because your testing sounds pretty comprehensive. For instance I haven't tried shooting "past" blocks, just at selected spots on a solid wall - basically the same test, but aiming past it could've had an unexpected effect.

 

And yeah, the pointer/aim is pretty dead center most of the time when testing - it moves a lot more when the player is moving. The crosshairs should reflect that by closing in if that's the case, but I'm just guessing that they haven't honed the system to that level yet. As in, haven't decided how random the aim should be etc.

 

Could be worth a bug report, I'd assume it's a known issue though; you can't really not see it if you're testing it at all, should come up in dev testing already.

 

Ah right, in the know issues I found this: "Laser sight dot doesn't move properly". The error message is slightly misleading as the targetting is broken even without laser sight but I assume a dev will instantly see the connection with general targetting while looking at the code.