TNI Where next? Managing content import/export

geophil

Tool Developer
What I have in mind is a notification add-on to Content Manager export and import/commit functions. I tried to explain it in the initial TNI thread:
http://forums.auran.com/trainz/showthread.php?128929-Trainz-Native-Interface&p=1494029#post1494029
http://forums.auran.com/trainz/showthread.php?128929-Trainz-Native-Interface&p=1512550#post1512550

The necessary control flow is bi-directional here. For the flow direction towards the Trainz process (=inbound), a plugin would act as a listener, receive external messages via some interprocess communication mechanism, convert it to internal messages and use some callback mechanism provided by TNI. In my case these messages would be the commands "Import content from specified directory" and "Commit imported content". Such a plugin probably has to be loaded automatically at process startup time. Whether that can be initiated with some form of static registration, config file or the like, I don't know.

For outbound, it means that either an existing Content Manager UI command has to offer an option to register a notification with it, which, again, will probably mean that the associated plugin has to be loaded at startup time, or the plugin must be able to add a custom command to the Content Manager UI. In my case that command would be "Open for edit and notify external listener".

BTW and off-topic: I noticed Content Manager is now using a sans-serif font for its asset list. That's nice.
 
My suggestion would be that we bypass CM entirely and go straight to Surveyor. We don't support writing to our binary file formats so that doesn't give you a lot of options if you're restricted to CM- you could create non-route assets for UTM tiles or whatever, but you couldn't turn around and build a route with them. With a Surveyor interface on the other hand, you could simply tell the game where you want things put and let it take care of the rest.

An example workflow:

* The user opens an existing route in Surveyor, or creates a new route.
* The user selects your plugin (eg. from some "external tools" menu, or similar).
* Your plugin perhaps displays a simple UI to allow the user to customise the operation as required and confirm what action will be performed.
* Your plugin then communicates with the external data source and issues the necessary commands to build/manipulate the route.

Thoughts?

chris
 
But if it's not a route you're editing but another asset, you can't use surveyor.
We have created a tool where you enter some datas as the vehicle mass, the max speed, the power and an equation involving running resistance (we have problem with how trainz handle this, but it's off-topic...).
Then this tool create the config.txt file for all the vehicle involved in the train. For exemple, for a french TGV Duplex (our main used train) it will create 3 config file, 1 for the two loco, 1 for the first and the last car, and 1 for the 6 intermediate cars.
Students will need to use this tool to test their result for a project later this year, and they will need to open for edit the right assets, copy the config.txt file from where it has been exported and then commit this. If we can do this directly it will be a lot simple for students that are not familiar with Trainz, and a huge time saving for students developing this tool.

Geophil, thanks for TransDem, it's a great tool and we've created a 500km routes from Paris to Bordeaux with it :).
 
But if it's not a route you're editing but another asset, you can't use surveyor.
We have created a tool where you enter some datas as the vehicle mass, the max speed, the power and an equation involving running resistance (we have problem with how trainz handle this, but it's off-topic...).
Then this tool create the config.txt file for all the vehicle involved in the train.

Absolutely. In that situation you'd go straight to the asset (whether or not CM should be involved is a question of UI). I'm pretty sure that's not what geophil is talking about here, though.

If all you want to do is edit config files, you possibly don't even need TNI - trainzutil probably offers everything you need there.

chris
 
For me the main objective is to simplify the workflow for the TransDEM user. But it also should avoid major recoding on my side. Therefore, a simple message exchange mechanism would be ideal. If Surveyor can be made to directly export and import entire routes via TNI, in conjunction with such messaging and without involving CM, then that might be an option.
 
As above, we don't support external tools writing directly to our binary formats. There are too many things that can and do go wrong with this approach. TNI isn't about to change that.

What TNI can offer is an alternative where the external tool specifies the intention, and Trainz itself generates the binary files. The simplest approach would be a series of calls such as "create terrain grid spanning <this> area", "place <this> object <here>", "apply <this> texture to <this> vertex", etc. - basically a list of actions similar to what a user would perform in Surveyor.

Sorry, not trying to make life difficult for you, this is just a long-standing policy based on problems that we've repeatedly hit in the past.

chris
 
As above, we don't support external tools writing directly to our binary formats. There are too many things that can and do go wrong with this approach. TNI isn't about to change that.

What TNI can offer is an alternative where the external tool specifies the intention, and Trainz itself generates the binary files. The simplest approach would be a series of calls such as "create terrain grid spanning <this> area", "place <this> object <here>", "apply <this> texture to <this> vertex", etc. - basically a list of actions similar to what a user would perform in Surveyor.
As things are, the TransDEM extension for Trainz is designed around the Trainz route files. It makes heavy use of direct reading and writing to the files or in-memory cache. Changing all these operations to message passing would indeed imply a major redesign and rewriting large parts of this extension. It's a matter of practicality. Performance aspects can also be of concern here. Keep in mind that TransDEM users easily create routes of more than 10,000 baseboards with just a few mouse clicks. As each and every ground vertex will be set by TransDEM, we will quickly reach millions of messages to be passed through TNI, if we address vertices individually, plus interprocess communication between the TNI plugin and TransDEM. It depends on the TNI functions, of course. If bulk operations are made available, that may look different. But then we probably need an intermediate representation format, which may come close to the binary format.
 
To be clear: you're welcome to read from our binary files. That comes with its own problems (for example, the route format in the test build has a lot of variations as compared to the format used in T:ANE SP1) but at the end of the day it either works or doesn't and won't cause ongoing problems for us or the users. It's when we start to encourage writing to the formats that problems start, because most of the support burden is then thrown onto us whether we want it or not. We don't protect the formats; you're welcome to reverse-engineer them and we even support efforts to read from the files by releasing documentation from time to time. There's also no legal impediment to writing the file formats; we don't intend to sue anybody just because they're doing something that's problematic for us. But we don't support it.

You're right that performance will be a concern for large routes, however you're also right that there are relatively simple solutions. I'd expect any bulk APIs to have limited range- for example, we'd probably require you to bring a particular part of the route resident, then edit it, then allow it to be streamed out again before moving on to the next part. We'd also want to use fairly generic primitives rather than tying the API to the disk format, as the disk format and its capabilities change regularly depending on our own requirements. For example, the ground grid used to be 10m x 10m; now it's up to 5m x 5m. In the future, perhaps it won't be a fixed-scale grid at all, or perhaps it won't be a regular heightmap. We don't want to have to rebuild the API and all of the external tools on each such change. Obviously there will be times when a tools upgrade will unlock new features and might be worthwhile for that reason, but we don't want to outright break tools just because we added another ground model, or similar.

chris
 
Back
Top