Floating-point test server

[ekzarh]

QoL? T_T

I must admit I fail to see how such a feature would be a QoL issue. I've never once been bothered by it when playing the game.

All kinds of item and char loss due to griefers, all silk grinding, the farming of 100x100 carrot field manually, all of this is really fun, sexy, interesting and entertaining compared to the goddamn annoyance caused by character unable to walk around a corner of some tiny box or cauldron! If I'd ever be asked to pay directly for some feature implementation - smooth char walking would be the one! If you don't believe me - make a poll

Getting stuck at stuff while moving around is one of the most annoying flaws of Haven.

Agree!

[loftar]

QoL? T_T

I must admit I fail to see how such a feature would be a QoL issue. I've never once been bothered by it when playing the game.

All kinds of item and char loss due to griefers, all silk grinding, the farming of 100x100 carrot field manually, all of this is really fun, sexy, interesting and entertaining compared to the goddamn annoyance caused by character unable to walk around a corner of some tiny box or cauldron! If I'd ever be asked to pay directly for some feature implementation - smooth char walking would be the one! If you don't believe me - make a poll :)

Again, though, that wasn't what was being discussed.

[APXEOLOG]

All kinds of item and char loss due to griefers, all silk grinding, the farming of 100x100 carrot field manually, all of this is really fun, sexy, interesting and entertaining compared to the goddamn annoyance caused by character unable to walk around a corner of some tiny box or cauldron! If I'd ever be asked to pay directly for some feature implementation - smooth char walking would be the one! If you don't believe me - make a poll

We discussed another things tbh. That mechanics doesn't related to the "walk around a corner", it related to the "stop point" that depends on the speed

[ekzarh]

Sorry then =)

But they seem a lil' bit related to me.
If some pathfinding would be implemented char with not much effort can get the next behavior:
1) stop at further distance at higher speed
2)see that it has not reached the destination
3) see that one more piece path is not actually blocked
4) try to to finish the movement with lower speed and smaller collision distance.

I've seen such behavior in AAA 3D games, they also are a bit annoying but also give some sence of immersion when character does not stop near the wall in an instant. IRL nobody would smash into the wall or other obstacle but decelerate(sometimes urgently) to come close to it, so yeah, somehow speed _does_ affect human being 'collision test'

UPD: rem oved since new post arrived =)

[APXEOLOG]

Sorry then =)

But they seem a lil' bit related to me.
If some pathfinding would be implemented char with not much effort can get the next behavior:
1) stop at further distance at higher speed
2)see that it has not reached the destination
3) see that one more piece path is not actually blocked
4) try to to finish the movement with lower speed and smaller collision distance.

I've seen such behavior in AAA 3D games, they also are a bit annoying but also give some sence of immersion when character does not stop near the wall in an instant. IRL nobody would smash into the wall or other obstacle but decelerate(sometimes urgently) to come close to it, so yeah, somehow speed _does_ affect human being 'collision test'

The server-side pathfinding will consume a lot of resources. The proper calculation of the best path can take up to 300 msec even for the single character. Of course there are a lot of optimisation can be done, but anyway this will cost too much even for 500 players.

In the "AAA 3D games" the pathfinding is usually done on the client side, but you should also understand that they usually has static world (no teraforming or object moving), this allows to use some optimisations like pre-built nav-meshes. This solutions will not fit our case because in H&H world is too dynamic

Of course there are some things that loftar can do to allow the creation of the proper client-side pathfinding, and the "do not stuck in corners" is one of them

[ekzarh]

The server-side pathfinding will consume a lot of resources. The proper calculation of the best path can take up to 300 msec even for the single character. Of course there are a lot of optimisation can be done, but anyway this will cost too much even for 500 players.

In the "AAA 3D games" the pathfinding is usually done on the client side, but you should also understand that they usually has static world (no teraforming or object moving), this allows to use some optimisations like pre-built nav-meshes. This solutions will not fit our case because in H&H world is too dynamic

Of course there are some things that loftar can do to allow the creation of the proper client-side pathfinding, and the "do not stuck in corners" is one of them

Agree. It shd be client side only.
For this particular case (char stopped at distance further than possible due to bigger collision check distance) client optimization may be done.
You have char coords, end point(click) coords, and you have (or can measure with some simple tests) collision check distance for each speed and hardcode it as a constant. So you take current speed-1 collision check distance and add it along the line between initial pos and destination. This is a best guess of course (since the obstacle may have moved) but seems reasonable to me. Then speed may be switched to lowest, new move triggered with precalculated coords (and maybe temporarily reduced speed to avoid failing the same collision check)

[APXEOLOG]

For this particular case (char stopped at distance further than possible due to bigger collision check distance) client optimization may be done

The problem is that you cannot get close enough to the object if you are too fast. And you cannot solve this with client optimisation (except for the case when you manually switch the speed, but this is ugly hack), server will simply not allow you to move to that point

[ekzarh]

For this particular case (char stopped at distance further than possible due to bigger collision check distance) client optimization may be done

The problem is that you cannot get close enough to the object if you are too fast. And you cannot solve this with client optimisation (except for the case when you manually switch the speed, but this is ugly hack), server will simply not allow you to move to that point

Ugly, true. But for the convenience sake it may be better to use it instead of just stopping too far. Obviously with proper server updates (like the one you proposed) it may be way better.

I'd say it may work with worst case mechanisms. Each movement speed means X steps in a tick. Let it be 4 for sprint. Collision system checks 4th one and only if it fails it falls back to 3rd, 2nd and 1st until it finds reachable one.

Let's say user makes a move 20 current sprint ticks long. It's 80 fixed ones. But server makes 19 checks 20th will fail so it'll make from 21 to 24 to give back the nearest uncolliding coordinates
So normally it shouln't overload the server too much since most of player moves are way longer than current sprint step.

[loftar]

The problem is that you cannot get close enough to the object if you are too fast.

That's not entirely true; if the last step of the movement is shorter than what the speed setting dictates, it will still stop at that point, so as long as you avoid an actual collision, you can have the character stop at any arbitrary point.

[Granger]

The problem is that you cannot get close enough to the object if you are too fast.

That's not entirely true; if the last step of the movement is shorter than what the speed setting dictates, it will still stop at that point, so as long as you avoid an actual collision, you can have the character stop at any arbitrary point.

So you're saying that colliding with an object will put you at exact the same spot irrelevant of speed setting?