Article: Content creation for Trainz: A New Era

WindWalkr said:

What I mean is that even a simple normal map can offer substantial benefits over a plain diffuse, in the same way that even a simple texture can offer substantial benefits over an untextured model.

Click to expand...

Normal maps are used to "develop a sirface shadow relief" under sunlight. But without sunlight (only with diffuse light) they are useless.

More often i use them to rotate normals of faces. For example, i need the same illumination level for the grass and for the ground regardless the sun position on the sky. With normal map i rotate normals of grass faces, they obtain vertical direction and the grass is illuminated like the ground under it.

If it wasn't for folks who push the envelope Trainz would be a far duller place.

For years I've been saying Trainz will not allow a traincar to be rotated along its longitudinal (coupler to coupler) axis. As a result Dale Pattee and I had to make our Rotary Coal Dump series enclosed so you couldn't see the fact that the traincar within didn't rotate. In the real world almost none of these items are enclosed (including down under). It took Dale and I over 6 months to get them working. Prior to that there was nothing like them on the DLS that was animated, interactive, with smoke and sound effects. They were quite well received. Unless I misunderstand the "don't push the envelope" statement - these would never have existed under that criteria.

As it turns out there is a way to rotate a real traincar but its so arcane, involved, complex, and restricted in its application its hardly worth the effort. So instead of limiting us in what we can do and telling us not to push the envelope - encourage us to push the envelope an enable it to do new (prototypical) things with ease because this will make Trainz better.

Innovations = a modern evolving product which will keep old customers and draw new ones.
No innovations = a dull stuck-in-the-mud product which will cause old customers to become legacy Trainzers and rarely draw new customers.

My 2 cents.

Ben

Im beginning to wonder why there is such a difference of opinion. On one hand N3V are telling the creators to hold back - while the creators are saying thats not the way forward. Looking at bendorseys comments above - I doubt he would have achieved what he has with the attitude of "dont push the envelope". I know that things are going to change in the new version of Trainz but surely the way forward is to push the envelope of what we have knowing that it will be pushed further forward when the new engine is available?

bendorsey said:

Unless I misunderstand the "don't push the envelope" statement...

Click to expand...

I think you did. They mean don't utilize a bug in order to implement a 'feature' because bugs get fixed - breaking your feature. I know of a pretty good example of where N3V and myself were both at fault regarding this and it created a big fat mess that still exists to this day.

I used to exploit a bug to get cab interiors to have world lighting, because the fixed blue cab lighting is pretty terrible and doesn't allow use of normal and spec maps. They didn't like that my cabs were too dark inside, and instead of simply asking me to brighten them up, they tried to change them by altering the brightness in code (worst fix EVER), and then found the bug I was using and fixed it. The result was a re-introduction of the terrible coloring in the cab and an extremely blown out bright look for any cab interiors below a certain build number (because they used the build number to determine when to brighten). In the end this causes me a lot more work because now I have to provide cab assets for multiple versions, so multiple assets. so because I wanted a certain lighting in the cabs, there is a big mess to deal with when putting cab interiors into TS12. I regret this very much, but I also regret that they never once asked me about the content, and instead tried to make fixes to it in-house, causing a bigger problem than a bug..

I think a lot of the questions here are arising from what "pushing the envelope too hard" means in this post.

It doesn't mean "don't do good work."

It doesn't mean "don't improve yourself."

It doesn't mean "don't use new features."

What it means is this: If you're going to do something new, make sure to thoroughly understand the subject before you release your work. Do use the features that the engine provides to the maximum, but don't rely on quirks of behaviour that aren't documented and don't have a clear purpose. In any complex system, there will be edge cases where the interaction between several behaviours is not clearly defined. If you rely on such edge cases, you may be able to make the system do something that it's not designed to do- but you're also very, very likely to find that the edge cases have changed in the next product release, and your content will no longer work.

