It would be really helpfull for ctb mapping/modding if we can get a value in ms to know the leniency a player have to catch next fruit. The formula should be something like (ms beween the two objects) - (ms spent in mouvements with dash) = (Leniency to catch next fruit). We could determine easier if an hyper is created and much more important : the difficulty of a standard dash. This will be very helpfull to improve CtB guidelines too imo.

If it is implemented for test mode maybe fixing the autoplay is the best way to do it.

FUCKING PLEASE.

Upvoting that one.
It would be VERY usefull and I guess it will improve CtB diff's. From my point of view it will be an awesome features. Cheers.~

Sure, why not?
star~

A star from me.

You have all my support!

Would be nice to see whenever a hyperfruit is created or not in the editor.

That would be a dream ;_;
Even if it is just autoplay

Support.

I wished to had an answer by the staff :s

Planned ? Yes ? No ? Bug jumps are being fix'd so this will make this req invalid ? Chorizo ?

inb4 peppy : Chorizo

Very much support from me <3

i see my post was discouraging ppl to post here

i cri evritim

Drafura wrote:

inb4 peppy : Chorizo

Also, support.

i, one actually like this idea, For all the reasons above and also will probably give you more of an idea on how you can improve your skill and technique for CtB

Don't let this die D:
It will be REALLY usefull, with it you can see if there is pixel jump etc ... So ctb mapping/modding can be better
For exemple, I suck at CTB, so I don't know if some jump are "pixel jump" or it's just because i'm too noob D:

uuuh support *D*)/

Support :3

The autoplay part of this request is invalid, since everything will be catchable once hyperdashes are fixed. I like the test mode stats, though!

Knowing the leniency of a non hyper jump could really help to set solid rules about jumps in ctb mapping, even if bug jumps are fixed. That's why I think this still make sense. If it's not seen in test/auto mode maybe in editor mode would be fine too. Should I edit the op ?

I'd get rid of the part about the autoplay, the test mode stuff is already good as is though.

It's not invalid. Why should auto behave differently in test mode than it does in general? It will not be harmful to incorporate this change to both autoplay and test mode autoplay.

The reason it's invalid is because everything will be catchable once hyperdashes are fixed. The only things besides missing hyperdashes that auto could catch but humans can't are fruits outside the map, and there's only a few old maps where that's a problem.

I don't think hyperdashes will be fixed IMO. peppy will never fix them.

It's on his to-do list, but it's a "low-priority bug". He'd probably rather fix them than go to the trouble of adapting auto to broken behavior.

You have a point that's hard to argue with. I mean it would seem like buggy behavior if auto didn't FC certain maps. I agree, it should be removed for standard autoplay.

TheVileOne wrote:

It's not invalid. Why should auto behave differently in test mode than it does in general? It will not be harmful to incorporate this change to both autoplay and test mode autoplay.

Actually there's a difference between test mode and autoplayer :



Having the jump leniency here or directly in the editor could be really helpfull. But if you think about how to implement it, you're going to make some calculations wich can be used to fix salad!, that's why it's related to autoplay.

In other words by fixing autoplayer peppy can extract some interresting datas to help ctb mapping/modding to growth. Even if bug jumps are fixed (one day after reskinning entierly the forum the chat and the entire game maybe) these datas will still be usefull.

I've edited op. I hope it is now valid.

TheVileOne wrote:

You have a point that's hard to argue with. I mean it would seem like buggy behavior if auto didn't FC certain maps. I agree, it should be removed for standard autoplay.

In my eyes auto Fcing maps wich actually aren't is the buggy behavior. If maps are FCable when bug jumps fixed then a fixed auto will FC it too.

peppy is most likely the one trying to implement this, but if he said he were going to fix hyperdashes first, then I doubt that will ever be implemented. Why would you implement something to adapt to the unwanted behaviour/problem when you're intending to fix it instead?

It's not okay to make an auto mod miss things because we can't catch them atm. It's like making it impossible for autoplay to hit notes in standard because they're way beyond a human level.

theowest wrote:

peppy is most likely the one trying to implement this, but if he said he were going to fix hyperdashes first, then I doubt that will ever be implemented. Why would you implement something to adapt to the unwanted behaviour/problem when you're intending to fix it instead?

I've modified op for this reason (and seriously I can't find how you understand that from it if you've read it)... Jump leniency could give a solid data to write a rule like : "If your jump have XXms leniency then your map isn't rankable".

This could HEAVILY help XAT and other modders to mod CtB diffs...

theowest wrote:

It's not okay to make an auto mod miss things because we can't catch them atm. It's like making it impossible for autoplay to hit notes in standard because they're way beyond a human level.

