You can view the page at http://forums.auran.com/trainz/content.php?71-Content-creation-for-Trainz-A-New-Era
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
Don't push the envelope too hard
The community occasionally surprises us with content that pushes hard at the boundaries of what is possible in Trainz to achieve something that isn't officially supported. Unfortunately, Trainz history shows that some of these assets turn out to be incompatible with future Trainz versions. So as tempting as it is to push the boundaries and try to get the absolute most functionality possible, if your aim is to have as smooth a transition to E2 as possible, you might want to build content with a more conservative feature set, and avoid some of the more advanced community-developed features.
I think that someone must be putting something in the water at the moment.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.
I do wonder why our creators have been told not to push the envelope? It suggests to me that the new engine has lower limits. I had assumed that those limits were further away not nearer, so pushing the limits with what we have now should be easily accomplished with the new engine. But Im sure our creators or N3V will tell me if I have the wrong idea?
Didn't Mike10 have animated points way back when that relied on an 'undocumented feature'?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.
Regarding texture sizes, modern hardware has GB of memory and TB of storage. The E2 engine is specifically designed to handle larger textures and deal with a larger memory footprint (which is the biggest advantage of going to 64 bit).
All content, unless it absolutely does not need one, should have a normals map. Snow textures even more so, so as to give 'depth' to a simple snow mesh
On the contrary: Push the envelope as hard and as often as you can!
So all these underlying textures I see popping in and out are a desired feature?
Not for me, thanks!
Chris.
Some examples are: Animated junctions, one way traffic on roads, applying texture replacement to alter vehicle liveries, nightmode on road traffic, traffic lights. Yes, some of these use undocumented features and some of them fail to work in the next release - as I said this is the price of progress. But they do keep you guys on your toes and in many instances you respond by adding the facility in native code. If the boundaries never get probed then the demand for things like this will never arise.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.
This wouldn't ring quite so hollow if some of your staff, Chris in particular, were a little more forthcoming in answering those questions when asked. If we look at your 4 optional Kickstarter features for instance, I've had at least partial implementations of items 1 and 4 sitting on my hard drive for months waiting for a response from your team and a fix to a bug which was supposed to have been repaired in the last hotfix.So he is saying "follow the guidelines" and if you want to do something "a bit different", ask questions and think about the ramifications before rushing off creating a brand new "feature".
All this is probably true but you do have a tendency to assume that large textures and multiple maps automatically improve asset quality. This is far from being the case - a good small texture in the right hands can knock the socks off a 50mB file wielded with inadequate skill.Regarding texture sizes, modern hardware has GB of memory and TB of storage. The E2 engine is specifically designed to handle larger textures and deal with a larger memory footprint (which is the biggest advantage of going to 64 bit).
Looking forward to reading the new T:ANE version of CCG where all these neat features are clearly explained with examples.
That only works well if the new car uses a normal key and has the keyhole in a standard location. If it is a keyless entry and you don't know the code, you'll have a had time starting in the morning.Think of the new graphics engine (E2) like your car. If your car currently won't start on a cold morning or leaks oil on your garage floor, you would expect replacing the old engine with a new one, your car will start without a problem and leave the floor nice and clean.
Regarding "secrets" I can assure you it has not been our conscious intention in the past. However, our approach for T2 will be to explain more, and involve the community more from the very beginning - as you will see in a few short days with our project on Kickstarter.
All good points, but I'm a bit concerned about the potential for massive filesizes if each asset uses .m.tbumpenv materials, or even just normal maps.
Consider a building with a typical 1024 x 1024 32-bit tga image (which is what I find is required for sharp resolution on many assets of that size). It's about 4MB. Add another 4 MB for the 32-bit normal map tga needed to complete the m.tbumpenv material. That's now 8 MB. Then double that to 16 MB if the asset has seasonal snow textures (I hardly consider snow as "pushing the envelope" these days).
Trainzdev, can you comment or offer us and our long-suffering hard drives some hope that N3V will address this issue by the time the New Era begins?