If you're unclear whether a specific behaviour is officially supported, then please ask us. Regardless of how much we improve the documentation, it's never possible to cover every combination of features in a system as complex as Trainz, so there will always be edge cases. Several of the N3V employees read the forums regularly, so if you make a thread asking about a specific feature, it will generally come to our attention.

The more you "go it alone", make use of functionality which isn't clearly spelled out as part of the official feature set, or try to do things that nobody else can do, the more likely it is that you're walking in this grey area and your content may break in a subsequent release of the game.

We're not saying "don't experiment", but if you find yourself uncertain (or if you're taking advice from someone who is experimenting with new techniques) then please do talk to us about it rather than just assuming that everything that happens to work now will definitely work in the future.

hth,

chris

norfolksouthern37 said:

They didn't like that my cabs were too dark inside, and instead of simply asking me to brighten them up, they tried to change them by altering the brightness in code (worst fix EVER), and then found the bug I was using and fixed it.

Click to expand...

Just to clarify the history of this one: our changes had nothing to do with you, and we didn't know about the negative effect on your cabs until far too late in the release cycle to provide a proper workaround. The bug was causing problems elsewhere, and we fixed it. The fact that this affected your content is unfortunate, but certainly wasn't aimed at your content and is a great example of what I'm referring to in the above comment.

cheers,

chris

Yes I know, hopefully we have both learned from it.

pendolino said:

some of the new requirements for content creation - such as mandatory normal and reflection maps, look like a waste of resources, as nobody will ever see their magnificent look.

Click to expand...

norfolksouthern37 said:

how in the world did you get this out of anything?

Click to expand...

These are the errors reported by CM 3.7 for a ground-texture without a normal map:

Error: Required tag 'normal-texture' was missing and has been set to default.
Error: The tag 'normal-texture' in container 'groundtexture' is empty.
Error: The tag 'normal-texture' in 'groundtexture' must have an image file extension.

Maybe I misunderstood something, but:

1) wouldn't this imply the texture must have a normal map?

2) wouldn't this cause a massive increase in file size with no visual benefit, if the texture is only to be seen at long range?

ah I see. well use a lower build.

You don't have to use a massive map you know

WindWalkr, in some cases re-emplimenting different features leads not only to bugs fixing, but also constriction of the implementation area.

Also some implementations "slightly" demage sub-systems, other implementations lead to necessity of complete overhauls of subsystems. For example, in TS12SP1 (HF3) messages "Junction","Leave" are posted mutiple times while the train IS on the junction, and didn't posted when the train leaves it. So i had to re-build some aspects of my signals and my dispather to get rid of usage of this messages. And to introduce "resetter" that does the job of your messages (with greater resourse consumption). Is it good? No, it is not good for both sides (yours and mine).

Pendolino said:

1) wouldn't this imply the texture must have a normal map?

Click to expand...

For modern ground textures specifically, yes.

2) wouldn't this cause a massive increase in file size with no visual benefit, if the texture is only to be seen at long range?

Click to expand...

As a content creator, you do not really have control over where your content is used. If it really is a long way away then the game won't read the file into memory anyway, so it's no great loss. If it happens to be used up close, the users will thank you for the normal map.

kind regards,

chris

TRam__ said:

For example, in TS12SP1 (HF3) messages "Junction","Leave" are posted mutiple times while the train IS on the junction, and didn't posted when the train leaves it.

Click to expand...

I would be interested in hearing more about this. I don't know of any repro case that matches what you are referring to here. Please start a thread on the content creation forum about it.

chris

Chris,

I can confirm that there are some inconsistencies in the current build with junction related messages, from memory there are also issues with messages which are supposed to be generated when the 'use-named-track' tag is used. This may or may not be the same issue that TRam is talking about - I will look it up.

WindWalkr said:

I think a lot of the questions here are arising from what "pushing the envelope too hard" means in this post.

