08-31-2013, 05:54 AM
Also, for curved rails, remember that 2 curved rails next to each other count as one diagonal, not 2 curved.
Moving physics from Tick to HandlePhysics
|
||
08-31-2013, 05:54 AM
Also, for curved rails, remember that 2 curved rails next to each other count as one diagonal, not 2 curved.
Thanks given by: tigerw
08-31-2013, 07:20 AM
Curved rails actually masquerade as a single piece straight in a 45-degree angle, so multiple curved rails will connect as a single 45-degree line.
Thanks given by: tigerw
08-31-2013, 06:42 PM
Useful to know, thanks.
X-soft, did you see the code I pasted?
T-sigerw, can you paste the code inside shcode=cpp instead of raw code tags? The scrolling is bad.
(btw, I'd appreciate if you didn't maul my name) The HandlePhysics function needs to be structured into logical blocks, something like this: 1. Check if the coords are inside world (Y within 0 .. 255); if not, only call the superclass' handling so that the minecart falls / takes void damage 2. Check if the block is rails. If not, only call the superclass' handling 3. (On a rail) Apply rail physics. It might even be beneficial to split the "Apply rail physics" into a separate function, for clarity. Thanks given by: tigerw
(08-31-2013, 08:43 PM)xoft Wrote: T-sigerw, can you paste the code inside shcode=cpp instead of raw code tags? The scrolling is bad. :DD Okay, 'x-soft' is how I pronounce it mentally, heh. 1. yay! 2. yay! 3. yay! 4. yay! Curved rails are progressing well. The diagonal movement tip was really helpful, thanks bear and xoft.
09-02-2013, 03:11 AM
That's it, I'm done with minecarts. The curve code seems to randomly make carts derail, not sure if it's good or bad, but I have no idea why it does that. East west movement seems stiff, but the code is the same as north south, so again, I have no idea. Other than that, it is good-ish.
Shall I commit?
Change the if (GetHealth() == 0) to if (GetHealth() <= 0) for example if I would somehow with a plugin hit 100 on a mob its not equal to 0 but much lower.
09-02-2013, 03:18 AM
Thats what I ment
![]()
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. | ||
« Next Oldest | Next Newest »
|