PDA

View Full Version : internal test build 78924



WindWalkr
October 13th, 2015, 11:01 PM
Hi all,

A new internal test build is available.

* Validation fixes targeted at aliased LM files.
* Improved TS12 compatibility for animations where the mesh file includes non-identity bones and the animation file is missing any data for those bones.
* Fixed some recently introduced issues where certain stitched meshes did not display.
* Reduced frame rate jitter on some Windows systems.
* Fixed path normalisation for Windows trainzutil "compile" command.
* Add support for 'emissive' material color.
* Add limited support for 'self-illumination' script functions and update the script comments to explain why these functions are not recommended.

chris

andi06
October 14th, 2015, 03:04 PM
* Fixed path normalisation for Windows trainzutil "compile" command.
In your dreams you might have fixed it:



------------------------------------------------------------------------------------
Compile (TANE)
Target File: F:\Assets\00508 Superscript Code Library\bstub.gs
Wednesday 14 October 2015, 20:55:04, Elapsed Time: 0:00:00:105
------------------------------------------------------------------------------------
; <NULL> : compile "-iE:\\TRS\\ts15_Windows_SIMCENTRAL_78924\\resources \\scripts" "-bc:\\windows\\temp" "-pc:\\windows\\temp" "F:\\Assets\\00508 Superscript Code Library\\bstub.gs"
- <NULL> : TrainzAssetAccessorFolder::InternalResolveRelative Path> subpath is not absolute
- <NULL> : TrainzAssetAccessorFolder::InternalResolveRelative Path> subpath is not absolute
- <NULL> : TrainzAssetAccessorFolder::InternalResolveRelative Path> subpath is not absolute
- <NULL> : TrainzAssetAccessorFolder::InternalResolveRelative Path> subpath is not absolute
- <NULL> : Could not read file fld:/| : f:\\assets\\00508 superscript code library\\bstub.gs.
; <NULL> : .. while compiling 'F:\\Assets\\00508 Superscript Code Library\\bstub.gs'
OK (5 Errors, 0 Warnings)


I have alpha numbering working correctly on a traincar with 'trainz-build 3.5' set.

As soon as the same traincar is up-versioned to 4.2 (with no other changes) no errors are reported but alpha-numbers are totally broken. This appears in the log:



- VE171: Expected texture file type but found 'loco_alpha_numbers/alphanumber_7.tga' for 'arc:fld:$(local)/hash-CF||kuid2 122285 700 1.tzarc|'
- VE171: Expected texture file type but found 'loco_alpha_numbers/alphanumber_1.tga' for 'arc:fld:$(local)/hash-CF||kuid2 122285 700 1.tzarc|'
- VE171: Expected texture file type but found 'loco_alpha_numbers/alphanumber_3.tga' for 'arc:fld:$(local)/hash-CF||kuid2 122285 700 1.tzarc|'


Would you care to translate?
Since its a numbered error why doesn't it appear on CM validation?
Where and exactly what are you expecting to find, and since this appears to be a change of specification where have you advised us of it?

ianwoodmore
October 14th, 2015, 03:41 PM
Download took two attempts to complete.
Instals went smoothly on both SSD mini TAD and HD maxi TAD.

Start Engine and Start Trainz seem to sit for quite a while. However timing it seems to be about 3 mins.
I was opening CM at same time.

Once Start Engine got under way the process took less than a minute to complete.

I'm operating at 4000m draw distance with Tree and Scenery Detail at normal, but with performance settings at Ultra or max.

WIN 10 is build 10565.
NVidia driver 358.50.
32GB RAM
Four (4) monitors at 1920x1080 120HZ Async

In Kickstarter Trees for Life I'm getting a smooth ride at between 25 and 50FPS.

On maxi instal, time to get route menu showing is about 15 secs. That thousands of entries. In mini instal almost instantaneous.

During initial loading after merging TANE core with existing Userdata, commit memory did not exceed 3.5GB. While hard hits were high for a while it was SearchIndexer.exe that was causing them not TANE.exe. Under most conditions hard hits 0-2.
Normal Commit Memory during Game was 1.7 to 3.5GB. On killing TANE in Resource Monitor this figure starting dropping rapidly until TANE.exe exited process queue. Then all commit memory associated with TANE.exe was released.

During Trees for Life session I Saved Session on two occasions at Fogarty, once on log consist and the other on passenger train. Save took two (2) secs and no sign of any problems. Similarly reloading saved sessions.

In CM I still believe 'Select All' should be in RMB menu for greater throughput during fault finding, repair and creation.

Highlighting a disabled asset does not toggle 'Content Disable' to 'Enable'.
Download menu shows 35 out of 3900 disabled items as 'Available for download' example see ish6 Ringling Brothers and Barnum & Bailey Circus Train assets. Use of AND NOT enabled hides these.

On Repair and Upversioning front I have made good progress.
Not rigorously tested yet but relative to TB 4.2 TANE validation:

TAD 365,905

Obsolete 98,949. Apart from those in Builtin I have relegated these back to DLS.

Installed not builtin 247,924

Faulty 3,583. 0.97% error rate of all that can be repaired. Still processing. This does not include any faulty assets that I have temporarily disabled most of which are the bugor mesh-asset or Speedtree Mk 5 issues I mentioned earlier.
Bear in mind I'm trying to upversion without enhancing assets to see what creators are up against in meeting TB 3.7 (TS12 SP1 HF4) and TB 4.2 TANE HF2 and Trainzdev compliance.

So far assets in my TAD are spread like this:

Build - ALL 266,461
Build < TB 2.9 20,219. Assets such as aliased, paintshed, chunky mesh, tag divider and various payware and builtin.
Build TB 2.9 to TB 3.4 6,399
Build TB 3.5 to TB 3.6 2,415
Build TB 3.7 142,752 55.6%
Build TB 3.8 and above 94,676 35.5%

So overall

Build <TB 3.7 10.9%
Build TB 3.7 or greater 89.1%

Defect Status associated with these build numbers:

Faulty - ALL 3,583 and reducing
Faulty < 2.9 401
Faulty TB 2.9 to 3.4 1
Faulty TB 3.5 to 3.6 0
Faulty TB 3.7 3,112
Faulty TB 3.8 and above 70

WARN - ALL 109,000+

I've really pushed validation to extreme.

