PDA

View Full Version : Fixed Track Objects (Road Assets)



andi06
June 21st, 2015, 02:23 PM
Chris, would you please enable (or re-enable) the ability for fixed-track objects to attach to each other when the attachment tracks are road assets. I can get around the fact that it doesn't currently work by adding 'istrack 1' to the track config but that obviously defeats the intention of the tag.

On a possibly related point I am now seeing meesages from Trainz when I try to attach incompatible spline objects to each other. Can you tell us what factors you are taking into account when you decide that the splines don't work together?

andi06
June 22nd, 2015, 07:22 PM
Another issue with fixed-track / industry / scenerywithtrack items is that rotate-yz-range appears to be broken, test case any of my stations <kuid:122285:3401> to <... 3406>.

WindWalkr
June 22nd, 2015, 10:08 PM
Another issue with fixed-track / industry / scenerywithtrack items is that rotate-yz-range appears to be broken

Thanks. Fixed.

chris

andi06
June 23rd, 2015, 12:37 AM
.... and fixed track attachment?

WindWalkr
June 25th, 2015, 02:04 AM
Chris, would you please enable (or re-enable) the ability for fixed-track objects to attach to each other when the attachment tracks are road assets. I can get around the fact that it doesn't currently work by adding 'istrack 1' to the track config but that obviously defeats the intention of the tag.

Can you please give me some specific examples (built-in or DLS, preferably) that exhibit the behaviour that you think is bad.



On a possibly related point I am now seeing meesages from Trainz when I try to attach incompatible spline objects to each other. Can you tell us what factors you are taking into account when you decide that the splines don't work together?

I'm not sure which messages you're talking about here. Can you please clarify this comment?

chris

andi06
June 25th, 2015, 04:15 AM
I've no examples, good or bad, and I don't know whether the inability of fixed-track roads to snap together is a bug or a deliberate omission.

Let's go step by step.

