View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001198 | FSSCP | multiplayer | public | 2007-01-06 04:27 | 2008-10-23 04:48 |
| Reporter | FUBAR-BDHR | Assigned To | taylor | ||
| Priority | high | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 3.6.9 | ||||
| Fixed in Version | 3.6.10 | ||||
| Summary | 0001198: Player ship speed resets to 0 at respawn | ||||
| Description | Well that is pretty much the problem. Everytime you respawn your speed goes to 0. 3.6.9 final. Not attaching any file on this one because it always happens no matter what mission. | ||||
| Tags | No tags attached. | ||||
|
|
This occurs even using Z axis on joystick for speed. Left set a full throttle the ship still stays at 0 until you manually change speed. |
|
|
Was it like this on retail? |
|
|
Yes and no. It was kind of like the primary bug. Sometime it would revert to default sometime it would stay where it was set. I don't know if it went to 0 in retail though. It might have reset to the initial velocity set in the mission. Been years since I played retail multi so the memory is kind of fuzzy. Just looked through some of the mission files. I do remember the speed going to 0 in TvT missions. Looked at a couple and they don't have an initial velocity for the ships. The other coop missions had initial velocity set at various speeds. |
|
|
Just noticed that there are 2 sides to this bug. Having a player ship with default speed of 0 is ignored. Steps taken: Alpha 1 initial velocity is set to 0. At start of game speed will go to about half throttle. Jumping and replaying mission results in same half throttle. Setting throttle manually and then respawning results in 0 speed. Replaying mission results in 0 speed at beginning of mission until FS2 exited. |
|
|
See if it's any better with this build: http://icculus.org/~taylor/fso/testing/20080403_trunk-win32.rar I doubt it's totally fixed, but see what it does differently for you and let me know what's still broken regarding this bug. |
|
|
Should be fixed in the Xt tree, but that isn't confirmed yet. One of the other devs will need to go through the Xt code and figure out of the fix is valid or not and then commit it. |
|
|
Get me a patch and I'll try it out. |
|
|
We need someone to go through the Xt code diff and pull out fixes like this soon. |
|
|
I looked through the diff, in order to point out the actual line numbers for the fix, but I don't even see it in there. Of course, I can not for the life of me remember what I changed to fix it, which makes it a bit more difficult to track down. |
|
|
Ok, I now remember what I did, and why I removed it ... I had three possible fixes for this bug and couldn't decide how best to fix it. The first fix was to set the players speed at respawn to the initial speed from mission parse. This change works for both player and AI ships. This sets it to the initial speed specified in the mission only, it doesn't restore the last velocity in use. The second fix was to backup the forward velocity though obj_delete() so that it could be restored during respawn. This is also pretty simple, though it requires a slight struct change, but it only works for the player. The third fix was to backup the forward cruise value from the control structure, which gets zero'd out, so we can restore the throttle settings at respawn. Controls as a whole would get reset, since they need to be to prevent various nastiness, but the throttle setting itself would be restored. The third fix was the one I included in the build I linked to in April. Also, only the first and third fixes can affect all players, rather that just "you". So, this can be fixed quite easily, we just need to decide on the best method to do it. |
|
|
I like the first actually, if the mission designer wants you to initially spawn at a certain speed, it can't hurt to spawn at that velocity every time. At least I don't see how it could. Otherwise we're taking away a bit of the designer's power. Although many missions probably don't take that into consideration, I still think we should give that power to the ones that do. |
|
|
The problem isn't so much the speed the spawn occurs at so much as the fact that it ignores any throttle/match settings you may have set until something changes. Most mission designers don't change the default settings so the result would be going from a system where you respawn at 0 and that doesn't change to one where you respawn at 33m/s and that doesn't change. It's an improvement but I don't think it totally fixes the bug. |
|
|
The reason karajorma gave is the same reason I opted not to go with the initial velocity version of the change the first time. I would ultimately prefer going with initial velocity, but to truth is that having your throttle settings completely ignored on respawn is counter-intuitive for the player. With a basic keyboard/mouse setup it isn't that big of a deal, but when you've got a joystick with an actual throttle setting, having that ignored doesn't make much sense. I pretty much keep going back to the throttle reset as the proper fix, but I can see positives and negatives in all three options. |
|
|
True but I think that's a bug in the mission and not in the code at that point. Are coders supposed to infer what a mission designer intended or leave that control up to them? If it worked we might see more designers using that option anyway. I'm not convinced the initial velocity even works in single player missions, it seems like ships are always going at whatever velocity they damn well please instead of what I've said to in FRED. Of course I'm a complete FRED noob so it's very possible I am Doing It Wrong. Regardless, I think the initial velocity in the mission should always be respected. |
|
|
It just came to me, perhaps we could expand on this with a new option. Something like Respawn Velocity in FRED, which can be set to static or the same as when they died, allowing us to make use of Taylor's third option. However, since it sounds like this mostly relates to the throttle on joysticks, perhaps we're looking at this wrong. We shouldn't be ignoring the spawn velocity, but instead polling the joystick after respawn instead of waiting for a change, and then accelerating to the new speed. This would only matter when you have a controller active that has the Absolute Throttle bound to it. |
|
|
I use a joystick but control throttle with my keyboard. Am I going to get messed up by this? Personally, I would go with the initial velocity option, although I realize this wouldn't help the joystick people. How many people actually use the joystick throttle anyway? |
|
|
Respecting the initial velocity on the first start of the level is one thing, but on respawn it's something different. On respawn the developer is no longer in control of the situation, it's now entirely on the user and the situation that the user was in when they died. The developers intentions for the start of the level are no longer in effect at that point since all objects now have different positions, orientations, and speeds. Having an extra respawn velocity option still does nothing to address that. As far as polling the throttle control goes, that doesn't really address the problem. It means a lot of extra coding and checks to handle a very specific situation while completely ignoring all others. Should we just ignore the throttle settings of keyboard users simply because they don't have a throttle control? What if we add mouse wheel support and the user binds the wheel to throttle changes, we can't reliably poll that, so do we just ignore it as a valid option? If we go that route we'll just be right back here again with a new bug report of inconsistent controls or even with this exact same issue being reported again because they can't test it properly since the fix wasn't uniform in the first place. |
|
|
I use joystick but mainly do throttle by keyboard. Actually I mainly turn full throttle on and leave it. If I want to slow down I use thrusters and leave the throttle set. Even with the joystick throttle bound it ignores it unless you move it. Would it be possible to carry over say either the throttle if it is bound or the last primary throttle setting? Basically whatever one of the 4 settings it was set to (off 1/3 2/3 full). Thrusters, burners, matching, etc wouldn't carry over. |
|
|
Is there any reason why we can't just write the forward speed into the parse_object on ship death and then just read it out again on respawn? Or is that basically what you're talking about for option 2? Cause I'm not certain why that would only work for the player. |
|
|
"Would it be possible to carry over say either the throttle if it is bound or the last primary throttle setting? Basically whatever one of the 4 settings it was set to (off 1/3 2/3 full). Thrusters, burners, matching, etc wouldn't carry over." What would be carried over in the third option is the throttle setting. This is just a % value from 0-100. This is the setting that is modified when using the off-1/3-2/3-full setting as well as the -/+ increments and the throttle setting from joystick or whatever. So what gets used isn't the actual throttle position so to speak, but the percentage of how fast you want to go, be it 0% or 50% or 100% (or anything in-between). "Is there any reason why we can't just write the forward speed into the parse_object on ship death and then just read it out again on respawn? Or is that basically what you're talking about for option 2?" That is basically just what I was going with for option two. The reason to do it that doesn't really make sense unless you also carry over slide accelerate as well, since option three covers forward velocity in a much simpler way. And I said that it affects the player only in the sense that option three is contained entirely in Net_players[], whereas option two is just client side and you have to sync it again which can cause a slight visual stuttering during play for others. Like I said though, I ultimately prefer the first option, except as an overall fix in which option three is probably better. The first option would be better with completely fredable respawn points, where the designer is sure that action will not be taking place, and then you could set a per-respawn-point initial speed. As a blanket option I don't think that it works though, and respecting the players throttle setting seems to make more sense. |
|
|
I may not understood fully how respawn works then. I don't pay enough attention I guess. I figured you respawned in the same place with the same orientation as you did when the mission started, but I guess it may just calculate a new orientation for you. I still think that if you have a joystick, and the absolute throttle control is bound to a valid control, that should be polled. It's easy enough to clear if you don't want it, and it's not even set by default so you would have had to set it that way at some point anyway. That's actually one of the most frustrating things for me is forgetting to map that every time I make a new pilot. But as it's not bound by default, I see nothing wrong with polling it. What if I wanted to reset my throttle between dieing and respawning? It would then ignore that instead. If the absolute throttle isn't bound to something, then I'm seeing that it makes sense to use the previous speed. I just think the throttle should be checked after respawn if it's mapped to a valid control. It won't affect anyone who never bothered to map it. |
|
|
Also, throttle is an inherent property of the ship, but velocity isn't. I could be moving at 30 m/s when I died but have just slammed the throttle full. With FS physics, it would spawn me at the full velocity of the ship. But what about mods that try to simulate full newtonian, with no real max velocity? I think setting the throttle and setting the initial velocity are two separate things, and each needs to be considered as such. |
|
|
That's why going with the throttle method in option three works better than the fix in option two. The throttle setting doesn't represent how fast you are going, but how fast you want to go. So when you respawn you would simply accelerate normally to the throttle setting (which is simply a percentage of your max velocity). In that respect it is the same as the initial velocity setting, since in both cases it will accelerate to that speed, rather than just be an instant-on sort of thing. The question is merely whether the player can get to decide to go half-throttle on respawn, or be forced to go full-throttle by the mission designer. I mean, what if the designer wants 0-throttle on respawn, then the player ends up sitting there for a few seconds before realizing that he needs to actually go somewhere and probably takes some damage because of it. It's just situation specific, and nobody can really say which is best except the person who is actually in that situation. |
|
|
It's up to the player to determine where he wants his throttle when he spawns. It's up to us or the mission to decide a sane starting velocity. The starting velocity in the mission works because it should always be sane. The player's death velocity is untrustworthy I think. There are too many scenarios when you don't want to use that value I would imagine, such as newtonian-style phsyics for example. Three does sound like the better option for getting a proper throttle value, but I still think it would be even better if it were instead polled initially since they may adjust their throttle before respawning. If there's enough reason against that, then three sounds like the best alternative, and it should be used if there is no valid absolute throttle axis to poll. The initial velocity is still undecided in that case, which is why I think the mission default should be used, even if things are changing, it seems like a good place to get a sane value. Even starting at 0 and immediately being accelerated by the previously determined throttle setting would be better. I just don't think initial velocity should have anything to do with your previous state. |
|
|
I think we need a little of both. We need to consider a fix for all existing missions. Say the third option for them. Anything newly written would have the option for special types of respawns. Say simulated hanger launches where you may want 0 or something even greater then the max speed of the ship (say full afterburner). This is more of a feature then a fix though. A whole way to control the respawn points, direction, speed, etc would be a great feature to have in future builds. So basically third option until further features are implemented. The third option would still be the default unless overridden by a feature. |
|
|
It looks like I may have been misunderstood -- I'm in favor of using the first option, using the initial velocity as specified in the mission file. Not only is it the simplest fix, it has the least negative impact on the player's expectations. When you respawn, you appear at the mission start point. Players are used to dealing with this, especially during escort missions when you inconveniently respawn 10km away from the convoy. So, having players deal with the mission's preset initial velocity wouldn't be a large step. |
|
|
The third option still only takes into account the initial throttle, not the initial velocity. So we either leave that at 0, or the mission initial velocity setting. However, I don't think polling the throttle breaks anything either, although that could also be construed as not exactly fixing this bug, but I still consider not accepting throttle changes while dead in that case a bug of its own. |
|
|
You don't always spawn at the same point. The game moves you from spawn to spawn and occasionally to who knows where for no apparent reason. Coops aren't bad at it but you get in a dogfight and you could be spawning at any number of places. If your sitting still you can be a dead duck. Same thing in TvT. Initial velocity of 0 is good in those types of missions on the initial spawn. After that though it can become a liability. Even in coops if you have a swarm of enemy fighters around the spawn area you can be dead by the time you get from clicking on respawn until you throttle up. Normal way around that is to just hit the afterburner and maneuver but then when your burner is out your back to 0 velocity. |
|
|
All I'm saying is that the third option doesn't change that, we need to pick a sane initial velocity from somewhere. Even existing missions (non-FS ones at least) could break (even worse) if we try to correlate throttle position to a particular velocity. So, the problem of finding a sane velocity still exists. I agree that leaving it at 0 is probably bad, and that using the initial mission velocity seems like the most stable alternative. |
|
|
I hope my approach to the conversation on this bug hasn't upset anyone, I've been trying to discuss it since I felt that's what was requested, and I have fairly strong opinions on it and some other multiplayer issues. I appreciate any means taken to resolve it and understand that certain requests I've made could be prohibitively difficult to accomplish, I've merely tried to outline the optimal solution gamewise, and it's up to someone else to tell me if it's actually feasible or not. I just hope I wasn't the reason discussion on this bug died (seemingly) before a verdict was reached. |
|
|
I don't really care how it's fixed, I just wanted the final opinion to be a properly informed one. :) Anyway, I've already got the code in there to use the mission initial velocity. If we need to change it later then we can. I'm just going to wait on feedback from the next multi_test build before I commit (since I fixed another bug in the same respawn function). |
|
|
That's what I was going for too. So that's in addition to the code that you said was already in there to restore the throttle position to its previous state? |
|
|
Using initial velocity or the throttle position do the same thing, it's only what velocity you end up at that's different, so there really isn't a point in using both. I just removed the throttle position fix and used the initial velocity one instead. |
|
|
Well I thought this one was going well until I looked up the initial velocity for the fighter I was flying. Played STV gauntlet and Alpha 1 is set to 33 for initial velocity. I was starting off somewhere between 15 and 20. I did change the default ship from a Ulysses to an Erinyes if that matters. |
|
|
The initial velocity specified in the mission is figured as a percentage of the ships max speed. So it would be 33%-of-max-speed rather than 33m/s. It's the same with initial hull/shields/etc., it's all just a percentage rather than a fixed value. Initial velocity is nothing more than initial throttle really. |
|
|
That makes sense then. Still needs more testing. I keep hitting / out of habit before I look and there is still the client side. |
|
|
I wasn't aware of it being a percent. That changes how I was thinking of it slightly. I still hope for throttle polling though someday, but I'll probably just file that as a feature request. |
|
|
Fixered. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2007-01-06 04:27 | FUBAR-BDHR | New Issue | |
| 2007-01-06 04:27 | FUBAR-BDHR | Status | new => assigned |
| 2007-01-06 04:27 | FUBAR-BDHR | Assigned To | => taylor |
| 2007-01-13 07:31 | FUBAR-BDHR | Note Added: 0007455 | |
| 2007-01-14 19:01 | Goober5000 | Note Added: 0007458 | |
| 2007-01-14 20:17 | FUBAR-BDHR | Note Added: 0007459 | |
| 2007-01-14 20:23 | FUBAR-BDHR | Note Edited: 0007459 | |
| 2007-02-12 12:43 | FUBAR-BDHR | Note Added: 0007624 | |
| 2008-04-03 10:01 | taylor | Note Added: 0009163 | |
| 2008-07-17 16:35 | taylor | Note Added: 0009470 | |
| 2008-07-17 16:35 | taylor | Assigned To | taylor => |
| 2008-07-17 16:35 | taylor | Status | assigned => new |
| 2008-08-06 20:10 | karajorma | Note Added: 0009538 | |
| 2008-08-06 20:10 | karajorma | Status | new => assigned |
| 2008-08-06 20:10 | karajorma | Assigned To | => karajorma |
| 2008-10-09 16:36 | chief1983 | Note Added: 0009894 | |
| 2008-10-09 16:36 | chief1983 | Priority | normal => high |
| 2008-10-09 21:34 | taylor | Note Added: 0009921 | |
| 2008-10-16 14:52 | taylor | Note Added: 0010002 | |
| 2008-10-16 15:55 | taylor | Assigned To | karajorma => taylor |
| 2008-10-16 16:00 | chief1983 | Note Added: 0010003 | |
| 2008-10-16 16:15 | karajorma | Note Added: 0010004 | |
| 2008-10-16 16:37 | taylor | Note Added: 0010005 | |
| 2008-10-16 16:40 | chief1983 | Note Added: 0010006 | |
| 2008-10-16 16:44 | chief1983 | Note Added: 0010007 | |
| 2008-10-16 16:45 | chief1983 | Note Edited: 0010007 | |
| 2008-10-16 17:34 | Goober5000 | Note Added: 0010009 | |
| 2008-10-16 17:42 | taylor | Note Added: 0010010 | |
| 2008-10-16 18:09 | FUBAR-BDHR | Note Added: 0010012 | |
| 2008-10-16 18:15 | karajorma | Note Added: 0010014 | |
| 2008-10-16 18:49 | taylor | Note Added: 0010015 | |
| 2008-10-16 18:52 | chief1983 | Note Added: 0010016 | |
| 2008-10-16 18:57 | chief1983 | Note Added: 0010017 | |
| 2008-10-16 19:22 | taylor | Note Added: 0010019 | |
| 2008-10-16 19:44 | chief1983 | Note Added: 0010020 | |
| 2008-10-16 20:41 | FUBAR-BDHR | Note Added: 0010021 | |
| 2008-10-16 20:46 | Goober5000 | Note Added: 0010022 | |
| 2008-10-16 20:51 | chief1983 | Note Added: 0010024 | |
| 2008-10-16 21:01 | FUBAR-BDHR | Note Added: 0010026 | |
| 2008-10-16 21:18 | chief1983 | Note Added: 0010027 | |
| 2008-10-17 19:21 | chief1983 | Note Added: 0010031 | |
| 2008-10-17 20:21 | taylor | Note Added: 0010032 | |
| 2008-10-18 00:14 | chief1983 | Note Added: 0010033 | |
| 2008-10-18 00:29 | taylor | Note Added: 0010034 | |
| 2008-10-20 06:13 | FUBAR-BDHR | Note Added: 0010059 | |
| 2008-10-20 06:28 | taylor | Note Added: 0010060 | |
| 2008-10-20 06:34 | FUBAR-BDHR | Note Added: 0010061 | |
| 2008-10-20 06:51 | chief1983 | Note Added: 0010064 | |
| 2008-10-23 04:48 | taylor | Status | assigned => resolved |
| 2008-10-23 04:48 | taylor | Fixed in Version | => 3.6.10 |
| 2008-10-23 04:48 | taylor | Resolution | open => fixed |
| 2008-10-23 04:48 | taylor | Note Added: 0010101 |
