[Let It Be Known To All] - Tumble Bug

[jes00]

To anyone who uses tumble(%player, %time);. There is a bug in it that Badspot hasn't fixed. When you're tumbling you can click to respawn. If you want to use the tumble function, the below code fixes the bug.

Code: [Select]

package TumbleFix
{
	function observer::onTrigger(%data, %cam, %slot, %bool)
	{
		if(%slot == 0 && %bool && isObject(%client = %cam.getControllingClient()) &&
		isObject(%player = %client.player) &&
		isObject(%vehicle = %player.getObjectMount()) &&
		isObject(%data = %vehicle.getDataBlock()) &&
		%data.getName() $= "deathVehicle")
		{
			return;
		}

		parent::onTrigger(%data, %cam, %slot, %bool);
	}
};
activatePackage(TumbleFix);

[Ad Bot]

[ZombieDude]

<3
This fixes skiis as well

[Honorabl3]

I came across this bug over a year ago, and for some reason it unmotivated me to finish my mod. Thanks for this, I'll add this fix to my mod.

[boodals 2]

Code: [Select]

package TumbleFix
{
	function observer::onTrigger(%data, %cam, %slot, %bool)
	{
		if(%slot == 0 && %bool && isObject(%client = %cam.getControllingClient()) && isObject(%player = %client.player) && isObject(%vehicle = %player.getObjectMount()) && isObject(%data = %vehicle.getDataBlock()) && %data.getName() $= "deathVehicle")
			return;
		parent::onTrigger(%data, %cam, %slot, %bool);
	}
};
activatePackage(TumbleFix);

Condensed it into one if statement because why not.

[Port]

Condensed it into one if statement because why not.

Why not? Simple: That line expands way beyond column 80.

[boodals 2]

Why not? Simple: That line expands way beyond column 80.

And? It makes no difference what column it goes into. I saved 15 lines (unless I miscounted) (although it could have been condensed by removing the {  }s ).

[Port]

You should generally never write lines longer than 80 characters for readability purposes.
You also pretty much butchered the code as much as possible. No inexperienced person is going to be able to read that.

[Honorabl3]

Condensed it into one if statement because why not.

Condensing it into one line isn't always as fast. If one 'if' statement is false, the thing will still need to check the statement for "&&" and "||". However the way he has it, if the first thing fails, it doesn't waste time checking the rest of the other statements.

[Ipquarx]

Condensing it into one line isn't always as fast. If one 'if' statement is false, the thing will still need to check the statement for "&&" and "||". However the way he has it, if the first thing fails, it doesn't waste time checking the rest of the other statements.

This is 200% false, condensing it into one if statement actually speeds it up and nothing he said is correct

You can condense it as follows into one if statement:

Code: [Select]

package TumbleFix
{
	function observer::onTrigger(%data, %cam, %slot, %bool)
	{
		if(%slot == 0 && %bool && isObject(%client = %cam.getControllingClient()) &&
		   isObject(%player = %client.player) &&
		   isObject(%vehicle = %player.getObjectMount()) &&
		   isObject(%data = %vehicle.getDataBlock()) &&
		   %data.getName() $= "deathVehicle")
			return;
		parent::onTrigger(%data, %cam, %slot, %bool);
	}
};
activatePackage(TumbleFix);

[-Jetz-]

Code: [Select]

package TumbleFix
{
	function observer::onTrigger(%data, %cam, %slot, %bool)
	{
		if(%slot == 0 && %bool && isObject(%client = %cam.getControllingClient()) &&
		   isObject(%player = %client.player) &&
		   isObject(%vehicle = %player.getObjectMount()) &&
		   isObject(%data = %vehicle.getDataBlock()) &&
		   %data.getName() $= "deathVehicle")
			return;
		parent::onTrigger(%data, %cam, %slot, %bool);
	}
};
activatePackage(TumbleFix);

This is good. It shows every condition together in a way that is easily readable.

Code: [Select]

package TumbleFix
{
	function observer::onTrigger(%data, %cam, %slot, %bool)
	{
		if(%slot == 0 && %bool && isObject(%client = %cam.getControllingClient()))
		{
			if(isObject(%player = %client.player))
			{
				if(isObject(%vehicle = %player.getObjectMount()))
				{
					if(isObject(%data = %vehicle.getDataBlock()))
					{
						if(%data.getName() $= "deathVehicle")
						{
							return;
						}
					}
				}
			}
		}

		parent::onTrigger(%data, %cam, %slot, %bool);
	}
};
activatePackage(TumbleFix);

This is sloppy but still tolerable. It isn't much harder to read but the sequence of nested if statements look bad.

Code: [Select]

package TumbleFix
{
	function observer::onTrigger(%data, %cam, %slot, %bool)
	{
		if(%slot == 0 && %bool && isObject(%client = %cam.getControllingClient()) && isObject(%player = %client.player) && isObject(%vehicle = %player.getObjectMount()) && isObject(%data = %vehicle.getDataBlock()) && %data.getName() $= "deathVehicle")
			return;
		parent::onTrigger(%data, %cam, %slot, %bool);
	}
};
activatePackage(TumbleFix);

This is disgusting, unacceptable, and literally Riddler. poor. It's much harder to read than the other two, and absurdly long lines are infuriating to read on smaller windows or screens.

[Ducky duck]

Thankyou!

[Electrk.]

There's a bug with Speedkart where you get teleported far below the ground when you tumble.

[jes00]

This is sloppy but still tolerable. It isn't much harder to read but the sequence of nested if statements look bad.

How is it sloppy? It's orderly and easy to read.
I like to always put brackets with my if statements.

[Xalos]

-snip-

A condensed if statement is ALWAYS going to be faster. You're basically reinventing the wheel. As a square.

Conditional jumps cost time. The CPU can't be sure what's going to happen, so (modern) CPUs take an educated guess. When the CPU is wrong, not only does it have to correct its mistake, but it also has executed several more instructions during the time it took to discover that its guess was wrong. These instructions must all be thrown out.


Your having multiple possible conditional jumps causes the chance of this to increase. Meanwhile, using a single if statement with all the comparisons done with && and ||, which are both already short-circuiting, both actually achieves what you were ostensibly trying to achieve, and does NOT produce additional conditional jumps.



Note: This is a simplification of the matter, because I don't entirely understand CPU workings myself and because, well, most explanations are simplifications.

[Ipquarx]

-snip-

The short of it really is just that when it's compiled into TS bytecode, more conditionals = more operations.

Therefore less conditionals = less operations = less running time, all the time, no matter the cpu.