Scriptor lost constants

[Jools]

My scriptor lost its linear and angular constants, and I'm now trying to recreate them. I found from some old thread in this forum the values:

linear: 65536.000000
angular: 182.000000

However, these seem to not be completely correct. For example, if I decompile some old cob and compare the bos ones from the decompiled and one subversioned, I get the following differences:

move mmakercore to y-axis [39.500000] speed [34.750000];
turn mmakercore to y-axis <-90.000000> speed <37.697802>;

turn lid2 to x-axis <30.3901> speed <38.5934>;

move mmakercore to y-axis [39.5000] speed [34.7500];
turn mmakercore to y-axis <-90.0000> speed <37.6923>;

turn lid2 to x-axis <30.395604> speed <38.598901>;

You see they are almost same but not quite. If I compile the wrong one the metal maker opens too high, leaving a gap in the unit. How does that constant work, I mean how can two zeros after the decimal affect the value? And any way to deduce the original constants from decompiled differences?

[Beherith]

Just a guess, but Scriptor may be using the default TA constants for decompilation, and using the user-supplied ones for compilation?

[smoth]

Scriptor has a lot of issues I would not be suprised if this was among them. Iirc don't we have a site to convert the scripts to luas? Why not use it and then this would be a non issue?

[Jools]

I think I solved the issue, I think it was just that I had different floating point precission [sic] compared to the ones in svn. It appears you should use 6 digits.

[bobthedinosaur]

So how do the TA ones compare again to the spring scriptor units?

[zwzsg]

In the TA world a linear constant of 163840 is traditionnaly used, because it is what used the Cavedog .bos leftover in totala1.hpi. It doesn't correspond to anything else much (that's 2.5 pixel on screen), but has been used as a convention for TA bos and TA 3do editors.

In the Spring world, a linear constant of 65536 is more common used, because it makes it more consistent with the rest of Spring's length units (what Smoth calls elmo, what I call "pixels" because it's the length of one pixel in the map texture).

Both for Spring and TA we use an angular constant of 182, so as to write angles in degree.

You see they are almost same but not quite.

Constants are merely for the syntaxing sugars of [ ] and < >.

That is, everytime you write:
[42]
it is replaced by:
(42)*LINEAR_CONSTANT
(and floored to nearest integer)

Everytime you write:
<42>
it is replaced by:
(42)*ANGULAR_CONSTANT
(and floored to nearest integer)

Internally, and in the compiled COB, there are no such constant, distances are expressed in 1/2^16 of a pixel, and angles are expressed in 1/2^8 of full turn.
Or if you prefer, X and Y are both four bytes, with the higher two the number of pixels from map corner(1), and the lower two within-pixel position. While angles are stored in one byte.

(1) that is why, both in TA and Spring, the max map size is 63x63. With map size expressed in "screens", where "a screen" = 1024 pixels.
(Come to think of it, max should be 64x64, but closenough.)

So <30.3901> is 30.3901*182 which should be 5530.9982, but is truncated to 5530, which when decompiled becomes 30.3846153... wait what? How did you even end up with 30.395604 ?

I wanted to explain how the discrepency you had was just from rounding errors, but it doesn't add up.




Aaaanyway. Compiling then decompiling doesn't give the same as the original source, with BOS/COB as with any compiled language. And with Scriptor's unit conversion, plus Scriptor's decompiler bugs, you don't even have a source that compiles to the same object. So don't compile->decompile->recompile->redecompile, or you'll end up with misaligned mexx covers. Keep your BOS sources.

[Jools]

It's probably related to something like that, even though those numbers you posted didn't add up.

I think that most scripts have already been decompiled a few times, because they have lost the static variable names. But it's probably best to still limit the number of descriptings further.