Remove black screen fade when taking resurrection

[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.