Sign In
Create Account
So not the most interesting topic but I wanted to get feedback from other devs on their feelings of best way to go around tracking in game objects.
Looking up missiles, particles, etc is suuuuupper laggy in ext and my understanding is that's riot's fault and can't be fixed. This leaves us with a lot of guess work which really influences the quality of scripts that can be created. I have a few different approaches that 'work' but am not really sure where the tipping point to the "track every missile 1 fps" issues some scripts have will be.
Issue 1: Tracking spells with no windup
When a skill has no windup there's no way in the API to read details about the spell. There's two problem types with this.
First - spells like syndra Q you cannot read cast position for evade, shield or to check ball position to use W/E, count balls for R, etc. This is solved by querying the ball object (ONLY when spell slot cooldown changes)
Second - spells like janna q or victor e cannnot read start position and end position. This is impossible to solve. We can query objects for start position but end position is simply not possible to read in GOS. For ourself we can use mouse position to estimate the direction but that's horribly unreliable as mouse will have moved by the time our script notices spell cast started.
The 'simple' solution for this type of spell is to search through object or missile list only when spell cooldown or toggle state changes.
To do this we would have to have a list of every spell slot and associated object name/type to search for. We then perform this search when a specified windup is complete. This will have TONS of outliers (like janna q which can be released at any time!).
Issue 2: Tracking spells with collision data
Just evade and other scripts allow you to turn on missile tracking but generally they will look at the active spell data to get the start, end, speed, width, etc of a spell to handle evade. With this approach there's no object querying or tracking but it also means if that spell was blocked by someone there's no way to know!
Lets say we're writing a Zoe script, we want to know where her Q is at all times. We can avoid querying by using activeSpell data but if it hits a minion or player directly then we have no way to know. The solution is same as #1 where after spell windup + gamePing we run a single missile query and we cache that one single missile.
Is a single missile search loop + caching that missile enough to cause FPS drops? Is the FPS drop from querying each index in the game or is it every time we access details of that missile even when its cached?
Issue 3: Fragmented development and core game logic
This is NOT a complaint against GOS in general but most of the more advanced logic needed to write better scripts is not part of the core API. Right now evade is where almost all of the work lies for spell detection and efficient calculation of inbound hits.... but because its intended for self evade it doesn't help us know about allies about to be hit by something and because of how slow it is to query missiles constantly it also makes it pretty useless to know where the spell is CURRENTLY - knowing we're in the danger zone is great but I'm not wasting zilean ult on ADC to protect against a max range thresh hook that wont arrive for 1.5seconds
...This is before you even look at spell hit detection for ENEMIES! Killsteal logic that takes into account attacks and spells that are about to hit enemies. Auto cast logic that can throw out key abilities before an enemy is even finished being CCd, etc. Those are all game changing for how well scripts feel to use.
Ideal Solutions?
So really what I want to see, and know will not happen.... would be to find the best ways to work around GOS limitations, come up with a list of best practices to solve as many common cases as possible. There will be always be edge cases where standardized logic falls apart but if we can get 90+% of situations handled then a 'all in one' script responsible for handling spell data would make working with GOS so much nicer and allow for much more complex logic.
A spell data core script. This would be the list of all spells in the game and the data on how to track them. It would include not just skillshots but single targeted abilities. It would expose the current game state of all active spells for other modules/scripts to use.
An evade module. This would hook into the core module to use the skillshot data to make evade decisions (duh) same as we do now.
A damage module. This would hook into the core module which holds all spell data. It would expose an API to calculate spell dmg by slot but also inbound damage for self, allies, enemies in the next X ms
Obviously I'm a realist and know that the time to put everything together and test is unreasonable to expect to happen in reality but I want to get feedback from other devs on if I'm missing some core issue. I attempted something similar with my AlphaLib and got pretty far (even if it was spaghetti code!) but the approaches I used weren't modular enough to really act as a 'central API' for other scripts to build on and it absolutely didn't scale well for efficiency. I don't want to sign my self up for a similar project only to run into similar issues.
TLDR: Will single loop missile/object queries triggered by spell casts be horribly laggy? Is it the querying constantly that causes the drops or accessing the cached object fields? If I have already found a lux Q will accessing its position every tick cause issues or no?
Back to top
Report