The standard autoplayer actually miss impossible hits (2 objects on the same note). And the modification about autoplay isn't to make it "human", it's to forbid it to go faster with the dash than a player can, this behavior is required to calculate the jump leniency. If peppy wants to implement jump leniency value, all calculation behind this number could be used to fix the autoplayer, that's the reason it's related.

As a non-CTB player I give my support. Sadly I don't have any stars :/

Drafura wrote:

TheVileOne wrote:

It's not invalid. Why should auto behave differently in test mode than it does in general? It will not be harmful to incorporate this change to both autoplay and test mode autoplay.

Actually there's a difference between test mode and autoplayer :



Having the jump leniency here or directly in the editor could be really helpfull. But if you think about how to implement it, you're going to make some calculations wich can be used to fix salad!, that's why it's related to autoplay.

In other words by fixing autoplayer peppy can extract some interresting datas to help ctb mapping/modding to growth. Even if bug jumps are fixed (one day after reskinning entierly the forum the chat and the entire game maybe) these datas will still be usefull.

I've edited op. I hope it is now valid.

TheVileOne wrote:

You have a point that's hard to argue with. I mean it would seem like buggy behavior if auto didn't FC certain maps. I agree, it should be removed for standard autoplay.

In my eyes auto Fcing maps wich actually aren't is the buggy behavior. If maps are FCable when bug jumps fixed then a fixed auto will FC it too.

What about TAg maps? They aren't possible, and are never going to be possible. it's not considered a bug if mappers violate the Time-distance equality rule. If auto was not able to play these maps 100% it would seem like buggy behavior. The game isn't accurate enough to detect that hyperfruits certain distances apart are catchable. Plus it is more optimized to let auto just beast through it rather than have the game restrict it.

Correct me if i'm wrong on this, but how fast the ryuuta moves is related to how long it takes input data to be read, and that framerate issues can affect your ability to play certain parts, because there's only so quickly the ryuuta will go from hyperdash left to hyperdash right, and there is a point where it doesn't matter how quickly the keypresses change, the game will think that both keys are pressed at the same time and so it will stop responding. This makes even certain hyperfruit patterns technically impossible.

Also combinations of patterns that would be humanly possible placed together will sometimes make something not possible. Feel free to completely destroy every bit of my logic here, as I only have theories as to why I move at x speed, but pro players seem to move faster than me. There seems to be differences in the speed between players.

Tag maps are theoretically SS-able, the patterns are just too fast for human reflexes (most of them have been done with HT, in fact.) Once they get fast enough, they're still theoretically possible for a robot on a keyboard with an ultra-high polling rate. Auto can hit notes outside the playfield in Standard, which are the only things not possible by a robot, and so it should be able to in CTB as wel, where it's the only thing that's impossible for a robot assuming hyperdashes are fixed.

MillhioreF wrote:

Tag maps are theoretically SS-able, the patterns are just too fast for human reflexes (most of them have been done with HT, in fact.) Once they get fast enough, they're still theoretically possible for a robot on a keyboard with an ultra-high polling rate. Auto can hit notes outside the playfield in Standard, which are the only things not possible by a robot, and so it should be able to in CTB as wel, where it's the only thing that's impossible for a robot assuming hyperdashes are fixed.

^More or less, this...

And to take your own words TheVileOne : Correct me if i'm wrong but I never talked here or anywhere to make an autoplayer wich can't catch a thing wich is theoretically SS-able but not by human being.
So please :
1) Stop interpreting my words in a wrong way
2) Stop being off-topic.

1. I was not interpreting your words wrongly. Perhaps you have phrased your words poorly so that they do not accurately reflect your actual thoughts. i'm saying that there are instances where if you hit left/right fast enough they register as the being pressed at the same time. This probably doesn't happen in any ranked map, which probably would make any tag map possible, but I mean that if auto uses the same inputs(left, right taps) to adjust, then there will be a distance where auto can't go left and right fast enough, because both buttons would be pressed at exactly the same time (a process known as key jamming).

2. Talking about auto's ability to SS certain maps is by no definition off-topic. It's related to auto, test mode, and the ability to catch beats by said auto mode. I was trying to ascertain whether the speed at which the ryuuta can move is related to the latency between their keyboard and the game and how much distance the game allows the ryuuta to move based on the frames that move per second, and if key-jamming would be an issue if auto used the same input methods as regular players. If that is off-topic, might as well lock this whole thread for being off-topic.

3. Please don't respond in a rude and ungrateful way.

In case you completely missed the point of my last post. My comment is that even if hyperfruits are fixed, I'm not entirely sure it will still make the map possible by regular inputs, because input triggers don't like to work the faster you go and if auto will move according to your latency, it will mean it will still miss, due to incorrect ryuuta placement, because of latency between your input and the games. I was hoping that someone would clarify whether I was wrong about this issue or not.

