Remove black screen fade when taking resurrection

[Daeriion_Aeradiir]

in any case it is ultimately a matter of (1) setting a new character position, (2) setting the camera position to match, and (3) moving the character and the camera to their new position.

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 (Dark Souls does a whole bunch of these transition trickeries, for example). It's the same reason there's black screens when you go through things like portals in The Chrysalis, Halicarnassus in O3's desert maze, etc. The actual area you're warped to exists right next to the arena field you fight in and could theoretically get moved there without a load screen in 0.5s, but the movement is insanely jarring. Which is the ultimate point here why raise has the fade out - it creates a much more smoother, pleasant on the eye transition.

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.

As far as potentially emulating rescue and causing the body to slide instead of warp? I doubt that's possible - we already know dead bodies can interact with stages elements (like if a diamond weapon platform gets destroyed, the dead body falls off of it and gets respawned elsewhere. I have zero doubts trying to slide the body over instead of warping it would cause the body to interact with field elements like pits/etc and cause a massive delay/issue in the respawning process.

For another example of why the developers do the fadeout - why do you think animation developers bother to animate the frames of the character moving in between one location and another, even when they're moving at high speeds? Or even during instant teleporting like in DBZ, why they always leave & create distortion effects at their start & end locations? Simply having a character start in one location and end in another is extremely uncanny for the vast majority. If you want an in-game example of something that looks extremely uncanny of instant warping, go do Elusive jump off a cliff with an area you can land on below. Your character will instantaneously snap to the bottom of the cliff, but the movement itself looks insanely wrong.

In the couple of gaming projects I've worked on at AAA studios, anytime we had instantaneous teleporting and hadn't put in the fading yet, the game testers would always complain & submit bug tickets regarding it citing that it looked wrong/broken - at the end of the day, it all comes down to the perception of smooth movement or the suspension of disbelief of moving from one spot to another without making it look uncanny.

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