Splines are not inherently useful for representing road junctions. The only way that they can be properly built is as fixed-track pieces (mocrossings are frequently used but I'm not too keen on that):

659

Snapping these objects together can be very useful:

660

At the moment this works, but only because the invisible track that I'm using is 'trainz-build 2' and has both 'isroad 1' and 'istrack 1'. This is clearly an illogical config, it may have unwanted side effects and I can't upload it anyway - I simply want to be sure that the capability will be present in an asset set that it is possible to upload.


I'm not sure which messages you're talking about here.

If I try to attach a road to a track I am seeing this:

661

but I also see this message, or something similar, when I try to connect splines which I think ought to be compatible. The question is an attempt to find out why.

Lastly, I have these assets:

662

The three centre meshes taken together form a lay by. As a legacy spline these are simple to assemble as a main spline with an initiator and a terminator. How can I do this in a spline to the new specifications?

andi06
June 28th, 2015, 05:33 AM
... when I try to connect splines which I think ought to be compatible.

More on this. In the screenshot the existing spline represents a pavement, it has 'isroad 0' and 'istrack 0' (You would be able to see it if the editor didn't go black when it has a modal dialogue on top)

When I try to connect to it with another spline asset I get this:

672

The second spline is a clone of the first, identical in all respects except for kuid and username.

I can see the logic of attempting to prevent trains from travelling along a motorway but this sort of restriction will be totally counter-productive, Creators, myself included, will simply add 'istrack 1' or 'isroad 1' to all spline assets just to make it possible to connect related items together.

[Edit: Yet more issues

1. This incompatibilty message remains even if both assets are explicitly assigned to the same asset group.

2. Connecting to a spline asset drawn left to right with another segment drawn right to left forces the first segment to the same direction as the second. When the spline is assymetrical (for instance a path with a kerb on one side only) this completely messes things up.]

andi06
June 30th, 2015, 10:21 AM
It seems that almost everything I am trying to do with splines in TANE is running into issues. I've tried to see a pattern behind when attaching a spline in one direction will reverse the direction of an existing spline but it just seems to boil down to - sometimes it happens, sometimes it doesn't.

One thing is crystal clear though, in TS12 the direction of a spline in a SceneryWithTrack is defined by the order in which the attachment points are defined in config. This is treated as immutable.

In TANE attaching a spline the 'wrong way round' to an attachment node will reverse the spline on the SWT (regardless of the setting of useadjoiningtrack)

It's all a bit of a dog's dinner.

WindWalkr
June 30th, 2015, 06:23 PM
The game tries very hard to ensure that splines are always connected start-to-end and never end-to-end or start-to-start. This isn't always possible, but it tries hard.

There are assorted visual problems that result when a spline is connected backwards. They're not catastrophic in many cases (depending on the asset) but they're unavoidable and reduce the quality of the visual result, so we avoid that scenario where possible.

chris

andi06
June 30th, 2015, 06:35 PM
Fair enough when the spline is symmetrical, but the ones I'm currently working with are not.

The obvious example is third rail track where it is important which side the conductor rail is on. Where I'm currently having problems is with road splines which have various combinations of pavement, one side, both sides or none at all. In cases like these where the spline is specifically designed to be compatible when the directions are reversed the behaviour we now have is unhelpful.

My station assets have, since TRS2006 relied on splines which are attached track segments retaining the direction which is set out in config. These assets are still working as designed but new ones, using the same technique, are not.

Do we need a flag to signify an assymmetrical spline?

WindWalkr
June 30th, 2015, 07:09 PM
Fair enough when the spline is symmetrical, but the ones I'm currently working with are not. The obvious example is third rail track where it is important which side the conductor rail is on.

That's a bit backwards.. an asymmetrical spline is the exact case where the game MUST make sure that they are connected the correct way around. That's an absolute worst-case for allowing the direction to vary (though certainly not the only problem case.)



Where I'm currently having problems is with road splines which have various combinations of pavement, one side, both sides or none at all. In cases like these where the spline is specifically designed to be compatible when the directions are reversed the behaviour we now have is unhelpful.

Your best bet here is likely to split the pavement off to a separate spline.

We've talked for some years about having selectable secondary-spline capabilities (such as for catenary) which would allow the Surveyor user to determine what kind of "attachments" they would like to add to the spline that they are laying, however such a thing involves a lot of design and implementation so won't be around any time soon. At the current time, the only real option is to allow the user to lay these manually.


We will not be providing end-user controls over the direction of a single track stretch. The game has always taken a bit of a hand in defining that, and yes- as of v3.8, the game is a little bit more active about this than it used to be. This is deliberate.

It does seem, however, that you're talking about fixed track pieces or something along those lines? We may have an opportunity to control things at that level, since it can reasonably be assumed that the content creator knew what he was doing when he put it together.

chris

andi06
June 30th, 2015, 08:19 PM
That's a bit backwards.. an asymmetrical spline is the exact case where the game MUST make sure that they are connected the correct way around. That's an absolute worst-case for allowing the direction to vary (though certainly not the only problem case.)

No, No, No. Its assymmetrical for a reason, talk to somebody who knows something about electric trains.

675

You need the conductor to swap sides on demand because that is what happens in the prototype. Its also vital to be able to control which side the conductor rail is on in stations, to help prevent all the little people from being electrocuted. In other words the end-user MUST have control over direction in cases like this.

As things stand you can only achieve what the screenshot shows by making a junction and deleting the leg which doesn't match. But the next track section you attach will spoil all the hard work it by re-aligning the whole section.


Your best bet here is likely to split the pavement off to a separate spline.
I'm already doing that (using attached-splines) and it nearly works beautifully but for these niggling issues with spline direction and compatibility. I'll come back tomorrow, its way past my bedtime.

WindWalkr
June 30th, 2015, 09:25 PM
No, No, No. Its assymmetrical for a reason, talk to somebody who knows something about electric trains.

I know it's asymmetric for good reason. My point is that asymmetric tracks are one of the major cases that we're trying to handle by keeping the direction aligned.



You need the conductor to swap sides on demand because that is what happens in the prototype.

Fair enough. That's nothing to do with being asymmetric and everything to do with you wanting to control how it's laid out. We DO NOT offer support for this via a single-spline approach. This is something where we'd need those additional properties I mentioned (in this case, a mechanism to control which side things are on.)



Its also vital to be able to control which side the conductor rail is on in stations, to help prevent all the little people from being electrocuted. In other words the end-user MUST have control over direction in cases like this.

You're collating several different use-cases, so it's hard to give a single one-size-suits-all answer.

For attached-track objects such as stations, I've already noted that we can probably arrange something suitable.

For regular spline usage, Trainz has no feature like what you're asking for, and while I acknowledge that there are good reasons to introduce such a thing in the future, it will definitely be "in the future" and not in the immediate sense. It might be possible to hack a direction change by using a fixed-track separator, but again you're walking on some fairly undefined behaviour here so caveat emptor.

chris

andi06
July 1st, 2015, 05:49 AM
I'm going to agree to differ on the fundamentals of this and suggest a slight change of tack which might keep us both happy.

As far as connections to SWT objects is concerned the behaviour since TRS2006 is described below:

The platform spline direction in the SWT objects is defined in config, trainz never changes this. At least for my objects, the 'correct' direction follows a left-to-right convention and is also shown by arrows in the invisible marker tracks. If a spline is connected the 'wrong' way round it will NOT alter the SWT but it will look silly and the route builder will need to erase it and redraw.

677678

The same was true of track, drawing left to right places the conductor on the correct side. Up until now this direction was immutable but current spec tracks align the whole track stretch to match the newly drawn segment. Any new track connected to this system (and the connection could be made five miles away) will wreck the track layout at the station.

679680

I'm not asking for any sophisticated new facility, I'm just asking you to retain existing behaviour rather than introducing this new spline direction switching. Remember that you are sworn to maintain compatibilty with TS12 :-)

Please ask yourselves if whatever you are trying to achieve now is more important than the route-builder's intentions for spline direction.

At the very least please:

1. Never realign attached-tracks.
2. Change the algorithm such that the new track stretch being added is realigned to match what is already present on the map. This would at least prevent the side effects of changes in existing directions.


681

This is one of the fixed-track road junctions I'm currently working on. The road surface and markings are a 'hard' mesh, the coloured lines are invisible traffic-bearing roads and the pavements (with a kerb on one side only) are attached splines with 'useadjoiningtracktype 1' I'm having the same issues with spline direction here.

The screenshot shows the perimeter as a pavement, the intention is that this can be altered to pavement + retaining wall, pavement + fence or a sloping shoulder for use in the countryside. All of these alternative splines have compatible dimensions and belong to the same asset-group yet I can't update the object with them because Trainz tells me that the tracks are incompatible.

In order to get these fixed-track objects to snap together I'm having to define the invisible roads as 'isroad 1/istrack 1', this works but is obviously undesirable and the spline circles show up in the wrong mode. Hence my request to enable (or fix) fixed-track road attachment capabilities.


676

This is a junction formed using splines only. There is a mix of single roads with zero, one or two pavements and a dual carriageway comprising two roads and three pavements. Since these are all compatible road assets everything works together very nicely. I want to be able to do the same sort of thing with pavements (isrtrack 0/isroad 0) so I need Trainz to recognise members of the same asset-group as compatible. It would also be useful to specify trackside objects such as signs and bus-stops that could be placed on pavement splines rather than roads (this allows for different road widths) This does work if the pavements as attached-splines are visual-only 0, but that introduces further compatibility problems.

WindWalkr
July 1st, 2015, 09:55 AM
The same was true of track, drawing left to right places the conductor on the correct side. Up until now this direction was immutable ..

This isn't actually the case. It was *usually* left alone, but not always.



I'm not asking for any sophisticated new facility, I'm just asking you to retain existing behaviour rather than introducing this new spline direction switching. Remember that you are sworn to maintain compatibilty with TS12 :-)

