Surveyor 2.0 feedback thread

1 puzzle piece of layer riddle solved

I did notice if I hide/lock all the layers except the track layer i could not anymore work on the track as the mouse pick/click not find anything although visible.
The only reason could be that there are nmore layers or layer that have received track some time (not by me 100% sure).
After trial and error check on each indivdual layer setup I ended up with the roads layer have track somewhere or maybe track object who knows.
Hiding ALL layers except roads I started slowly to scan the entire route and with quiet some luck i could find a bunch of tracks which I carefully changed layer back to track layer.
Next step verify if the roads layer still bock working on tracks on the track layer I did a hide and lock on all the others.
Bingo the road layer is free of mishaps and sorts of failures and now I can work on the tracks only (visible).
Lucky me I could find it rather quick by chance going somewhere that just happened to be the troubled area.
Let me know if this was helpful to anybody not able to work on stuff if other layers are in hide and or lock mode.

moderator kind request to move my feedback S20 to the weevil thread where it could make more sense.
Sorry for using this thread I forgot about weevil's surveyor 2.0 feedback thread.

I was about to post that we'd gone way off topic/

There are lots of words about layers - what we need is a step by step guide as to how things end up on the "wrong" layer and to remove all the commentary about anything not related to the required steps. It could be a bug in mergin layers for example, so if there are lots of layers being moved, merged, locked, unlocked, then it's a matter of finding the right pattern. Good luck.

Tony_Hilliam said:

I was about to post that we'd gone way off topic/

There are lots of words about layers - what we need is a step by step guide as to how things end up on the "wrong" layer and to remove all the commentary about anything not related to the required steps. It could be a bug in mergin layers for example, so if there are lots of layers being moved, merged, locked, unlocked, then it's a matter of finding the right pattern. Good luck.

Click to expand...

Wait a minute Tony, this layer issue is many years old if you read Denaban his post you will see it is not on the users side to solve this very old problem.
In S20 I did not fiddle with any layer or merged moved yet stuff ends up on a layer I did not even touch for many many month.

The hide lock feature now in S20 was causing trouble for details I posted today #61 solving the reason why the track was not accessible on the track layer!
Trainz DOES move stuff to other layers without the knowledge of the user. Deneban confirms this too.
Why I cannot see it happens without knowing!
In the best case you discover this much later or when something stops working and the user start check the layers if something wrong.
So kindly I give the good luck wish back to you.

You wish for a step by step guide as to how things end up on the "wrong" layer so the required steps.
I believe your people have to figure out in you office in your program.

I am sure there were problems many years ago. We've fixed many, many issues relating to layers, merging, renumbering named objects etc. The key is not what used to happen, but what can happen in the current build.

Trainz CANNOT move anything from one layer to another, without some action being performed. i.e. changing layers requires some code to be executed that makes the change. We have not found any way that this is possible. We have anecdotal evidence that it has happened, but that doesn't help us find where things go wrong. I can assure you that we will attempt to find some way for this to occur, but it is far more likely that someone like yourself that identifies the problem will be able to point us in the right direction.

Tony_Hilliam said:

I am sure there were problems many years ago. We've fixed many, many issues relating to layers, merging, renumbering named objects etc. The key is not what used to happen, but what can happen in the current build.

Trainz CANNOT move anything from one layer to another, without some action being performed. i.e. changing layers requires some code to be executed that makes the change. We have not found any way that this is possible. We have anecdotal evidence that it has happened, but that doesn't help us find where things go wrong. I can assure you that we will attempt to find some way for this to occur, but it is far more likely that someone like yourself that identifies the problem will be able to point us in the right direction.

Click to expand...

You might be in for an ugly surprise stating Trainz CANNOT move anything to another layer.
I CAN state, 100% sure that trainz moves stuff WITHOUT me changing layers or do anything with layers.
Unlikely I will see things happening live but in the event it does I will keep you posted.
I rest my case and enjoy working on my W.I.P route.

RoysTrainz said:

You might be in for an ugly surprise stating Trainz CANNOT move anything to another layer.
I CAN state, 100% sure that trainz moves stuff WITHOUT me changing layers or do anything with layers.

Click to expand...

In all my years of experience of using and promoting the use of layers I have never come across a case where Trainz has moved a scenery object from one layer to another without user intervention. There have been plenty of times when I have accidentally placed objects in the wrong layer, but that was my fault (and the fact that Trainz did not tell you what layer was active).

