The "Floating shell" bug

The place to discuss all things Receiver.
Post Reply
User avatar
UNHchabo
Posts: 21
Joined: Mon Sep 23, 2013 4:20 am

The "Floating shell" bug

Post by UNHchabo » Wed Nov 27, 2013 5:26 am

So I've talked previously about how I wanted to fix this bug:
viewtopic.php?f=17&t=16833&start=30#p178359

Where the current code chambers a round either on pulling the slide back, or inserting a mag on an open slide, my fix changes it so that the round gets chambered when the slide moves forward. The only file I've changed so far is GunScript.js.

I tested my patch before, and everything seemed fine, but after getting the go-ahead from Wolfire to check it in, I ran into a new bug while testing. Originally I was using Unity 4.2, but now I'm using 4.3, if that matters.

I insert the mag on a locked-back slide, and occasionally the top round gets stripped right away, but usually not. If I leave the mag in and slide locked, then I can walk around, and sometimes the top round will get stripped all of a sudden, and float in the chamber. It seems to be able to happen at any time, but it seems like I can get it to happen most of the time when a new room gets generated.

Anyone have an idea why this is happening?

On another note: this is my first time working with Unity, so I haven't been able to get the debugger to trigger breakpoints. Has anybody here been able to do it?
Attachments
GunScript.js
GunScript
(32.07 KiB) Downloaded 333 times

User avatar
Josh707
Posts: 123
Joined: Sun Jan 22, 2012 3:09 pm
Location: Canada

Re: The "Floating shell" bug

Post by Josh707 » Wed Nov 27, 2013 6:22 pm

I logged each value in this part of the script:

Code: Select all

if(slide_amount < kFeedPosition && old_slide_amount >= kFeedPosition){
    ChamberRoundFromMag();
}
slide_amount is fluctuating around 0.3-0.4 while it is supposed to be stuck at 0.9 as it's set to kSlideLockPosition earlier in the script, while old is stuck at 0.9.

Code: Select all

slide_amount = Mathf.Max(0.0, slide_amount - Time.deltaTime * kSlideLockSpeed);


Is causing slide_amount to fluctuate, it's set to kSlideLockPosition earlier in the script, the slide's transform position is set just below it, and then this calculation is done after so it doesn't affect the movement. It will take the time between the previous frame and current multiplied by 20 and subtract that from slide_amount, but the slide lock part of the script earlier overrides that. Apparently slide_stage is set to nothing rather than hold when the slide lock is engaged as well, so this whole block will execute if it's locked but doesn't do anything (except chamber the round currently).

Adding an argument to the if statement for not having the slide lock on makes it work but it seems like more of a hack than a fix. You can lower kFeedPosition to something below 0.3 roughly and it will work as well, but the value may be framerate dependant. I think this part of the script needs to be reordered/rewritten it to work the way you want, I've been looking at it for a while now so I'm gonna take a break but I'll let you know if I figure something out.

User avatar
UNHchabo
Posts: 21
Joined: Mon Sep 23, 2013 4:20 am

Re: The "Floating shell" bug

Post by UNHchabo » Wed Nov 27, 2013 8:17 pm

Josh707 wrote:Apparently slide_stage is set to nothing rather than hold when the slide lock is engaged as well, so this whole block will execute if it's locked but doesn't do anything (except chamber the round currently).
It's set to hold only when the user is actively holding the slide in place, whether all the way back, or as part of a press check.
Josh707 wrote:Adding an argument to the if statement for not having the slide lock on makes it work but it seems like more of a hack than a fix. You can lower kFeedPosition to something below 0.3 roughly and it will work as well, but the value may be framerate dependant. I think this part of the script needs to be reordered/rewritten it to work the way you want, I've been looking at it for a while now so I'm gonna take a break but I'll let you know if I figure something out.
kPressCheckPosition is 0.4, so it doesn't make sense to me that the pistol would feed after that point. I think it'd make more sense to not even calculate the new slide position if the slide lock is on, cause it should be held in place.

Here's my revision of that block; what do you think?

Code: Select all

		if(slide_stage == SlideStage.NOTHING){
			var old_slide_amount = slide_amount;
			if(slide_lock){
				var new_slide_amount = Mathf.Max(0.0, slide_amount - Time.deltaTime * kSlideLockSpeed);
				if(old_slide_amount >= kSlideLockPosition){
					slide_amount = Mathf.Max(kSlideLockPosition, new_slide_amount);
					if(old_slide_amount != kSlideLockPosition && slide_amount == kSlideLockPosition){
						PlaySoundFromGroup(sound_slide_front, kGunMechanicVolume);
					}
				}
			} else {
				slide_amount = Mathf.Max(0.0, slide_amount - Time.deltaTime * kSlideLockSpeed);
				if(slide_amount < kFeedPosition && old_slide_amount >= kFeedPosition){
					ChamberRoundFromMag();
				}
				if(slide_amount == 0.0 && old_slide_amount != 0.0){
					PlaySoundFromGroup(sound_slide_front, kGunMechanicVolume*1.5);
					if(round_in_chamber){
						round_in_chamber.transform.position = transform.FindChild("point_chambered_round").position;
						round_in_chamber.transform.rotation = transform.FindChild("point_chambered_round").rotation;
					}
				}
			}
			if(slide_amount == 0.0 && round_in_chamber_state == RoundState.LOADING){
				round_in_chamber_state = RoundState.READY;
			}
		}

