wizard puke
Refugee
Your gun is in your chin and renders through walls in almost every fps game but this is the thing that makes it unrealistic for you? 
PC Simple improvements that fun pimps should make to the firearms in 7d2d
- Thread starter Nifty_games
- Start date
theFlu
Hunter
Ok, I might be a taad slow today, but, I went back and understood the issue (I think):
But as I assume the current system is sway-based already, I didn't even think to suggest otherwise.
If you assume that the sway would be random AND unrelated to the actual point of aim, then absolutely, I'd be filing bug reports. The current "Crosshairs even while aimed" would be better, because a sway animation without relevance to the shooting would just drive me up a wall ...
But as I assume the current system is sway-based already, I didn't even think to suggest otherwise.
Last edited by a moderator:
Ok, I might be a taad slow today, but, I went back and understood the issue (I think):
If you assume that the sway would be random AND unrelated to the actual point of aim, then absolutely, I'd be filing bug reports. The current "Crosshairs even while aimed" would be better, because a sway animation without relevance to the shooting would just drive me up a wall ...
But as I assume the current system is sway-based already, I didn't even think to suggest otherwise.
The current system sway-based? What evidence seems to point in that direction? This would (IMHO) only be the case if they had inherited code from or adapted a shooter game where weapon sway was included.
The devs and Roland (to my knowledge) have always said that the actual hit is just a random spot inside the "accuracy" circle you see in the HUD.
And how they produce that randomness internally is not known, but getting two simple random numbers that depict a specific point in a circle only when you shoot uses MUCH less cpu and is much easier to program than an invisible swaying point that needs to be updated continually. Occams razor decidedly points to no invisible sway being used.
Last edited by a moderator:
theFlu
Hunter
The Laser Dot mod I've been railing about. It's quite a good pointer at that..
Try it. I just tried in my current game with a crossbow, bolts on the dot, always. Dot travels like sway.Might be plausible there's a mechanic for it in the game env they're working on top of.
Test the laser, guess more after. I agree it is a more expensive way, but not THAT much more expensive, couple of cycles (x_travelSpeed + rnd(-0.5,0.5) .. x_coord + travelSpeed, every 1/60 sec)
Last edited by a moderator:
Urban Blackbear
Refugee
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.
Also, I'll give a cookie to anyone who can post the formula for the area of a circle without googling it first.
Last edited by a moderator:
BFT2020
Hunter
theFlu
Hunter
Urban Blackbear
Refugee
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.
theFlu
Hunter
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.