Jump to content

MrAires

PC Member
  • Posts

    17
  • Joined

  • Last visited

Reputation

6

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Quixot "Watchout dreamers, word on the rails is a General of the Old War is Back; and he has -No Idea- What's Goin on"~Nora Quixot was a mighty general in the Old War Who fought against the enemies of the Empire. However, as the Old World fell around him, the sights he saw drove him to madness and he turned on his allies. Or so he thought. Originally this "General" was truly just a farmhand, who fell into madness from a life of stories and legends. Eventually, when the old war broke out and desperation struck the orokin, they enlisted this crazed man in their ranks. Only to regret their decision. Quixot is a new warframe who is built around his "Noble Kaithe", Sancho's Dapple. Dapple is in truth a Gourv a more honery relative of the kaithe. Passives: Quixotic Direction: Our fine Hero has no idea where he is at any point in time. As long as one pilots Quixot, one will not see any nav markers, waypoints, objective symbols, or any other form of UI element; Nor will the map appear. NOTE: This only affects the physical images of the maps, not markers such as teleportation points in open world zones. Names will not be present above any other player's head. Quixotic Detection: ...His enemies are everywhere... Any given static lootable object will appear to Quixot as an appropriate enemy type which will wander aimlessly. Attacking this target will cause a destructible object to break but at the location of the actual object. interactable lootable objects will vulnerable to finishers, which will cause their source object to be opened. Any given warframe will be replaced by a corresponding ally. Quixotic Desperation: "No animal is as dangerous as one that is cornered" ~The Business. When Quixot is damaged he gains damage proportional to health lost. Active Abilities 1. Dapple: Dapple summons his mighty steed and allows Quixot to travel at 50% higher speed. If Dapple is already present, This ability will enable a charge which will give nearby enemies a guaranteed radiation status effect. 2. Have At You: This ability increases Quixot's attack speed at the cost of his attack damage; each attack landed with this ability will leave a bleed proportional to the damage lost. If this ability is used while on Dapple, Quixot will flail his weapon about, causing Dapple to drift about as he lands impact status effects on his foes. 3. By Dearest Maam: Quixot channels his chivalry to grant protection to any nearby ally. This protective field grants Quixot the ability to dash to an ally who has been harmed by targeting them and blocking. When on Dapple, this field allows a Retaliatory charge to be used on an aggrieved ally, knocking all adjacent enemies away. 4. Full Tilt: Quixot begins to charge forwards, automatically veering towards any any enemy that comes close to his path. On Dapple, he and his steed begin to dance and flail striking any foe within range, and stopping any projectile that would come close.
  2. Well, since they are building the engine as they go, that will happen.
  3. Just because something is rendered, doesn't mean it is present. Those can just be SFX nodes with no context connected to them. The only nodes that are present fully on client are the ones that survive the transfer; that seems fairly obvious. So. when speaking on peer to peer communication, sending 32bits (or 16 depending on implementation of float; because iso is a joke or something) for the number 1, vs, 1 singular bit, is a massive difference in efficiency. My masters was in brute force hardware based data transfer and when you are operating in an environment such as netcode you can't just throw everything. Each one and zero matters and you can't afford the fat from floats for something you are sending over the socket at 30hz. ya think 5 floats per point, 40-80 bits each, maybe up to 1000 points, so that's 40k-80k per cycle, 120-240kbit/s on just the map data on the low end. I'm sure you would need more than that for an actual implementation. See above, the data is obviously only visually on the clients, and not at all actually present. There is a vast difference between a host instance and a client instance. It makes no sense to be actually running every player's abilities on every client, that is a lot of redundant execution. The reason you wouldn't transmit EVERYTHING, is because there is a physical latency related to using a network connection, and this latency does not have a consistent rate. Sure your ISP may guarantee two gbit, but that isn't the whole story here. There is a long chain of different processes between the host, whatever overwatch DE has, then to you and back through to the host again; those processes are occuring at anywhere between 20-60hz, so you can't have ALL state data included and expect someone playing on a switch in S#&$ty wifi to be able to play with any stability. Further, because only the visual data is present on the client, there wouldn't be any specific character bonuses attached; all of that would be host side; unless they modified their rendering pipeline to embed that data, which would be a nightmare. The host migration topic can't really be addressed without advanced knowledge of the future state from the host physically ready in the clients PC and currently there is no such data. Else this wouldn't be an issue
  4. Not really... if these errors were inconsistent, id agree, but the same planter in a given Lua cell is always pitch black, and my lander hasn't had all of its bits in the right place since the before the last major patch. These mean that there is corruption in the actual models themselves or in the pipelines that render those models. This affects premium and base content alike and while I can't expect DE to comb over the whole game every patch, some of these errors are rather critical.
  5. ABSTRACT The current problem is that much of the data concerning a mission instance is saved on the Host, and the exit process prioritizes the host's ability to exit, over the ability of the other players to play the game at all. There is substantial unreliability in the current process and a high likelihood of critical failures would will lead to player loss. IDEA A possible fix would be to use a scratch data struct to encode mission state data. METHOD The exact syntax of this struct would come down to optimization studies in engine, however my proposed solution is to use a "key and map" structure using UTF-8 char values. The idea behind the key would be to create connections between abstract data and specific ids. This essential or "key" data would only be appended to during a mission, which would increase data integrity whereas the physically volatile locations of items in each level would be "mapped" out at regular intervals in a separate data structure. EXAMPLE The Key: data type1-HEXID1, data type2-HEXID2,... ::The described data types would be any sort of player placed objects, (such as Mirage's traps,) or any permanent player specific state (active abilities or DUVIRI decrees.) Any HEXIDs would be either unique in that instance or predefined elsewhere. The Map: HEXID1, CHAR-CHAR-CHAR-CHAR-CHAR//1 ... CHAR-CHAR-CHAR-CHAR-CHAR//N HEXID2, .... HEXIDN ::The map structure will be set using UTF-8 Char encoding to allow the placement of high bit depth data in a low latency format (as it will have less physical ones and zeros than a corresponding float) and does not require any terminating values/spaces as those are inherent parts of the encoding process. The five char values would be uint-16 data values which correspond to: (map cell index)(mission map cell index)(mapcell_X)(mapcell_Y)(mapcell_Z) The encoding process would take a map cell's X Y and Z float size, divide by the item location from some predefined datum then convert to the uint-16 form. The resolution of this conversion can be arbitrarily large, such that you may implement this as 0-3-7, 0-256-511, or 0-32000-64000 corresponding to 0-.4-.9. Numerical normalization will increase extensibility and allow for map specific unwrapping processes to be done on the new host. So if at some later time DE decides a series of open world maps should be stitched together, that can be done fairly seamlessly using the same structure. Additional data could be encoded by simply having key CHAR or HEXID values for players or what not. This would definitely come down to the engine. DISCUSSION Why uint-16 as UTF-8 char instead of just using floats!?? The specific conversions to the char type will allow for an easier handoff process to the new host, and increase speed by reducing the net number of bits required to be sent to do said handoff, with a tradeoff of using marginally more CPU cycles on the host side. How is this faster if the Host unexpectedly drops? This process does not guarantee speed nor would it be done upon the host leaving, but rather this data would be sent at regular intervals (20hz, 1hz or slower) to the clients so that when the host leaves, each possible host will already have a copy and can implement the most recent map. Ideally you would have some number of map slots, preferably 3 or more, with some set arbitrary cache size such that if a host leaves during a write process the map being written to may be trashed, an older map may be checked for validity and if that fails the third can be loaded. Something to remember is that the serialization of maps allows for this write process to occur piecemeal throughout the game loop and could be delegated as a lower priority action. If it isn't faster, then why bother? The aim of this process is not to accelerate the host migration process itself, but to make it more reliable and more user-friendly. The current process is currently barely functional, and often leads to complete breakdowns of content: Archon mission breakdowns, Duviri circuit failures with loss of progress, and substantially more. Players won't want to spend longer than they have to waiting for host migration Players would rather have marginally longer wait times on loading screens than have to redo possibly hours of frustrating or difficult content due to some seemingly minor flag breaking.
  6. The recent content patch has injected a load of various misc visual bugs related to model rendering. Missing/wrong textures. Improper model assembly. Shader breakdowns. Light engine failures. adding a feature that players can use to report these visual glitches would help the team be able to catch them all.
  7. Fish do not use consistent grading between quality levels, and there is no easy way to determine what (B) or (V) or (A) means from the tooltip. An added blurb about what quality a fish is in the expanded tooltip description would make this easier for differentiating fish.
  8. Also, Duviri incentivises having multiple different builds on each weapon/frame. being able to have radically different polarizations would make this easier
  9. With modern changes such as helminth or mod loadouts, there is more customization than ever. Now, the title would suggest something that would break that down; however... What if different loadouts could have completely different mod polarities? This is my suggestion: when you forma a slot with a pre-existing polarity, you can now swap between the two polarities on that slot between different loadouts. This could be implemented as a selectable thing, or as an automatic function of mod placement; creating a wildcard functionality. I think this would be a nice way to incentivise players to consume more forma (thus more platinum, and thus spend more) while also making content like Duvari more convenient to setup loadouts around.
  10. BUG: Ammo flying at user and preventing interaction with objects Bug Condition: be in lich/sister mission or spawn nascent lich/sister on mission Bug Effect: Audio: endlessly repeating clicking noise of ammo being picked up Visual: ammo will be stuck at current player position Way to resolve bug: TEMPORARY FIX: 1. "consume the ammo" by using a given weapon, (purple or orange) and reloading it until all ammo is consumed or they drop 2. if the appropriate weapon has been disarmed, one will be unable to pick that weapon up again. to clear the bug in this case, one must first become operator, and then die and be teleported back to one's warframe. While the bug will reappear, one can grab the disarmed weapon. Known fix: end mission. Bug Cause: Unknown. bug info: I exclusively do my sister/lich content solo (unless I am just trying to do the relic order and have failed a bunch and now have a lvl4/5) i very regularly get a bug where ammo is flying at me, and unless I consume the ammo by expending ammo and then reloading the appropriate weapon, i will be unable to interact with anything on the map. I do not usually get the glitch unless I am on a sister/lich mission, or have just caused a lich/sister to spawn. this can perma lock any player without operator.
×
×
  • Create New...