Randomly picks a 2D point in a 50m radius around the player using three different randomization techniques.
You can use that 2D point to then spawn objects, infantry would be placed at ground level, aircraft would spawn flying in the air.
Or ammo crates, plants, animals, weapons, fences, buildings, etc.
why do first person shooters never implement realistic bullet trajectory with tilted scopes like you'd have in real life?
In real life you have to aim below you target at medium-long distances and only above at short and long distances, but i've never seen a game implement this. Would be fun i think
>never
Even the Battlefield games had that, with quite a few tricks (including some projectiles being affected by stronger gravity) to make it noticeable at shorter ranges.
It's neat but a low priority feature in most cases, and gamedev is notorious for unrealistic deadlines and unifinished releases.
Because it causes problems when you need to do realistic looking physics and you need to do it fast. Most physics engines do a number of bullshit to be fast.
The easiest way to simulate a bullet is to draw a straight line from the barrel to infinity and check for the first colliding object. Many physics engines actually optimize this raycasting and stop on first hit for you. This works very well.
The next thing you can do is to actually fire a bullet. This is usually a gameobject which has an associated script that simulates the deacceleration of the bullet by calculating and applying the negative forces on every tick according to the equation of a bullet.
There are multiple problems with this: for starters it is expensive and the bullet's hitbox actually needs to collide. So it is an expensive fully simulated object travelling. Due to the huge velocity of the bullet many physics engines don't tolerate this well. There are often problems with fast moving objects in game physics. That's why developers cheat with world size and car speed. A fast moving object might travel enough distance to "jump through" an object between two ticks. To handle that the engine needs to detect that there was an object between the positions at P(tick_n) and P(tick_n_1) and then do a correction step. This is costly.
Another problem is the fact that now that your bullet is a gameobject it needs to be synced between players. This can lead to more strange situations when a player's local calculations differ from the server's due to ping and you might think that you are not getting shot when you do and vice versa.
This ping issue is actually far more generic. It stems from the fact that there is ping G1 beetwen P1 player and S sever. There is G2 between P2 and S. Finally, there is G1+G2 between P1 and P2. To be more precise G1+G2 is a lower limit since additional calculations are also taking place on the server side.
>Because it causes problems when you need to do realistic looking physics and you need to do it fast.
computers are fast >The easiest way to simulate a bullet is to draw a straight line
a straight line is not that much different from an arc >This is usually a gameobject which has an associated script that simulates the deacceleration
that's the moronic brute force way of doing it, you can precalculate the arc on click and just step through it through time, gravity and direction won't change in such a short time, you know every force in frame 0 >for starters it is expensive and the bullet's hitbox actually needs to collide
again, use a fricking raytrace with an arc >So it is an expensive fully simulated object travelling
we have machines way faster than the 90s and it's only a problem for diversity hires and morons >There are often problems with fast moving objects in game physics
here's a simple little secret, you can extend the bullet shape (checking for a line segment instead of a point), that's one way to avoid ghosting >gameobject it needs to be synced between players
DETERMINISTIC SIMULATION, was discovered more than 20 years ago, send only player input
even if you want cool bullet vs bullet interaction, you just need an extra step
>constants
why do you feel its important to indicate mutability in the variable name? especially when you evidently dont feel its important to indicate type. How do i know if _angle is in radiants or degrees? how do i know if _distance is a float or an int.
Identifiers shouldn't include type information and that includes mutability.
>private methods
use namespaces or w/e that language equivalent is
>constants
why do you feel its important to indicate mutability in the variable name? especially when you evidently dont feel its important to indicate type. How do i know if _angle is in radiants or degrees? how do i know if _distance is a float or an int.
Identifiers shouldn't include type information and that includes mutability.
>private methods
use namespaces or w/e that language equivalent is
It's a mandatory part of the language >Identifiers of local variables must start with an underscore.
https://community.bistudio.com/wiki/Identifier
1 month ago
Anonymous
ok i forgive you and blame the language instead then
1 month ago
Anonymous
Arma's jank knows no bounds
https://community.bistudio.com/wiki/call#Examples
To generate random positions in a circle, it's actually easier and faster to generate random positions in a square and throw away the positions that are not in the circle. Computing a square root is expensive, throwing away ~22% of your positions isn't.
t. autism
>Arma is fricking technology
The original Arma was indeed tech. It integrates with a body suit the US Army used for training and was ultra-realistic. Arma as it is used now is a pew pew pew game, even when people try to set it to a more realistic play-mode and LARP with combat communications. It's also gotten crappier with time, as in less realistic. Bots can see you through cover.
I played the OFP campaign. I didn't notice it being any more realistic than Arma 3 when it comes to the physics. The only thing that comes to mind is how you could get your legs broken and have to crawl for the rest of the level or restart. But Arma 3 has stances which make firing under cover much more realistic.
It is more realistic in the sense that the weapons are real and in Arma 3 most of them are fictional or prototypes which does indeed suck.
>fictional or prototypes
They're all based on real things, though.
Eg. the SPAR-17 is an HK 417, the ASP-12 is a VSSK Vychlop, the GM6 Lynx actually exists and is a licensed insert, the devs went to the company in Hungary and test-fired it and recorded audio, etc.
The only smoewhat "futuristic" thing is the 6.5mm ammo, but honestly, if you use 5.56mm, you're happy they made that change.
That being said, it's the AK-12 for me, which, AFAIK, is one of the AK-1xx variants, with standard barrel, stock and using 7.62x39mm ammunition.
It's more of a "let's not use the real names due to licensing issues."
Same with vehicles, the MBT-52 Kuma is a Leopard 2A5, the M4A2 Slammer is a Merkava Gen. 3 or 4 (can't remember), there's the T100 which is an upgraded T90 IIRC and the T140 which is the Armata, etc.
For the record, I don't use mods, shit needs to work with vanilla before opening another Pandora's Box.
gaussian just looks right
This looks like something average moron middleschooler would write in class in python
What does this shit even do?
Randomly picks a 2D point in a 50m radius around the player using three different randomization techniques.
You can use that 2D point to then spawn objects, infantry would be placed at ground level, aircraft would spawn flying in the air.
Or ammo crates, plants, animals, weapons, fences, buildings, etc.
Only gaussian naturally fades out without leaving a halo around the perimeter.
Build a pc with a 7900X3D a rtx4090 128gb of the fastest ram and fastest nvme and still get as low as 21 fps at some moments.
Still a great game but badly optimized.
>7900X3D
Oh no, it's moronic.
that's an example, doesn't really matter what pc you have you'll still drop way below 30 fps a lot of the time.
what language has a "random" keyword?
iirc they use their own c# based language called nforcer script.
Arma 3 uses SQF
https://community.bistudio.com/wiki/SQF_Syntax
Oh, true enforced was for dayz and Arma Reforger.
Several languages that are functional or that try to be "multiparadigm" (a.k.a. "shit") wind up looking like that. Also autohotkey.
A scripting language where RNG is expected to see a lot of use.
frick it since this is basically a IQfy thread
why do first person shooters never implement realistic bullet trajectory with tilted scopes like you'd have in real life?
In real life you have to aim below you target at medium-long distances and only above at short and long distances, but i've never seen a game implement this. Would be fun i think
some games do and it sucks
you're in a thread about a game that does this so i have no idea what you're talking about. plenty more out there, too.
Because it's easier to do a hitscan from the camera position along the view axis, and that's what most players expect.
arma 3 has scope zero adjustment with realistic(ish) bullet trajectories (rng deviation instead of a simulated wind)
scripting arma missions and writing morrowind mods was my first encounter with coding
godspeed, anon
>godspeed, anon
Same, Anon, same.
Pubg anon
They do.
And it's bad.
it's fun in hunting games and in mil shooters, wouldn't be so much fun in arena shooters (including derivatives like counter-strike)
>never
Even the Battlefield games had that, with quite a few tricks (including some projectiles being affected by stronger gravity) to make it noticeable at shorter ranges.
It's neat but a low priority feature in most cases, and gamedev is notorious for unrealistic deadlines and unifinished releases.
Because it causes problems when you need to do realistic looking physics and you need to do it fast. Most physics engines do a number of bullshit to be fast.
The easiest way to simulate a bullet is to draw a straight line from the barrel to infinity and check for the first colliding object. Many physics engines actually optimize this raycasting and stop on first hit for you. This works very well.
The next thing you can do is to actually fire a bullet. This is usually a gameobject which has an associated script that simulates the deacceleration of the bullet by calculating and applying the negative forces on every tick according to the equation of a bullet.
There are multiple problems with this: for starters it is expensive and the bullet's hitbox actually needs to collide. So it is an expensive fully simulated object travelling. Due to the huge velocity of the bullet many physics engines don't tolerate this well. There are often problems with fast moving objects in game physics. That's why developers cheat with world size and car speed. A fast moving object might travel enough distance to "jump through" an object between two ticks. To handle that the engine needs to detect that there was an object between the positions at P(tick_n) and P(tick_n_1) and then do a correction step. This is costly.
Another problem is the fact that now that your bullet is a gameobject it needs to be synced between players. This can lead to more strange situations when a player's local calculations differ from the server's due to ping and you might think that you are not getting shot when you do and vice versa.
This ping issue is actually far more generic. It stems from the fact that there is ping G1 beetwen P1 player and S sever. There is G2 between P2 and S. Finally, there is G1+G2 between P1 and P2. To be more precise G1+G2 is a lower limit since additional calculations are also taking place on the server side.
I mean you're right, but it's kind of a transversal issue. You can perfectly implement a hitscan with a curved trajectory instead of a straight line.
>Because it causes problems when you need to do realistic looking physics and you need to do it fast.
computers are fast
>The easiest way to simulate a bullet is to draw a straight line
a straight line is not that much different from an arc
>This is usually a gameobject which has an associated script that simulates the deacceleration
that's the moronic brute force way of doing it, you can precalculate the arc on click and just step through it through time, gravity and direction won't change in such a short time, you know every force in frame 0
>for starters it is expensive and the bullet's hitbox actually needs to collide
again, use a fricking raytrace with an arc
>So it is an expensive fully simulated object travelling
we have machines way faster than the 90s and it's only a problem for diversity hires and morons
>There are often problems with fast moving objects in game physics
here's a simple little secret, you can extend the bullet shape (checking for a line segment instead of a point), that's one way to avoid ghosting
>gameobject it needs to be synced between players
DETERMINISTIC SIMULATION, was discovered more than 20 years ago, send only player input
even if you want cool bullet vs bullet interaction, you just need an extra step
>_ identifiers
Frick off.
elaborate
not him but i share the sentiment
whats the point of prepending _ ? other than to feel special of course, which you are not.
constants and/or private methods
>constants
why do you feel its important to indicate mutability in the variable name? especially when you evidently dont feel its important to indicate type. How do i know if _angle is in radiants or degrees? how do i know if _distance is a float or an int.
Identifiers shouldn't include type information and that includes mutability.
>private methods
use namespaces or w/e that language equivalent is
It's a mandatory part of the language
>Identifiers of local variables must start with an underscore.
https://community.bistudio.com/wiki/Identifier
ok i forgive you and blame the language instead then
Arma's jank knows no bounds
https://community.bistudio.com/wiki/call#Examples
To generate random positions in a circle, it's actually easier and faster to generate random positions in a square and throw away the positions that are not in the circle. Computing a square root is expensive, throwing away ~22% of your positions isn't.
t. autism
>Arma is fricking technology
The original Arma was indeed tech. It integrates with a body suit the US Army used for training and was ultra-realistic. Arma as it is used now is a pew pew pew game, even when people try to set it to a more realistic play-mode and LARP with combat communications. It's also gotten crappier with time, as in less realistic. Bots can see you through cover.
I played the OFP campaign. I didn't notice it being any more realistic than Arma 3 when it comes to the physics. The only thing that comes to mind is how you could get your legs broken and have to crawl for the rest of the level or restart. But Arma 3 has stances which make firing under cover much more realistic.
It is more realistic in the sense that the weapons are real and in Arma 3 most of them are fictional or prototypes which does indeed suck.
>fictional or prototypes
They're all based on real things, though.
Eg. the SPAR-17 is an HK 417, the ASP-12 is a VSSK Vychlop, the GM6 Lynx actually exists and is a licensed insert, the devs went to the company in Hungary and test-fired it and recorded audio, etc.
The only smoewhat "futuristic" thing is the 6.5mm ammo, but honestly, if you use 5.56mm, you're happy they made that change.
That being said, it's the AK-12 for me, which, AFAIK, is one of the AK-1xx variants, with standard barrel, stock and using 7.62x39mm ammunition.
It's more of a "let's not use the real names due to licensing issues."
Same with vehicles, the MBT-52 Kuma is a Leopard 2A5, the M4A2 Slammer is a Merkava Gen. 3 or 4 (can't remember), there's the T100 which is an upgraded T90 IIRC and the T140 which is the Armata, etc.
For the record, I don't use mods, shit needs to work with vanilla before opening another Pandora's Box.