The only time Trainz came close to doing this was a bug in T:ANE and possibly in early versions of TRS19 where if you placed a ruler in a layer and then deleted the layer it did not delete the ruler but hid it from view. If you then created a new layer with the same name as the deleted original layer then the ruler would reappear in the new layer. If you saved the route and exited Trainz after deleting the layer then the next time you loaded the route the "missing" ruler would appear in the route-layer. I just tested this before posting and the bug has been fixed.

Like Tony, I would like to see reproduce-able evidence of this effect.

@Tony & PWare: The fact that one cannot enquire what layer a ruler is on, even in this TANE epoch, is still on topic, it prevents us from confirming whether they are behaving within the layer conventions or not. Statements above calling the layer situation stable may not be 100% confirmed because rulers (and cameras) cannot be readily monitored for correct behavior, save for exhaustive layer hiding and unhiding attempts. There is no "?" palette button for a ruler.

My experience has been routes created pre-TANE are susceptible to layer antics when rulers are present. If you import pre-TANE creations into TANE-based releases, they will immediately crash upon loading or continue to cause issues like RoysTrainz is experiencing.

As seen in my blog entry https://forums.auran.com/trainz/entry.php?1053-At-Look-at-Techniques-and-Progress-on-the-Fostoria-Route, I used rulers extensively in TS12 (as in ~ 500 rulers) to create my Fostoria route to be geographically accurate with respect to Google Maps:



Every one of those rulers had to be deleted to avoid crashes or mishaps in TANE and TRS19, which I derived by an exhaustive process of elimination. In the process of removing those rulers, they were seen to switch layers within the route, and sometimes move an asset in concert. When a ruler was deleted, others would disappear because they migrated to a layer currently hidden, and reappeared when all was unhidden. Good news is with TRS22 Beta, the route at least load without crashing (I have not tried editing the route), so the ongoing debugging efforts seem to be zeroing in on resolving this issue.

Looking at the drivers, when the static images are displayed, the appropriate portraits are show but when the animated images are used, the wrong portraits appear.
static


animated

deneban said:

@Tony & PWare: The fact that one cannot enquire what layer a ruler is on, even in this TANE epoch, is still on topic, it prevents us from confirming whether they are behaving within the layer conventions or not. Statements above calling the layer situation stable may not be 100% confirmed because rulers (and cameras) cannot be readily monitored for correct behavior, save for exhaustive layer hiding and unhiding attempts. There is no "?" palette button for a ruler.

Click to expand...

I have no argument with you there. In Surveyor 2.0, because all tools are visible on the screen at the same time, the name of the active layer does appear in one of the on screen palletes/panels but this can be hidden/minimised - but I must concede that this is also true of my favourite graphics package where layers are just as important.

deneban said:

I used rulers extensively in TS12 (as in ~ 500 rulers) to create my Fostoria route to be geographically accurate with respect to Google Maps

Click to expand...

I continue to use rules just as extensively and for the same purpose. I reported a bug in TRS19 SP3 where rulers of over a certain length, about 100 kilometres, would partially vanish as if TRS19 had run out of the multicoloured "rainbow ink" used to make rulers. But the arrowheads with their distance data were still visible. I posted about this at https://forums.auran.com/trainz/showthread.php?163783. By the end of that thread I was able to produce a detailed set of steps to reliably recreate the problem and N3V QA were able to confirm that it was a bug.

This is the step that many "bug reports" in these forums do not provide. It takes a lot of detective work, time and effort but if you can provide the detailed steps that produce the problem every time then N3V QA will have a starting point. I understand how difficult it can be for N3V's QA to reproduce "strange behaviours" and claimed "bugs" because there are often just too many different variables involved and the users posted description are often just too vague and lack sufficient details. While it is time consuming and thus does not appeal to everyone, a methodical approach is often the only way to (hopefully) resolve these problems.

My thoughts.

Still looking at this and have found i continually have to go back to the Classic Surveyor
Rules for distances
No spline circles
Are we able to get rid of the default ground texture and select the Grid

big_b said:

Still looking at this and have found i continually have to go back to the Classic Surveyor
Rules for distances
No spline circles
Are we able to get rid of the default ground texture and select the Grid

Click to expand...

Others have commented on the lack of spline circles and/or the pixel sized replacement "dots" being too small.

