Kramuals ACTUALLY explained, and why diagonal kramuals are possible
+11
Apple
hypothet
Pawel3
Chuggers
rabid squirrel
efrazable
ScrungleBlumpkus
Conundrumer
Inukaza
[senpai] kevans
Fauxfyre
15 posters
Page 1 of 3
Page 1 of 3 • 1, 2, 3
Kramuals ACTUALLY explained, and why diagonal kramuals are possible
I was going to write this awhile ago, but I was too lazy at the time and didn't think anybody would really care in any case, however I think some false information provided recently needs to be corrected.
HOW KRAMUALS WORK
When the binding between two contact points attempt to normalize the distance between them, they add or subtract x&y coordinates from the points equally (without affecting the angle of the segment) to get the points the correct distance apart.
Example:
These changes constantly cause the angles between other points to be put off from each other, so the changes aren't usually equal between different segments.
Example:
However, what happens when you put all the points inline? If all the points are at the same angle, when the distances between two points change, the rest of the bindings angle's are unaffected.
Example:
This is the reason why kramuals happen. When all the points get moved into alignment, the angles between points never change. Since a single bindings adjustment doesn't change it's own angle, nothing will ever be forced to move out of alignment until a line causes a disturbance. There is nothing saying this is impossible in the hypothetical situation of a diagonal kramual, in fact it is just the opposite. If all the bindings are at an equal angle, the adjustments will never cause the angles to change.
I'll provide some snippets of code and try to explain it as simply as I can.
(In the code, the a&b are the contact points, and the .x/y are the x/y property of that point.
I'm pretty sure that covers it, if someone has irrefutable proof against my explanation or has further questions (perhaps because I was too confusing), please ask!
HOW KRAMUALS WORK
When the binding between two contact points attempt to normalize the distance between them, they add or subtract x&y coordinates from the points equally (without affecting the angle of the segment) to get the points the correct distance apart.
Example:
These changes constantly cause the angles between other points to be put off from each other, so the changes aren't usually equal between different segments.
Example:
However, what happens when you put all the points inline? If all the points are at the same angle, when the distances between two points change, the rest of the bindings angle's are unaffected.
Example:
This is the reason why kramuals happen. When all the points get moved into alignment, the angles between points never change. Since a single bindings adjustment doesn't change it's own angle, nothing will ever be forced to move out of alignment until a line causes a disturbance. There is nothing saying this is impossible in the hypothetical situation of a diagonal kramual, in fact it is just the opposite. If all the bindings are at an equal angle, the adjustments will never cause the angles to change.
I'll provide some snippets of code and try to explain it as simply as I can.
- Code:
function satisfyDistance()
{
var _loc3 = a.x - b.x;
var _loc2 = a.y - b.y;
var _loc7 = Math.sqrt(_loc3 * _loc3 + _loc2 * _loc2);
(In the code, the a&b are the contact points, and the .x/y are the x/y property of that point.
- Code:
var _loc6 = (_loc7 - restLength) / _loc7 * 5.000000E-001;
- Code:
var _loc5 = _loc3 * _loc6;
var _loc4 = _loc2 * _loc6;
- Code:
a.x = a.x - _loc5;
a.y = a.y - _loc4;
b.x = b.x + _loc5;
b.y = b.y + _loc4;
I'm pretty sure that covers it, if someone has irrefutable proof against my explanation or has further questions (perhaps because I was too confusing), please ask!
Fauxfyre- Member
-
Re: Kramuals ACTUALLY explained, and why diagonal kramuals are possible
Shotoku wrote: if someone has irrefutable proof against my explanation
https://iridethelines.forumotion.com/t10747-kramuals-explained
You do know that not once in the functions to check for bosh's shape rely on angle? If kramuals were causes of all points sharing the same angle, we could rotate during kramuals without him crashing.
Also as i mentioned in my thread, if _loc2/3 don't result in 0, the function will cause bosh to return back to his normal position. if the points are not either no slope or infinite slope, _loc2/3 has no chance of resulting in 0. You can graph 10 points in a diagonal line and apply the math yourself.
Re: Kramuals ACTUALLY explained, and why diagonal kramuals are possible
You are partially correct, but it isn't just based on everything being 0 in one way or the other. It is based on the angles or the lines, and the adjustments between them, not the directions the points are moving.
Fauxfyre- Member
-
Re: Kramuals ACTUALLY explained, and why diagonal kramuals are possible
I never mentioned direction, I explained that they must share the same X or Y coordinates. The resulting math with _loc2/3 equaling 0 is what causes the lock into a kramual.
Re: Kramuals ACTUALLY explained, and why diagonal kramuals are possible
I know that isn't the entire truth. The fact that they all share the same X/Y coordinates contributes to them all having the same angles, right? Either 0 degrees, 90, 180, or 270. That is what it comes down to. Now, if they all have a 45 degree angles, the same logic still applies. You were on the right track, but didn't take into consideration the big picture.[senpai] kevans wrote:I never mentioned direction, I explained that they must share the same X or Y coordinates.
Fauxfyre- Member
-
Re: Kramuals ACTUALLY explained, and why diagonal kramuals are possible
Well i think you need to first show that bosh can stay in the kramual form without needing to share X/Y coordinates. I already know it can't, but if you can show that, I concede defeat.
Re: Kramuals ACTUALLY explained, and why diagonal kramuals are possible
hmmmm. after reading both of your posts (many, many times lol) I think I understand both of you.
kevans is arguing that the only time a kramual "lock" is possible is when the X or Y values of all of the contact points are the same (meaning on the X or Y axis)
Shotoku is arguing that a kramual is possible whenever the points are exactly on the same line, whatever angle that line may be on, because it is changing the distances between the contact points.
Honestly I'm mostly inclined to go with kevans because nobody has made a diagonal kramual in several years of making X/Y kramuals. But I think shotoku's theory makes more sense to me. I buy his argument that this code is changing the distances between the contact points, and if they are all in a line this creates the kramual "lock" and as far as I can see, kevans has not refuted this. (EDIT: since I typed this you guys have been posting back and forth. Shotoku makes an excellent point that kevans's scenario actually fits shotoku's scenario, and kevans has not proven that his scenario is wrong.) But I don't think shotoku has proven it is possible for points to be exactly aligned on a diagonal line.
Question for kevans:
1) "What this function does is basically check the distance between each contact point and tries to move him back to the default distance, not position, distance." Can you explain this better? Move "him" back? "distance, not position"? Why is it moving him "back"?
2) Can you prove that either a) it is impossible for all points to be exactly aligned on a non-XY surface, b) alignment of all points on a diagonal will not cause a kramual "lock"?
Questions for shotoku.
1) Why is it not too hard to make a X or Y axis kramual but super hard to make a diagonal one?
2) Is it possible that it is not possible to have all points exactly aligned on a diagonal surface? maybe because of the limits of x/y positions using decimal numbers that would make them never mathematically precise in alignment?
3) Can you walk us through the code with actual numbers of a hypothetical points-in-alignment-on-a-diagonal with the x and y coordinates? to demonstrate?
kevans is arguing that the only time a kramual "lock" is possible is when the X or Y values of all of the contact points are the same (meaning on the X or Y axis)
Shotoku is arguing that a kramual is possible whenever the points are exactly on the same line, whatever angle that line may be on, because it is changing the distances between the contact points.
Honestly I'm mostly inclined to go with kevans because nobody has made a diagonal kramual in several years of making X/Y kramuals. But I think shotoku's theory makes more sense to me. I buy his argument that this code is changing the distances between the contact points, and if they are all in a line this creates the kramual "lock" and as far as I can see, kevans has not refuted this. (EDIT: since I typed this you guys have been posting back and forth. Shotoku makes an excellent point that kevans's scenario actually fits shotoku's scenario, and kevans has not proven that his scenario is wrong.) But I don't think shotoku has proven it is possible for points to be exactly aligned on a diagonal line.
Question for kevans:
1) "What this function does is basically check the distance between each contact point and tries to move him back to the default distance, not position, distance." Can you explain this better? Move "him" back? "distance, not position"? Why is it moving him "back"?
2) Can you prove that either a) it is impossible for all points to be exactly aligned on a non-XY surface, b) alignment of all points on a diagonal will not cause a kramual "lock"?
Questions for shotoku.
1) Why is it not too hard to make a X or Y axis kramual but super hard to make a diagonal one?
2) Is it possible that it is not possible to have all points exactly aligned on a diagonal surface? maybe because of the limits of x/y positions using decimal numbers that would make them never mathematically precise in alignment?
3) Can you walk us through the code with actual numbers of a hypothetical points-in-alignment-on-a-diagonal with the x and y coordinates? to demonstrate?
Re: Kramuals ACTUALLY explained, and why diagonal kramuals are possible
rabid squirrel wrote:Question for kevans:
1) "What this function does is basically check the distance between each contact point and tries to move him back to the default distance, not position, distance." Can you explain this better? Move "him" back? "distance, not position"? Why is it moving him "back"?
2) Can you prove that either a) it is impossible for all points to be exactly aligned on a non-XY surface, b) shotoku is interpreting the code to calculate distances between contact points wrong somehow?
1) If it was position and not distance, bosh wouldn't fall because of gravity and couldn't rotate.
2a) I never said it wasn't impossible to be aligned to a non xy line, I said it wasn't possible to stay "locked" in that position. 2b) Shotoku is thinking that angle is somewhere involved in this positioning calculation, when it's not.
Edit: Here are the three skeletal functions that bosh has
- Spoiler:
- Code:
class Stick
{
var a, b, restLength;
function Stick(_a, _b)
{
a = _a;
b = _b;
this.getRestLength();
} // End of the function
function satisfyDistance()
{
var _loc3 = a.x - b.x;
var _loc2 = a.y - b.y;
var _loc7 = Math.sqrt(_loc3 * _loc3 + _loc2 * _loc2);
var _loc6 = (_loc7 - restLength) / _loc7 * 5.000000E-001;
var _loc5 = _loc3 * _loc6;
var _loc4 = _loc2 * _loc6;
a.x = a.x - _loc5;
a.y = a.y - _loc4;
b.x = b.x + _loc5;
b.y = b.y + _loc4;
} // End of the function
function getRestLength()
{
var _loc3 = a.x - b.x;
var _loc2 = a.y - b.y;
restLength = Math.sqrt(_loc3 * _loc3 + _loc2 * _loc2);
} // End of the function
function render(target)
{
target.moveTo(a.x, a.y);
target.lineTo(b.x, b.y);
} // End of the function
} // End of Class
- Code:
class BindStick extends BreakableStick
{
var a, b, getRestLength, restLength, endurance;
static var crash;
function BindStick(_a, _b, _endurance)
{
super();
a = _a;
b = _b;
this.getRestLength();
endurance = _endurance * restLength * 5.000000E-001;
} // End of the function
function satisfyDistance()
{
var _loc3 = a.x - b.x;
var _loc2 = a.y - b.y;
var _loc7 = Math.sqrt(_loc3 * _loc3 + _loc2 * _loc2);
var _loc4 = (_loc7 - restLength) / _loc7 * 5.000000E-001;
if (_loc4 > endurance || BindStick.crash)
{
crash = true;
return (true);
} // end if
var _loc6 = _loc3 * _loc4;
var _loc5 = _loc2 * _loc4;
a.x = a.x - _loc6;
a.y = a.y - _loc5;
b.x = b.x + _loc6;
b.y = b.y + _loc5;
return (false);
} // End of the function
} // End of Class
- Code:
class RepellStick extends Stick
{
var a, b, getRestLength, restLength;
function RepellStick(_a, _b)
{
super();
a = _a;
b = _b;
this.getRestLength();
} // End of the function
function satisfyDistance()
{
var _loc3 = a.x - b.x;
var _loc2 = a.y - b.y;
var _loc4 = Math.sqrt(_loc3 * _loc3 + _loc2 * _loc2);
if (_loc4 < restLength)
{
var _loc7 = (_loc4 - restLength) / _loc4 * 5.000000E-001;
var _loc6 = _loc3 * _loc7;
var _loc5 = _loc2 * _loc7;
a.x = a.x - _loc6;
a.y = a.y - _loc5;
b.x = b.x + _loc6;
b.y = b.y + _loc5;
} // end if
} // End of the function
} // End of Class
Re: Kramuals ACTUALLY explained, and why diagonal kramuals are possible
You didn't answer these.rabid squirrel wrote:Move "him" back? Why is it moving him "back"?
I edited my post, didn'ty quite catch you in time:[senpai] kevans wrote:I never said it wasn't impossible to be aligned to a non xy line, I said it wasn't possible to stay "locked" in that position.
like, more concretely than pointing at the zeroes and saying it's the only way?Can you prove that... b) alignment of all points on a diagonal will not cause a kramual "lock"?
not sure you totally understand shotoku's reasoning here. shotoku is only talking about changing distances between points when the angle happens to be the same (which is also true in your scenario as well as his)[senpai] kevans wrote:2b) Shotoku is thinking that angle is somewhere involved in this positioning calculation, when it's not.
EDIT: actually, can either of you walk us through the code with hypothetical values?
Re: Kramuals ACTUALLY explained, and why diagonal kramuals are possible
rabid squirrel wrote:You didn't answer these.rabid squirrel wrote:Move "him" back? Why is it moving him "back"?
Because if he wasn't "moved back", he wouldn't retain shape.
I edited my post, didn'ty quite catch you in time:[senpai] kevans wrote:I never said it wasn't impossible to be aligned to a non xy line, I said it wasn't possible to stay "locked" in that position.like, more concretely than pointing at the zeroes and saying it's the only way?Can you prove that... b) alignment of all points on a diagonal will not cause a kramual "lock"?
Yes, I can.
- math stuff:
First, lets assume in this first frame, point A is at (5, 10), and point B is at (7, 14). And we'll assume _loc6 is 5. (reason why we do this is because that number is different for every connection)
This function here:- Code:
function satisfyDistance()
function satisfyDistance()
{
var _loc3 = a.x - b.x;
var _loc2 = a.y - b.y;
var _loc7 = Math.sqrt(_loc3 * _loc3 + _loc2 * _loc2);
var _loc6 = (_loc7 - restLength) / _loc7 * 5.000000E-001;
var _loc5 = _loc3 * _loc6;
var _loc4 = _loc2 * _loc6;
a.x = a.x - _loc5;
a.y = a.y - _loc4;
b.x = b.x + _loc5;
b.y = b.y + _loc4;
} // End of the function
Becomes:- Code:
function satisfyDistance()
{
var _loc3 = 5 - 7;
var _loc2 = 10 - 14;
var _loc6 = 5;
var _loc5 = -2 * 5;
var _loc4 = -4 * 5;
a.x = 5 - (-10);
a.y = 10 - (-20);
b.x = 7 + (-10);
b.y = 14 + (-20);
} // End of the function
At the end of the function, point A goes from (5, 10) to (15, 30), and point B goes from (7, 14) to (-3, -4). You can keep doing this indefinitely and it'll keep adjusting itself until both points are 5 (_loc6) pixels apart
Now lets do the same steps, but lets assume that A is (5, 14) and B is (5, 10).- Code:
function satisfyDistance()
{
var _loc3 = 5 - 5;
var _loc2 = 14 - 10;
var _loc6 = 5;
var _loc5 = 0 * 5;
var _loc4 = 4 * 5;
a.x = 5 - (0);
a.y = 14 - (20);
b.x = 5 + (0);
b.y = 10 + (20);
} // End of the function
After one iteration, point A will be (5, -6), and B shall be (5, 30). Notice something? They still have the same X coordinate! And they will for as long as those two have the same points each time. Same can happen with the Y coordinates as well. This is why a kramual at an angle will not lock.
not sure you totally understand shotoku's reasoning here. shotoku is only talking about changing distances between points when the angle happens to be the same (which is also true in your scenario as well as his)[senpai] kevans wrote:2b) Shotoku is thinking that angle is somewhere involved in this positioning calculation, when it's not.
I just showed it's not the changing distance and angles, it's shared coordinates.
Re: Kramuals ACTUALLY explained, and why diagonal kramuals are possible
As far as I can see kevans just proved it.
EDIT: unless shotoku can do the same thing with the actual numbers
EDIT: unless shotoku can do the same thing with the actual numbers
Re: Kramuals ACTUALLY explained, and why diagonal kramuals are possible
I'm going to answer Rabid's questions in opposite order here:
3) Can you walk us through the code with actual numbers of a hypothetical points-in-alignment-on-a-diagonal with the x and y coordinates? to demonstrate?
I will go one round of this process to show that angle does not change during adjustments:
Given the simplest possible situation, we know we can have 1 points at (1,1), (2,2), and (3,3) that are all inline. In a only slightly complicated situation, we can have (4.2, -7.6), (5.2, -6.6), and (6.2, -5.6) that are also in line on a 45 degree slope. Also, given the proven fact that we can get all of them to align on a vertical or horizontal axis, I don't think the fact that we are dealing with extremely precise fractional values is changing anything, especially considering when we are landing Bosh on a LINE SEGMENT to squish his points together.
1) Why is it not too hard to make a X or Y axis kramual but super hard to make a diagonal one?
I honestly cannot fathom why. I spent a good hour trying to get a diagonal kramual to work in multiple situations, and while I could get an X one easily, I can't get Bosh to live longer than a frame in a diagonal one. If I try to think of anything wrong with my hypothesis, then I find several other situations that suggest I am right. I am going to ponder this particular question more.
If you look very closely at both of our theories, you will notice that we are essentially going for the same thing, it's just Kevans is trying to use his to prove that diagonals are not possible, while I am trying to prove that they are possible with the same evidence. I think it is only fair if I am going to try to furnish additional proof that they can be done, that you try to furnish proof to me that they can't, more than the words that both of us are throwing around.
3) Can you walk us through the code with actual numbers of a hypothetical points-in-alignment-on-a-diagonal with the x and y coordinates? to demonstrate?
I will go one round of this process to show that angle does not change during adjustments:
- Spoiler:
- In the simplest 45 degree situation, where x=y, we have 2 connected points making a segment
Coordinates (1,1) & (2,2)
Slope formula = (y2-y1)/(x2-x1)
Slope of the segment is 1/1 or 1
function satisfyDistance()
{
var _loc3 = a.x - b.x;
var _loc2 = a.y - b.y;
var _loc7 = Math.sqrt(_loc3 * _loc3 + _loc2 * _loc2);
var _loc6 = (_loc7 - restLength) / _loc7 * 5.000000E-001;
var _loc5 = _loc3 * _loc6;
var _loc4 = _loc2 * _loc6;
a.x = a.x - _loc5;
a.y = a.y - _loc4;
b.x = b.x + _loc5;
b.y = b.y + _loc4;
} // End of the function
becomes (restlengths will arbitrarily be 3.5)
loc3 = 1 - 2 = -1
loc2 = 1 - 2 = -1
loc7 = sqrt(-1 * -1 + -1 * -1) = ~1.41
loc6 = (1.41 - 3.5) / 1.41 * .5 = ~-2.96
loc5 = -2.96 * -1 = 2.96
loc6 = -2.96 * -1 = 2.96
1 - 2.96 = -1.96 = a.x
1 - 2.96 = -1.96 = a.y
1 + 2.96 = 3.96 = b.x
1 + 2.96 = 3.96 = b.y
Slope formula is (3.96-(-1.96))/(3.96-(-1.96)) or 1/1 or 1
Given the simplest possible situation, we know we can have 1 points at (1,1), (2,2), and (3,3) that are all inline. In a only slightly complicated situation, we can have (4.2, -7.6), (5.2, -6.6), and (6.2, -5.6) that are also in line on a 45 degree slope. Also, given the proven fact that we can get all of them to align on a vertical or horizontal axis, I don't think the fact that we are dealing with extremely precise fractional values is changing anything, especially considering when we are landing Bosh on a LINE SEGMENT to squish his points together.
1) Why is it not too hard to make a X or Y axis kramual but super hard to make a diagonal one?
I honestly cannot fathom why. I spent a good hour trying to get a diagonal kramual to work in multiple situations, and while I could get an X one easily, I can't get Bosh to live longer than a frame in a diagonal one. If I try to think of anything wrong with my hypothesis, then I find several other situations that suggest I am right. I am going to ponder this particular question more.
If you look very closely at both of our theories, you will notice that we are essentially going for the same thing, it's just Kevans is trying to use his to prove that diagonals are not possible, while I am trying to prove that they are possible with the same evidence. I think it is only fair if I am going to try to furnish additional proof that they can be done, that you try to furnish proof to me that they can't, more than the words that both of us are throwing around.
Fauxfyre- Member
-
Re: Kramuals ACTUALLY explained, and why diagonal kramuals are possible
that in this you can see that the the angle didn't actually change, so shotoku's postulate actually holds here. (and thus his conclusion that diagonal kramuals are possible in theory)kevan wrote:At the end of the function, point A goes from (5, 10) to (15, 30), and point B goes from (7, 14) to (-3, -4). You can keep doing this indefinitely and it'll keep adjusting itself until both points are 5 (_loc6) pixels apart
and then I saw that shotoku posted that exact thing.
So I was wrong, shotoku actually seems to be right here. again, as far as I can see. (and only in theory at this point)
Shotoku, have you tried monitoring the values step by step in some kind of debug process while trying to make a diagonal kramual? My thought is we can see the actual variables then, and see if anyone them should make a diagonal kramual - and if not, why it's impossible to get them into diagonal kramual position.
One way we could resolve this is actually simulate this situation and literally force all of the contact points into shotoku's scenario in actual code and then see how bosh behaves. Shotoku, any thoughts about doing that?
I feel like there must be a reason that diagonal kramuals are seemingly impossible (otherwise I'm sure they would have been discovered years ago) but I think shotoku is right here in his theory (aka I don't think kevans has effectively proved him wrong even though I thought he did for a couple hours lol)
EDIT: Damn it, wait.
did that change the angle? now I think it did. ugh I need sleep. I will look at this later.kevan wrote:point A goes from (5, 10) to (15, 30), and point B goes from (7, 14) to (-3, -4)
also
:15 AM shotoku ban: maybe, just maybe, it has to do with the actual collision with the line
2:17 AM shotoku ban: I can get Bosh and the sled to go into kramual positions separately
2:18 AM shotoku ban: but not while staying together with the sled
2:18 AM rabidsquirrel mod: Ohhh hmmmm
2:19 AM shotoku ban: In a regular kramual, if you delete the line that Bosh's on, he stays in position
2:19 AM shotoku ban: but if you delete them while in diagonal separated, they pop out of alignment
Re: Kramuals ACTUALLY explained, and why diagonal kramuals are possible
You're forgetting shotoku, bosh isn't made up of two contact points. He's made up of ten. But for this example, I only need three.
I don't need to show any math here for this one, it just needs an explanation. Bosh doesn't just have 2 points, he has ten, and he doesn't just have one "stick", he has 22 "edges" ranging from stick, bindstick, and repellstick. And each "satisfydistance" function is checked one by one on bosh six time each frame, and in between each distance check, a collision check occurs. Now, say hello to the culprit:
The only two repellstick binds. Now, what's so special about them? They behave differently:
In shotoku's example, the points will move, and they will change in relationship to every other point. The problem occurs with the fact that _loc4 has to be a certain distance in order to cause point movement. This is why that lock is important. At the end of each "edge check", a collision check occurs. This means that while edges 21 and 22 are too far apart to change points location, they will follow a different set of rules after colliding with a line. For a visual aid:
(It's a bit of an exaggerated example) The instance that happens, that nice 45 degree plane will go away. This is why that XY lock is important, because when it collides with a line, whichever coordinate is locked will cause the same output of movement, meaning the fact that those repellstick binds won't be activated are irrelevant, it has other binds keeping them inside that lock at all times. More specifically, the shoulder (riderAnchor[5]) and both feet (riderAnchor[8]/riderAnchor[9]) contact points has multiple connections keeping it in place. For added visual, here's the full snippet of edges:
Shotoku wrote:You were on the right track, but didn't take into consideration the big picture.
I don't need to show any math here for this one, it just needs an explanation. Bosh doesn't just have 2 points, he has ten, and he doesn't just have one "stick", he has 22 "edges" ranging from stick, bindstick, and repellstick. And each "satisfydistance" function is checked one by one on bosh six time each frame, and in between each distance check, a collision check occurs. Now, say hello to the culprit:
- Code:
edges[21] = new RepellStick(riderAnchors[5], riderAnchors[8]);
edges[22] = new RepellStick(riderAnchors[5], riderAnchors[9]);
The only two repellstick binds. Now, what's so special about them? They behave differently:
- Code:
function satisfyDistance()
{
var _loc3 = a.x - b.x;
var _loc2 = a.y - b.y;
var _loc4 = Math.sqrt(_loc3 * _loc3 + _loc2 * _loc2);
if (_loc4 < restLength)
{
var _loc7 = (_loc4 - restLength) / _loc4 * 5.000000E-001;
var _loc6 = _loc3 * _loc7;
var _loc5 = _loc2 * _loc7;
a.x = a.x - _loc6;
a.y = a.y - _loc5;
b.x = b.x + _loc6;
b.y = b.y + _loc5;
} // end if
} // End of the function
In shotoku's example, the points will move, and they will change in relationship to every other point. The problem occurs with the fact that _loc4 has to be a certain distance in order to cause point movement. This is why that lock is important. At the end of each "edge check", a collision check occurs. This means that while edges 21 and 22 are too far apart to change points location, they will follow a different set of rules after colliding with a line. For a visual aid:
(It's a bit of an exaggerated example) The instance that happens, that nice 45 degree plane will go away. This is why that XY lock is important, because when it collides with a line, whichever coordinate is locked will cause the same output of movement, meaning the fact that those repellstick binds won't be activated are irrelevant, it has other binds keeping them inside that lock at all times. More specifically, the shoulder (riderAnchor[5]) and both feet (riderAnchor[8]/riderAnchor[9]) contact points has multiple connections keeping it in place. For added visual, here's the full snippet of edges:
- Code:
edges[0] = new Stick(riderAnchors[0], riderAnchors[1]);
edges[1] = new Stick(riderAnchors[1], riderAnchors[2]);
edges[2] = new Stick(riderAnchors[2], riderAnchors[3]);
edges[3] = new Stick(riderAnchors[3], riderAnchors[0]);
edges[4] = new Stick(riderAnchors[0], riderAnchors[2]);
edges[5] = new Stick(riderAnchors[3], riderAnchors[1]);
edges[6] = new BindStick(riderAnchors[0], riderAnchors[4], ENDURANCE);
edges[8] = new BindStick(riderAnchors[1], riderAnchors[4], ENDURANCE);
edges[9] = new BindStick(riderAnchors[2], riderAnchors[4], ENDURANCE);
edges[10] = new Stick(riderAnchors[5], riderAnchors[4]);
edges[11] = new Stick(riderAnchors[5], riderAnchors[6]);
edges[12] = new Stick(riderAnchors[5], riderAnchors[7]);
edges[13] = new Stick(riderAnchors[4], riderAnchors[8]);
edges[14] = new Stick(riderAnchors[4], riderAnchors[9]);
edges[15] = new Stick(riderAnchors[5], riderAnchors[7]);
edges[16] = new BindStick(riderAnchors[5], riderAnchors[0], ENDURANCE);
edges[17] = new BindStick(riderAnchors[3], riderAnchors[6], ENDURANCE);
edges[18] = new BindStick(riderAnchors[3], riderAnchors[7], ENDURANCE);
edges[19] = new BindStick(riderAnchors[8], riderAnchors[2], ENDURANCE);
edges[20] = new BindStick(riderAnchors[9], riderAnchors[2], ENDURANCE);
edges[21] = new RepellStick(riderAnchors[5], riderAnchors[8]);
edges[22] = new RepellStick(riderAnchors[5], riderAnchors[9]);
Re: Kramuals ACTUALLY explained, and why diagonal kramuals are possible
At some point it comes down to this: It hasn't been done, ever. When I think about how crazy quirk has gotten these days, I do think that if one of our members hasn't be able to figure it out yet, it won't happen. Keep hacking, friends.
Inukaza- Member
Re: Kramuals ACTUALLY explained, and why diagonal kramuals are possible
Kevans, I believe you can literally hardcode bosh's starting position to be in kramual position by forcefully setting the positions of the contact points after initialization. First, attempt to hardcode a horizontal kramual. And then try rotating all the points by 45°.
Conundrumer- Line Rider Legend
- actually working on OII
Re: Kramuals ACTUALLY explained, and why diagonal kramuals are possible
^I literally had this idea last night. So glad somebody else did.
ScrungleBlumpkus- Member
- Interior Crocodile Alligator
Re: Kramuals ACTUALLY explained, and why diagonal kramuals are possible
I think I'm with kevans here, unless someone can do this:
and simulate a 45degree kramual and show that it actually works. Or that it doesn't, which would sort of seal the deal.Conundrumer wrote:Kevans, I believe you can literally hardcode bosh's starting position to be in kramual position by forcefully setting the positions of the contact points after initialization. First, attempt to hardcode a horizontal kramual. And then try rotating all the points by 45°.
Re: Kramuals ACTUALLY explained, and why diagonal kramuals are possible
rabid squirrel wrote:I think I'm with kevans here, unless someone can do this:and simulate a 45degree kramual and show that it actually works. Or that it doesn't, which would sort of seal the deal.Conundrumer wrote:Kevans, I believe you can literally hardcode bosh's starting position to be in kramual position by forcefully setting the positions of the contact points after initialization. First, attempt to hardcode a horizontal kramual. And then try rotating all the points by 45°.
Gonna bump this with this:
https://iridethelines.forumotion.com/t8840-omg-finally#162480
ScrungleBlumpkus- Member
- Interior Crocodile Alligator
Re: Kramuals ACTUALLY explained, and why diagonal kramuals are possible
he doesn't stay in position for longer than a frame though, kevans insists it's just a wtf well
Re: Kramuals ACTUALLY explained, and why diagonal kramuals are possible
yeah, just a coincidental wtf well, ive gotten a few like that myself
Chuggers- Member
- villainous quirker
Re: Kramuals ACTUALLY explained, and why diagonal kramuals are possible
Would it not count as a kramual though
Now there needs to be a time based definintion.
I'm all for kevan's arguemnt, honestly. His reasonig is sound. However, we can still be wrong and until I see something hardcoded...
Now there needs to be a time based definintion.
I'm all for kevan's arguemnt, honestly. His reasonig is sound. However, we can still be wrong and until I see something hardcoded...
ScrungleBlumpkus- Member
- Interior Crocodile Alligator
Re: Kramuals ACTUALLY explained, and why diagonal kramuals are possible
Dapianokid wrote:
Now there needs to be a time based definintion.
Well if you've noticed, we already do. We've already dubbed kramuals that last for one frame as "Single Frame". So by this reasoning, a "kramual" would be where he's able to hold this position indefinitely.
As for what Kramwoods has here, if he's willing to share the sol, I'd be willing to do the deep digging to see how "aligned" the contact points are.
Re: Kramuals ACTUALLY explained, and why diagonal kramuals are possible
[senpai] kevans wrote:Dapianokid wrote:
Now there needs to be a time based definintion.
Well if you've noticed, we already do. We've already dubbed kramuals that last for one frame as "Single Frame". So by this reasoning, a "kramual" would be where he's able to hold this position indefinitely.
As for what Kramwoods has here, if he's willing to share the sol, I'd be willing to do the deep digging to see how "aligned" the contact points are.
Truuust me, he has the technology to do so! I'm really hard pressed to explain this, but here are from me which don't make sense so screw me
- lol:
- If the points must end up such that 0 is somewhere along the line added to the coordinates of a point on an x or y axis, then the only mathematical alternative that allows for 45 degree kramuals is a situation where miraculously, every single addition performed in the routines for all 10 points all 6 times in a frame, adds exactly the same arbitrary amount in either the x or y axis, or if this happens such that the sums end up resulting in another perfectly 45 degree frame should he be moving horizontally or vertically.
The engine allows this to be perfectly possible mathematically, but the system by which we obtain physical situational simulations forbids it because of simple physics. We cannot (without control-enhancement focused editor modding) reset his x or y velocity and simultaneously all his points to exist in both axes for more than one frame. This is because the numbers dealt with are too precise to get such a miraculous occurrence, and also because we can't control his velocity in only one direction due to the limitations on the environment. XY kramuals allow this to happen and control because one axis is removed from relevance and thus we have enough control. logically, one would assume this to be possible in 45. yes. it is. but there is no path to take us there following the rules and restrictions imposed by the game. odd numbers exist. but if you asked me to arrive at one by starting with an even and only add multiples of that even number or any even number, no matter how much exploring or how far we went, we'd never obtain an odd one. Some people reason that must be because odd numbers don't exist, despite plain evidence that they do. others can see that it is simply a matter of limits in the system. By that same reasoning, if you always had that system, it would seem crazy for one to suggest odd numbers can exist. 45 and all other angles can exist. We can't make them though.
ScrungleBlumpkus- Member
- Interior Crocodile Alligator
Page 1 of 3 • 1, 2, 3
Page 1 of 3
Permissions in this forum:
You cannot reply to topics in this forum
|
|
Mon Mar 18, 2024 11:03 am by alpha leonis
» bubblegum - Pure5152
Thu Nov 23, 2023 4:36 am by Rafael
» Started in 2020 - thoughts?
Mon Jul 24, 2023 1:21 pm by cvang
» Hypersonic Motion - Preview and explanation
Mon Jul 24, 2023 12:15 pm by alpha leonis
» Track question
Mon Jul 24, 2023 12:14 pm by alpha leonis
» Line Rider Pointy Wobbly Italian Rat ~ Leonis
Mon Jul 24, 2023 12:12 pm by alpha leonis
» Line Rider Prism ~ Leonis
Mon Jul 24, 2023 12:11 pm by alpha leonis
» Playtime - pure5152
Tue May 16, 2023 4:05 pm by Sheldon
» I coded today!
Mon Mar 20, 2023 6:53 am by jimmysanders