The TANE faulty's are actually a few 'Lowest mesh >500 polys' that occurred while I was batch upversioning from TB 3.7 to TB 4.2. This is a real show stopper because many, many assets that I currently have at TB 3.7 cannot be upversioned to TB 4.2 without this fault mode (VE109) changing from a warning to an error. The thing is these are not the lowest mesh per se but often the ONLY mesh in none LOD assets and include the majority of kind traincar and bogey.

Incidentally, any of the legacy assets that I upversioned to TB 4.2 as part of the testing, can be regressed to TB 3.7 without any further actions other than changing trainz-build tag.

Yes TANE can use assets with a trainz-build < 3.8, but at the moment only the creators have the source files that will allow creation of the LOD meshes and advancement of the assets to TANE validation compliance.
Updating thousands of loco and rolling stock as well as other objects will take years unless a compromise is found. And then there are the creators who are no longer with us.

I can't automate generation of new LOD meshes from a single legacy mesh, unless there is a. a reliable LOD decimator/reductor and b. a windchange in attitudes towards making someone elses assets compliant and uploadable.

So from a repair point of view this is an impasse.

While I appreciate what you are trying to achieve, and long term it is probably a good decision, right now it is unachievable in the quantity and quality we want prior to the next LifeCycle roadblock in Sep 2016.



At the risk of being labelled a rebel and heretic and cast into the wilderness, I would like to point out that the excellent FPS and smooth results that I see in the TANE builtins, I have also witnessed in a number of legacy routes and sessions without the assistance of LOD or LM.

So while we build up a roster of LOD assets to TANE standards, can I suggest a moratorium on the <500 poly issue, combined with greater help for creators to achieve more efficient meshes and textures.

In addition, what are your plans for making TANE DX12 capable? Right now we are starting to see NVidia drivers that are DX12 for higher capable cards, but I would expect that Microsoft's promise that this can be extended down to existing FERMI based cards may well happen in 2016. Can TANE performance be improved significantly by being DX12 capable?

One last final word for the benefit of those seeing CTDs, for goodness sake sort out your pagefile criteria. I haven't had a crash in months. Even taking into account that I have a high end rig, you can't get a worse environment than simultaneously using beta copies of WIN10, NVidia driver, TANE trainzdev build and an advanced AssetX/PEVTools/TARDIS toolbox in conjunction with all the DLS hosted assets.

whitepass
October 14th, 2015, 05:00 PM
After un-zipping I get a not a win32 program when trying to run TANE.exe.

JCitron
October 14th, 2015, 05:23 PM
After un-zipping I get a not a win32 program when trying to run TANE.exe.

This sounds like a corrupted download. I got the same and just finished downloading again but haven't unzipped yet.

WindWalkr
October 14th, 2015, 07:43 PM
In your dreams you might have fixed it:

Thanks. Will send this back for more investigation. Looks like the fix is only partial.



I have alpha numbering working correctly on a traincar with 'trainz-build 3.5' set.

As soon as the same traincar is up-versioned to 4.2 (with no other changes) no errors are reported but alpha-numbers are totally broken. This appears in the log:



- VE171: Expected texture file type but found 'loco_alpha_numbers/alphanumber_7.tga' for 'arc:fld:$(local)/hash-CF||kuid2 122285 700 1.tzarc|'
- VE171: Expected texture file type but found 'loco_alpha_numbers/alphanumber_1.tga' for 'arc:fld:$(local)/hash-CF||kuid2 122285 700 1.tzarc|'
- VE171: Expected texture file type but found 'loco_alpha_numbers/alphanumber_3.tga' for 'arc:fld:$(local)/hash-CF||kuid2 122285 700 1.tzarc|'


Would you care to translate?

The game expected to find a texture file ("*.texture.txt") but was provided an image file ("*.tga"). There are two problems here:

1. You are assumedly providing the wrong file format. This is something that needs to be fixed on your end.
2. The game doesn't provide you with any way to specify the right file format. This is something that needs to be fixed on our end.



Since its a numbered error why doesn't it appear on CM validation?

As to why it appears when it does- this is a runtime failure.

As to why it doesn't also flag the content as faulty- obviously we don't have any validation for this issue. It's not automatic because these are not referenced directly from any config file or mesh. I'll add a request to get some.




Where and exactly what are you expecting to find, and since this appears to be a change of specification where have you advised us of it?

On the contrary, I've regularly advised that all in-game textures MUST be *.texture format in T:ANE. You will see failures across the board if you try to make T:ANE-versioned assets which don't follow this.

chris

WindWalkr
October 14th, 2015, 07:57 PM
I would like to point out that the excellent FPS and smooth results that I see in the TANE builtins, I have also witnessed in a number of legacy routes and sessions without the assistance of LOD or LM.

Of course you can. That's why we're getting more strict about this as time goes on. The scale and density of a route from back in the early days is very, very different from what we've been seeing since 2010. I would definitely encourage route builders to keep things sensible, but at the same time it's stupid to penalise the end result just because the content is not up to par. LOD isn't a new technique, but we've all done a pretty lousy job of utilising it prior to this point. We're not throwing out all of the older content that is often excellent in every other way, but we are saying "no" to new content which is severely below par in this area. This is our way of phasing out the problematic content over time.



In addition, what are your plans for making TANE DX12 capable?

It's certainly something that I'm interested in. We're taking a wait-and-see approach for now. This is something that we're likely to tackle for a future product release once things settle down a bit and we're happy that the gains will prove worthwhile. I would expect that performance gains will vary depending on the nature of the scene, and depending on how well the DX11 drivers were optimised to start with.

chris

Pencil42
October 15th, 2015, 01:39 AM
* Add support for 'emissive' material color.
* Add limited support for 'self-illumination' script functions and update the script comments to explain why these functions are not recommended.


Hi Chris,

Can you explain the above a little more (or point me to the documentation?) The numbers on my loco still aren't lighting up when the headlight is turned on. The loco uses a default-night mesh for the numbers. KUID2:124060:1029:1; on the DLS.

TS12:
http://www.carsoncarshops.com/images/web/ts12_light.jpg

TANE 78924:
http://www.carsoncarshops.com/images/web/tane_light.jpg

Thanks!
Curtis

andi06
October 15th, 2015, 05:07 AM
The game expected to find a texture file ("*.texture.txt") but was provided an image file ("*.tga"). There are two problems here:

