Your code will still crash the server if the minecart goes out of the world Y-wise. You need to check the Y coord first, and only then you can call cChunk::GetBlock().
I don't like calling a function "ActualSomething" when there's already "Something" - it feels as if "Something" is doing bad job and is being replaced. Why not call it HandlePhysicsOnRail() ?
Also the huuuge switch() in HandlePhysicsOnRail() can be made smaller by leaving out the speed limit check in each branch and doing the check once for all directions after the switch. Not to mention that instead of hardcoding a number (8), you might want to consider using a named constant for it - use "static const double SPEED_LIMIT = 8;" at the top of the file, this will make it easier if we ever decide to tweak the limit or change the speed's units of measurement (I'm seriously considering moving away from m/sec to m/tick to avoid division-by-twenty in all physics code).
Is the "else" branch in cMinecart::DoTakeDamage() needed? The superclass should already decrease the health by the amount specified in the TDI, so unless minecarts take more damage than other entities, that code is wrong.
I think your HandlePhysicsOnRail() should NOT call super::HandlePhysics(), and instead it should adjust the speed (your big switch + limit, add small friction), update the cart position and snap to the rail block's axis (the "center" of the rail).
Any chance you're getting duplicate carts on the client? I think the cMinecart::Initialize() function is not needed at all - the cEntity's Initialize() already calls the BroadcastSpawnEntity(). Try to comment the entire function out (both cpp and header) and see if the carts still spawn, if they do, just delete the function altogether.
I don't like calling a function "ActualSomething" when there's already "Something" - it feels as if "Something" is doing bad job and is being replaced. Why not call it HandlePhysicsOnRail() ?
Also the huuuge switch() in HandlePhysicsOnRail() can be made smaller by leaving out the speed limit check in each branch and doing the check once for all directions after the switch. Not to mention that instead of hardcoding a number (8), you might want to consider using a named constant for it - use "static const double SPEED_LIMIT = 8;" at the top of the file, this will make it easier if we ever decide to tweak the limit or change the speed's units of measurement (I'm seriously considering moving away from m/sec to m/tick to avoid division-by-twenty in all physics code).
Is the "else" branch in cMinecart::DoTakeDamage() needed? The superclass should already decrease the health by the amount specified in the TDI, so unless minecarts take more damage than other entities, that code is wrong.
I think your HandlePhysicsOnRail() should NOT call super::HandlePhysics(), and instead it should adjust the speed (your big switch + limit, add small friction), update the cart position and snap to the rail block's axis (the "center" of the rail).
Any chance you're getting duplicate carts on the client? I think the cMinecart::Initialize() function is not needed at all - the cEntity's Initialize() already calls the BroadcastSpawnEntity(). Try to comment the entire function out (both cpp and header) and see if the carts still spawn, if they do, just delete the function altogether.