Remove black screen fade when taking resurrection

[Raven2014]

Bolded is the important point here - the reason for the black screen in its entirety is to create a seamless transition from one point to another. It's a pretty game industry standard effect to mask extremely jarring movements over long distances, some developers simply have better ways to mask the transition with environmental tricks

Yeah, if you had ever played with some who lagging really bad, when they die their corpse would just rubber banding around the arena, very creepy and ackward. And rescue-res would be the same thing.

However, there is a crucial point that you get wrong about your shukuchi example - shukuchi is not an instantaneous movement, your character slides to the location quickly, on top of the camera follows you during the slide to match your character's movement. This is extremely important, as it creates the exact same seamless transition from one point to another that's pleasing to the eye. With raise being point A -> point B with absolutely zero interpolated locations inbetween, there is no opportunity to create the fluid motion from one location to another.

This is another valid point, outside of actual teleport, the game has no actual physical displacement, everything is just extremely fast movement masked with an illusionary animation. Case in point, you can't use DRG jump hope over a ground AOE (you still gonna get the tick even if you never land on it), nor you can use it to hop over a split platform (you just gonna fall down). Without teleportation, there would be no way for a healer to res someone that's not on the same platform of them if there are a split arena.

[Rongway]

However, there is a crucial point that you get wrong about your shukuchi example - shukuchi is not an instantaneous movement, your character slides to the location quickly, on top of the camera follows you during the slide to match your character's movement. This is extremely important, as it creates the exact same seamless transition from one point to another that's pleasing to the eye. With raise being point A -> point B with absolutely zero interpolated locations inbetween, there is no opportunity to create the fluid motion from one location to another. That's also without factoring in that the theoretical highest distance for shukuchi is only 20yalms, whereas with raise you can get raised 30y away, creating an extremely jarring camera snap from point A to point B.

It's not important. The timing of the pre-move, move, and post-move can be adjusted so that the movement happens smoothly enough without affecting the total raise sequence timing. Of course an instantaneous camera movement from point A to point B that happens in a single frame would be jarring; that's obviously not what we're asking for here. Let's review the relevant portion of the timeline again.

Currently, here's what is involved in just the movement:

1. The character model becomes invisible.
2. The screen fades to black.
3. The character's position is updated.
4. The camera's position is updated. The camera instantaneously moves to the new poisition.
5. The screen fades in.
6. The character model becomes visible.

There is plenty of time between when character model becomes invisible and when it becomes visible again to move the camera smoothly to the new position instead of fading the screen in and out.

Maybe it is the way it is for the same reason you can't accept party invites while engaged with the marketboard. Spaghetti code that's been around probably since 1.0.

We really need to stop blaming everything on "spaghetti code". We're talking about a movement animation. That's all. We're not querying any database tables or making changes to the data structures that could be abused if done in an improper order.

Yeah, if you had ever played with some who lagging really bad, when they die their corpse would just rubber banding around the arena, very creepy and ackward. And rescue-res would be the same thing.

That's a non-issue: the character model is invisible during the movement portion of the raise. For everyone who is not the dead person, it wouldn't look any different than it already does. Removing the fade would affect only the dead person because the dead person is the only one who sees the screen fade anyway.

This is another valid point, outside of actual teleport, the game has no actual physical displacement, everything is just extremely fast movement masked with an illusionary animation. Case in point, you can't use DRG jump hope over a ground AOE (you still gonna get the tick even if you never land on it), nor you can use it to hop over a split platform (you just gonna fall down). Without teleportation, there would be no way for a healer to res someone that's not on the same platform of them if there are a split arena.

Diamond Weapon example clearly contradicts this. Terrain is irrelevant to the problem.

[DPZ2]

We're talking about a movement animation. That's all.

Except that is not all we're talking about. There are at least four separate things being done during this "movement", including health bar adjustments, removing effects, adding effects and the 'rez' animation itself.

Ignoring those other four things is where you continually go wrong.

Diamond Weapon example clearly contradicts this.

Oddly enough, that portal movement does not involve health bar adjustments, removing effects, adding effects and presenting a 'rez' animation. Who'd have thought otherwise?

[Rongway]

Except that is not all we're talking about. There are at least four separate things being done during this "movement", including health bar adjustments, removing effects, adding effects and the 'rez' animation itself.

Ignoring those other four things is where you continually go wrong.

All the other things are irrelevant to the movement portion. They can happen in their own time. We literally are only talking about the movement part of the raise, from the time the character becomes invisible to the time the character becomes visible again. All the other things that happen do not care about that portion of the sequence.

[DPZ2]

All the other things are irrelevant to the movement portion. They can happen in their own time. We literally are only talking about the movement part of the raise, from the time the character becomes invisible to the time the character becomes visible again. All the other things that happen do not care about that portion of the sequence.

Except that they all occur as part of the movement portion. And have done so since A Realm Reborn was released. The movement was coded along with the animation and the character adjustments.

Look, I get it. You don't want to lose face. To the point where you'll change the argument from "this all occurs as part of the Raise" to "they don't need to do this to cover up the movement", which are not the same arguments.

[Rongway]

Except that they all occur as part of the movement portion. And have done so since A Realm Reborn was released. The movement was coded along with the animation and the character adjustments.

Look, I get it. You don't want to lose face. To the point where you'll change the argument from "this all occurs as part of the Raise" to "they don't need to do this to cover up the movement", which are not the same arguments.

No, they don't happen "as part of the movement potion."

Look, I get it, not everyone here has a graduate degree in computer science. Not everyone understands dependency resolution and task ordering using a topological sort of a directed acyclic graph (DAG). These are concepts I usually introduce in a second semester undergrad data structures and algorithms course and discuss in detail in discrete mathematics.

Here is a DAG showing the raise sequence.



Each box is a step in the sequence. Arrows indicate that a ->step cannot happen until after the step-> before it happens. Note that all the buff and HP management really doesn't need to happen in any particular order; the only hard requirement is that they happen after the player accepts the raise and before character control is restored. There may be technical requirements we don't know about regarding the ordering of the buffs and debuffs to prevent strange interactions, but that at worst forces the three buff/debuff steps into a rigid sequence, and that sequence would still not care about the character movement sequence and the camera movement sequence.

If we wanted to linearize the graph, we could do a topological sort. In a topological sort, we arrange all the steps in a single sequence such that all the arrows are pointing from left to right; that is, no step happens unless all the steps that have to happen before it have happened. Here is what appears to be the order that the game uses, based on reviews of raise footage from my raid archives:



Note that this is not the only valid topological sort of this graph. The steps can be rearranged freely as long as all the arrows flow in one direction.

Here is a representation of the thread topic:



Above, the camera subsequence marked in fuschia, gets replaced with the below camera subsequence marked in green.

And here is a topological sort of that change:



As you can see, changing the camera sequence from a fade-snap-fade to a smooth movement does not affect anything and does not care about what's happening elsewhere in the sequence. The character model, moving invisibly and instantaneously, does not care about terrain or the limitations of player character movement. The buffs/debuffs do not care at all what is going on with the camera.

The obstacles you keep insisting exist do not exist.