![]() It's something that needs to be implemented with care, and which touches on many parts of the code, carrying with itself increased risk and increased testing. Part of code that handles this, is again, not high math, but it's also not a list of permutations and their outcomes, it's a bunch of functions which check a bunch of variables and try to not kill each other in the process of finally deciding on which key does what when. As you may notice, we only have a few buttons on our controllers, but they and their combinations need to do vastly different things depending on which permutation of options you selected, while avoiding conflicts. It's far from impossible, and not even particularly hard on the surface, but it's about the hidden cost of "how many issues could potentially arise once we change the code in so many places at once", and time investment of fixing them or merely thoroughly checking for them.Īnother difficulty is handling the bindings themselves, again, not hard, but not as trivial as it seems. ![]() But some other function which makes sure physics doesn't break down at supersonic speeds, might need to read 3 same as 1. So if player is using 3 (both), for this specific subsystem which is concerned with handling certain motion sickness related fallback, it should treat 3 same as 2, as if player requires no motion sickness specific fallback in handling of some special case when this function is called. For example, for subsystem x, it needs to do A in case of 1 and B in case of 2. In other words, it's nothing that can't be done, but the modification would need to be made everywhere where any subsystem asks what kind of locomotion is currently used, as we'd now require a 1,2,3 system, (teleport, classic, both) and then all the subsystems should be slightly modified to know if they should interpret "3" same as 1 or same as 2. So there are many systems in the background, which check if the teleport locomotion is set to 1 or 0, in order to check for situation and handle special cases accordingly. And then there are all the motion-sickness-preventing functions that only activate when using some kind of teleport movement (as selecting teleport as opposed to smooth locomotion, implies you are probably sensitive to motion sickness). It is in fact something that we can change on the fly, but the bigger issue is that many of those special handlers are a bit complicated. ![]() It was actually wrong of me to say "2 different physics rulesets" as it makes it sounds as 2 different physics, it's actually just a few rules get temporarily tweaked with some special handling of such cases. ![]() Since teleport is essentially incredibly fast movement speed (otherwise we couldn't calculate that mine was supposed to kill you along the way), now you have to take special care not to launch this bumped cube into the sky at supersonic speeds. ![]() Say you got an active physics object in the middle, like cube is falling down there at that very moment, then you teleport with a trajectory that would bump the object along the way. When dealing with teleport, we do what's called substepping, which means we calculate let's say 10 steps of physics in between 2 frames of rendering, as well as needing to be extra careful about how things are handled in between start location and destination. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |