I
In part their programming mess is, I think, due to lost history. They had many good programmers working there in the past and all are gone now. The previous Brew Crew knew the product and the code, and knew the pitfalls. The new crowd coming in has no clue and are going on the code they have. This introduces all kinds of errors when this is bolted on to previous code that's already in use. What doesn't help is the developers do not use the product to understand where the flaws are and only go back after there are complaints. To use an analogy, it's like a chef making an elaborate dinner but never tasted any of it until the customers complain that the meal tastes putrid. In the olden days, Greg Lane made programmers build test routes to try out the tools they were creating. The routes didn't have to be works of art, but they served the purpose. As quirky as Trainz 1.0 through TS12 is, the program worked pretty well all things considered and we wouldn't be where we are today without that legacy.
I too wish they would slow down the development of new pretty and fancy things and go back and fix the leaky roof and put the wallboard up in the dining room, but unfortunately, putting in a swimming pool and landscaping a fountain garden is more fun, referring to my old metaphors and analogies.
I agree with you on the poor documentation updates. N3V said that it's left open for the community to update. While this is all well and good, like everything else in Trainz as you said and so have I, nothing is ever finished and like everything else the enthusiasm and goodwill spreads pretty thin in a short time.Unfortunately John N3V don't update the wiki as they should. There are so many dead ends that often it becomes quite a task to find the answers that you are looking for. Documentation including digital format has become a dirty word in today's environment, sadly.
Many years ago I made the jump from 8bit to 32 bit assembler on an ARM processor. The documentation did not come as standard and had to be paid for separately, but the cost was worth it. The detail was superb and progamming without it would have been very difficult.
Today I think software companies fail to see that good and detailed documentation is still important to many an end-user. Unfortunately N3V are stuck in the middle here trying to please everyone from the game kiddies to the more serious hobbyist. Keeping a good profit level is obviously important to every business but it just seems that there are so many unfinished tasks in Trainz that they are unable to dig themselves out their hole. The wiki is part of this hole and is now left to end users like PWare and others to maintain through trial and error of Trainz. The forum and knowledgeable users are a godsend, without it the Trainz product would die.
The thing that annoys me immensely is that the updates fix bugs (that is a good thing obviously), but bugs are not created by end-users but introduced by programmers and bad or sloppy design. System documentation should be referenced when coding and memory not relied upon. Of course I am assuming that system documentation exists. As an ex-professional it saddens me to see standards slip.
I hear the arguments from some that the code has many thousands of lines of code and that N3V are a small company and not in the same league as Micro$oft or Adobe$$$, very true indeed but they are only developing, maintaining and suporting a single product. We all love Trainz or we wouldn't be here would we, but it does get very frustrating these days. Graphically the game is excellent these days and with future improvements to come it looks very promising, just wish the tasks were finished and to a better standard.
Anyway, I'm just glad for the people on the forum and the help given, without which I would probably still be on Trains 2009 or Railsimulator.
Keep the knowledge flowing people it's good to see.
John
In part their programming mess is, I think, due to lost history. They had many good programmers working there in the past and all are gone now. The previous Brew Crew knew the product and the code, and knew the pitfalls. The new crowd coming in has no clue and are going on the code they have. This introduces all kinds of errors when this is bolted on to previous code that's already in use. What doesn't help is the developers do not use the product to understand where the flaws are and only go back after there are complaints. To use an analogy, it's like a chef making an elaborate dinner but never tasted any of it until the customers complain that the meal tastes putrid. In the olden days, Greg Lane made programmers build test routes to try out the tools they were creating. The routes didn't have to be works of art, but they served the purpose. As quirky as Trainz 1.0 through TS12 is, the program worked pretty well all things considered and we wouldn't be where we are today without that legacy.
I too wish they would slow down the development of new pretty and fancy things and go back and fix the leaky roof and put the wallboard up in the dining room, but unfortunately, putting in a swimming pool and landscaping a fountain garden is more fun, referring to my old metaphors and analogies.