Do people move faster/ slower based off their latency? And if so, how do we know how fast auto should go? It would move faster or slower based off the resources available.

Edit: Final Point in this post: If pixel jumps are technically possible without a hyperdash, then auto would be able to hit them regardless. It wouldn't be that useful in preventing them in the maps if this feature was included, because as you know, auto is pixel perfect. And on the flipside, if a pixel jump is possible without hyperdash, then we can't claim it should be a hyperdash, because it's just very difficult to hit. I guess that's my nod to the hyperdash's being fixed issue in tech support.

Edit 2: I see you've completely changed the request entirely.... Oh well answering this question about latency still applies. Does someone with less resources take more ms to move with the same input as someone with more resources?

TheVileOne wrote:

Perhaps you have phrased your words poorly so that they do not accurately reflect your actual thoughts.

Please, you're the only one here wich don't understand. Even MillhioreF failed at explaining you what this thread was about when we look at your next answer.

I don't want to be rude at you, seriously, but you are totally off topic. Even with the old op, this wasn't about making an autoplayer wich press keys it was just about an autoplayer having the same technical (not physical) limitations as players. Meaning can't go out of screen or using the same mouvement speed.

Two different computers, of course, moves the ryuuta from X to Y in the same amount of time while dashing. Auto can dash faster, that's it. If you want to learn more about how those bugs are generated you can watch this video http://fr.twitch.tv/drafura/b/339578796 and try them by yourself easily.

So again this isn't at ALL a thread about how many different moves can do a computer versus a human. If you want to talk about this open new thread, if you think you found a new issue with the game, open new thread in TS, if you want to make philosophy, math, speaking about the coming end of the world open new thread in OT. If you still posting this kind of unrelated things I'll call an admin to clean the thread.

I see TVO's point. And I see other peoples points.

None of the points are off topic. Infact: Both points are the same. TVO is saying how fast auto can dash. The other points are exactly the same.

Perhaps I'll try to give an example.......

Ryuuta moves from one fruit to another on each side of the screen in a 150 bpm. The one fruit would be on a white tick, and the other fruit on the next white tick. Ryuuta in auto mode would dash across the screen.

TheVileOne wrote:

It would move faster or slower based off the resources available.

Drafura wrote:

Two different computers, of course, moves the ryuuta from X to Y in the same amount of time while dashing.

These two quotes are EXACTLY the same thing. TVO saying about the resources as in moving across the screen to the next fruit. Drafura saying about how moving ryuuta would be dashing across the screen.

I support this request (but i dont have any stars :/ ).

VinylDash14 wrote:

TheVileOne wrote:

It would move faster or slower based off the resources available.

Drafura wrote:

Two different computers, of course, moves the ryuuta from X to Y in the same amount of time while dashing.

These two quotes are EXACTLY the same thing. TVO saying about the resources as in moving across the screen to the next fruit. Drafura saying about how moving ryuuta would be dashing across the screen.

Actually this is the only thing in his post i've found on-topic, so I just answered him about this point.

More exactly it's an answer to this question :

TheVileOne wrote:

Edit 2: I see you've completely changed the request entirely.... Oh well answering this question about latency still applies. Does someone with less resources take more ms to move with the same input as someone with more resources?

My thread would have been more on topic if you had not decided to suddenly completely rewrite said topic. Do not complain about people being off topic because you decided to change the topic and especially when someone was simply asking a question, backing up said question with support details that were also closely related to the topic at hand.

The way the idea is currently presented, I see potential here. This would be simple enough to implement, but at some time down the road, a custom CTB editor would be much more useful. One step at a time though.

TheVileOne wrote:

My thread would have been more on topic if you had not decided to suddenly completely rewrite said topic. Do not complain about people being off topic because you decided to change the topic and especially when someone was simply asking a question, backing up said question with support details that were also closely related to the topic at hand.

Are you kiding me ?







I've edited op to keep my second idea about the jump leniency valid, your posts was off-topic as soon as you posted. And even if I didn't edited it, talking about bot vs human was off-topic. Please stop that, I'm begging you ><

TheVileOne wrote:

A custom CTB editor would be much more useful. One step at a time though.

Yes, claiming directly for a custom CtB editor have a huge chance to be rejected. That's why i'm focusing on the usefull things. Actually I allready tried to implement something like this with the osu!sdk but if I remember well the sdk have a bug about returning end positions of sliders. osu!sdk seems dead, I didn't saw any updates for months now, so i'm pretty screwed without slider's end positions to determine spacing between all objects of the map...

This is to be known : So few XAT can decently mod CtB atm, a value/program/salad!/whatever helping them to mod easily would be really appreciate.