Loftar's thoughts on pathfinding

[ekzarh]

As a tradeoff between 'bear problem' and game experience I'd say that pathfinding could work on short distances, like 10-20 cells and fall back to ol'good straight line on longer distances.
Then when we walk around village objects or cave corners - we walk around them, but when we walk around cliffs or walls - we run to them and stop.
This solution is also easier from performance perspective.

Regarding 'interfaces' issue other guys made a good point. If client has precise hitboxes of objects - all patfinding can be done on client side

[loftar]

Anyway, a first step, that is very compatible with how objects work right now, would be to provide good neg layers, like in legacy, where the coords for the bounding boxes were encoded into the neg layer of the res files and properly decoded by the client.

I did tell you previously that the information is there in precisely the same way as it was in Legacy. :)

That being said, though, I generally don't want to depend on the client having information about mechanics. The dumber it can be, the better.

There is some way to maintain the same general direction with some simple math I would need to figure out on paper.

The math is certainly the least problem, it's easy as pi (haha lolol roflcopter). The only issue is fitting it into the structure of the various mechanics.

[ArvinJA]

I did tell you previously that the information is there in precisely the same way as it was in Legacy.

Yes, you did. It's not correct though. the neg layers are mostly (0,0) for most objects. Do you think all these different client makers that I listed used these inconvenient ways of getting bounding boxes just for fun? If it's there it is pretty hidden. I've gone through the res files with a hex editor without finding anything relevant either. Of course, I might be missing something, but if so, so are most (all?) other client modders as well.

[Oddity]

I did tell you previously that the information is there in precisely the same way as it was in Legacy.

Yes, you did. It's not correct though. the neg layers are mostly (0,0) for most objects. Do you think all these different client makers that I listed used these inconvenient ways of getting bounding boxes just for fun? If it's there it is pretty hidden.

am a client maker, can vouch

[loftar]

As I said, though, it's there in precisely the same way as it was in Legacy. There's literally no difference.

[Sever]

It's actually all pretty well all figured out. There's quite a few 3D programming books with the calculations, though you do need to have a grasp of the math to be able to program it without significant bugs. Otherwise, you pretty much described the algorithms used to move two potentially intersecting objects if one is trying to "push through" the other.

I've always seen it called "sliding" the objects, but language varies in different regions.

The big problem with the current design, I think, and the way people cram stuff together off-grid is that with any sliding algorithm, you end up potentially still stuck in a corner with no way to get around it. In a typical WASD movement game, the person can usually just sidestep left or right to get off the concave corner (convex corners/curves won't, or shouldn't, ever be an issue). In point-and-click (Haven), there does need to be some smart way for the user to get out of that sort of corner without moving the mouse back behind or to the appropriate side of the avatar model for a quick side step. On the other hand, if it's at a wall or cliff where the corner is more than an integral or two (say half a tile or more), yes, they should have to manually move out of the corner.

3D engine design is a complex beast. It's why we've come down to about 4 major engines (Unreal, Source, CryTek, Unity, maybe missing one or two) and a half dozen or so minor ones.

Haven & Hearth is not 3D, if you know what I mean. At least in this respect, it doesn't seem like it would matter.

Sliding is a much better word, and pathing around those crammed-in jagged corners is exactly what I was talking about, but the only way you can path around them is to find the corner that's going to block the character and start moving along a line that doesn't hit it. I think that's the real problem, and if you can't do that then I don't think it's really possible, because if you use the FPS kind of sliding, when you run yourself into a badly lined up wall/corner, you do get stuck.

I guess in that sense, sliding/push-off of a single hitbox and making sure that many in a straight line will not catch you up on tiny bumps is probably the best solution without creating an expensive, buggy function.

[DPblH]

There are 12 bytes, which are skipped by loftar. Looks like they contains 6 short values (3 coords). First two are offsets from object center: top left, and bottom right.

For example:

Code: Select all

anvil: -5, -2, 7, 2, 0, 0
12x4

borka: -3, -3, 3, 3, 0, 0
6x6

Not sure what for last coord is.

[warrri]

So is this it then? Do we have to bitch for another two - three months till something is done? We're not finished with the topic and i am literally triggered by your post. "Too hard lel fuck off" Yea i just might.

At least address the most glaring problems.
Tree hitboxes are fucking retarded. Livestock hitboxes are fucking retarded. Getting stopped by frogs and chicks is fucking retarded.

[pedorlee]

I'm probably sayinh something stupid but here I go:

Isn't it possible to substitute the "internal" shape of a structure for a cross instead of a square? That would allow to cross the corners.

[Granger]

I'm probably sayinh something stupid but here I go:

Isn't it possible to substitute the "internal" shape of a structure for a cross instead of a square? That would allow to cross the corners.

You could walk into the object, and you would get stuck even more: in the corners of the cross.