Line order does not affect physics.
+8
ACwazHere
rabid squirrel
Danthedragonman
Conundrumer
roflmaoqwerty
Pawel3
Sheldon
[senpai] kevans
12 posters
Page 1 of 1
Line order does not affect physics.
I've noticed that people here believe that line order will affect the out come of a track. This is not true one bit.
First, I will show you the only times where line order is actually important;
This one is a loop that will store each line within a list to be saved. for (var_loc7 in lines) is basically saying "For every time a line is counted, add 1 to _loc7".
That little snipet sets up that progressive loading we see. segmentsRemainingToLoad is the total line count so it knows when to quit loading when that number hits 0;
Nowhere else within the code is line order mentioned, so obviously the problem lies somewhere else. The redo function.
No... I don't see where you drew that conclusion from, albeit they are plagued by the redo bug, but I don't see where stacking had anything to do with it.
For any reason, I'm willing to discuss anything you don't quite understand or have concerns for, and I believe there will be people asking.
It's true that this issue does happen and it may look like it has something to do with when it was drawn, and I can easily see that connection. But like many things proven to be false and/or revealed, things aren't always what they look like... Let's see some examples:Anonymous wrote:But it does affect the out come. I'll erase an earlier line on accident, then shift-backspace, and the track does not work anymore!
First, I will show you the only times where line order is actually important;
- Code:
_loc1 = lines[undoList.pop()];
- Code:
if (redoList[lineToUndo][0] != undefined)
{
addLine(_loc1);
} // end if
if (redoLineList.length == 1)
{
redoLineList[0] = undefined;
} // end if
redoLineList.shift();
- Code:
for (var _loc7 in lines)
{
var _loc1 = lines[_loc7];
_loc4[_loc3] = [_loc1.x1, _loc1.y1, _loc1.x2, _loc1.y2, _loc1.lim, Number(_loc1.inv), _loc1.prevLine, _loc1.nextLine, _loc1.name, _loc1.type];
++_loc3;
} // end of for...in
This one is a loop that will store each line within a list to be saved. for (var_loc7 in lines) is basically saying "For every time a line is counted, add 1 to _loc7".
- Code:
var _loc1 = buffer[segmentsRemainingToLoad - 1];
--segmentsRemainingToLoad
That little snipet sets up that progressive loading we see. segmentsRemainingToLoad is the total line count so it knows when to quit loading when that number hits 0;
Nowhere else within the code is line order mentioned, so obviously the problem lies somewhere else. The redo function.
Anonymous wrote:But doesn't stacks that are required influenced by order?
No... I don't see where you drew that conclusion from, albeit they are plagued by the redo bug, but I don't see where stacking had anything to do with it.
For any reason, I'm willing to discuss anything you don't quite understand or have concerns for, and I believe there will be people asking.
Re: Line order does not affect physics.
He's right no room for argument. I work with stacks essentially everyday, or every time I open line rider. This is true. Stacks are not affected by order, otherwise the meticulously complex trick that is a stack would be altered or unbalanced every time I tried to redo a line, but this is not the case. It only happens part of the time due to a bug. If order was part of the mix it would kill him almost every time.
Last edited by Sheldon on Mon Jun 03, 2013 1:53 pm; edited 2 times in total
Re: Line order does not affect physics.
but when you delete a line from a namual and draw it back there it does
Pawel3- Member
Re: Line order does not affect physics.
Pawel3 wrote:but when you delete a line from a namual and draw it back there it does
Redoing lines and line order are completely different. The manual problem deals with an error in snapping when redoing lines, iirc.Kevansevans wrote:...obviously the problem lies somewhere else. The redo function.
Kevans, thank you very much for this informative post. I now understand the mechanics behind line order, and appreciate that you've cleared up this area of confusion so well for so many of us.
Re: Line order does not affect physics.
Okay that makes a lot more sense.roflmaoqwerty wrote:The manual problem deals with an error in snapping when redoing lines, iirc.
Conundrumer- Line Rider Legend
- actually working on OII
Re: Line order does not affect physics.
What button is the undo button like what do I press for it
Danthedragonman- Member
Re: Line order does not affect physics.
Yes, the problem is with the redo function and has something to do with snapping. (not with line order as I thought months ago, I believe Rafael was the one who theorized that)
If you draw a line without snapping involves, shift+backspace works just fine even with long section of track after that line. Sempiternal, by MBF, proves that because shift+delete is required to make a recording of the track - if you play it straight he crashes, you delete two lines and then he crashes later, but if you mark a flag between the two places and shift+delete and then stitch the recordings the whole thing plays. But if the line was snapped when drawn, regardless of whether the line it originally snapped to exists or not, THEN shift+backspace fails. Hence it basically always fails with manuals. I could be wrong about this but I think this is the issue.
If you draw a line without snapping involves, shift+backspace works just fine even with long section of track after that line. Sempiternal, by MBF, proves that because shift+delete is required to make a recording of the track - if you play it straight he crashes, you delete two lines and then he crashes later, but if you mark a flag between the two places and shift+delete and then stitch the recordings the whole thing plays. But if the line was snapped when drawn, regardless of whether the line it originally snapped to exists or not, THEN shift+backspace fails. Hence it basically always fails with manuals. I could be wrong about this but I think this is the issue.
Re: Line order does not affect physics.
Thanks for explaining it clearly. No offense but you were doing a crappy job explaining it in the shoutbox (from what I had seen), which is why people were getting annoyed, etc. =p This totally makes sense though.
ACwazHere- Member
- fuck around and get dunked on
Re: Line order does not affect physics.
Danthetubaman wrote:What button is the undo button like what do I press for it
Pressing backspace will undo the line, and while holding shift when pressing backspace will redo the line erased/undone.
EDIT:
ACwazHere wrote:Thanks for explaining it clearly. No offense but you were doing a crappy job explaining it in the shoutbox (from what I had seen), which is why people were getting annoyed, etc. =p This totally makes sense though.
Lawl, all I said was that line order wasn't part of the physics function, what was so hard about that?
roflmaoqwerty wrote:The manual problem deals with an error in snapping when redoing lines, iirc.
rabid squirrel wrote:Yes, the problem is with the redo function and has something to do with snapping. (not with line order as I thought months ago, I believe Rafael was the one who theorized that)
As evidence does point towards that, I don't think it's snapping (that doesn't mean it's out of the question) because I've encountered a few times where a well being redone caused the track to act differently, when it wasn't even snapped in the first place. Oh well, we may never know [shrugs].
Re: Line order does not affect physics.
If you can find a solution to this problem (well, redo), I will respect you infinitely.
LineMagiX- Member
- The ghost of LR
Re: Line order does not affect physics.
I would theorize that that line is not currently snapped to anything, but it snapped to something when it was drawn and the line it snapped to was later erased. Just my guess though.kevansevans wrote:As evidence does point towards that, I don't think it's snapping (that doesn't mean it's out of the question) because I've encountered a few times where a well being redone caused the track to act differently, when it wasn't even snapped in the first place. Oh well, we may never know [shrugs].
Re: Line order does not affect physics.
Well it really depends on how lines are saved. I'm guessing they have coordinates for the two points at the extremeties?
Re: Line order does not affect physics.
Not always, but most of the time. Sometimes it won't work anyway. It's like when you draw a manual and delete a line from the manual. If you use the two lines as snap points, it may not work anyway.Kramwood wrote:didn't read the whole thread, but if you just redraw the line by making 2 smaller lines around it erase the initial line and then snap it to the two smaller lines it will work again. Idk why the redo action does this. The lines in the right spot just for some reason it needs to be redrawn in order for It to work again. Ill see if I can make a vid later demonstrating this.
hypothet- Member
- don't read this
Re: Line order does not affect physics.
Line order is in fact absolutely fundamental to the determinism of the physics engine. During collision detection the order of collisions HAS to be kept the same otherwise you will definitely get different outcomes. I hit this problem numerous times while implementing collisions in Unleashed, where tracks I made with one version of the engine were breaking with another because I wasn't performing collisions in draw order.
I took a quick look at my flash source to confirm that a redone line is treated as a newly drawn line. That is to say, if I were to draw two lines and erase the first, a redo does the same thing as drawing a new line in the same spot as the first, not bringing the first line back.
Plus, as we all know redo wreaks havoc with the snapping mechanics. Honestly, the redo in the flash versions is so broken I can't see it being useful in any way. Fortunately I've solved all of these problems with the redo in Unleashed.
I took a quick look at my flash source to confirm that a redone line is treated as a newly drawn line. That is to say, if I were to draw two lines and erase the first, a redo does the same thing as drawing a new line in the same spot as the first, not bringing the first line back.
Plus, as we all know redo wreaks havoc with the snapping mechanics. Honestly, the redo in the flash versions is so broken I can't see it being useful in any way. Fortunately I've solved all of these problems with the redo in Unleashed.
Re: Line order does not affect physics.
mhenr18 wrote:Line order is in fact absolutely fundamental to the determinism of the physics engine. During collision detection the order of collisions HAS to be kept the same otherwise you will definitely get different outcomes. I hit this problem numerous times while implementing collisions in Unleashed, where tracks I made with one version of the engine were breaking with another because I wasn't performing collisions in draw order.
I don't think we're on the same page here. I was referring to how people believe that like line 232 will make bosh travel 2 pixels farther, as opposed to line 89, just because it's line 232, despite having the exact same dimensions.
I understand that line order will let the physics know how to react to the lines, IE he touches line 25 in this spot, make the point do this. But it wont add anything different just because it's line 25.
(those numbers we just examples)
Re: Line order does not affect physics.
Say you have two lines, 1 and 2. Line 1 is below line 2 and they pull Bosh up in a stack. Line 1 will pull Bosh up, then 2 will pull him up some more, all in a single frame.
If you remove line 1 and redraw it in the exact same position, it's now line 3. Line 2 will now collide with bosh *before* line 3 does, so the final effect on bosh is going to be different, because when bosh collides with line 2 he's in a different position. So the effect is only noticeable when there's multiple lines interacting with Bosh in a single frame, but it's definitely there.
If you remove line 1 and redraw it in the exact same position, it's now line 3. Line 2 will now collide with bosh *before* line 3 does, so the final effect on bosh is going to be different, because when bosh collides with line 2 he's in a different position. So the effect is only noticeable when there's multiple lines interacting with Bosh in a single frame, but it's definitely there.
Re: Line order does not affect physics.
That is definitely true.mhenr18 wrote:Say you have two lines, 1 and 2. Line 1 is below line 2 and they pull Bosh up in a stack. Line 1 will pull Bosh up, then 2 will pull him up some more, all in a single frame.
If you remove line 1 and redraw it in the exact same position, it's now line 3. Line 2 will now collide with bosh *before* line 3 does, so the final effect on bosh is going to be different, because when bosh collides with line 2 he's in a different position. So the effect is only noticeable when there's multiple lines interacting with Bosh in a single frame, but it's definitely there.
Similar topics
» Professional Riders Order Clan! (P.R.O.)
» physics?
» Why the physics have issues.
» What is quirk physics?
» Physics regarding endurance
» physics?
» Why the physics have issues.
» What is quirk physics?
» Physics regarding endurance
Page 1 of 1
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