User avatar
Josh707
Posts: 123
Joined: Sun Jan 22, 2012 3:09 pm
Location: Canada

Re: The "Floating shell" bug

Post by Josh707 » Thu Nov 28, 2013 2:42 pm

UNHchabo wrote:kPressCheckPosition is 0.4, so it doesn't make sense to me that the pistol would feed after that point. I think it'd make more sense to not even calculate the new slide position if the slide lock is on, cause it should be held in place.
Yeah, it was just a crappy suggestion 'cause the value was fluctuating around 0.3, rewriting was the best option like you did.
UNHchabo wrote:Here's my revision of that block; what do you think?

Code: Select all

		if(slide_stage == SlideStage.NOTHING){
			var old_slide_amount = slide_amount;
			if(slide_lock){
				var new_slide_amount = Mathf.Max(0.0, slide_amount - Time.deltaTime * kSlideLockSpeed);
				if(old_slide_amount >= kSlideLockPosition){
					slide_amount = Mathf.Max(kSlideLockPosition, new_slide_amount);
					if(old_slide_amount != kSlideLockPosition && slide_amount == kSlideLockPosition){
						PlaySoundFromGroup(sound_slide_front, kGunMechanicVolume);
					}
				}
			} else {
				slide_amount = Mathf.Max(0.0, slide_amount - Time.deltaTime * kSlideLockSpeed);
				if(slide_amount < kFeedPosition && old_slide_amount >= kFeedPosition){
					ChamberRoundFromMag();
				}
				if(slide_amount == 0.0 && old_slide_amount != 0.0){
					PlaySoundFromGroup(sound_slide_front, kGunMechanicVolume*1.5);
					if(round_in_chamber){
						round_in_chamber.transform.position = transform.FindChild("point_chambered_round").position;
						round_in_chamber.transform.rotation = transform.FindChild("point_chambered_round").rotation;
					}
				}
			}
			if(slide_amount == 0.0 && round_in_chamber_state == RoundState.LOADING){
				round_in_chamber_state = RoundState.READY;
			}
		}
The way you rewrote it seems to be working properly, it doesn't pick up a round when the slide is locked but it does when it's moving forward, and still allows that little movement when it's locked. Just reading it I can't see any other problems it would cause so I think you're good! I tested just about every method of moving the slide and no problems, and logging the values when it chambers a round from the locked position are all around this:

Code: Select all

Slide: 0.2928888 Old: 0.6261443
Slide: 0.3624157 Old: 0.6506624
Slide: 0.375492 Old: 0.6649231
Sometimes it seems like it cuts a little close to missing the feed position but it seems to be working properly. At a low frame rate the old value is always 1 if you release the slide from being fully back, and 0.9 from the lock, so yeah I think it'll work properly. Nice! It's definitely more realistic this way.

User avatar
UNHchabo
Posts: 21
Joined: Mon Sep 23, 2013 4:20 am

Re: The "Floating shell" bug

Post by UNHchabo » Thu Nov 28, 2013 5:36 pm

Josh707 wrote:Sometimes it seems like it cuts a little close to missing the feed position but it seems to be working properly.
Well, even if you were able to render at a billion frames per second, you'd still have one single frame where the slide position goes from 0.6000000 to 0.5999999, and that's when it would pick up a round. Meanwhile, lag that causes the slide to move all the way from 1.0 to 0.0 in a single frame would still trigger that.

User avatar
Josh707
Posts: 123
Joined: Sun Jan 22, 2012 3:09 pm
Location: Canada

Re: The "Floating shell" bug

Post by Josh707 » Thu Nov 28, 2013 6:26 pm

UNHchabo wrote:Well, even if you were able to render at a billion frames per second, you'd still have one single frame where the slide position goes from 0.6000000 to 0.5999999, and that's when it would pick up a round. Meanwhile, lag that causes the slide to move all the way from 1.0 to 0.0 in a single frame would still trigger that.
Yeah good point, I miss some obvious things when I stare at one chunk of code for a while. If it sets the old position then changes new there's no possibility for the old amount to be less than the feed position unless you release it before. Anyways, good job with this! The round just floating there didn't make much sense before.

User avatar
UNHchabo
Posts: 21
Joined: Mon Sep 23, 2013 4:20 am

Re: The "Floating shell" bug

Post by UNHchabo » Thu Nov 28, 2013 10:45 pm

I checked in my changes and issued a pull request to the main branch. Thanks for your help!

https://github.com/David20321/7DFPS/pull/11

User avatar
Josh707
Posts: 123
Joined: Sun Jan 22, 2012 3:09 pm
Location: Canada

Re: The "Floating shell" bug

Post by Josh707 » Fri Nov 29, 2013 12:51 am

Shweet! I've never used Github but it's pretty cool, I see you changed some of the help menu logic for it too. I didn't think I really helped but no problem!

User avatar
UNHchabo
Posts: 21
Joined: Mon Sep 23, 2013 4:20 am

Re: The "Floating shell" bug

Post by UNHchabo » Fri Nov 29, 2013 5:22 am

You pointed out that it was decreasing the slide position even with the slide lock in place. That helped immensely! :)

User avatar
Josh707
Posts: 123
Joined: Sun Jan 22, 2012 3:09 pm
Location: Canada

Re: The "Floating shell" bug

Post by Josh707 » Sat Nov 30, 2013 1:14 am

Oh yeah I suppose you're right, hehe

Post Reply