[eric from trainsim]

One of my WFH customers was running into an error with an Int32 overflow... in helping debug and come up with a patch, I found the following entry being made in multiple (i.e. more than 100) of his W files:

	Forest (
		UiD ( 4294967295 )
		ScaleRange ( 0 6.72623e-043 )
		Area ( 99000 99000 )
		Population ( 0 )
		TreeSize ( 0 0 )
		StaticFlags ( 00100000 )
		Position ( 942.991 210.805 -949.252 )
		QDirection ( 0 -0.945537 0 0.325515 )
		VDbId ( 4294967294 )
		StaticDetailLevel ( 0 )
	)

What jumps out at me are a bunch of errors --

1) the extraordinarily large UID value (which in turn created the overflow, as I've never seen a UID in excess of 64,000....)
2) the lack of a texture file
3) the yuge size of the Area()
4) the tree size and population of 0

Has anyone else seen these types of entries, and if so, what is generating them?

[Goku]

UiD 4294967295 is valid unsigned int value (if it makes overflow - it is something wrong with your app). Lots of routes has this in their .w files.
Why?
MSTS uses 'broken' forest for making Yard Camera (RE -> track objects -> yard definition), example:

	Forest (
		UiD ( 551 )
		ScaleRange ( 0 5.38099e-043 )
		Area ( 50 50 )
		Population ( 1 )
		TreeSize ( 0 0 )
		StaticFlags ( 00100000 )
		Position ( -172.193 12.6631 -110.55 )
		QDirection ( 0 0 0 1 )
		VDbId ( 34 )
		StaticDetailLevel ( 0 )
	)

There is no forest texture because it is not a forest, it is yard camera. Area is size of the yard.

Forests with UiD = 4294967295 and area = 99000 99000 comes from Yard Cam tool for msts. It puts yard camera in all .W files. It sets maximum value for UiD (4294967295) because it doesn't know the max UiD value in .W file. Area 99000 99000 allows to move the yard camera over whole route, not only small area.

[eric from trainsim]

Oh, you're right I wouldn't be expecting to see the max unsigned 64 bit integer used as a UID when the legacy route editor is a 32 bit application.

It was a simple fix, but you might want to rethink that, since it will introduce errors in other apps (many of which are no longer supported) which wouldn't be expecting to handle unsigned ints.

Also, with ORTS, why is there a need for the yard cam definition when the free camera (8) pretty much does the same thing?

[Genma Saotome]

eolesen, on 31 August 2016 - 04:52 PM, said:

Also, with ORTS, why is there a need for the yard cam definition when the free camera (8) pretty much does the same thing?

Maybe because it isn't an ORTS editor (there not being any ORTS world files, tiles, or anything else to edit). IMO it's a replacement for KUJU's RE and, also IMO until such time all of the functionality is complete and entirely safe to use it should be 100% backwards compatible. A 64 bit Int isn't and even it it was 32 bit Int choosing the largest possible value will likely screw up RE next time you try to add anything.

Just my two cents.

[DRelyea]

Hi,

This a Yard Cam definition system that was developed well before ORTS 0.6 for use with MSTS. I think it was uploaded to TrainSim, but I have no idea what the file name is. It has been around since at least 2010.

Doug Relyea

[Goku]

eolesen, on 31 August 2016 - 04:52 PM, said:

Oh, you're right I wouldn't be expecting to see the max unsigned 64 bit integer used as a UID when the legacy route editor is a 32 bit application.

4294967295 is max 32 bit value. 2^32-1. Not 64 bit.

eolesen, on 31 August 2016 - 04:52 PM, said:

It was a simple fix, but you might want to rethink that, since it will introduce errors in other apps (many of which are no longer supported) which wouldn't be expecting to handle unsigned ints.

It is not my feature - it is original MSTS feature. Yard Cam Tool is also not mine.

[eric from trainsim]

You're right - it's a 32 bit max unsigned.

Goku, when a yard definition added by the RE, it seems to be using a sequential UID based on the tile it sits on.

Doug, I saw the "add a yard cam to every tile" app in the library, which is probably what caused this given there are 105 tiles with the yard definition.

Dave, I was referring to whether or not there's a need for the yard cam at all in ORTS, not TSRE5.

Suspecting what some of us do about UID's and memory for the legacy RE, using the max uint value on every tile is probably exacerbating the memory problems some route builders have, since it is reserving literally millions of unnecessary slots to accommodate the yuge gap in numbering.

WFH already adjusts the max uint on the hacked yard cams, and replaces it with a sequential UID.

It's also easy to add a new feature which strips them out just like I'd done with the options to strip interactives.

[Goku]

eolesen, on 01 September 2016 - 04:11 AM, said:

Suspecting what some of us do about UID's and memory for the legacy RE, using the max uint value on every tile is probably exacerbating the memory problems some route builders have, since it is reserving literally millions of unnecessary slots to accommodate the yuge gap in numbering.

Allocating memory for 4294967295 UiDs Int values would require 32 GB of RAM, so it is impossible that any app does it.

[eric from trainsim]

Goku, on 01 September 2016 - 05:33 AM, said:

Allocating memory for 4294967295 UiDs Int values would require 32 GB of RAM, so it is impossible that any app does it.

Exactly, and that's the point I'm making -- you don't normally see UID's numbered > 10000 on any given tile when the native tools are used.

There's been lots of discussion over the years about how many objects can exist on a tile. It's an assumption on my part that there is a practical limit to the number of UID's that can be used.

From personal experience, heavily populated tiles which would regularly crash in the RE started working reliably after those tile's UID ranges were compressed and gaps were eliminated.

Other route builders have had similar experiences, and where there's smoke, there's usually fire.

[DRelyea]

Hi,

The "default" yard cam definition that shipped with MSTS uses the sequential UiD system. The Add a yard cam app hacks the w file and adds the entry with the 4294967295 UiD number so that it does not get overwritten when working in the tile with the MSTS RE. Two different ways to skin the cat. :wtf01:

The reason for the app (I think) is the Default yard cam is placed like a forest region, has to be stretched like a forest region, and has the same limits as the default forest, ie it can't be stretched to cover a tile. The app puts in a w file entry with the "forest" size set to 2048, 2048, which seems to work most of the time, for most people. I think it makes it 2048 by 2048, those are the sizes I have encountered in a couple of routes. Could the 99000, 99000 size be a problem because now they overlap to the point of ludicrosity, and MSTS can't tell which definition it should be in?

Doug Relyea