I'm happy that the current system is sufficiently TS12-compatible. If you want to get technical:

* Existing routes built in TS12 are not affected whatsoever.
* Routes created in TANE using older content is affected, and this spans as far back as 3.8. There is nothing new in T:ANE regarding this.
* This isn't arbitrary, it's necessary for correct spline rendering.



Please ask yourselves if whatever you are trying to achieve now is more important than the route-builder's intentions for spline direction.

For the most part, yes, it is. The fact that you haven't noticed it until now is a good indicator that route creators simply don't pay a lot of attention to this stuff. We've been doing this to some extent since Trainz 1.




1. Never realign attached-tracks.
2. Change the algorithm such that the new track stretch being added is realigned to match what is already present on the map. This would at least prevent the side effects of changes in existing directions.

I'll have to review both of these carefully. On the face of it, they both sound reasonable. The former is potentially problematic, but it will be typically problematic in ways that should be obvious to the content creator. The latter is unlikely to be problematic, since we don't really care which track has its alignment changed; of course there will always be problem cases, but if the trivial case is problematic when it clearly doesn't need to be then we should easily be able to clean that up.


chris

andi06
July 1st, 2015, 10:15 AM
The fact that you haven't noticed it until now is a good indicator that route creators simply don't pay a lot of attention to this stuff.
I'm not a route creator and I do pay attention. I've noticed it in the past as an issue which was caused by the innaccuracy of texture mapping on chunky tracks and in one or two badly drawn assets.


