MaxisKevin

---------------- On 10/7/2003 1:21:03 PM the7trumpets wrote: MaxisKevin - Good news!!! Here is what I have observed: Any lot which is once classified as having a long commute time stays as classified as long, regaurdless of whether thier commute time lowers, even to 0 minutes. In general, the long,short,medium designation does not seem to be consistant, and is almost random. I set up the test shere there is a long road with Residential on one side and ID on the other. The only pattern I can discern so far is that the problem seems to be either 'correct calculation' of this property, or it is set at 'long'. The cases I noticed were as all over the map, seemingly every combination possible. Then I exited without saving and ran the same test again, only this time I zoned small areas at a time and played relatively slowly, careful to make sure there were enough jobs available. To my surprise, there were no problems whatsoever. So, I had one of my hypothesis, and though...hmm... perhaps it's houses who have been unable to find a job in the past who get classified as having a 'long' commute regaurdless of what thier actual commute time is. And it was right! I tested no job zots by dezoning all but one workplace, and all the R lots which had no job zots went to 'long' commutes after I re-zoned more Industry. The R lots which were working at the one remaining workplace (a fire station) did not change to 'long', they kept showing the right designation. Then I tested no car zots by de-zoning all the R lots which had long commute times, and dezoning all the jobs. This caused no car zots over the remaining two R lots. When I put jobs back in, thier querry showed 'long' instead of medium and short like before. So, a summary, and the 'semi' official bug report: Once R lots are classified as having 'long' commute times in the general query, they cannot get assigned medium or short designations, regaurdless of how the commute changes. Once R lots cannot find a job, thier commute time designation in the query window is stuck at 'long' for life, regaurdless of how near you zone a job for them to work at. I'm guessing that the first problem is related to the second. In order to get a sim to change jobs (other than using mysims) you have to buldoze the old job, which although it doesn't show a no job zot, probably raises the flag in the simulator, which is why it looks for another job. Aparently by the time it finds the new closer job, the damage is already done and the commute designation is already stuck at 'long'. There still seem to be some instances when even though you have enough jobs, a newly zoned R lot will show a 'long' commute time in the general query. My only hypothesis on this is that the way the simulator works, there are some cases where a R lot gets tagged having no job before it has a chance to search for one and devlop, and other times it searches for a job and finds one before it's tagged as having no job. I don't know whether this is related, or a potential cause, but R lots when dezoned and rezoned within the same pathfinding cycle always retain the same route and job placement. Hope this helps!!! By the way, why was the commute x10 multiplier changed to x12? Or is that a bug too?---------------- This is incredibly helpful. Thanks! After looking into this, I can verify that this is only a display (UI) bug. It is not effecting desirability nor any other simulator. I agree that this is something we need to fix, so we'll do what we can (no promises). As far as that 10x bug goes, I'm not sure I understand it. We have a multiplier that we use to convert our debug data into minutes used for the graph. This is actually set to 25 and has not changed since the core product. If you want to play with it the property ID is ca76013b. Set it to 1 to remove the effect. I'm not sure what this will get you though. Again, my understanding is that this only effects the graph. Am I misunderstanding the bug?

---------------- On 9/29/2003 3:38:47 PM the7trumpets wrote: Thanks mikeyb, that helps. Lately, I've become interested in figuring out the 'long' 'medium' and 'short' designations, as some on the official site's BBS have indicated that there may be a bug. I'm pretty sure there is a bug somehow, but if someone could help me narrow down where it is, I'd really appreciate it. Here's what I did: Upon starting a new city, driving road route commute times increased to medium from short at a distance of 10 tiles, which is 9 steps, or 6 minutes. However, as soon as I used roads, every driving commute time I could generate was classified as long. When I switched back to roads, every commute time I could generate was still listed as 'long'. And yes, I waited a long time between every step to ensure the simulator had time to update. THEN, to be sure about my findings, I tried the test again. (I like to be thorough). This time, it behaved exactly the same way with roads. This time, when I buldozed the road to form a street, I waited a very long time (about 2 years sim time) after buldozing the road before laying the street down, to make sure the simulator wasn't getting confused with what network was placed there. However, the exact same thing happened. Then, I tested a third time This time, I waited a long time after building the street before laying down the residential lot. Now, the street behaved like the road did, switching to a medium commute time at 6 minutes (7 street tiles). HOWEVER, when I zoned additional residential lots, they all went to 'long', even when they were zoned closer to the job lot than the lot which displayed a 'medium' commute time. But, in all these tests, the actual commute time appeared to be what it should be, as discovered in tests over on simtropolis, so these short, medium, and long designations are not correctly representing the underlying commute time. So, in conclusion, this may be an extremely big issue. If the simulator uses these 'short' 'medium' and 'long' designations as the real desirability factors, we have a major logic bug on our hands. If it uses the underlying commute time as the desirability factor, what we have is purely a visual bug, which should still be corrected. In any case, I feel fairly certain saying that this is a bug. ---------------- Thanks everyone for all the hard work that's clearly evident from this thread. I'm trying to reproduce this issue and I may be misunderstanding it. I assume the commute length you're talking about is the one displayed in the regular query? Based on that assumption I drew a nine tile street and put a residence on one side and an industry on the other. For a street the commute length reported medium. When I put in a road, the commute length would either be short (if the trip type was car) or medium (if the trip type was walk). Under that scenario it would be possible to have a closer house have a longer commute if the closer house chose to walk while the farther house drove. I've attempted to post a screenshot to show my test. Is this an accurate recreation of your test? If not, can you help me understand where I went wrong? Thanks again for your help! -Kevin