Train Bogie Hitbox - Look for Update-Code after Cleanup

[NitroxydeX]

Trains have multiple hitboxes when they are placed but they aren't moving along with the train.

[NitroxydeX]

This should have something to do with the hitboxes. Attached Carts after Trains have no space like Carts attached to Carts

[CovertJaguar]

This is fairly trivial, look at the Ender Dragon.

Another example from the Railcraft Tunnel Bore:
https://github.com/CovertJaguar/Railcraft/blob/dev1.10/src/main/java/mods/railcraft/common/carts/EntityTunnelBorePart.java#L38

[EternalBlueFlame]

That does help a bit, mostly it's just the mess is this entire nasty hitbox system needs a full replacement with something proper.

[CovertJaguar]

Entity.getParts() is about as proper as it gets. Its how all the vanilla entities handle the problem.

[EternalBlueFlame]

you're sugguesting changing the entire positioning system for how carts place next to eachother while moving. As it is right now it's built off hitboxes
based off movement is a lot more complex of a fix than necessary. Not to mention is anything but proper, unless minecraft's idea of proper is inefficient designing, then again, nothing is done well in forge......

Add to it, theres issues with getParts because it can randomly be null, especially in 1.8+ (which i would assume this will get ported to eventually). so that would create more errors in place of this.

[CovertJaguar]

Just trying to help, it's a tried and true system that works for vanilla and many other mods.

Basically the master entity has one large hit box that encompasses the entire entity in any orientation, the collision detection uses this to determine if it should look closer. If it detects a possible collision, it then grabs the part entities from the entity and refines the collision detection against them. A collision is only determined to occur if part entity collision boxes intersect the entity being tested.

I don't see what this really has to do with intercart positioning, and even if it does, it should be trivial to adapt anyway. As for nulls...I'm not sure why you'd even be calling getParts() anyway. That's for the collision detection subsystem to use.

[CovertJaguar]

Frankly it should even be possible to link part entities from two different carts together to create links. You could even create a part entity specifically for the link attachment points. Then you'd just feed the positions for the two anchor part entities to the linkage physics (which unless the linkage physics code has been rewritten, used to be based on my code) and the physics code would keep the two anchor point entities close. Applying the spring forces might be a bit weird as you'd need to apply them to the parent entities, but I'm sure it's a solvable issue. In fact you could probably crank the spring and damping forces up for a much less bouncy and more solid connection as the two anchor points can be very close together. But that's just brainstorming off the top of my head.

[EternalBlueFlame]

If we shouldn't be using getParts, why did you mention it, and then go on to explain it?

I'll look into this when I have some more time to put into debugging.

I know the hitbox setup was changed in TC 1.6.4 because a lot of related issues spawned there, suffocation in 3x3 tunnels but not 3x4 tunnels, this weird linkage between carts, the 3 hitboxes rather than one, along with them not moving.

I've done a lot of hitbox work in .net, C++, and C. I know how it's supposed to be done, method wise anyway, but that doesn't mean I just magically know the forge API calls.

The issues shouldn't even be the anchors, they work fine, producing working and reliable results with what they are given, but the hitboxes themselves are just all over the place, which would cause the anchors to seem a bit wonky.
That is assuming the term anchor means an anchor between hitboxes and not an anchor between the hitbox and the host entity (which wouldn't normally have a name in other API).

Don't get me wrong, I appreciate the effort to try and help, I just want to try and better convey the actual issue that's going on here.

[CovertJaguar]

I said you had no reason to call the getParts() method. What you do want to do is return your child part entities to the method so that the game can use them during collision detection. As I said before, look at the Ender Dragon or Railcraft Tunnel Bore for working examples.

As for Anchor I just mean a point where two cars would connect to each other, think coupler.

[Hagrud]

About this issue, I try to solve this in my fork of Tc. Those hitbox are the hitbox of tileEntityBogie and not of EntityRollingStock.

They don't move because entity boggie was not updated on the client side.

When we use entityBogie, the function updateDistance() push them out of the rail on sharp if the train was too fast.

To handle this I put the locomotive out of the track when I detect one bogie is not on the track. (This is not a good solution).

I think we can handle this by a beter way by preventing entityBogie to be pushed out of track in updateDistance().

[EternalBlueFlame]

@Hagrud is correct the hitbox issues are all fixed as of his patch #59
however they are still multiple hitboxes and that may not be the most efficient method, so i'll keep this thread as an enhancement idea.

[NitroxydeX]

And the hitboxes are moving away from its positions.

[EternalBlueFlame]

the displacement you are seeing is due to a delay in the positioning updating, it only updates every other tick in an attempt to improve performance since when I first got this mod working it was VERY laggy.
An intentional bug until the code is more efficient where such a practice is not necessary.

[31trainman]

Is this issue fixed?

[EternalBlueFlame]

partially. it's still open because of a displacement in the hitboxes at high speeds.
which is due to a delay in movement to preserve performance while the code is still highly inefficient.