1. You are assumedly providing the wrong file format. This is something that needs to be fixed on your end.
2. The game doesn't provide you with any way to specify the right file format. This is something that needs to be fixed on our end.

No, there is only one problem and its at your end. Since seeing the error I've been providing both 'loco-alphanumbers/alphanumber_?.tga' and 'loco-alphanumbers/alphanumber_?.texture.txt' but the game refuses to use the latter. :)


As to why it appears when it does- this is a runtime failure.
There seem to be a significant number of script and content errors reported in the logs and nowhere else. The end result of many of these is that content is failing silently. Why can't we go back to visible runtime exceptions so that we can all see that we have a problem and have a fighting chance of fixing it. It really isn't helpful to have all these errors hidden away in a file that few will look at, and even fewer will understand.

WindWalkr
October 15th, 2015, 06:09 AM
Can you explain the above a little more (or point me to the documentation?) The numbers on my loco still aren't lighting up when the headlight is turned on. The loco uses a default-night mesh for the numbers. KUID2:124060:1029:1; on the DLS.


Regular nighmode support is documented here (http://online.ts2009.com/mediaWiki/index.php/KIND_Scenery#nightmode).

I've added documentation for KIND Traincar light-linked meshes here (http://online.ts2009.com/mediaWiki/index.php/KIND_Traincar#mesh-table_Usage).


Emissive lighting is very briefly mentioned here (http://online.ts2009.com/mediaWiki/index.php/CCG/Modelling:_Bump_Mapping_Information), but there's not really enough information and somebody with Max experience might want to consider adding more information (specifically, the various Material Types (http://online.ts2009.com/mediaWiki/index.php/Material_Types) subpages sound like a good place for this.)


The scripted support for emissive control is best documented in the MeshObject.gs script interface, however I would avoid this unless you have a very specific requirement for it.

kind regards,

chris

WindWalkr
October 15th, 2015, 06:11 AM
There seem to be a significant number of script and content errors reported in the logs and nowhere else. The end result of many of these is that content is failing silently. Why can't we go back to visible runtime exceptions so that we can all see that we have a problem and have a fighting chance of fixing it. It really isn't helpful to have all these errors hidden away in a file that few will look at, and even fewer will understand.

I'm not really sure what you're talking about here. What "visible runtime exceptions" are you referring to? Surely you're not asking the program to crash whenever a minor fault is detected- take a quick look at the volume of data sent to the logs as a good example of what that would do to stability.

chris

andi06
October 15th, 2015, 08:04 AM
Surely you're not asking the program to crash whenever a minor fault is detected.
Of course not.
Here is an edited extract from one of my logs:


- SplineSpec29::Init> Failed to initialise collision data for Protrack B No Ballast/Dark Timber - <kuid2:122285:80104:1>
! ProductSpec> missing 'icon-texture' tag for product '<kuid:-3:11061> "Passengers"'
! MeshObject::SetMeshAnimationState> <kuid:-1:3577> "Tside Crossing2": mesh index (0) has no animation frames
! ProductSpec> missing 'icon-texture' tag for product '<kuid:-25:987> "Logs"'
! MeshObject::SetMeshAnimationState> <kuid:316:27007> "Hyde Pulp Mill": mesh index (0) has no animation
- VE171: Expected texture file type but found 'loco_alpha_numbers/alphanumber_7.tga' for 'arc:fld:$(local)/hash-CF||kuid2 122285 700 1.tzarc|'
- VE171: Expected texture file type but found 'loco_alpha_numbers/alphanumber_1.tga' for 'arc:fld:$(local)/hash-CF||kuid2 122285 700 1.tzarc|'
- VE171: Expected texture file type but found 'loco_alpha_numbers/alphanumber_3.tga' for 'arc:fld:$(local)/hash-CF||kuid2 122285 700 1.tzarc|'
- VE168: File 'lamp.texture' is not a valid compiled texture file for 'arc:fld:$(local)/hash-46||kuid2 51536 9212 4.tzarc|'
- FXCorona::Init> unable to create texture instance for: "lamp.texture"
? ScriptableObject::CallScriptInit> <kuid2:122285:300:5>
? ScriptableObject::CallScriptInit> <kuid2:122285:508:22>
; Constructors::NewBrowser> called before user interface initialised (file constructors.gs)
; *** DUMPING ALL THREAD STACKS ***
; *** STACK DUMP OF THREAD 0 ON GAME OBJECT (null), id 9323 ***
; function $void@Superscript::WeatherMonitor(), line -1
; File mbss.gs, Line 52, ER_NullReference
; *** DUMPING ALL THREAD STACKS ***
; *** STACK DUMP OF THREAD 0 ON GAME OBJECT (null), id 9323 ***
; function $void@Superscript::WeatherMonitor(), line -1
; Stack Dump...
; function $void@MBSS::MessageBox(bool,string), line -1
; function $void@MBSS::MessageBox(string), line 65
; function $void@MBSS::SetParent(TrainzGameObject,bool), line 41
; function $void@Superscript::Init(Asset), line 590
; Unable to load Code Library <kuid:122285:508>
- FXCorona::Init> unable to create texture instance for: "lamp.texture"

My point is that some of these (alpha-numbers, textures etc) are errors which will be causing the respective assets to fail in some way. The script error we have already discussed and is due to the script trying to execute inside the Preview window.

If these failures are silent and the only evidence is hidden away inside a file which few will look at how are they ever going to get fixed?

If any of these errors are significant (and if they are not they probably shouldn't be in the logs anyway) it would be far better in my view if they were notified via the interface, at least in Developer mode. Not only would this draw the creator's attention to the problem but it would be a strong incentive to deal with it.

andi06
October 15th, 2015, 08:10 AM
Regular nighmode support is documented here (http://online.ts2009.com/mediaWiki/index.php/KIND_Scenery#nightmode).
I've added documentation for KIND Traincar light-linked meshes here (http://online.ts2009.com/mediaWiki/index.php/KIND_Traincar#mesh-table_Usage).
Emissive lighting is very briefly mentioned here (http://online.ts2009.com/mediaWiki/index.php/CCG/Modelling:_Bump_Mapping_Information), but there's not really enough information and somebody with Max experience might want to consider adding more information (specifically, the various Material Types (http://online.ts2009.com/mediaWiki/index.php/Material_Types) subpages sound like a good place for this.)
The scripted support for emissive control is best documented in the MeshObject.gs script interface, however I would avoid this unless you have a very specific requirement for it.
You neglect to mention that traincar nightmode isn't currently working at all, which is almost certainly the reason why Curtis's loco is broken.

WindWalkr
October 15th, 2015, 08:31 AM
You neglect to mention that traincar nightmode isn't currently working at all, which is almost certainly the reason why Curtis's loco is broken.

Firstly, I'm not entirely sure what you're referring to. Have you got an example which exhibits the fault that you're describing?

Secondly, the example that curtis gave didn't use nightmode.

chris

WindWalkr
October 15th, 2015, 08:44 AM
If these failures are silent and the only evidence is hidden away inside a file which few will look at how are they ever going to get fixed?

If any of these errors are significant... it would be far better in my view if they were notified via the interface, at least in Developer mode. Not only would this draw the creator's attention to the problem but it would be a strong incentive to deal with it.

You mean add a new UI to display whenever an error is written to the logs? That's possible but would be exceedingly spammy. It's the kind of thing that would be quite useful when you're working on a single asset, but falls apart when you start working at the route level. It could make sense to do this kind of thing with the asset preview window.



..if they are not (significant) they probably shouldn't be in the logs anyway..

Significance is in the eye of the beholder. Some examples:

* If you trigger a fault accidentally, and it causes your content to stop working, you want to know about it.
* If you trigger a fault but don't care about that particular fault, then not only do you not want to know about it, but you'd prefer nobody else knew about it either. I obviously don't encourage this, but we have to acknowledge that it's common for people to send invalid requests through various script APIs and assume that they will silently fail, or deliberately omit a required-per-spec file from certain assets because they don't want the functionality that the file would provide.
* If you trigger a fault but don't understand how to fix it, and it's not hurting your gameplay experience, then the chances are you don't want to be bugged about it.
* If you trigger a fault and it IS hurting your gameplay experience, you'd like to know about it so that you can attempt to resolve the problem.

The computer frequently does not have the context to decide whether the problem is significant, which is why these logs exist. In a scenario where we know about the problem in advance, we can add validation code to generate a per-asset warning or error. In a scenario where we're fairly sure that the problem is serious, we have script exceptions. For everything else, we now have the log window, and I do expect that content creators will use this facility. It's definitely something new in T:ANE and it will take some time to be able to sort out what's important, but it's a useful tool and it shows you a lot of information that would previously have been completely hidden from end users.

chris

andi06
October 15th, 2015, 08:50 AM
Firstly, I'm not entirely sure what you're referring to. Have you got an example which exhibits the fault that you're describing?
All of my traincars (and many others) light up at night in TS12 using various techniques, mainly a default-night submesh. The only ones that work (partially) in TANE are those which use a reflective texture for part of the effect. Do you need specific kuids?


Secondly, the example that curtis gave didn't use nightmode.

The loco uses a default-night mesh for the numbers.

Pencil42
October 15th, 2015, 08:57 AM
the example that curtis gave didn't use nightmode.

Thanks Chris,

The loco does use nightmode; at least, I believe that the number mesh in the 'default-night' container qualifies as nightmode. I was conflating the emissive fixes in the change log with fixes to nightmode. I'll wait to test again until you specifically mention 'nightmode fixed' :)

Thank you for the documentation; I may be able to add something for Blender.

Curtis

andi06
October 15th, 2015, 09:16 AM
I do expect that content creators will use this facility.
That may be a triumph of expectation over reality.

I agree that the logs are useful, they would be more useful if you included some filtering facilities - life is way too short to scan files of this size on a regular basis.

To look at practical implications take a look at two specific examples:

The script exceptions related to Superscript: These have come about because you have introduced a new context for script (the Preview window) which Superscript had no prior knowledge of and didn't allow for. I definitely want to know about it because I don't want my assets showing up in logs with the word error attached, but I'm not working on that asset at present and I've no reason to go looking for problems with it. As a result these entries were uncovered by accident and I'm saying that a visible exception would have turned them up sooner and with more certainty.

Problems with alpha numbers: This time I have been working on the asset concerned but not on the alpha number system. Since you have stated that 'if it works in TS12 it should also work in TANE' there was no reason to suppose that alpha numbers should be broken. Again by accident I noticed that they weren't working and went looking for the cause. Since I am currently re-exporting all of the meshes the log wasn't the first place that I looked. In this case I think we probably agree that this issue should be picked up by CM (and the existence of a fonts-path tag should be enough for you to find it) but there will be similar cases.


Significance is in the eye of the beholder.
Up to a point yes, but I would have thought that if it affects gameplay you should be publicising it as widely as possible, irrespective of the creator's motives. No matter how useful you or I might see the logs as being the details are going to be more or less invisible to most people, including many of those who ought to be reponsible for fixing the items concerned.

Pencil42
October 15th, 2015, 10:10 AM
Pure emmisive lights (non-nightmode) appear to be working for me now:
TANE HF2:
http://www.carsoncarshops.com/images/web/tane_hf2_lamps.jpg

Test build 78924:
http://www.carsoncarshops.com/images/web/test_lamps.jpg

Curtis

WindWalkr
October 15th, 2015, 10:37 AM
..light up at night.. mainly a default-night submesh. The only ones that work (partially) in TANE are those which use a reflective texture for part of the effect. Do you need specific kuids?

A specific asset would be good, yes.

To be clear, "default-night" is not nightmode, and IS what curtis' example is doing. However, read the documentation link that I provided above on why that won't be enough by itself. As far as I can tell, there's no change in behaviour as compared to TS12 here.

chris

WindWalkr
October 15th, 2015, 10:49 AM
The loco does use nightmode; at least, I believe that the number mesh in the 'default-night' container qualifies as nightmode.

No; they're two separate concepts. Both "default-night" and "nightmode" are described in the links I gave you, and they're not related to each other.

In short, "default-night" is a mesh-table entry with a hardcoded name which changes visibility based on the traincar's spotlight configuration and a few related parameters. I don't see anything about changing the emissive color of those meshes or any other rendering details.

"nightmode" is a mechanism for selecting whether a given asset shows its night meshes. Night meshes are always parented to some other mesh, and are only shown if the parent mesh is visible. Night meshes in TS12 were always shown without being affected by the world lighting model. This is not an option in E2, so they get an emissive color set on them instead.

I suspect that this emissive color change won't apply on a non-stitched mesh, which might explain Andi's complaint- however that's not related to "default-night" which your example uses.




I was conflating the emissive fixes in the change log with fixes to nightmode. I'll wait to test again until you specifically mention 'nightmode fixed' :)

I'm not aware of any problem with the example you gave. I didn't see anything there which would toggle "night lighting". If you think that there's still an issue, you'll have to spell it out to me.

chris

WindWalkr
October 15th, 2015, 11:03 AM
That may be a triumph of expectation over reality.

Perhaps, but at the end of the day you can only lead the horse to the water.



I agree that the logs are useful, they would be more useful if you included some filtering facilities - life is way too short to scan files of this size on a regular basis.

Yeah, I completely agree and it's been on the list for over a year now :)



To look at practical implications take a look at two specific examples:

The script exceptions related to Superscript: These have come about because you have introduced a new context for script (the Preview window) which Superscript had no prior knowledge of and didn't allow for. I definitely want to know about it because I don't want my assets showing up in logs with the word error attached, but I'm not working on that asset at present and I've no reason to go looking for problems with it. As a result these entries were uncovered by accident and I'm saying that a visible exception would have turned them up sooner and with more certainty.

It would; one option here would be to add a script exception notification to the preview window. There are substantial problems with that though; adding a GUI and the associated rendering costs defeats the purpose of having the accurate measurement tools in this window. One option would be to offer several modes for the window, one of which shows the UI and one of which shows the render stats. Another (perhaps better, but definitely longer term) option would be to take the script exception UI out of the 3D view altogether and put it into the native UI.




Problems with alpha numbers: This time I have been working on the asset concerned but not on the alpha number system. Since you have stated that 'if it works in TS12 it should also work in TANE' there was no reason to suppose that alpha numbers should be broken.

If we're still talking about the same thing, then it's a 4.2 asset and won't actually work in TS12, believe it or not :)

That said, there are definitely cases where we choose to not retain compatibility because the performance of the feature was horrible.



Again by accident I noticed that they weren't working and went looking for the cause. Since I am currently re-exporting all of the meshes the log wasn't the first place that I looked. In this case I think we probably agree that this issue should be picked up by CM (and the existence of a fonts-path tag should be enough for you to find it) but there will be similar cases.

Again, this comes down to how to notify the user without being a nuisance. When it's just your model, we could very reasonably expect that you want to know about every problem. When it's an entire route, you really don't want to go there, unless you were planning to set a day aside (in which case the logs work brilliantly.)

This is always something of a balance, and as you say there are things that definitely need to be picked up by validation rather than being left to runtime. I think in the short term the logs serve the necessary purpose here and we just need to learn to use them. One option for testing in the preview window might be to build a log viewer onto the bottom of the window, so that you don't forget to look at it.



Up to a point yes, but I would have thought that if it affects gameplay you should be publicising it as widely as possible, irrespective of the creator's motives.

But how do we know if it affects gameplay? That's the million dollar question. It really only affects gameplay if the user thinks it does. There are many, many errors which are legitimate failures but the user just doesn't care about. Take a look at the complaints that traditionally arise every time we improve validation as a good example of this.

In your specific example, if a user was using your updated asset, never knew that it was supposed to have running numbers, and one day we added validation for this issue- in his eyes, we just took a perfectly good asset and broke it.

chris

Pencil42
October 15th, 2015, 11:07 AM
I'm not aware of any problem with the example you gave. I didn't see anything there which would toggle "night lighting". If you think that there's still an issue, you'll have to spell it out to me.

OK:
In TS12, the loco's numbers light up when the headlights are turned on. In TANE, including in this test build, they do not.

Curtis

WindWalkr
October 15th, 2015, 11:15 AM
In TS12, the loco's numbers light up when the headlights are turned on. In TANE, including in this test build, they do not.

"default-night" doesn't cause that. Other possibilities that I can think of:

* The mesh in question is emissive. I'm pretty sure that's working fine in the current builds, so unless there's some fairly odd case, that's not it.
* There's a script running somewhere that is changing the emissive color of that mesh. I didn't spot anything, but I didn't look through all the script includes line-by-line either.
* The mesh is physically in front of the TS12 spotlight. Seems unlikely but I guess it's possible.
* ?? I can't really think of any other ways in which it could be lit up.

chris

andi06
October 15th, 2015, 11:19 AM
Top to bottom, kuids are <kuid:122285:500, 300, 558, 240 and 662> the latest DLS version in each case. The issue actually affects virtually all of my traincars.

All of the assets are set up to show lit interiors irrespective of the headlamp switch (UK traincars don't usually have headlamps) Various techniques are used, most of them include a 'default-night' sub-mesh.

In Surveyor, TS12:
823

The same assets in Surveyor, TANE
824

I've bugged this at least twice and moaned about it here several times.

If I understand the proposals correctly, it will probably be best to to adjust all of these to use the traincar-interior-lighting mechanism - is this working yet?

WindWalkr
October 15th, 2015, 11:21 AM
If I understand the proposals correctly, it will probably be best to to adjust all of these to use the traincar-interior-lighting mechanism - is this working yet?

I haven't retested it, but by memory the only thing stopping it being useful was the lack of emissive color control, which has since been added, so I'd assume that it works.

chris

andi06
October 15th, 2015, 11:31 AM
It would; one option here would be to add a script exception notification to the preview window. There are substantial problems with that though; adding a GUI and the associated rendering costs defeats the purpose of having the accurate measurement tools in this window. One option would be to offer several modes for the window, one of which shows the UI and one of which shows the render stats. Another (perhaps better, but definitely longer term) option would be to take the script exception UI out of the 3D view altogether and put it into the native UI.
How you do it is your problem chuck :). Do you actually need to run scripts in Preview?


That said, there are definitely cases where we choose to not retain compatibility because the performance of the feature was horrible.
Fair enough, but you need to tell us about it and the log is not a good place to do so.


Again, this comes down to how to notify the user without being a nuisance. When it's just your model, we could very reasonably expect that you want to know about every problem. When it's an entire route, you really don't want to go there, unless you were planning to set a day aside (in which case the logs work brilliantly.)
Simple really, if the kuid of the asset with the problem is the same as that of the current user you notify, if it isn't then leaving it in the log will usually be fine.


One option for testing in the preview window might be to build a log viewer onto the bottom of the window, so that you don't forget to look at it.
OK but please be sure to leave some screen space for the Preview itself.


In your specific example, if a user was using your updated asset, never knew that it was supposed to have running numbers, and one day we added validation for this issue- in his eyes, we just took a perfectly good asset and broke it.
So instead of this you break a perfectly good asset anyway and make sure that even the creator may never find out about it.

andi06
October 15th, 2015, 12:14 PM
I haven't retested it, but by memory the only thing stopping it being useful was the lack of emissive color control, which has since been added, so I'd assume that it works.

Looks like you're wrong again!

Tags added:
- interior-light-texture "autocoach-autocoach.texture"
- interior-light-color 200,200,200

As advertised this triggers a switch in object properties but the train remains dark.

Pencil42
October 15th, 2015, 06:03 PM
Is it possible that meshes in the default-night container in TS12 and before were displayed at full brightness; whereas in TANE the scene lighting is being applied?

Curtis

WindWalkr
October 15th, 2015, 07:18 PM
- interior-light-color 200,200,200

These are decimal values btw, so you probably want 1.0, 1.0, 1.0 or less.

I take it that you're placing a call to SetInteriorLightState()?

chris

WindWalkr
October 15th, 2015, 07:19 PM
Is it possible that meshes in the default-night container in TS12 and before were displayed at full brightness

It doesn't appear that this was the case.

chris

WindWalkr
October 15th, 2015, 07:25 PM
How you do it is your problem chuck :).

Well, yes and no. What we already have works fine for me, it's you who thinks it needs changing.



Do you actually need to run scripts in Preview?

Yes, unless you expect that all objects will look correct without having Init() called. This would mean disallowing any kind of visual (mesh, texture, material, pfx, etc.) manipulations in Init(), which I think a lot of people would be unhappy about.



Simple really, if the kuid of the asset with the problem is the same as that of the current user you notify, if it isn't then leaving it in the log will usually be fine.

Perhaps. It has merit, but I can also see cases where this would fall down. Admittedly, the few people this wouldn't work for would be more likely to understand the limitations of what they're doing.



So instead of this you break a perfectly good asset anyway and make sure that even the creator may never find out about it.

Actually, we didn't break anything in this example. The asset in question never worked in its current form. As the creator, you're aware of what it's supposed to do and the onus is on you to take a look at the logs if you don't understand why something is not working.

chris

ianwoodmore
October 15th, 2015, 07:29 PM
OUCH

I was doing some work on queues in aliased assets and in particular the animation "load" that appears in many assets. In this instance it should have read 'topdoor\ etc.

kuid:-10:199 has been obsoleted by kuid:-25:472. It appeared as if I had modified a builtin so I deleted modified copy, but instead of reverting to 'Builtin' it disappeared.

Using CM and Author #-25 does not show kuid:-25:472 either builtin DL or obsolete. Nada.

I was then able to download kuid:-10:199 as if it had never been superseded by kuid:-25:472. This I confirmed by using 'List Asset Versions'.

backups show kuid:-25:472 as a tzarc, but how do I restore it? I've never ever had to use the backups before so I'm dumb on this. Ideally I would like to drag and drop into CM content window.

A further check in TS12 confirms that kuid:-25:472 was a builtin.
Crosschecking with my other TANE instal does not show kuid:-25:472 as a builtin.

Thus it is probably supposed to be on its way to DLS. I've not been able to find it even in the hidden helpdesk folder. So it is MIA.

WindWalkr
October 15th, 2015, 08:21 PM
<kuid:122285:500>

Yep, this is pretty much as I suggest above, and should be fixed for the next build.

chris

WindWalkr
October 15th, 2015, 09:07 PM
I've also updated some of the documentation on the wiki. I'd recommend that people have a read through the updates, because it provides detail that was not previously documented as well as going into some upcoming (v4.3) changes.

chris

Pencil42
October 16th, 2015, 12:47 AM
It doesn't appear that this was the case.


Well, I just re-exported the numberboards, but added an emissive ("emit") component of 80% in Blender, and now it's working in this test build. Before, the emit for the material was set to '0', so TS12 would have had to be rendering them at full brightness by default (since the numberboards light up correctly in that version of Trainz.)

With the new emitting numberboards in 78924:
http://www.carsoncarshops.com/images/web/tane_emit.jpg

Curtis

WindWalkr
October 16th, 2015, 03:50 AM
Before, the emit for the material was set to '0', so TS12 would have had to be rendering them at full brightness by default (since the numberboards light up correctly in that version of Trainz.)

Are these things using the native running-number support? Perhaps it's something to do with that, rather than anything to do with the "default-night" feature.

chris

andi06
October 16th, 2015, 05:15 AM
These are decimal values btw, so you probably want 1.0, 1.0, 1.0 or less.
rgb colour specifications in config generally offer a choice between integer values in the range [0..255] and float values in the range [0.0..1.0] I always use the integer variant since its easy to get the necessary values from other software.

Are you saying that the integer variant is not available for the interior-light-color tag? (Its defined as 'vector3' which is the same as any other rgb tag.) Or are you saying that interior-light-color is some form of multiplier?

Your phrase on the wiki: 'fragment_lighting = emissive_color + (diffuse_color * light_color) + specular_term' may hold the key to this, if it were in english rather than bergmannese.


I take it that you're placing a call to SetInteriorLightState()?
No, the documentation states that lights will be on by default and the object property editor confirms that this is so.


What we already have works fine for me, it's you who thinks it needs changing.
Perhaps, but you write software and we create 3d models. I rather thought that one of the points of this forum was to give you a better feel of the implications of what you do on what we do. If we were to change roles then who knows where we would be (except that compile would have been working three months ago :))


Actually, we didn't break anything in this example.
Then let's redefine some terms. The act of upgrading an asset to trainz-build 4.2 breaks alpha numbering by introducing additional requirements on the alpha-number sources. This is important because at some point in the future the lowest build which can be uploaded to the DLS will be 4.2 and any existing models which are repaired will be forced to use that build. This will mean that alpha-numbering will suddenly stop working on assets which are ostensibly error-free.


<kuid:122285:500> Yep, this is pretty much as I suggest above, and should be fixed for the next build.
Its become a complicated thread, what exactly do you mean by 'pretty much as I suggest above'?

WindWalkr
October 16th, 2015, 08:56 AM
rgb colour specifications in config generally offer a choice between integer values in the range [0..255] and float values in the range [0.0..1.0] I always use the integer variant since its easy to get the necessary values from other software.

Are you saying that the integer variant is not available for the interior-light-color tag? (Its defined as 'vector3' which is the same as any other rgb tag.) Or are you saying that interior-light-color is some form of multiplier?

Umm.. no?

I'm not sure what you're thinking of, but the choice of unit is never optional, because it's not specified anywhere- so for example, the code would have no way of knowing whether "1, 1, 1" was near black or fully white if you were correct.

What is probably true is that different tags use different units, which is unfortunate, but doesn't change my statement.




No, the documentation states that lights will be on by default and the object property editor confirms that this is so.

Yep, you're right- it's actually default off, but there's a call in the native code to perform this once the object is created.

That leaves me with no real thoughts on why it might be failing. If you've got a model available, send it in and i'll take a look. Otherwise, we'll have to wait until I've had a time to get back to this.



I rather thought that one of the points of this forum was to give you a better feel of the implications of what you do on what we do.

To some extent, that's definitely true. If I don't see a particular path that is better place than where we are now, however, and you're not offering any suggestions, then that leaves us at a bit of an impasse. So far you've raised some valid points, but we also have some reasonable counterpoints illustrating why there are not necessarily any trivial solutions. I'm not going to take a step which makes your life better but everybody else's life worse.

That's not to say that there is nothing that can be done; certainly we've touched on a few areas where what we have now could potentially be improved in the future. But so far, we certainly haven't come up with any kind of "eureka" solutions.



The act of upgrading an asset to trainz-build 4.2 breaks alpha numbering by introducing additional requirements on the alpha-number sources. This is important because at some point in the future the lowest build which can be uploaded to the DLS will be 4.2 and any existing models which are repaired will be forced to use that build. This will mean that alpha-numbering will suddenly stop working on assets which are ostensibly error-free.

Yup, completely agree with all of this. But it means that the example is not relevant to your point. In a different world, where we broke it for existing content, for example- sure, that would be a different outcome.



Its become a complicated thread, what exactly do you mean by 'pretty much as I suggest above'?

This bit: I suspect that this emissive color change won't apply on a non-stitched mesh, which might explain Andi's complaint- however that's not related to "default-night" which your example uses.

But you're right, we should split this into separate threads, discussing the separate issues.

chris

andi06
October 16th, 2015, 12:13 PM
What is probably true is that different tags use different units, which is unfortunate, but doesn't change my statement.
OK, but given that most tags, smoke colours for instance use 0..255 you have left it unclear just how 'interior-light-color' is supposed to work. The notes in the wiki don't help much, for example you state 'Colors are defined in the RGB color space and typically range between 0, 0, 0 (for no light, or "black") to 1, 1, 1 (for full light, or "white".) Trainz supports HDR colors beyond 1, 1, 1 for "overbright" objects.' Using the 0.0..1.0 notation how can something be brighter than 1,1,1?


That leaves me with no real thoughts on why it might be failing.
I will send you a model.


I don't see a particular path that is better place than where we are now, however, and you're not offering any suggestions, then that leaves us at a bit of an impasse. So far you've raised some valid points, but we also have some reasonable counterpoints illustrating why there are not necessarily any trivial solutions. I'm not going to take a step which makes your life better but everybody else's life worse.
I've made several suggestions but please try to remember that you have the advantage of knowing exactly how your code works. You also have a tendency to think up possible (and often very obscure) exceptions to anything that is put forward here.

Here is a more detailed strategy:
- 1. Provide filters in the log, make sure that one of the options is the users own userid.
- 2. Add an additional checkbox to the Dev tab on Launcher settings, label it 'Notify Log Errors'. If this is checked then pop up a message box when any trainz session ends with the text 'Errors have been logged which might affect your assets, View Log?'


Yup, completely agree with all of this. But it means that the example is not relevant to your point. In a different world, where we broke it for existing content, for example- sure, that would be a different outcome.
The text in red just doesn't make sense. I'm warning you of a potential time bomb which will result from the alpha-number changes - don't you think that this is relevant?


Separate Threads
Not much I can do at this stage but I will make a point of responding in a new thread when you post that a new build is available.

andi06
October 16th, 2015, 03:48 PM
http://forums.auran.com/trainz/images/misc/quote_icon.png Originally Posted by andi06 http://forums.auran.com/trainz/images/buttons/viewpost-right.png (http://forums.auran.com/trainz/showthread.php?p=1450155#post1450155)

rgb colour specifications in config generally offer a choice between integer values in the range [0..255] and float values in the range [0.0..1.0] I always use the integer variant since its easy to get the necessary values from other software.



Umm.. no?
I'm not sure what you're thinking of, but the choice of unit is never optional, because it's not specified anywhere- so for example, the code would have no way of knowing whether "1, 1, 1" was near black or fully white if you were correct.


Umm.. yes.

try these:

smoke0 {
color 128,128,128,128
}

smoke0 {
color 0.5,0.5,0.5,0.5
}

You will find that they give the same result in game. As for what happens with 1,1,1 - you tell me - you wrote the software. :)

WindWalkr
October 16th, 2015, 08:44 PM
Using the 0.0..1.0 notation how can something be brighter than 1,1,1?

Look at your screen displaying white. You'd agree that this is 1,1,1?

Now turn up the brightness. Still 1, 1, 1?

Now walk outside and look at the sun- actually, don't do this! but hopefully you get my point :)


Specifically, HDR (https://en.wikipedia.org/wiki/High-dynamic-range_rendering).

For any given scene, the highest color that can be represented in the output is 1, 1, 1, because that's the brightest your screen can manage. But there's no reason that any given intermediate value can't exceed that range. Exceeding that range is very useful; take the following contrived example:

* You have two white materials, one which is 1, 1, 1, and the other which is 10, 10, 10.
* You see these as 1, 1, 1 and 1, 1, 1.
* You place a 25% transparent dark sheet of glass in front of them.
* You can now see the two materials as 0.25, 0.25, 0.25 and 1, 1, 1.

This gets much more interesting when you consider post-processing effects such as bloom, tonemapping, and exposure controls.



- 1. Provide filters in the log, make sure that one of the options is the users own userid.

Yep. As stated above, this is already on our list and will definitely happen.



- 2. Add an additional checkbox to the Dev tab on Launcher settings, label it 'Notify Log Errors'. If this is checked then pop up a message box when any trainz session ends with the text 'Errors have been logged which might affect your assets, View Log?'

Can do, but I honestly don't think you will find this useful.



The text in red just doesn't make sense. I'm warning you of a potential time bomb which will result from the alpha-number changes - don't you think that this is relevant?

I think you are making two separate points here. I am replying to your comment about us breaking existing content and not letting the user know about it. That simply isn't the case here. The issue that you're talking about does not apply to existing content.



Not much I can do at this stage but I will make a point of responding in a new thread when you post that a new build is available.

Yeah. It's not about responding automatically in a new thread. It's about bringing up new topics in a new thread, rather than just tagging them into whichever thread sparked the idea.

chris

andi06
October 17th, 2015, 12:47 AM
Look at your screen displaying white. You'd agree that this is 1,1,1?
Now turn up the brightness. Still 1, 1, 1?
Now walk outside and look at the sun- actually, don't do this! but hopefully you get my point :)
You, and computer scientists in general are confusing (combining if you prefer) colour and intensity, like trying to describe the pitch of a musical note and its amplitude in the same metric. However I can see how it might be useful to do so.


I think you are making two separate points here. I am replying to your comment about us breaking existing content and not letting the user know about it. That simply isn't the case here. The issue that you're talking about does not apply to existing content.
Not really, the issue that I'm talking about does not apply to existing content yet, but it will do so in the future.

You can hedge all you like but the reality is that whatever you set up for 4.2 content will eventually apply to existing content as a natural result of your support and DLS policies, unless the existing content either fades away or successfully anticipates where the goalposts are going to be in the future.

WindWalkr
October 17th, 2015, 01:03 AM
You, and computer scientists in general are confusing (combining if you prefer) colour and intensity, like trying to describe the pitch of a musical note and its amplitude in the same metric. However I can see how it might be useful to do so.

Or perhaps more accurately, you are confusing the human ideas of the world with the reality of the world. We cannot perceive colour and intensity of light separately, nor can we perceive absolute material color without context, although our brains do an interesting job of trying. This leads to a lot of optical illusions such as the dress (https://en.wikipedia.org/wiki/The_dress_(viral_phenomenon)) and the checker shadow illusion (https://en.wikipedia.org/wiki/Checker_shadow_illusion).

chris

Pencil42
October 17th, 2015, 01:28 AM
Are these things using the native running-number support? Perhaps it's something to do with that, rather than anything to do with the "default-night" feature.


No, just a simple, unscripted rectangle; referenced in the default-night container.

Curtis

andi06
October 17th, 2015, 02:06 AM
Or perhaps more accurately, you are confusing the human ideas of the world with the reality of the world. We cannot perceive colour and intensity of light separately, nor can we perceive absolute material color without context, although our brains do an interesting job of trying. This leads to a lot of optical illusions such as the dress (https://en.wikipedia.org/wiki/The_dress_(viral_phenomenon)) and the checker shadow illusion (https://en.wikipedia.org/wiki/Checker_shadow_illusion).

chris
JHC. Read my post again and tell me where I refer to perception. Colour and intensity, frequency and amplitude are distinct and separately measurable properties of light and sound and are both totally independent of human perception.

WindWalkr
October 17th, 2015, 04:10 AM
No, just a simple, unscripted rectangle; referenced in the default-night container.

Okay, thanks. I'll add a task for this to be reviewed more thoroughly. There's no obvious reason why these should be treated any differently from any other mesh.

kind regards,

chris

WindWalkr
October 17th, 2015, 04:22 AM
JHC. Read my post again and tell me where I refer to perception. Colour and intensity, frequency and amplitude are distinct and separately measurable properties of light and sound and are both totally independent of human perception.

You don't, and that's my point. In the real world, light most definitely has "frequency" and "amplitude" among other properties (if you're looking at classical physics anyway; let's not start discussing quantum behaviour here.) Humans can't actually detect that; we're limited to detecting amplitude of ~2-4 distinct color bands. Computer displays work by emitting light in 3 color bands which overlap fairly well with the common 3 bands that humans can perceive. You already know all this, but you seem to be forgetting what it means to us:

From the perspective of both the computer and the human, there is no difference between color and amplitude. Changing the amplitude of one of the channels changes the perceived color.

Given that we understand the human perceptual model very well, we can give the illusion of varying the intensity of light without varying the underlying colour, at least within a certain range supported by the hardware.

It's not just "useful to do so", it's the only possible way to look at this given the limitations of human perception and the display technologies that we use.

chris

JCitron
October 17th, 2015, 11:17 AM
OUCH

I was doing some work on queues in aliased assets and in particular the animation "load" that appears in many assets. In this instance it should have read 'topdoor\ etc.

kuid:-10:199 has been obsoleted by kuid:-25:472. It appeared as if I had modified a builtin so I deleted modified copy, but instead of reverting to 'Builtin' it disappeared.

Using CM and Author #-25 does not show kuid:-25:472 either builtin DL or obsolete. Nada.

I was then able to download kuid:-10:199 as if it had never been superseded by kuid:-25:472. This I confirmed by using 'List Asset Versions'.

backups show kuid:-25:472 as a tzarc, but how do I restore it? I've never ever had to use the backups before so I'm dumb on this. Ideally I would like to drag and drop into CM content window.

A further check in TS12 confirms that kuid:-25:472 was a builtin.
Crosschecking with my other TANE instal does not show kuid:-25:472 as a builtin.

Thus it is probably supposed to be on its way to DLS. I've not been able to find it even in the hidden helpdesk folder. So it is MIA.

Ian,

kuid:-25:472 is also not found, shows as a missing asset, in the retail build as well.

Did you import this at some point from TS12?

Eventually these assets will be ported over to T:ANE at some point in the future.

Regarding the .tzarc files. According to Chris, these are used internally by the program and are not accessible via any kind of interface. I too would think that this -25.. asset you deleted should be in the backup folder, they're arranged by date, as you know. Perhaps if you look in the individual edit(hex#) folders and of one with a particular kuid or name, it should be in there somewhere. T:ANE and TS12 has worked this way for as long as I can remember now, and I don't expect this behavior has changed.

I too don't venture in here often, but they are a good safety net and have restored some things I've deleted or even ruined with an edit. In the past 5 years, I've searched for stuff in these folders maybe 4 times and have found everything I've needed.

John