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.
Interesting post. I wrote, and maintained for a few years, programs that communicated via named pipes either on the same computer or across a LAN. This was aeons ago before sockets got popular. How would two or more programs doing IPC manage a shared memory cache?I... Also, Trainz communicates locally with TADDaemon via TCP/IP sockets, vs a shared memory cache. That would make the asset loads and lookups hella fast...
![]()
Also TADDaemon appears to do a lot of idle thumb twiddling, validating assets that are already validated.. it's not a CPU waster but it's still there.
One thing it definitely is, it's a bloody time waster, sitting there for tens of minutes just validating crap that it's already installed and committed.
Regarding the TCP/IP vs shared memory thing, Windwalkr has claimed that this is not a bottleneck in Trainz.
http://forums.auran.com/trainz/showthread.php?103371-Two-Suggestions-64-Bit-Support-IPC-DB&p=1172819#post1172819
TADDaemon is not wasting time. The purpose of a daemon is to run in the background and monitor events and act on them when needed. This is a common application, or process, found on many systems and especially those that use a database, and is called by different names including a daemon. This terminology is more common on Unix and Linux then it is in the Windows Environment. The bigger database systems such as SQL, and Oracle 12g run a daemon, or background process, for many of the same reasons that we run TADD, and stopping those would have the same effect as it would if we were to stop TADD from running.
Remember our Trainz content is kept in individual files that need to be organized so Trainz its self and us can find easily. Even TRS2004 had a database. In that version, items were loaded and cached in the old .CHUMP files which would need to be deleted manually periodically or when items were modified. When content was repaired, or created and added, the .CHUMP files would have to be manually deleted prior to running Trainz. When the program was started up, it would then reload the content from disk and populate the menus we have in Surveyor. The old creation process, as simple as it sounds, was quite risky with manual file deletion. With the way the things are now, TADDaemon does that work for us as it checks and loads the content on the fly once the content has been installed into Trainz using Content Manager.
If you were to run the command consoles, you'll see TADD doing lots of transactions in TS12 SP1 and up. Perhaps these processes were going on all the time and the Service Pack has made this more verbose so we see what's going on. When a DB Repair has been done, and then Trainz is started afterwards, you'll see TADD verifying content and decrementing a number while individual TrainzUtil processes open up and close.
John
I've not noticed this and my major Trainz activities are building in Blender and testing in a Trainz session. So I usually have CM running, Blender, AssetX, Context and probably an image editor as well. Not to mention the "usual suspects" of Chrome, Outlook, etc...
TADD may not be wasting time, but TADD doing things at all the wrong times is sure as hell wasting everybody's time.
Hi John,
If you could so kindly further enlighten me as to some behavioral aspects of TADD, that would be great. I'm perfectly alright with the database doing what needs to be done (ie. validating and organizing assets), heretofore referred to as "essential stuff". The "wasting time" part comes when I have left CMP alone all day to take it's own sweet time to perform essential stuff. It appears to be done because it's just sitting there doing nothing. I try to get back to work on some content or maybe apply a search filter, CMP jumps back into action and does that validating thing again. In the meantime, nothing can be done. Why can't it just settle the essential stuff at one go, however long it takes? This I do not understand.
Similarly, let's say a bunch of trains are installed. CMP appears to be done with essential stuff. So the user fires up trains and open up the route and tries to open Railyard. Oh no. Trainz appears to have frozen! And there it is, TADD doing that validating crap again. Stays this way for at least 20 minutes. Something that could've been gotten out of the way during the process of installing or committing and it had all day to do it, but noooo, as usual Trainz is bent on wasting as much of the users' time as practically possible.
TADD may not be wasting time, but TADD doing things at all the wrong times is sure as hell wasting everybody's time.
This is exactly what I was explaining. It will sit there idle until it's called to action.
The verification process is due to a database action of some sort such as an install and perhaps a database repair. This usually doesn't happen until the database is called to action such as clicking on a menu in Surveyor, or starting up Trainz its self. Yes, TADD and even TrainzUTil will kick into action when Trainz is running and not just while using Content Manager.
During this time, especially if the system is busy, it can cause performance problems with Trainz. I'm not saying this is a good thing - just saying that it's doing it this. Once the verification process completes, the performance is usually okay. If you look at the messages in TS12 SP1 HF3, you'll see the number become less and less as the process completes along with TrainzUtil popping up messages windows and closing as it completes a verification of a some assets.
John