The "Floating shell" bug
The "Floating shell" bug
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?
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 334 times
Re: The "Floating shell" bug
I logged each value in this part of the script:
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.
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.
Code: Select all
if(slide_amount < kFeedPosition && old_slide_amount >= kFeedPosition){
ChamberRoundFromMag();
}
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.
Re: The "Floating shell" bug
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: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).
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.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.
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;
}
}
Re: The "Floating shell" bug
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: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.
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: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; } }
Code: Select all
Slide: 0.2928888 Old: 0.6261443
Slide: 0.3624157 Old: 0.6506624
Slide: 0.375492 Old: 0.6649231
Re: The "Floating shell" bug
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.Josh707 wrote:Sometimes it seems like it cuts a little close to missing the feed position but it seems to be working properly.
Re: The "Floating shell" bug
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.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.
Re: The "Floating shell" bug
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
https://github.com/David20321/7DFPS/pull/11
Re: The "Floating shell" bug
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!
Re: The "Floating shell" bug
You pointed out that it was decreasing the slide position even with the slide lock in place. That helped immensely!
Re: The "Floating shell" bug
Oh yeah I suppose you're right, hehe