wolfiregames / 7dfps Goto Github PK

As soon as the application is opened from steam, it starts in a window and the mouse pointer disapears. Once in the game, the mouse successfully changes aim when done in small amounts. After moving the mouse enough in a direction, the game freezes while continuing to play audio. Using alt-tab (xfwm4 is window manager) to switch to another window and then switch back makes the unfreezes the game and the cycle repeats.

Nice game, otherwise. :)

Thanks,
Mark

Looks weird, but they still manage to find their target at 30fps.
Drones fail to find their target at some point, but at that point the game is pretty unplayable anyways.

Might still be a problem for a sudden spike though.

On the Glock and 1911, If you clear the gun, lock the slide back, insert a loaded mag, then press R to rack/release the slide, sometimes the top round will be ejected. This only happens sometimes, and I'm not sure why.

Describe the problem:
Acquire a Glock Pistol with the full auto modification.
Make sure it's loaded.
Hold down the left mouse button while the firemode selector is on semi-automatic.
A bullet will fire, do not release the mousebutton. Switch to full-automatic.
The magazine will deplete.

I cannot confirm if this is what really happens on the real glock. I would put mythbusters on it but it's not a very interesting problem.

I imagine that because of the trigger reset after each shot, it may be preventing the gun from releasing the hammer when the gun is switched to full-auto. But since no one is dumb enough to risk their fingers trying this, I don't mind having it the way it is.

After testing this in Algodoo with an AR15, it turns out that switching from semi to full auto pushes the mechanism down that prevents the rifle from firing full auto.

I will do some research about this and look at blueprints to see if the Glock does the same.

I think this has been mentioned on the forum but there was no issue about it here.

If David or whoever is working on this game decides to fix it, you can just tick this issue fixed.

Describe the problem:
Pulling the slide back with "R" and then inserting a magazine with bullets and then taking out the magazine will result in the bullet from the magazine to be floating near the feeding ramp.

Letting the slide forward by releasing "R" will then have successfully loaded the gun.

The same bug can be created while having the slide locked with the slide catch, inserting a loaded magazine and then taking it out again. However, most people won't notice this bug while dry reloading because the chamber cannot be visually seen after a dry reload.

Gunsmith's rant:
A bullet never leaves the magazine until the slide pushes it forward from the magazine into the feeding ramp and into the chamber.

Exceptions for this rule are:
Chamber loaded pistols and shotguns.
Revolver guns with cylinder.
Pump & Semi-Auto Shotguns with tube.
Machineguns with linked bullet casings.
Harpoon rifles.

Suggestion:
It would create some more bugs but would make gameplay realistic:
Create a 0 to 100% distance the bullet must travel from the magazine to the chamber. If you release the slide and then quickly pull it back again, a bullet may be stuck at 40% and in order to fix it, the player must remove the magazine, holster the pistol, press z to push it back in again or make a new key to remove the bullet.

If the slide is released to the point where the bullet is no longer under the magazine's spring tension and then quickly pulled back again, the next bullet in the magazine will be at the top position in the magazine. Releasing the slide at this point will create a double feed which will jam the gun. If there's a bullet in the chamber at this point, the slide will have to be moved forward with the magazine taken out, to catch the bullet sitting in with the extractor and then pulled back to successfully remove it.

Thanks for the awesome game.

When used the help-control ("?") on Linux the player/character jumps and shoots:
http://www.youtube.com/watch?feature=player_embedded&v=60f_djFlyKw (this video is not made by me). I'm using a German Keyboard/Keyboard-layout and the steam version of Receiver.

This is a suggestion and should not be top priority, but the people from /v/ and /k/ will love this feature.

Upon releasing the mousebutton after shooting, a distinct click sound of a trigger reset should be present.

The sound should be present every time the trigger has been pulled and the hammer been pulled back by the slide, and then releasing the mousebutton.

Here's a vid to inspire you:
http://www.youtube.com/watch?feature=player_detailpage&v=i-f6G6-2T4w#t=38s

Thanks for your time.

As per request, I have moved #27 into an issue and split the pull request up into smaller ones.
I will try referencing back to this issue while providing smaller pull requests.

TODO:

