(Usability) Inconsistent behavior of 'rotstep' config option in Surveyor 2.0

ZyxwvU

Member
I'm currently working on a town part in Surveyor 2.0 and I noticed that 'rotstep' option from asset config.txt is being applied while trying to copy objects with 'Ctrl' button. This is a bit annoying and inconsistent, because Surveyor 2.0 generally allows rotating such objects by arbitrary angle in some places, and other places take this option into account, giving weird effects and forcing the modeller to fix the angles after each single operation.

I checked the behavior on two different objects. Firstly, 'ZiuT Tenement 1 V3 - Seasonal', <kuid2:448741:1523:2>. This asset does not configure any value for 'rotstep' in its config.txt file, therefore I believe the game applies the default value of 1:

1. I create an object and set the rotation angle to 123.5 degree,
2. I click the object, press 'Ctrl' and drag it to create a copy,
3. In the new object, the rotation angle has been rounded to 124 degrees.

The difference is visible if you try to create a row of identical objects that touch one another.

The second object, 'Building City Office 05', '<kuid2:60349:25307:1>. This asset sets the 'rotstep' to 5 in config.txt:

1. I create an object and set the rotation angle to 8 degrees,
2. I click the object, press 'Ctrl' and drag it to create a copy,
3. In the new object, the rotation angle has been rounded to 10 degrees.

Again, if you want to create a row of objects, the game firstly allows you creating an object with arbitrary angle and then messes it up during the copy operation.

Expected behavior

I would expect to ignore the custom 'rotstep' in Surveyor 2.0 consistently for the sake of usability. If I can type any angle in 'Info' box and the gizmo also rotates the object by any angle, the other tools should preserve it and the game should not do any rounding based on 'rotstep' option.

In the second scenario the configured angle is big enough that we can easily notice that something is wrong. In the first scenario, with rotstep = 1, the difference is small enough that you may not notice it in some cases until it is too late, forcing you to redo the recently done work. I started noticing it while creating track junctions on one of the stations from the template objects based on real-world junctions which assume that the side track deviates from the main one by 6.4 angle. I copied some templates, started laying tracks and noticed that something is wrong, because the templates did not match each other. After the inspection, I realized that for all copied templates, the rotation was rounded down to 6 degrees and my track layout is invalid. The ability to copy an object is useless, because I need to fix the rotation anyway which is no different from creating new objects.
 
I just tried your experiment using <kuid2:60349:25307:2> Building City Office 05 in builds 126195 (latest beta) and 123794 (non beta) and I could not reproduce your problem. Note that I am using the latest update of that asset (2) from the DLS and this may "possibly" be the difference but I checked its rotstep tag in its config.txt file and it was also set to 5.
  1. I placed the asset into a scene and, using the Info Palette Rot setting I was able to manipulate its Y rotation in increments of 0.1deg - confirmed by observation.
  2. I set the rotation to 119.5deg and cloned the object - the clone had its rotation reset to 120deg so I changed it back to 119.5deg.
  3. I used the Free Move tool to drag the clone to a new location - its rotation remained at 119.5deg.
  4. I dragged it back again and placed it flush alongside the original copy. Both meshed perfectly with no difference in their rotation.
It seems that using the Info Palette Rotation (Y) setting ignores the assets rotstep value - at least that is my conclusion.

EDIT: Repeating the above using the Fine Adjustment Blue Rotation Anchor (the blue arc) and Object Anchor (black dot) I was able to repeat the experiment with the same results. So the Fine Adjustment rotation anchor also ignores the rotstep setting.
 
Last edited:
Regarding point 2 - you said that the clone had its rotation reset to 120deg, so you actually reproduced the issue - this is exactly what I reported yesterday :).

This rotation reset makes 'clone' operation a bit useless in certain situations, if one needs to fix the rotation manually afterwards.
 
Regarding point 2 - you said that the clone had its rotation reset to 120deg, so you actually reproduced the issue - this is exactly what I reported yesterday :).
You are right. I somehow missed that:(

I did another experiment using the Scrapbook to see if that would make any difference but it did not.
 
If this is happening in build 126195, then it should be reported through the bug reporting system.
Please report any bugs using this link: https://n3vgames.typeform.com/to/xRdryu
N3V has made it clear that they no longer monitor this forum for unique threads describing bugs. In fact, for the most part they are no longer active in the forums at all except for announcements of new beta builds.
 
Back
Top