What red letters would those be?
Look at the video, listen to the commentary. “It is possible to die before you’ve even ejected and are in control of your character”.
Unless this has been changed since this video came out, OP has no leg to stand on.
The ones in Korean that show up the moment her mech reaches 1 HP. And then they flash once or twice. To the outside observer, that’s the part where her mech undergoes death animation. That’s the part where she has i-frames. 9:19 or 9:20 in video.
Look at the video, look at the commentary. “It is possible to die before you’ve even ejected and are in control of your character”.
Oh, yes, it’s definitely possible to die before she actually gains control. But she still has a window in which she is invulnerable before her eject even begins. The moment her model actually appears is when she becomes vulnerable. But there’s a delay of 1 second or 0.75 seconds from the moment her mech reaches 1 HP to the time when baby D.Va is actually vulnerable.
Yes, she has a handful of frames of invulnerability while the mech dies in which you can either eject, or eject and do self-destruct if you have it.
However, Pilot D.va is completely vulnerable from the very frame she ejects from the mech, so OP’s point is invalid.
Baby D.va shouldn’t start taking damage on the same frame that her mech is destroyed. not only would that look completely stupid, it would be unfair as well.
Yes, she has a handful of frames of invulnerability while the mech dies in which you can either eject, or eject and do self-destruct if you have it.
However, Pilot D.va is completely vulnerable from the very frame she ejects from the mech, so OP’s point is invalid.
Yeah, ok. I wasn’t sure if you were responding to him or to us who were discussing the existence of those frames in the first place.
Baby D.va shouldn’t start taking damage on the same frame that her mech is destroyed. not only would that look completely stupid, it would be unfair as well.
I simply think she should start to propel out of mech the moment it gets to 1 HP. Not after a delay. She still contests the point during those iframes and you can’t do anything to stop her from doing so.
So? That’s not something that you can abuse or tactically use to your advantage. it’s basically a grace window for the D.va player, in which they’re given a second in which to think:
“OK, my mech has been destroyed and I am about to be in control of a very squishy and vulnerable character instead of a sturdy tank. I should run for cover immediately!”.
To have her immediately controllable and vulnerable the second her mech is destroyed is unfair and ridiculous.
She becomes immediately controllable and vulnerable when she pops self-destruct. There isn’t a delay. She immediately starts ejecting.
And it may seem like little, but that’s basically 10 seconds in a long 2CP game of free stall in addition to her already formidable stalling capabilities.
The true reason why it’s there is to give D.Va player a moment to initiate self-destruct to get a new mech if she wishes to. But even that seems too lenient.
There is a delay, but you don’t see it the way you’re thinking. There are 2 portions to this: the actual code/logic and the model. The code must be attached to the model for it to work properly and the code must be assigned to that model. The code cannot just jump between assigned models, so what’s happening with D.va is when the Meka is killed, its a complete model swap to the pilot with pilot logic while the meka and its logic are taken out of the game.
The model and the logic are two different things, but both are required to make the game work.
You see, for the computer - everything happens instantly… Or near instantly as in milliseconds, but in order. Command 1, Command 2, Command 3… It could be one command, it could be thousands (in this case it would be thousands). These are executed one after another, but so rapidly it may as well be instant. The effect is that yes, you take control of the pilot instantly.
However, that’s just the coding… Which is attached to the model. The coding is the instructions that interprets how the model is supposed to move and what it does. For a model to be rendered in 3D, thousands of geographic vector calculations are taking place to compute the XYZ coordinates of the geometry. There is no telling - at least for PC users, what CPU I’m using, how much RAM I have, and which graphic card I’m using as well as the speed of my internet connection. All of these things are accounted for in system requirements. The point I’m trying to make is that older hardware will experience a delay.
At the extreme end of things, my friend has such an old computer that when you shoot a rocket with Pharah, the missile will not render, so it’s invisible… At least until it reaches the target and there’s an explosion. A pharah rocket is a very low poly item. Imagine the delay when rendering a high poly character if it was done instantly. The result is that in competitive matches, you would have an invisible D.Va popping out of the meka, and you wouldn’t be able to tell where she’s going or where she’s landing until it’s too late.
Disagree. Windmill doesn’t have nearly as many poloygons to draw as a character. The windmill has exactly one function - and that’s to perform a single low cost animation (the sail spinning). The logic of a playable character is to interpret the players commands into the game, as well as everything else that goes with it like hitboxes and health meters.
The logic between a static environmental object and a playable character aren’t even remotely on the same level.
Again, not talking about RAM. At least not specifically. You know, cache, HDD speed, etc… These all help, but we’re talking two different things. I feel that when I said “optimization” you thought I was talking about RAM. But I’m not. We’ve accounted for those in system specs. Even so, about the only thing I want you to understand is that a new model is not rendered instantly. It takes time. Milliseconds, but time all the same. What I’m talking about is how games render in only what needs to be seen to reduce the amount of resources required… Because having everyone render a metric ton of unnecessary crap will hurt the performance of the game and make everyone mad. Good example is Crysis 2… Who decided to have a giant, tessellated ocean under the map. Tanked the game’s performance. You look as far back as the NES and a game like Mario 3 where you had a blank row on the left side of the screen or the Megaman games where there was a garbled mess on the right side of the screen. These are render seams done to optimize the game. You may not feel that it’s important, but this is done everywhere, in every game, where you don’t see it and where you wouldn’t expect it. Most games are only rendering on screen what the player can see for this very reason. Anything beyond what you can see has typically been culled (see: culling).
sigh
Okay, the jist of it is like this. So far, you now know that having 2 playable characters for 1 player coexist at the same time is not possible. So, to have the pilot sit inside of the meka would be wasteful because she wouldn’t have any logic assigned to her. It also cannot be that the logic migrates to that instance of the model once the meka is killed. You’d just have to swap out a pilot without logic for one that does have logic… And that would still mean derendering and then rendering a new model.
1 Like
I really don’t have the energy to write a lengthy response so I’m just going to write it shortly.
Yes I know that the actual swapping takes some time, but it is a matter of miliseconds in terms of actual execution unless there is an intentional delay coded.
My point was that the 1 second prior to even starting the eject when death demeching is not there for technical reasons. Because if it were, same thing would be present for self-destruct eject. And it isn’t. She begins the eject the moment Q is pressed. You can easily see for yourself in training ground. The real reason why 1 second of invuln is there is to give D.Va player time to press Q if she wants to self destruct to get a new mech after her old mech just reached 1 HP. That’s why you have the delay there and not when pressing Q while self-destructing. It’s not because of actual time necessary to swap models. Because it would be present in both cases if that was the case. And simply, just for a moment, consider how absurd it is that in 21st century you need to add a significant delay so that you can load and swap the model. It would be extremely bad programming. Doesn’t matter that there’s thousands of geographic vector calculations bla bla bla. Modern GPUs and CPUs do faaaar more than that. The game is not optimized for older hardware anyways. And even then, acceptable performance can be achieved simply by changing resolution, render scale, etc.
Disagree. Windmill doesn’t have nearly as many poloygons to draw as a character. The windmill has exactly one function - and that’s to perform a single low cost animation (the sail spinning). The logic of a playable character is to interpret the players commands into the game, as well as everything else that goes with it like hitboxes and health meters.
It is absolutely not a factor. And I disagree about windmill having less polygons overall. Simply because of its size compared to a typical character model. Logic of a playable character is completely irrelevant to loading the model. Absolutely a non-factor.
And as for the last paragraph, I very much understood what you meant by optimization. But textures and models still have to be loaded up from disk into memory when the game is starting. And yes, it takes some miliseconds to actually display something. But not 1 second for a single model. That is absolutely not the reason for it. Yes, I know that games are rendering on screen what player can see. Some flags in spawns in OW will move only when player is looking at them. But that isn’t relevant to this. It won’t take 1 second to display a single character model. It won’t even take 0.1 second on a typical PC. It will take far less. Especially when the model is likely preloaded already and queued for displaying which will happen in next refresh.
Okay, the jist of it is like this. So far, you now know that having 2 playable characters for 1 player coexist at the same time is not possible. So, to have the pilot sit inside of the meka would be wasteful because she wouldn’t have any logic assigned to her. It also cannot be that the logic migrates to that instance of the model once the meka is killed. You’d just have to swap out a pilot without logic for one that does have logic… And that would still mean derendering and then rendering a new model.
Nonsense. You can literally have her model appear in some offset to dying MEKA and then simply inside one loop of execution mark it as active while simulatenously deactivating MEKA. The D.Va that’s visible from the front part side of meka likely isn’t even D.Va which gets ejected. But my point is, it will never take an appreciable amount of time to actually make the swap. It’s very much possible to get her to leave the MEKA almost instantly as evidented by comparing the self-des and mech death in terms of it.
Anyhow, I’m done with this thread. I’ve said enough. Not sure why I even dragged myself into this discussion.
You literally can hit dva before she regains control of her character and nuke her with splash abilities and things like rein hammer, so she ejects from the mech with low hp. She gets no invulnerabilities from ejecting.
1 Like
But she doesn’t start to eject immediately. There’s ~1 or 0.75 seconds where she will sit inside the meka after it reached 1 HP before the eject actually starts happening. You can’t touch her during that period. That’s the window of opportunity for her to press Q to start self-destruct if she wants a new mech. You can’t touch her during that interval. But she still contests the point.
So you basically want to remove the self-destruct mechanic so dva will not have a chance to use self-destruct when they see their mech being destroyed.
Whining after less than 1 second mechanics that it takes for char to die while they cannot do anything but get splash damaged to death is so inane but exactly what I would expect from anti-dva brigade on these forums.
Removing the time it takes to eject would make it impossible to self-destruct. You gotta figure out some other reason to break dva.
There are plenty ways to contest point and being ejected from mech is not one of them lol. Being ejected means dva is going to die lol.
1 Like
Honestly Twix I wouldn’t be surprised if no one takes you seriously anymore. If you spent more time in the game and getting better rather then complaining in 1000 posts about why you’re a perfect replacement for Mr Grumpy then I’d say you wouldn’t have such a problem with D.Va.
2 Likes
It would be really funny if the mech’s ejection system malfunctioned while being hacked, so all that popped out was a burning corpse.
So am I correct in my summary: the problem op has is that babydva spends a second or so in her Meka after it breaks whereby she doesn’t take damage?
Yes but the difference is that is initiated by the D.va player, so they will already be prepared to be put in control of a far squishier character. That’s not the case when the mech is destroyed by enemy fire.
This is such a non-issue tho
Dva is well balanced mate what you whining about ant hit a target with no abilities while she can’t hurt you longer go cry mate dva sits perfect with how her kit is not our problem youre aim is below zero yup can hit her whole she ejects guess what she can’t even shoot or see you while you can reload and point you’re Crossair at her if you are smart you know she needs the extra 150 life chance cause many tanks have abilities that give them extra health/protection rein 1600 shield hog 600 go plus big healing and lots of damage sigma has orb that gives extra shield and shield etc etc go cry if you can’t hit a target who can’t shoto for a moment and has no abilities mate
4 years later, dude.
1 Like