• Fix tabs / 4 spaces issue inside the gunscript (As this script will be heavily rewritten anyways)
• Add some way of specifiying controls. (As of writing this, trying to make a bolt action with a mag will cause duplicate key assignments [rotating bolt and ejecting])
• Add more guntype options to allow at least all the original mods to work
• Make it possible to disable Vanilla weapons
• Make it possible to disable Vanilla tiles
• Add a gun selection
• Add warnings if mods aren't compatible or incorrectly setup
• Make the process of creating custom tiles as easy as possible
• Untie tile balance from the amount of possible item/enemy spawns (experimental branch had... varying success)
• Add support for custom Tapes (I'm sure people would love that)
• Add warnings when trying to create modbundles with wrongly setup prefabs
• (Probably more I missed)

NOTES:

• I have noticed that two shotgun runs had way too many things spawn. I have yet to reproduce this, but think that this wasn't just due to "luck"
• One planned addition was "Rotate the camera when aiming big guns to better simulate resting on the stock", after implementing I noticed that this does not play well at all.
  Feedback is always appreciated!

I can click-and drag to move around the text or use arrow keys though.

I don't own a 1911 myself, but I'm fairly sure you can pull the slide and check the chamber with the safety on. That doesn't seem to be the case in-game.

Describe the bug

When playing at high refresh rates (~120+fps), it becomes quite obvious that movement is being updated at a much lower rate than view control, making it feel somewhat choppy. This appears to be due to it using FixedUpdate(), which is presumably running at 50 or 60 Hz. I didn't do a ton of digging around, but it looks like just changing the bool useFixedUpdate = true; in AimScript.cs to false would solve this problem? I haven't figured out how to properly get this repo working in unity so I haven't been able to experiment, but this seems like a simple fix in any case. ¯\_(ツ)_/¯

To Reproduce
Steps to reproduce the behavior:

1. use high refresh rate monitor
2. enable v-sync to bypass 60fps cap
3. move around, look around, observe non-smoothness?

Expected behavior

smooth movement

What
Add option to press shift to run in addition to W-tap.

Why
Receiver 2 has it, https://steamcommunity.com/app/1129310/discussions/search/?q=shift+run&gidforum=2865909887923510527&include_deleted=1

For me personally the worst part about it is not being able to fine-jump onto ledges, as tapping w makes me leap over into death.

Turning on shift/hold-sprint should at the same time disable tap-sprint.

Alternatives
I've been hacking the game with dnspy for my need but I'd be nice to have for accessibility.
Others use AHK scripts or something.

How

R1 ui suggestion:

Ideally "toggleable sprint" would be disabled if "holdable sprint" is disabled but even R2 doesn't have that, so...

R2 ui:

Code findings

From discord:

- Find if(old_vert_axis < 0.9f && character_input.GetAxis("Vertical") >= 0.9f){
- Replace with if(Input.GetKey(KeyCode.LeftShift) || old_vert_axis < 0.9f && character_input.GetAxis("Vertical") >= 0.9f){

but then

if((Input.GetKey(KeyCode.LeftShift) && character_input.GetAxis("Vertical") >= 0.9f) || (old_vert_axis < 0.9f && character_input.GetAxis("Vertical") >= 0.9f)){
Would do that instead

and also

if (true)
{
    if (!this.crouching && Input.GetKey(KeyCode.LeftShift) && !base.GetComponent<AimScript>().IsAiming())
    {
        this.SetRunning(Mathf.Clamp(2f, 0.01f, 1f));
        this.bool_running = true;
    }
    this.forward_input_delay = 0f;
}
this.forward_input_delay += Time.deltaTime;
if (!Input.GetKey(KeyCode.LeftShift) || base.GetComponent<AimScript>().IsAiming())
{
    this.SetRunning(0f);
    this.bool_running = false;
}

I was told that MovementInputs.cs gets auto-updated after modifying MovementInputs.inputactions, so there would be no need to manually edit it.

Would be cool if someone was up to the task but worst case I'll come back with more free time in a year and try to make a commit based on these notes :)

When having a 1911 or glock empty with a mag clip inside. The top of the gun is sled off. When you press t you can slide it back (with an empty mag inside). I think it should be prevented as long pressing r in this state doesnt slides back.

As I don't have an American keyboard, most of the non-alphanumeric keys you've chosen for certain things (like ? and ~) are either Shift+ or even a dead key, and so I had to rebind them. Thanks for providing that feature in your launcher, a lot of games just assume everyone's an American.

However, in the game, it still says to press the original keys, not my rebound keys. I bound holster to comma(,) help to dash(-) and reset game to period(.), but in the game, it still tells me to press ? for help, and to press ~ for holster and to hold l for reset.

It's a bit confusing, to say the least. Shouldn't you update your in-game instructions when the bindings are changed?

game locks to 1024x768 windowed and there is no way to change graphical settings.
thats quite a pitty to have to play the game via wine to be able to change resolution.