The ability to set your own preferred grid pattern or starting texture will be coming in a future (the next??) beta release.

If I happen to press the X on a palette how do I get it back

You can toggle the various palettes using Menu Bar > Window Menu.

Clickable area for splines has been improved greatly in the next update.

S20 offers the option to toggle between transparent (wireframe), grid and textured (Display Menu > Ground).

For TRS22 and TRS19 SP5 users, the next beta build has a Grid Region which you can use as your default.

pware said:

Like Tony, I would like to see reproduce-able evidence of this effect.

Click to expand...

Here lies the problem you and Tony ask for hard evidence and reproducable step by step documentation.
This is beyond what (I think) you can ask from a customer and for sure in this case.
You are understaffed for the tasks and make your customers fill in that gab.Don't get me wrong if users are willing to do than good for you.

I try to help where I can but I am not willing to also do the detective work on something not accessible to the users anyway in a runtime version of the sim.
I have my hands full on my W.I.P. and spending 40% of my time looking over my shoulder like Kotangagirl posted in fear checking if the layer changed from where I was supposed to work only exclusively at that time.

The pixel vs spline point circle is another thing I can understand most users have a problem young and old, good or bad eyesight.

I solved this years ago and continue to always use a big screen now the latest 4k 65" Qled samsung which is up to the task of producing crisp and HDR results.
Very expensive but a must for me to work on the so dense detailed routes I make and my eyesight working long hours not help too when getting tired makes it not easier.

Like Tony posted somewhere he set the windows display HDR text mode 150% allows also good readable content outside trainz eg the forum and still have a good trainz experience.

His 3840x2160 res I think would hamper the fps when running driver as the max setting for Trainz has been shrinked to 2560x1440 120Hz unfortunately so I cannot use my 4096 or 3860 x 2160 120Hz 4K capability.

N3V wrote that most computers and monitors could not handle well higher settings than what they allow today so here we are and for N3V understandable they keep the majority of much cheaper configs.

I understand that it isn't your responsibility to fix the bug, but it is your responsibility to tell us as much as you can about the bug.

We have not seen anything about content moving from one layer to another unless explicitly merging or moving items. We have two people telling us they have seen it happen. My assumption is that something in your workflow has resulted in things being moved accidentally. Until we know all the steps you use in your workflow, we are unlikely to find any solution to the problem.

Tony_Hilliam said:

I understand that it isn't your responsibility to fix the bug, but it is your responsibility to tell us as much as you can about the bug.

Click to expand...

It is not a responsibility for the user that sounds to heavy not working for the company but it is logic that the user provide as much evidence as he can or is able to.
This said, today for one more time try to clean/repair the roads layer from tracks AND track objetcs which appeared on that layer.
In doing that I did see once more in S20 that when testing CMTM4 and having a bunch of consists most single cars running in driver showed up on my specific DEM Bboard layer which is hidden and locked 99% of time. Knowing that the visible lock and hide not prevent things to get caught too I assume here that somehow all these most single cars dropped in driver at a given point ended up on the DEM Bboard layer.
Correcting this now so busy for the rest of the day.
Pware do not try to tell me I put them there on that layer i did not.
Back to my drawing board.

Here's a hypothetical example. "I have downloaded and installed your <kuid2:122860:100436:27> Canadian Rocky Mountains - Golden, BC route. It is not working, please fix it!"

RoysTrainz said:

Pware do not try to tell me I put them there on that layer i did not.

Click to expand...

I did not tell you that you put them there (in the wrong layer). I stated that I have done that on occasion myself.

pware said:

Here's a hypothetical example. "I have downloaded and installed your <kuid2:122860:100436:27> Canadian Rocky Mountains - Golden, BC route. It is not working, please fix it!"



I did not tell you that you put them there (in the wrong layer). I stated that I have done that on occasion myself.

Click to expand...

You are a trainz vet reading your avatar so I scratch my head how on earth you could come with such an oversimplified example.
First of all My routes are always tested on my and n3v side before making it past QA.
Comparing your oversimplified example with mine and Deneban's post I think is comparing appels and figues.
We both give as much evidenc what happens afterwards and at what places why that is the 60k question the user can not answer and request the provider/developer of the sw.
If the return question is we cannot fix it as long we the user not provide hard evidence step by step report nothing will happen.
That is now crystal clear and as said in another post I rest my case, enough back and forth.