so in short, there’s no way to do this without it being severely inefficient?
1 Like
Not really…
As long as your topic makes sense, you’re good.
1 Like
No, just state your idea and current tests.
2 Likes
Well, I think the jump one and jump two method could easily work. We just need to find the numbers for different directions.
The actual speed modifier? Eh. Possibly not.
1 Like
Currently, yes. In the future? Probably. But maybe someone will find a smart solution.
1 Like
I think so. There are methods, though.
1 Like
What happens when they jump in quick succession without the player going down?
2 Likes
Again. It’s all about the numbers. Either way, we still have our max value for one and two, and we just add those together and see if it’s a double jump. Because jump one on it’s own will never equal a double jump, and if you go down too much it will still be more then the original if you double jump. My wording changes every time lol, but I think this will work.
3 Likes
Fragility. And a sentry.
I take personal offense at social media being toxic lol 
(in ur bio)
I think a better way of doing this is FIRST checking if the change in height is even possible for one jump in a certain interval. For example, you can’t jump 12 meters at once. Then, if it passes the check, start the second process which checks if you’ve fallen down and then risen up again. The fault in this system is that the player could’ve just hit a platform and jumped again quickly.
1 Like
Where will the sentry be positioned?
1 Like
Right. The speed of the whole system is really the issue. It might end up only being compatible with some jumps. Enough chatting, let’s start testing lol.
I think we should ignore the whole speed modifier thing and focus on getting this:
If the player double jumps, transmit on channel x.
So currently, I think doing the math for the values of the first jump, then checking to see if it’s a double jump, then storing that and comparing it with the next change in y, to see again @here would work?
3 Likes
Behind the player, in the opposite direction of where you’re trying to go. And it heals in 2 seconds afterward. Soon after, the sentry is deactivated.
True.
So it’ll be on a platform?
Probably.
How many platforms will you make to account for the different positions a player could be when dashing?
No probably, definitely, lol.
And that’s why I think it’s easiest and most efficient to focus on getting the input first before we think about the output. Regardless, the system will be groundbreaking anyways.
Max aim, and you don’t need that many. Just use the zones mentioned by me earlier, and you’re good.
Check 1: Check if player height has increased more than a standard jump allows them too.
Check 2: Check if the player’s height has been constant.
Check 3: Check if the player went down and then up again.
If you want to check a specific interval, store all coordinate changes in a text string and splice it up to see what has changed in the player’s y-position.
That’s my theoretical design. It’s probably really flawed, so if you want, criticize it.
3 Likes