Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Physics System Overhaul Tracker #467

Open
VMSolidus opened this issue Jun 16, 2024 · 3 comments
Open

Physics System Overhaul Tracker #467

VMSolidus opened this issue Jun 16, 2024 · 3 comments
Labels
Changes: C# Changes any cs files Changes: YML Changes any yml files Holy Shit Priority: 3-Medium Needs to be resolved at some point Size: 2-Large For large issues/PRs

Comments

@VMSolidus
Copy link
Member

VMSolidus commented Jun 16, 2024

Description

Space Station 14 has a key feature available to it that gives it a significant advantage over coding for Space Station 13, that being a fully fledged Physics System. Under this system, every entitity in the game has access to information such as Mass, Density, Size, Hitboxes, and so on. This information gets referenced by other systems, which allows the game to have a sort of tactile responsiveness to a player's actions. Yet unfortunately, the core game of SS14 doesn't have consistent applications of it. Objects are missing correct mass values, systems that could account for it don't, some systems have incomplete usage of it.

I have been for awhile seeking to expand upon the game's usage of Physics, and have been pushing for a series of PRs that add complicated interactivity to the game. The start of which is my Space Wind Rework, which has gradually turned into a substantial overhaul of the game's Atmos system. But SWR isn't the whole story, because a whole host of other systems have emergent interactions with Space Wind.

Imagine, a security officer is sucked out of space by a nukie's C4 explosion. Armed with his own Lector, the security officer uses Newton's 1st Law to get himself back to the station. If this security officer was a short or lightweight character such as a Harpy, he might have been thrown farther from the station, yet at the same time he will need to shoot less mass from his gun to change his direction. Yet if this security officer was a heavier character like an Oni, his higher mass might have saved him from being propelled to space in the first place. Yet if he is thrown out, changing his direction by throwing mass is harder to do, owing to his own higher mass. Imagine he only has a handgun instead. The lighter mass and force of the handgun should be less effective than the heavier rifle at propelling him through space.

What if he was instead an engineer carrying floor tiles? Plastic tiles? Steel tiles? One of these two should have substantially higher mass, and would therefore be more useful to throw!

Related Issues:

  • The Great Mass'ening #460
    Objects need variety in mass, not everything should weigh a uniform 5kg. Differently massive objects are thrown at different rates by space wind

  • The Great HitBox'ening #461
    Objects should have actual variety in hitboxes, which will change the behavior of them coming into contact with barriers and such.

  • Significantly Improve the Sound Library #352
    When I throw a steel tile at a wall, it shouldn't make the same sound as a sheet of paper.

  • Port Supermatter Engines from White Dream #337
    Supermatter is the undisputed king of creating atmos system chaos, whether someone uses it to make an air cannon, or it spawns a tesla ball that in turn creates a vast number of holes in the station for air to escape.

Related PRs:

@VMSolidus VMSolidus added Changes: C# Changes any cs files Changes: YML Changes any yml files Holy Shit Priority: 3-Medium Needs to be resolved at some point Size: 2-Large For large issues/PRs labels Jun 16, 2024
This was referenced Jun 19, 2024
DangerRevolution added a commit that referenced this issue Jul 1, 2024
# Description

Part of #467, #460, and #474

This is a small PR that corrects a math error in SharedGunSystem,
causing shell casings to be "Thrown" directly downwards instead of in an
actually cinematic and exciting arc. While I'm at it, I also corrected
the fixture of base shell casings to favor "Bounciness", and decreased
its mass to approximately 100 grams. Finally, I added a sound for when
casings bounce off of walls, which wasn't present before.


https://github.com/Simple-Station/Einstein-Engines/assets/16548818/56bb4ecc-d5eb-4b36-853b-42f05374150d

🆑
- fix: Spent bullet casings now fly away from a shooter in a cinematic
manner, rather than fall at their feet.

Co-authored-by: Danger Revolution! <[email protected]>
@WarMechanic
Copy link
Contributor

it would be cool if bullets were affected by physics to some degree, such that their trajectory would arc around gravitational singularities or a potential psionic power

@DEATHB4DEFEAT
Copy link
Member

it would be cool if bullets were affected by physics to some degree, such that their trajectory would arc around gravitational singularities or a potential psionic power

I believe they are and do.

@WarMechanic
Copy link
Contributor

hm, ill have to test this at some point

DangerRevolution added a commit that referenced this issue Jul 13, 2024
# Description

Part of Issue #467 

This is a complete re imagining of the Nyanotrasen Mass Contest
System(Long since removed from the game). This system adds a highly
flexible function that outputs a ratio of a given entity's mass, that is
optionally relative to another entity. I've primarily written this
system to be used in conjunction with PR #458 , as it adds several new
implementations of variable player mass to the game.

How this differs from the original Mass Contest system is that it is
configured via hotloaded CVars, and is inherently clamped so that
character mass only modifies functions by a finite amount rather than
providing infinite scaling. This essentially means that while an Oni is
25% better at shoving a Felinid to the floor thanks to their different
masses, a 2000kg Lamia is also only 25% better at shoving a Felinid to
the floor, rather than 50000% better. The inverse is also true, a small
player character can only be 25% better or worse at a given
implementation. These implementations are not handled directly by the
ContestSystem, and are instead handled directly by other systems that
call upon it.

This percentage limit can be modified by a new CVar at any time.
Additionally, the entire MassContest system can be optionally toggled
off completely at any time via CVar, without needing to modify any code
that calls upon it.

At this time, I have included three different implementations to serve
as suitable examples for how MassContest can be used.

1. Weapon recoil is now modified by an entity's mass relative to the
human average baseline. Smaller characters experience more recoil,
larger characters experience less recoil
2. Disarm/Shove is now modified by Mass Contests. Entities that are
sized differently from their target have their shove/disarm chance
modified based on the ratio of performer and target mass.
3. Certain types of handcuffs(such as Cablecuffs and zipties) are now
faster to slip out of if you are smaller than the average.

# Changelog

:cl:
- add: Mass Contests have returned in a new reworked form. 
- add: Weapon Recoil is now resisted by character mass. More massive
characters take less recoil, less massive characters take more recoil.
- add: Disarm and Shove actions are now modified by relative character
mass. It is easier to shove people around if you're bigger than them.
- add: Cablecuffs and Zipties are now easier to escape out of if you're
smaller.

---------

Signed-off-by: VMSolidus <[email protected]>
Co-authored-by: DEATHB4DEFEAT <[email protected]>
Co-authored-by: Danger Revolution! <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Changes: C# Changes any cs files Changes: YML Changes any yml files Holy Shit Priority: 3-Medium Needs to be resolved at some point Size: 2-Large For large issues/PRs
Projects
Status: In Progress
Development

No branches or pull requests

3 participants