We're not saying "don't experiment", but if you find yourself uncertain (or if you're taking advice from someone who is experimenting with new techniques) then please do talk to us about it rather than just assuming that everything that happens to work now will definitely work in the future.

Click to expand...

This is a perfectly reasonable position and one that I would love to co-operate with in terms of objects being prepared for release but emails of this type from me to you, even emails sent at your request, have a distinct tendency to disappear into a digital black hole. This leaves me with a choice of allowing projects to wither on the vine due to your lack of response or to adopt a publish and be damned attitude.

Yup. With any content creation emails, if you don't get a follow-up then please keep pushing. Unfortunately we tend to be rather busy, and some emails can require hours worth of research in order to provide a thorough answer. In an ideal world, such emails would not be lost, but unfortunately email is not a great task tracking system.

TRam__ said:

For example, in TS12SP1 (HF3) messages "Junction","Leave" are posted mutiple times while the train IS on the junction, and didn't posted when the train leaves it.

Click to expand...

I remember this one. I tested many different cases, and was not able to reproduce the problem. It's not just train length - I tested trains of over a thousand wagons, and it all still worked perfectly.

There must be more to the bug than just what is described, as just from the descriptions I was given, I was unable to reproduce the problem. Maybe there's something track related -- either which assets are used, or perhaps how the track layout is built. Or maybe it requires specific traincars to cause the problem. Perhaps it's a concurrency thing. Does something else have to happen somewhere else on the map at the right time to cause it.

WindWalkr said:

I would be interested in hearing more about this. I don't know of any repro case that matches what you are referring to here. Please start a thread on the content creation forum about it.

Click to expand...

Also, a simple test session which has the problem occur is really helpful when tracking down bugs.

Tony_Hilliam said:

What James is referring to here is content creators trying to fit a square peg in a round hole. He will have a dozen examples (I might think of one shortly) where a "solution" has been found to an issue by utlizing a bug, and then with the next update, the bug is fixed and the "feature" no longer works.

Click to expand...

I've got loads of examples. Several of them I had a hand in creating, before joining Auran back in 2007... so you could say that I've learned this one the hard way

andi06 said:

On the contrary: Push the envelope as hard and as often as you can! This is the way to get humanity to the stars a few centuries from now. If Auran want to stay behind on an overcrowded planet with dwindling resources, let that be their choice.

If something gets left behind that is the price of progress.

Click to expand...

If you are willing to provide support to those users who get stuck half-way to the moon when the engines on your bug-exploit powered shuttle have failed, when everyone else is now boarding for their officially supported launch, and will soon be well ahead of your users -- then go for it. But expect and plan to be fixing it later when it's found that it doesn't work.

But if what you want is to have your shuttle seamlessly work into the future without needing day 1 emergency maintenance, then it's better to avoid powering it from a bug-exploit.

amigacooke said:

Didn't Mike10 have animated points way back when that relied on an 'undocumented feature'?

Click to expand...

Yes, he did. And that's probably the first well known example where something a community member created broke in a later release. They were made for UTC, and they died with the release of TRS2004.

And countless hours has been spent "trying to make them work", or "trying to make something like that" since. And they all suffer the same basic flaw - they are fixed, train-set like objects. Proper flowing trackwork can only be achieved by custom making each individual point. It's worth noting that the correct way to do animated points (procedurally, so they can be worked into arbitrary radius curves) is listed as a Kickstarter feature. I wonder if that would have been done by now if all the effort ploughed into 'fixed junctions' had been directed at doing it properly...

TrainzDev said:

And they all suffer the same basic flaw - they are fixed, train-set like objects. Proper flowing trackwork can only be achieved by custom making each individual point. It's worth noting that the correct way to do animated points (procedurally, so they can be worked into arbitrary radius curves) is listed as a Kickstarter feature. I wonder if that would have been done by now if all the effort ploughed into 'fixed junctions' had been directed at doing it properly...

Click to expand...

