Forums » Bugs
Docking during the jump-in animation gums up the game client.
If you're unfortunate enough to jump in to a sector and float into a capship docking bay, there's a chance your game client will get stuck with the HUD looking at the capship from outside, but without the in-ship interface to be able to undock.
Steps to reproduce:
1. Put a Trident in a sector somewhere.
2. /set autodock on
3. Jump in at just the right place so your ship floats into the docking bay right in the middle of the jump-in animation.
At first it seems like there's nothing you can do but log off and back on, but if you open the console and type: "/lua RequestLaunch()" you'll undock from the Trident and everything goes back to normal.
This is one hell of a corner case, but it's worth posting here in case somebody gets stuck and freaks out.
Steps to reproduce:
1. Put a Trident in a sector somewhere.
2. /set autodock on
3. Jump in at just the right place so your ship floats into the docking bay right in the middle of the jump-in animation.
At first it seems like there's nothing you can do but log off and back on, but if you open the console and type: "/lua RequestLaunch()" you'll undock from the Trident and everything goes back to normal.
This is one hell of a corner case, but it's worth posting here in case somebody gets stuck and freaks out.
Yeah, thats the same thing. Didn't know anyone else had run into this one.
At least i found a way out of it. Logging off and back on sucks when you're in a group and you've laid a bunch of mines.
At least i found a way out of it. Logging off and back on sucks when you're in a group and you've laid a bunch of mines.
Ah yeah, that has been reported before. Since it happens so infrequently, it's not on the top of our list to fix, but I'll see if there's some quick fix for it. It sounds like it's an issue with the player's current state not being able to deal with the state change of being docked.
Maybe instead of such a long jump in animation, immediately drop into normal game state but give a delay equal to current animation time before battery starts charging from 0.
Then you don't get the purdy jump graphics. Spuck's suggestion for a fix actually seems like a better way to deal with it:
Yeah.. I guess a workaround would be to throw together a plugin that turns off autodocking during jump.
Yeah.. I guess a workaround would be to throw together a plugin that turns off autodocking during jump.
That's not a fix, and the problem is real enough that a plugin is the wrong way to deal with the issue. It should be coded into the game, rather than an optional user contributed addon, and it only deals with one symptom of the actual problem, not the problem itself.
The problem isn't just that the jump animation screws up the client when it docks while still active, although that's a pretty ugly problem. It's that jumping into a system and the subsequent animation yields a lot of bad behavior that the player sees first hand and is far more harmful to the game than the benefit of seeing the wormhole animation a second time. Things like passing through asteroids or ships happen too often while the jump animation is progressing.
The reason for the length of the animation isn't a result of wanting to make people look at some animation, it was just the most convenient way to slow down people from jumping in and out of systems.
A better solution to slowing people down is to give the battery a cool down period before recharging from 0%. You can stop, turn your ship and thrust around... but similar to the current behavior, you can't turbo, jump, target, or shoot (weapons that require energy anyway). This solves both the case of the animation driving you through objects but also state issues since you would be in a proper state already when docking and it gives you a chance to avoid blowing directly into objects as soon as animation is complete.
The problem isn't just that the jump animation screws up the client when it docks while still active, although that's a pretty ugly problem. It's that jumping into a system and the subsequent animation yields a lot of bad behavior that the player sees first hand and is far more harmful to the game than the benefit of seeing the wormhole animation a second time. Things like passing through asteroids or ships happen too often while the jump animation is progressing.
The reason for the length of the animation isn't a result of wanting to make people look at some animation, it was just the most convenient way to slow down people from jumping in and out of systems.
A better solution to slowing people down is to give the battery a cool down period before recharging from 0%. You can stop, turn your ship and thrust around... but similar to the current behavior, you can't turbo, jump, target, or shoot (weapons that require energy anyway). This solves both the case of the animation driving you through objects but also state issues since you would be in a proper state already when docking and it gives you a chance to avoid blowing directly into objects as soon as animation is complete.
I don't think you understand what a "workaround" is.
the original person who mentioned it called it a workaround. arf called it a fix which is what i responded to.
Workarounds are fine for minor annoyances that are either intended to be fixed real soon, or too specific to a person's particular environment to warrant a fix if one was even possible. The problem that caused the behavior originally described in the thread is not particular to any isolated situation and is in fact a behavior that causes issues fairly regularly, though only rarely with this particular state bug.
I understand just fine what a workaround is and used for, and I don't think the one described is a fix for this problem nor would i even consider it an acceptable way to deal with the bug caused by the state change because that is a game bug, not a player environment issue and it only addresses a problem a very tiny portion of the player base experiences that is caused by the extended animation sequence rather than dealing with the more visible and common problems.
Workarounds are fine for minor annoyances that are either intended to be fixed real soon, or too specific to a person's particular environment to warrant a fix if one was even possible. The problem that caused the behavior originally described in the thread is not particular to any isolated situation and is in fact a behavior that causes issues fairly regularly, though only rarely with this particular state bug.
I understand just fine what a workaround is and used for, and I don't think the one described is a fix for this problem nor would i even consider it an acceptable way to deal with the bug caused by the state change because that is a game bug, not a player environment issue and it only addresses a problem a very tiny portion of the player base experiences that is caused by the extended animation sequence rather than dealing with the more visible and common problems.
"That's not a fix, and the problem is real enough that a plugin is the wrong way to deal with the issue. It should be coded into the game, rather than an optional user contributed addon"
He didn't mean it should be fixed with a plugin. He meant the devs should just make the game do what the suggested plugin would have done. I do agree with you regarding fixing it rather than working around it, though. I don't agree with your proposed fix.
"The reason for the length of the animation isn't a result of wanting to make people look at some animation, it was just the most convenient way to slow down people from jumping in and out of systems."
Says who?
He didn't mean it should be fixed with a plugin. He meant the devs should just make the game do what the suggested plugin would have done. I do agree with you regarding fixing it rather than working around it, though. I don't agree with your proposed fix.
"The reason for the length of the animation isn't a result of wanting to make people look at some animation, it was just the most convenient way to slow down people from jumping in and out of systems."
Says who?
Says who?
Incarnate in response to a post requesting a solution to sector hopping practically instantly in regards to evading battles etc.
http://www.vendetta-online.com/x/msgboard/3/11201#131657
Incarnate in response to a post requesting a solution to sector hopping practically instantly in regards to evading battles etc.
http://www.vendetta-online.com/x/msgboard/3/11201#131657
The problem isn't just that the jump animation screws up the client when it docks while still active, although that's a pretty ugly problem. It's that jumping into a system and the subsequent animation yields a lot of bad behavior that the player sees first hand and is far more harmful to the game than the benefit of seeing the wormhole animation a second time. Things like passing through asteroids or ships happen too often while the jump animation is progressing.
Yes, the problem IS just the jumping into your precisly parked trident. Hence this post, and hence all the reasonable commentory addressing it. And it is incredibly rare, and should be low priority.
This supposed plethora of "bad behavior" yielded by the animation is something that only exists in your head... OR you are just trolling us.
So just....stop....
Yes, the problem IS just the jumping into your precisly parked trident. Hence this post, and hence all the reasonable commentory addressing it. And it is incredibly rare, and should be low priority.
This supposed plethora of "bad behavior" yielded by the animation is something that only exists in your head... OR you are just trolling us.
So just....stop....
That's not a fix, and the problem is real enough that a plugin is the wrong way to deal with the issue.
The devs could just make the game not autodock during the jump animation, then it would be fixed.
Whats the problem?
The devs could just make the game not autodock during the jump animation, then it would be fixed.
Whats the problem?
The original reason why the animation lasts as long can be better handled in another way that doesn't lead to any of the above issues, rather than just handle one niche problem caused by it. So i'm not saying turning off autodock wouldn't stop the state bug from being triggered and that the state bug isn't an actual bug on it's own.
I'm saying what caused the state bug to get triggered causes more than just a docking bug and you should kill both birds with one stone by tackling the jump animation scene length itself. Avoidable graphic glitches caused by this happen far more frequently than jumping directly into docking bays.
I'm saying what caused the state bug to get triggered causes more than just a docking bug and you should kill both birds with one stone by tackling the jump animation scene length itself. Avoidable graphic glitches caused by this happen far more frequently than jumping directly into docking bays.
Why not make a separate thread for issues with the jump animation's camera position? It's not the same problem.