Floating-point test server

[SiO2]

Im hyped because romovs said that he will improve pathfinder when floats are in. Currently pathfinder in amber is a bit buggy and gets stuck in things and so on.

atm pathfinder miss simpler futures like shift+LMB travel over the long distances. Which do not really need a f.p. coords.

[shubla]

Im hyped because romovs said that he will improve pathfinder when floats are in. Currently pathfinder in amber is a bit buggy and gets stuck in things and so on.

atm pathfinder miss simpler futures like shift+LMB travel over the long distances. Which do not really need a f.p. coords.

They necessarily dont need floating coords. But romovs said that he wont "fix" these things before they come.

[romovs]

Just to clarify, the main issue with the pathfinder as far as I see it is that object hitboxes have "uneven" rotation. With the current integer based coordinate system they rotate around "pixel" center, that is for example if you take player's hitbox which is perfect square its rotation can be offset by one unit depending on the direction player is facing. This makes making a proper pathfinder rather difficult (not event mentioning that we don't know how object collisions are implemented server side. Like for example, why on earth character's speed affects how close he can get to the object...?) Yeah I know there're ways around it, but it's rather cumbersome.
I don't know whether floating point coords will solve this. Haven't checked it yet, but it's definitely a move in the right direction. I was hopping more about the "slide around objects" feature which should theoretically make everything much more easier.

[APXEOLOG]

Like for example, why on earth character's speed affects how close he can get to the object...?)

This is because of the movement system. In Haven speed defines the length of the "step" that character does per one tick. So the movement system calculates the next point based on the step length and then collision system checks if this point can be reached. If player cannot reach the point the movement is not occures. So as you can see, less length of the "step" (less speed) leads to the more accurate movement because the next points calculated more often. This is also the reason why 1st and 4th speed matters for some actions (for example is was possible to run through the wall without corner at 4th speed in legacy, or you must use 1st speed for line-mining in legacy).
I don't know if it remains the same right now, or loftar fixed anything, but actually i think i'd rather make the "step" a fixed parameter and perform number of collision checks during each tick. This way we will have accurate movement with any speed, but maybe more expensive in terms of collision-detection

[Pickard]

Like for example, why on earth character's speed affects how close he can get to the object...?)

This is because of the movement system. In Haven speed defines the length of the "step" that character does per one tick. So the movement system calculates the next point based on the step length and then collision system checks if this point can be reached. If player cannot reach the point the movement is not occures. So as you can see, less length of the "step" (less speed) leads to the more accurate movement because the next points calculated more often. This is also the reason why 1st and 4th speed matters for some actions (for example is was possible to run through the wall without corner at 4th speed in legacy, or you must use 1st speed for line-mining in legacy).
I don't know if it remains the same right now, or loftar fixed anything, but actually i think i'd rather make the "step" a fixed parameter and perform number of collision checks during each tick. This way we will have accurate movement with any speed, but maybe more expensive in terms of collision-detection

Just bad code, could be fixed in minutes without any side effects - when next step blocked, find last open cell and move there.

[APXEOLOG]

Just bad code, could be fixed in minutes without any side effects - when next step blocked, find last open cell and move there.

How do you find it without translating the point along the vector with some small steps? I don't know any algorithm for this...

[Pickard]

Just bad code, could be fixed in minutes without any side effects - when next step blocked, find last open cell and move there.

How do you find it without translating the point along the vector with some small steps? I don't know any algorithm for this...

https://en.wikipedia.org/wiki/Bresenham ... _algorithm

[APXEOLOG]

Just bad code, could be fixed in minutes without any side effects - when next step blocked, find last open cell and move there.

How do you find it without translating the point along the vector with some small steps? I don't know any algorithm for this...

https://en.wikipedia.org/wiki/Bresenham ... _algorithm

Yeah, this is how you will find the point, but how you will find the collision-free point? The only way is to make collision checks for each point of the path until you got the nice one. This is literaly the method i've described above

[Pickard]

Yeah, this is how you will find the point, but how you will find the collision-free point? The only way is to make collision checks for each point of the path until you got the nice one. This is literaly the method i've described above

Its only checking additional 3-5 cells when you hit obstacle. Very cheap.

[APXEOLOG]

Yeah, this is how you will find the point, but how you will find the collision-free point? The only way is to make collision checks for each point of the path until you got the nice one. This is literaly the method i've described above

Its only checking additional 3-5 cells when you hit obstacle. Very cheap.

Yes, but this is a question to loftar why didn't he still implement this