I'll have to review both of these carefully. On the face of it, they both sound reasonable.
Of course they are reasonable, am I ever anything else?

Thanks.

WindWalkr
July 1st, 2015, 07:00 PM
I'm not a route creator and I do pay attention. I've noticed it in the past as an issue which was caused by the innaccuracy of texture mapping on chunky tracks and in one or two badly drawn assets.

Considering chunky tracks weren't affected by this, no..



Of course they are reasonable, am I ever anything else?

I'm glad you asked! ;-)

chris

andi06
July 2nd, 2015, 02:47 AM
Time to stop being reasonable, this is even more pernicious than I thought.

1. Open a new route, assume that the first base board is Kings Cross, add enough terrain to get you to Edinburgh.

2. Draw a single length of third rail track, draw it south to north and note which side the third rail is on.

3. Add enough trainz-build 4.2 track to get you to Edinburgh, make sure that you include plenty of fixed-track, crossing and station objects and change track type frequently but don't use the third-rail track again and always draw the track sections south to north.

4. Once you get to Edinburgh add a final section using third rail track drawn north to south.

5. Go back to Kings Cross, check again where the third rail is, and explain how it helps spline rendering for your direction switching to operate over 300 miles.

WindWalkr
July 2nd, 2015, 02:56 AM
5. Go back to Kings Cross, check again where the third rail is, and explain how it helps spline rendering for your direction switching to operate over 300 miles.

Distance has nothing to do with it, really. The point is that if you change directions between the beginning and the end of those "300 miles", you are by definition also changing distance over the distance of "one meter" at some point on that line. The change is instantaneous, distance isn't actually a factor (unless you want to argue that one defect every N meters is reasonable..)

chris

andi06
July 2nd, 2015, 03:29 AM
Tell that to the route-builder who lays a track in Edinburgh which changes the track he has carefully laid down in Kings Cross.

.. and how can you possibly justify switching direction between different tracks?

WindWalkr
July 2nd, 2015, 03:36 AM
.. and how can you possibly justify switching direction between different tracks?

Could you clarify what you mean by "different tracks" ?

chris

andi06
July 2nd, 2015, 03:59 AM
Given this arrangement:

683

Attaching ANY additional track the 'wrong' way round at either end will alter the position of the third rail in the centre segment. I can't see any justification for this behaviour and it makes the use of assymetrical splines so unstable as to be effectively impossible.

All of the tracks I've used in these tests are your own procedural-track samples and my own procedural-tracks and road objects.

WindWalkr
July 2nd, 2015, 09:10 AM
Attaching ANY additional track the 'wrong' way round at either end will alter the position of the third rail in the centre segment.

As above, it seems reasonable in this trivial case to reverse the direction of the new track rather than the existing track (there's still the case of joining two existing tracks where this doesn't hold, of course.)



I can't see any justification for this behaviour..

I'm not really sure whether there is any benefit to it in this case or not. I'll find out, and either let you know or get this case improved, depending on the outcome.

chris