Except that in most places if not all, points are standardized- not arbitrary radius curves... I look forward to the way we can also standardize this in Trainz. It is also an even bigger can of worms in that USA engineers them differently than Europe for example. Not sure who else follows this practice world wide, but switches (points) here only curve until the frog is reached, at which point they become tangent. Others carry on through the frog.

norfolksouthern37 said:

Except that in most places if not all, points are standardized- not arbitrary radius curves...

Click to expand...

You'll get standard vee (frog) angles, and standard blade lengths - but if the 'straight' leg of a point needs to go into a wide curve, then most railways will just build it to fit as necessary. Very few will make a flat spot in the curve just so they can use a fixed point.

You'll see this most where there are higher speeds (needing wider curves and longer points) and higher population density (restricting space for land-take). I'm not going to go comb the track layout of the entire North East Corridor, but I'd be very surprised if somewhere there or in the close vicinity, there wasn't a load of points with gentle curves in the 'straight' leg.

It is also an even bigger can of worms in that USA engineers them differently than Europe for example.

Click to expand...

And every US Railroad will have it's own pattern. As will different railways in Europe. Not just per country, but each original private company that started each line. Add to that the variations throughout history, and there are about as many options as you can imagine. Take a look at the various options for how to make points (switches) in Templot, for example...

Pushing the Boundaries

Click to expand...

Considering you are a poacher turned gamekeeper aren't you rather mixing your metaphors?

You need to remember that we have garden sheds and you have a fully equipped spacecraft factory which is currently building bicycles. Perhaps you should also remember the experience of IBM when they failed to fully exploit the work that was originating in garden sheds.

We are both expressing extreme views here, what is really needed is better co-operation. Auran don't have the resources to provide the content that the game requires so they must rely on input from third parties, yet as a third party creator getting support information from Auran is like drawing teeth. This doesn't just relate to pushing at the edges, there are many instances where simply getting parts of the game to work as advertised is a serious problem which can hold up third party development indefinitely.

And countless hours has been spent "trying to make them work", or "trying to make something like that" since. And they all suffer the same basic flaw - they are fixed, train-set like objects. Proper flowing trackwork can only be achieved by custom making each individual point. It's worth noting that the correct way to do animated points (procedurally, so they can be worked into arbitrary radius curves) is listed as a Kickstarter feature. I wonder if that would have been done by now if all the effort ploughed into 'fixed junctions' had been directed at doing it properly...

Click to expand...

I couldn't agree more and when you produce your fully functioning, flowing parametric trackwork and adequate tools for laying it I will be the first to applaud. Of course the term free flowing will take account of varying local standards and will include transition curves in plan and section that start slack and get tighter (the exact reverse of the way that spline track currently works) and of course it will allow for compound objects like slips and crossovers.

TrainzDev said:

You'll get standard vee (frog) angles, and standard blade lengths - but if the 'straight' leg of a point needs to go into a wide curve, then most railways will just build it to fit as necessary. Very few will make a flat spot in the curve just so they can use a fixed point.

You'll see this most where there are higher speeds (needing wider curves and longer points) and higher population density (restricting space for land-take). I'm not going to go comb the track layout of the entire North East Corridor, but I'd be very surprised if somewhere there or in the close vicinity, there wasn't a load of points with gentle curves in the 'straight' leg.

Click to expand...

Yes very possible, I was just hoping you didnt mean the diverging side. curved turnouts are not extremely common but yes they should be taken into account.

TrainzDev said:

And every US Railroad will have it's own pattern. As will different railways in Europe. Not just per country, but each original private company that started each line. Add to that the variations throughout history, and there are about as many options as you can imagine. Take a look at the various options for how to make points (switches) in Templot, for example...

Click to expand...

I cannot speak for everywhere in the world but I have had experience at my previous job designing turnouts in the USA and they were very standardized, not per railroad. perhaps back a long time ago each one had it's own pattern but for many many years this has been a standard regulation.