How about addressing what is going on
I'm not really sure what more information I can give you at this point. Some of you are reporting something that (as far as we can tell, from the varied and sometimes vague reports that reach us) should not be happening. That's not a dig at any of you, but there's very little meaningful information that is user-visible here, so the amount of useful data we can get from your posts is minimal. It's not something that we can currently repro in-house, so (as above) our QA lead is talking to a few people and asking them to assist us with testing.
..and why 'validating' Errors and Warnings then committing is different from this, or that you believe them to be the same?
What's being referred to here is a background validation process that only shows up in the diagnostic logs. This is the same process that is run when you use 'View Errors and Warnings', when you install new content, when you the current version of dependencies, and so on- there are many legitimate reasons for it to occur; we have no concerns at all about the messages showing up in the logs; the question is simply whether there are some cases where unnecessary validation is occurring, and if so: why?
You know, An intelligent dialog where you don't go off and just further alienate people with that childish passive-aggressive avoidance stuff. You know. Like an adult.
It's responses like this that typically encourage me *not* to take that path. Pot, kettle, black, etc. I know you don't like my way of doing things, and honestly I don't really care. I'll happily give information when there's something constructive to say. If you're just going to snipe then i'll either ignore you, tell you off, or snipe back.
The problem with you is you treat these guys as adversaries instead of co-workers.
No; you'll note that where somebody has a meaningful question, I will happily answer them. If someone is being purely adversarial, then I'll still answer them accurately as well, though I won't go out of my way to make it nice on them. I'm not a PR person and I don't pretend to be a PR person. I'm here to deal in facts, and if sometimes people don't like the facts then that can be hard to deal with.
To reply to your assorted notes:
..Steam and all of its momentum and comparing them to Trainz 2012 it looks like it’s in some sort of time warp from 10 years ago.
You really think that comparing a multi-billion dollar company to a million-dollar one is even remotely reasonable? While I'd love to own something like Valve, I'll be the first to admit that we're not in their league when it comes to cashflow, employee count, market share, and many other relevant statistics.
The Kickstarter project seems to be a last gasp for N3V to get more money out of us but until they change internally, to really listen to their customer base on problems and suggestions, I’m afraid I’m out.
Well, I'm sorry that you feel that way, but I'm glad that many other users have supported us. TANE development is coming along very well, with you or without you.
My personal view is that Trainz has evolved rather than been planned out
Absolutely true. Or more accurately, there was a plan, and it did not survive the encounter with the enemy (to steal a good phrase.) Each individual version of Trainz is carefully planned out, and certain systems have long-term plans, but to claim that we know exactly what we'll be doing in another 10 years is completely rubbish. We'll take it as it comes. Generalisation is easy (we'll improve graphics, make the DLS more robust, add some key gameplay features, etc.) but as to what we'll be doing on this day in ten years time? No idea.
The problem is most of their code relies on the old index methods against the files out on disk and the rest relies on the SQLite database. It’s a problem of inconsistency in data stores and really the amount of thrashing they put the disk subsystem through is pretty awful.
This is fairly accurate. We suffer pretty hard for maintaining on-disk compatibility with a system that was written at a time when 10 baseboards was a big route, and 256MB was a lot of memory, and direct filesystem access to the custom content was a requirement by our users. I don't think that anyone is under any illusions about the need to overhaul this, although ironically it's going to happen at around the same time as hardware actually makes this approach a lot faster (no more seek delays, yay!)
You could show lots and lots of diagrams and arguments to Chris but in the end I’m afraid he’s not interested in hearing opinions outside his own dev. Team. This can all be fixed pretty easily and would actually help Trainz but as a comedian has said “You can’t fix stupid!”
It's true, you can't.
(See how easy that was. Still wonder why I don't bother repeating answers that have been explained several times over?)
Unfortunately, it's very easy to say things like "fixed pretty easily" if you're not the person responsible. Underestimating the effort required to maintain a system which involves many, many stakeholders with varying requirements is a very common issue, and programmers tend to be the worst at this. Ever heard something like "Oh, that old crud? Just rewrite it, it'll only take a few weeks"? I assume that you're familiar with the fallacy in that line of thinking.
On the technical side of things, I’ve been thinking that perhaps this is a program bug more than actual data corruption that is triggering this revalidation process. The intended purpose of this occurrence is to validate data corruption due to database anomalies. These glitches could easily because by the end-user performing a system reset, a program crash, or a hardware fault somewhere. Since the database wasn’t closed properly, the database is flagged as “dirty” and TADaemon then needs to verify the integrity of the underlying database records. Unfortunately in our case, the implantation is bugged so TADaemon has a hissy fit when things don’t appear right to it.
Close, but no.
If there's regular background validation occurring for no good user-initiated reason, then there's definitely a bug.
That has nothing to do with "dirty" flags or bad data or anything else. This is probably confusion on the speaker's part between database repair and validation.
From my experience, this has happened after performing a database repair, whether an EDR (a very, very rare occurrence at that), or an QDR.
Definitely valid cases for it to occur, and not considered a problem.
Other times this has kicked in after adding assets from CDPs. I recently downloaded some content from Jointed Rail, and sure as shootin, I got a long dreaded data validation afterwards. I also got this after installing the Murchison update, or rather bug fix.
Definitely valid cases for it to occur, and not considered a problem.
Anyway, if this is a programming buy, the first thing I would do, on Chris’ part would be to take a look at his “perfect” code and see what’s happening.
Again, no claims on my side that our code is "perfect", nor that our code is "my code". Are you sure it's me who is being the negative one, here? Sounds to me like somebody has a grudge.
My gut feelings is this is a linear database file so everything gets appended to at the end, so any changes, updates, or transactions require a long read, write cycle, and there is not enough time allocated for the process.
His gut feeling is very, very wrong.
The current designs for both of these subject areas are terrible and the lack of focus on fixing them represents a bit of arrogance on the part of N3V towards its user community.
Perhaps. However, you should also keep in mind that:
* In this thread, well in advance of your post, we've already identified specific issues that we'd like to investigate further.
* We have a major project underway to overhaul the Trainz engine, specifically to bring it up to date for modern workloads.
If that's "arrogance" and "lack of focus" then so be it.
In short, all from technical professionals who have a bit more experience in large ponds as small fish growing wiser without fullfilling the Peter principle so young as you
In short, a comment like that makes you an ass and comes across more than a little ageist. Not saying you're stupid or don't make occasional useful input, but turning everything into personal attacks against myself and my colleagues doesn't help anything and has actively lead to you being banned from our wiki. I find that a real shame personally, because you were one of the more active wiki editors and we want to see more wiki activity, but if you spend as much of your time attacking what we do as you do making yourself useful, then we don't have much time for you.
chris
), So my question is if it can run at that speed then why doesn't it run at that speed all the time ? 20,000 items is a pain but if it could clear through those in a few minutes then I'd put up with it !