new mod: common.startangle

[o7Moon]

contains the angle the rider's starting positions are rotated by.

TODO: make this rotation well-defined so an implementation other than .com can do it and get the same floating point result.

[Malizma333]

.com just stores angle as a double floating point precision number, in degrees. Positive rotation causes the rider to be rotated clockwise about the tail.

[o7Moon]

.com just stores angle as a double floating point precision number, in degrees. Positive rotation causes the rider to be rotated clockwise about the tail.

i suppose i'll have to experiment with it in LRO at some point and write down exactly what a matching implementation does.

it can be very specific, like how start offset affects bone length - its not really documented afaik, which could break physics on implementations that don't know this detail and assume the bone lengths are constants. i would assume the same is true for rotation (that the slight differences in rounding at different angles make bone lengths slightly different)

[Malizma333]

@o7Moon I have confirmed that, at least in .com's implementation, start offset and rotation do not affect bone length, and are only applied to contact points after all of the bone lengths have been calculated

[Malizma333]

but i guess it doesn't matter since implementations have to emulate javascript's Math.sin and Math.cos functions to position the contact points exactly the same

[o7Moon]

I have confirmed that, at least in .com's implementation, start offset and rotation do not affect bone length, and are only applied to contact points after all of the bone lengths have been calculated

hm this confuses me, in both flash and LRA the offset seems to have an effect on rest length (the points are moved, and then rest length becomes the distance between the points at their new positions rather than the default ones at 0,0 so its affected by float rounding and not constant if start offset changes).
i would expect this is also the case in .com because it'd otherwise cause a desync on tracks that don't start at 0,0 (like alt-key's part in fakie park, which was made in .com and rendered in LRO perfectly fine)

but i guess it doesn't matter since implementations have to emulate javascript's Math.sin and Math.cos functions to position the contact points exactly the same

this sounds like a headache especially if those differ in behavior between js engines, maybe common.startangle should include some well defined trig functions in its spec too? it might differ from .com, and .com tracks might have to have a separate mod to specify that they use the js rotating instead of the one in the spec, but it'd be clearer to make a matching implementation.

[Malizma333]

(the points are moved, and then rest length becomes the distance between the points at their new positions rather than the default ones at 0,0 so its affected by float rounding and not constant if start offset changes).

would the start offset affect bone constraint lengths at all? it seems like the differences in the relative positions of points would have the same effect regardless of their start position.

it might differ from .com, and .com tracks might have to have a separate mod to specify that they use the js rotating instead of the one in the spec, but it'd be clearer to make a matching implementation.

i like this solution yeah. this also might be a problem in how .com calculates scarf flutter (more trig functions) if a mod specifies that, and potentially other places i haven't found. maybe a more global track property/feature could be set to specify the trig functions used overall to future proof it?

at the same time though it could be really easy to write to lrb without setting that flag properly, and implementations wouldn't know at all that the native sin or cos for that specific language was used.

[o7Moon]

would the start offset affect bone constraint lengths at all? it seems like the differences in the relative positions of points would have the same effect regardless of their start position.

because of floating point when the initial contact point positions have the offset added to them they don't all get the same rounding. but im actually questioning rn if this is flash behavior or not, need to check.

(edit: i have not checked flash yet, but a flash track required this behaviour to be removed from LRA to run properly in LRA so i believe this is a bug?)