Starting this as a placeholder for continuing discussions that started with my first post at http://sc4devotion.com/forums/index.php?topic=5382.200 and ended with my last on page 12 (maybe, unless someone else posts after me ;D )
Thanks Z for letting me borrow your thread for a bit but now I return it to you.
Also being as this really doesn't have anything to do with the NAM either we will leave them as well.
This is traffic simulator for noobs!
So with Jason's shiny new adjusted NetworkAddonMod_Traffic_Plugin_A_Hard in plugin directory I boldly go off...to test....stuff...oh yeah...buses...we are going to build a city to test out buses not adding to congestion (the default condition in A) and then we are going to mod the mod to have buses add to congestion and run the same city for another decade or two for good measure and see how we fare. Time and interest permitting I will then take this city and do the same thing with Sims B and Z as well.
So let's start out with laying the testbed. Here is what I had written last night before I went to bed:
Region 20 km square composed of 5x5 large city tiles (although I think I have found something more interesting (to me anyway) see below)
City in center used for test
Plugins installed:
NAM A hard with minimal options
Click for cash and click for reset
God terraforming in mayor mode
Hole digger and raiser lots (I am pretty sure it is the version by NHP Shadowassassin? the one with the big bright blue and red icons that say how many meters you are adjusting by)
My own Maxis MT station patch (which has transit entry costs scaled to current traffic sim)
My own I jobs mod (it is the CAM suggested settings...without the CAM...will allow me to build a bigger city faster)
My own GRR station fix (also per CAM specs...all it is is is a correction to the utilization % required to unlock)
*Not really relevant but listed for completeness*
All Maxis plugins (the landmarks...I figure they are safe enough)
The 3 Maxis building props files (All Maxis building props with proper names, bldgprop_vol1, bldgprop_vol2...I don't need any of these at the moment but I don't want to forget to put them back)
The no area 51/afb exclusion mod (I looked at it and it is clean, just changes the exclusion type so they aren't mutually exclusive)
Operahouse fix (stupid bugs)
My own police station fix mod based off (I got the ideas off this thread http://sc4devotion.com/forums/index.php?topic=3809.0 so what I did was adjust the dispatch stuff to match the fire department, and then I also changed the effect at edge of radius to the fire dept 50 as well for good measure)
Peg's Brigantine water mod (because I cannot stomach the default water textures)
I am torn between stripping every nonessential (obviously we need the NAM (well not really, I guess we could just use the traffic sim, but then life without diagonal roads is no life at all...besides is there anyone who does NOT use the NAM?), and a few of the other plugins will make getting the city going much easier and faster) mod out...because that is really the proper way to test things and the fact that I am going to have to play this city for quite some amount of time and it is going to be a total drag to play with all vanilla content. Especially I am a freak for waterfront, I LOVE LOVE LOVE Peg's CDK lots (and most of his lots in general) but most of them are transit switches and so they would add even more work modding them each time (which really doesn't bother me so much) but that also introduces the risk that I will forget somewhere along the line, invalidating the tests (that does bother me much). RTMT once same as above so none of them. SFBT stations...nixed. :( Kevdan restaurants, SGs commercial buildings...would probably be safe but K.I.S.S. Swampers automata and all the GM cars by mikeseith? Probably safe too but not gonna chance it. A bunch of other content I haven't mentioned. (ok enough with the plugs for some but by no means all of my favorite content)
Ok, so this is below. About the map. A blank map is pretty boring. Even if I do some terraforming in game it is going to be boring. Also who the hell plays on a full 4km flat tile? BORING! I want oceans and rivers and mountains! Besides my goal in testing (right now at least) is not to find the limits of the simulators. It is to see how they play in a "typical" map.
I really love the 3RR map. That is some fantastic work. Unfortunately it takes forever to load. And I've got 3 friggin WD raptors in a stripe for f'sakes. Old games running on new computers you make me cry! Oh...sorry...right...3RR...focus...focus.... Not to mention 256 city tiles? I'd rather get a root canal (and I been putting that off for a year). Also at its current scale you really have to play the bulk of the map to get a mix of interesting terrain in each tile. So I need a shrunkdown version of it. So today while crossreading some posts I find the original 3RR development thread over at Simtropolis and I think we have a weiner! If I can find the original map (going to look for it now) it is just the size and variety of terrain I want. In fact I don't think I could find a map that is more what I want right now if I made it myself. I will also have to go back and read this entire thread because it was really a lot of interesting design theory that Dedgren had going (and well it shows in the final product).
Ahhh man! ??? Who renamed my thread? :'(
::) I suppose I should go read the CoC before I get myself in trouble.
Ok...so it doesn't look like we are going to find it. And it also isn't quite the original. It looks like it is an intermediary (around page 32). When he took it from being an 8x8 km to a 16x16 km square.
I could pm Dedgren and ask him if he still has it (which I doubt, but no harm in asking I guess) or go to plan B which is export the image out of SC4T, shrink it down in Gimp and run it back through SC4T. I think I will do both.
Lovely conversation I'm having with myself so far. Maybe I shoulda made an MD out of this. Nah. Maybe some other time. I've got enough on my plate right now.
Also this may seem to everyone to be a really unnecessary amount of work just to test out congestion effects of buses. If that were all I was going to do with it, it certainly is.
Fear not gentle reader (all 1 of you...or is that just my reflection?) I plan on testing out much more.
The region I currently play with is based on the "Lakelandia" map that I had found on the STEX. It does not have real moutains but the terrain is not flat either, and it has an interesting layout with a great river and various lakes. If you have not found a map to your liking yet, you may give it a look.
@Douzerouge, Thanks for the suggestion, I'll check it out.
In the meantime I did find an older elevation map Dedgren had put on the Simtropolis forum 3RR CJ.
I think it was probably his earlier draft. Maps also twice the size, and I am finding when you use SC4T to scale down an image the height gets pretty badly messed up.
So it's either wait for response, edit the map I generated which is still a lot less work than making one from scratch, it also affords me the opportunity to "personalize it"
That may be the way I go. I really love the map.
@Jason ok this is really wierd. I put in the new sim. Since I am still getting the map sorted, and after all this reading and posting and thinking and posting some more I needed to get in some kind of playtime so I dropped back into last nights city for a bit (30+ years actually...no wonder I am tired). The city went berserk. Routes starting pingponging for a bit. As I was running in cheetah I got to see "realtime" traffic updates as each cycle it recalculated all the routes. Bus usage also actually dropped to nothing during this time. Population actually started growing for a bit...I don't really know how since I thought the city was stabilized and not going to grow anymore but the pop went up another 40k. Then things got ugly. We got massive abandonment from commute time. And population dropped the extra 40k plus another 20k or so. Of course then I had a fire in a few abandoned buildings that I didn't dispatch to fast enough for the games liking and it also took out the water main running through that block, which also cut off half of the city. One of the lovely things about cheetah speed is that if you don't catch these things very quickly, you get more abandonment YAY! So actually I think that was the extra 20k, because I had to bulldoze quite a few skyscrapers after that happened. I also had to bulldoze a lot of industrial, but this was good since it was all dirty and it got manufacturing to grow in its place. Then it started coming back up to about where it was before and stabilized again. Bus usage is still nil. Like I said earlier I know this isn't a good testbase since it is too small and also simplistic so route options are very limited. I am sharing the results "just for fun".
Anyway, enough for tonight. Tomorrow I'll start fresh. That or I'll upgrade to Windows 7. Been putting it off.
This was on a large tile, am I right? At what population level did you start getting abandonment? And what was the reason for abandonment?
Quote from: z on October 25, 2009, 12:57:49 AM
This was on a large tile, am I right? At what population level did you start getting abandonment? And what was the reason for abandonment?
Yes, large tile. It was around 160k.
I figure the extra 40k pop that I suddenly gained when I switched simulators abandoned from commute length (although I didn't click and read every single one, they all got no job icons and when I checked them it said due to commute). I think I lost about 20k from the water main break, which is of course no fault of the simulator; just plain bad luck. Those buildings of course went to no water zots and when clicked said abandoned due to water. And all that was different between those 2 versions was that Jason cut the trip start costs in half on both types.
Since then I had been playing on a map I whipped up from an old greyscale of 3RR in its transition period (it resembles its present form but is 4x smaller) but it was a very rough draft. That and no doubt Dedgren's mapmaking skills have increased greatly through the process. Once again though I didn't get very large, maybe about 200k. I purposely made some areas that I knew would have bad congestion and although it doesn't really have anything to do with the testing I was pleased with the results. I had a mix of road, highway, heavy rail, and bus and the sims adapted very well to the situation. The residential area was south of the industrial park, which was on an island with only 3 road bridges and 1 rail. I had the highway running some distance away in kind of a u-shape on both sides of the river around the industrial island. To get to the east bridge, they had to go south to the highway, take it across the river and then back north and there they were doing it.
So still not having heard back from Dedgren I took the full 3RR, exported image and ran it back through in a 1/4 size. Had to do a bit of terraforming, but it is much prettier. It really is too small to do the region justice, but I like it. It also occurred to me that this is even still far more work than I anticipated (you can say I told you so now :P ). It really is very hard to isolate something with so many variables. I also got dreadfully bored (especially with the default seaport and marina, UGH!) so I put most of my plugins back in. I figure since this is really going to take A LOT of time I need to have fun with it or I'll never get it done.
Nope. I know better ;) Only changed the traffic plugin.
I didn't change anything in that city until well after a decade. Then all I did was bulldoze abandoned buildings for the next 20 years.
Now one thing that I doubt may be a factor but I am not ruling it out, a couple years before I made the switch, I did raise ind-d taxes from 9% to 11% and invoke the clean air act.
Although I was also bulldozing dirtys during that period but manufacturing was immediately growing in its place. I didn't notice any stressed buildings though.
This is of course Fridays city we are talking about. I still have it (different region).
Yesterdays city, I think I put my slope mod back in before I started playing but no other changes. That was built from scratch with the modified A, and yes I did see increased bus use. Also this city had roads and highways, heavy rail, bus. The other city had only roads with bus. Also I'm not sure what the typical playstyle is but I don't make a grid of busstops. I try to lay out semi-realistic "bus lines" as best as the game can accomodate. So along the "route" I want the bus to go I put stations every few blocks. And if you don't live close to the route it is a bit of a hike. Interesting to note "Steve's sims" are very athletic types. They love to walk everywhere. They have no problem walking a long time to take the bus, and they really like the bus. "Your sims" are very lazy. They will only walk a short distance to the bus. Of course this is just a generalization and I am trying to inject a little humor into it. Also as I said I don't see it as a bad thing. While I may be able to walk 3.5 mph (and that's probably stretching the truth ::) ) there is no way in hell I am going to spend an hour walking to get to work. I think it was Mott who produced the figure that mass transit stations are designed to be a 5 minute walk for the commuter.
Now for todays city, (which I'm about ready to get going) I'm back to screwing around with my own traffic sim (I just can't resist). This is something new though. I reset speeds to defaults. I extended the max commute a bit from A's 17 to 24 so it still follows at least part of A's design philosophy, namely to allow a large tile to be traversed on an avenue. Actually it can almost be done on a road if there is no traffic because of the congestion effects, which is also something I was aiming for. I rescaled the congestion vs speed a bit. What else? Travel percentages tweaked a bit but nothing as extreme as A or Z (one of these days I am going to find time to look at B as well). I doubled stock capacity for road/ave/owr/highway, bumped streets up to 800, but I left the mass transit at defaults. because if I am trying to drive up care use then road cap needs to be higher but the mass transit doesn't (for the moment). I also cut the MT time (I scaled it up some but not to the same ratio, keeping those walks short) Also using the lower ph of .003 . I am sure everything will need to be tweaked some more.
Ahhh work called. I need to VPN into our servers, so my connection will be severed. Had more to say but will have to cut it short (well short for me anyway :P )
Quote from: jplumbley on October 25, 2009, 11:45:02 AM
My goal with Travel strategies was to put more emphasis on the "best" route. My low percentages for Car Preferred and MT Preferred compared to No Preference where 70-80% of all Sims are No Preference helps greatly in providing a balance, in my opinion. But, this is one of those sets of properties that will be greatly effected by your own personal preference and where in the world you live. In North America, there will no doubt be a higher preference for using cars so many people here will want something with higher car preferences, whereas in Europe the is a greater emphasis on MT and walking, so there will be many people who would like MT preferred. And then there are places where people have the ability to choose more easily and would have no preference at all.
Actually, that may have had an impact. Some or much of your I-D may have "abandoned" or atleast reduced in number of jobs provided, and if you were already at such a population where you were close to equalibrium in your population-jobs, it may have caused some of your R$ buildings to go abandoned. And then when you were replacing the jobs with I-M jobs, the wealth of your City would grow, but your overall density would fall due to the capacity gap between, R$ and R$$. For example homes would have 4 sims instead of 6 in you new sections and to gain in population you would have to zone more for the higher wealth in your City. Does that make sense? You were growing your City in a positive direction from a wealth perspective, but lowering the overall density of it. R$$ takes up more space than R$, and they pay more taxes for it. What would really interest me is if you had taken a look at the change in the population demographics and see if there actually was a decline in R$ and a rise in R$$. I would put money on that there was.
Well that was just great. I love driving into work on my day off for no good reason. I am about ready to "abandon" this job :angrymore: Don't think it doesn't happen in real life!
It takes me far too many commute time units to get there and the idiots on the road make me nuts. Hey! &idea Think there's anyway we can model roadrage into the game? ;)
Oh, it isn't so much personal preference at this point as I want to see closer up the effects of things. Vanilla is the baseline, but as I think we can all agree it is sorely in need of work, so there isn't much point in trying to actually play with it. I am starting to see some of the relationships that you and Steve no doubt see much more clearly and I can see why it is not easy for either of you to just say "oh well X does X and Y does Y and if you change this then you get that" nothing can ever be easy like that. I am sure there are ways to adjust 2 different variables in the simulator and get the same thing to happen or not happen. Not to mention there are ways outside the traffic sim to also make certain things happen or not happen.
As for the abandonment, it was actually just about all of my R$$$ (who lived on the far side of town) and a smattering of R$ and R$$ (I think, y'know I don't tend to notice a lot of R$$, seemed like I had mostly $ and $$$ &ops ) I got a lot of industrial abandonment of both kinds, but I think that was more due to waterloss. The thing is the traffic abandonment happened first and was probably responsible for the fires.
I'm pretty sure I didn't save over that game so I can always run it again from the other night when I changed the traffic sim and I should get the same results. Just have to remember to run with the same plugin loadout I had before.
For shitsngiggles I went ahead and reran it with my current pet traffic sim. I didn't get the mass abandonment, although I did see buildings periodicly abandoning and rebuilding city pop slowly but steadily grew over 20+ years. The R$ jittered every year, it looked like a sine wave. R$$ slowly went up. Rising education. Bus use was a bit higher, but then they really don't have any choices in how to get around, the whole thing is just a grid, it is all roads. They can walk, drive or take the bus and along pretty much the same routes. I did put Bones1 less abandonment plugin back in though...because the description intrigues me...it isn't supposed to stop abandonment from happening directly; it is supposed to make the buildings need more desireability to develop in the first place so that they are unlikely to be marginal and start flapping. To me it sounds like something that actually makes it a little more work to develop a city; hence a little added challenge and less annoyance. I could be dead wrong of course but that's my take on it. Poking through (and hey these developer exemplars have ALL kinds of interesting values in them...I bet I could completely screw the game up with them...uhhh... &ops ....I mean highly tune it) all he did was raise the "desireability threshold growth" he didn't touch anything else. If that works the way documentation says it does I would think it is a good thing.
Hey looky looky "traffic effect" and "trip length effect" so we actually CAN modify not just how far they can possibly travel (via max commute time and speed) but also how pissed off they get when they have to travel. I was wondering if it were possible or not. Hrmm...lemme take a stab in the dark here, traffic effect is the traffic noise value? Oh the fun we can have.
Yeah, I know I am getting completely offtopic; in my own thread no less. So much to see and do in Ilives reader. I think I spend more time with it than the game.
Quote from: jplumbley on October 25, 2009, 03:09:32 PM
There are a lot of things in the developer files that need fine tuning... In fact Tage (Ripplejet) did a lot of fine tuning with the developer files with the creation of CAM. If I remember correctly he did use a tuned version of Bones1's abandonment mod as part of the CAM files. If CAM is good for anything it is the tuned developer files that come with it, and it would be a good idea to have those files installed rather than Bones1's abandonment mod because it deals with a lot more than just the abandonment issues in the game.
I think many people see CAM as only adding the extra stage levels to the game with the taller buildings.... But it is much, much more. Even if you dont want the extra stage levels (simply dont download the CAM buildings if you dont want them), CAM is still worth all the tuning in the developer files to create a more balanced game.
Oh, good idea. I did actually download it, although I never installed it and I never went through the exemplars (I dove into simple stuff like the traffic sim first ::) )
There are a lot of good things in the CAM, a few simple little mods I made for myself were things that were well enough documented in the CAM to easily do even just starting out. I was just afraid to install the CAM since population density is already too high and the vanilla skyscrapers while they may be to scale still look ridiculously large to me. Reminds me I need to put RJs census repository back in too.
Oh! Now I remember what I wanted to mention before, you know the A&B data plugin does not match your actual capacitys? Or is that another one of those things like the commute time graph that is fudged? I've been going through and adjusting the ltext files when I change things but I don't know if the multiplier in the exemplar needed to be touched or if it should always be accurate. I see that you can change the ranges and steps but I wasn't ready to start tweaking those values as well (I would like to adjust the "steps" to correspond to each % that changes speed/congestion but that is a project for some other time)
Quote from: jplumbley on October 25, 2009, 09:22:40 AM
That result really makes no sense at all, considering both changes would actually make it "easier" to find work and allow Sims to travel further.
It makes a lot of sense to me. The pathfinding heuristic has a HUGE effect on the whole traffic simulation. To the extent that it's higher than .003, the other properties in the simulator related to pathfinding have less of an effect than you'd otherwise expect, due to the less accurate actions of the pathfinder as a whole. This is why, for example, the Travel Strategy Percent properties are skewed more toward mass transit than in typical American cities; this is to offset the randomness introduced by higher pathfinding heuristics. When I set the pathfinding heuristic to .003, I moved those properties to favor cars more, but the net effect was that mass transit usage increased! This makes sense, because with the exception of buses, mass transit is always significantly faster than cars, and I had eliminated the randomness factor. I then had to reduce the rail speeds to bring the usage of travel types back into balance. But if you're not using perfect pathfinding, the changes made to increase bus usage will have a much smaller effect than you would expect for this reason. And if you do start using perfect pathfinding, there's a whole group of properties that have to be changed to keep everything in balance.
[All further quotes are from ldog.]
QuoteI think it was Mott who produced the figure that mass transit stations are designed to be a 5 minute walk for the commuter.
I think a 10 minute walk is quite realistic; I've certainly done that enough myself. But for the sake of argument, let's use 5 minutes, and let's use the Simulator A pedestrian speed of 5 kph. Then using the standard rule of thumb formula (which I first learned from Jason :)), it takes 1/5, or .20 minutes for a pedestrian to traverse one square. This translates to five squares per minute, or 25 squares in five minutes. This should be plenty of time to get to a mass transit stop. The problem here is that in Simulator A, the max commute time one way is 8.5 minutes, and 5 minutes for walking takes too big a chunk out of that. And if you add another 5 minutes for walking from your destination stop to work, then you've already significantly overshot your max commute time, even without allowing any time for traveling on mass transit. This is why you don't see pedestrians traveling very far in Simulator A.
The above analysis applies when you're using a perfect pathfinding heuristic; things just get worse when you use a higher heuristic.
QuoteNow for todays city, (which I'm about ready to get going) I'm back to screwing around with my own traffic sim (I just can't resist).
That's fine, but if you want to have a really useful comparison, and one that will help you with your own traffic simulator, you should try building an identical city from scratch using Simulator Z v1.2.
QuoteI rescaled the congestion vs speed a bit.
Be very careful here. There's really not much room for changing this without creating problems. For best results, the top speed should be about 1.3, the bottom speed must be 0.3, and there should be exactly six pairs in the table, with no three adjacent points on a straight line. For the reasoning behind the last two requirements, read Amit Patel's work.
QuoteWhat else?...
Again, it would be very useful to compare your results against those of Simulator Z's. But I should warn you that a lot these changes are being made without understanding how these properties are linked. You might get lucky, though... :)
QuoteFor rubbishsngiggles I went ahead and reran it with my current pet traffic sim. I didn't get the mass abandonment, although I did see buildings periodicly abandoning and rebuilding city pop slowly but steadily grew over 20+ years.
I gather that this is with using Perfect Pathfinding, yes? It sounds to me like you're slowly rebuilding Simulator Z on your own.
QuoteBus use was a bit higher, but then they really don't have any choices in how to get around, the whole thing is just a grid, it is all roads.
Still, just changing to Perfect Pathfinding will increase bus usage. Otherwise, the Sims can always use cars.
QuoteI did put Bones1 less abandonment plugin back in though...because the description intrigues me...it isn't supposed to stop abandonment from happening directly; it is supposed to make the buildings need more desireability to develop in the first place so that they are unlikely to be marginal and start flapping. To me it sounds like something that actually makes it a little more work to develop a city; hence a little added challenge and less annoyance. I could be dead wrong of course but that's my take on it.
If you're going to do simulator testing that's going to have real meaning, you shouldn't add in extra mods like this. They really throw in doubt the meaning of much of your results. Proper testing means limiting the number of variables changed to an absolute minimum.
QuoteHey looky looky "traffic effect" and "trip length effect"...
Where do you find these? If these are in that mod you're referring to, that's just another reason not to use that mod, as it will definitely interfere with any simulator testing results.
I would also like to strongly second Jason's comments about CAM. This is a widely-used and well understood mod, and the traffic simulators are designed to work with it.
QuoteOh! Now I remember what I wanted to mention before, you know the A&B data plugin does not match your actual capacitys? Or is that another one of those things like the commute time graph that is fudged?
Could you explain what you mean here? The capacities as stated in the examplar are what is used.
Quote from: z on October 25, 2009, 03:50:35 PM
It makes a lot of sense to me. The pathfinding heuristic has a HUGE effect on the whole traffic simulation. To the extent that it's higher than .003, the other properties in the simulator related to pathfinding have less of an effect than you'd otherwise expect, due to the less accurate actions of the pathfinder as a whole. This is why, for example, the Travel Strategy Percent properties are skewed more toward mass transit than in typical American cities; this is to offset the randomness introduced by higher pathfinding heuristics. When I set the pathfinding heuristic to .003, I moved those properties to favor cars more, but the net effect was that mass transit usage increased! This makes sense, because with the exception of buses, mass transit is always significantly faster than cars, and I had eliminated the randomness factor. I then had to reduce the rail speeds to bring the usage of travel types back into balance. But if you're not using perfect pathfinding, the changes made to increase bus usage will have a much smaller effect than you would expect for this reason. And if you do start using perfect pathfinding, there's a whole group of properties that have to be changed to keep everything in balance.
The thing is the pathfinding heuristic (and I am gonna call it PH from now on) didn't change from simulator run to simulator run. It was still Sim A, just with the trip starting costs both lowered. His MT starting is still very high compared to default and he is also using the same value for both of those, and the default ratio was also very different (I forgot what you used in Z but IIRC you still had similar ratios). You understand the implications of that better than I do, so I'm just throwing it out there. It may be really relevant and it may not be.
Quote from: z on October 25, 2009, 03:50:35 PM
[All further quotes are from ldog.]
I think a 10 minute walk is quite realistic; I've certainly done that enough myself. But for the sake of argument, let's use 5 minutes, and let's use the Simulator A pedestrian speed of 5 kph. Then using the standard rule of thumb formula (which I first learned from Jason :)), it takes 1/5, or .20 minutes for a pedestrian to traverse one square. This translates to five squares per minute, or 25 squares in five minutes. This should be plenty of time to get to a mass transit stop. The problem here is that in Simulator A, the max commute time one way is 8.5 minutes, and 5 minutes for walking takes too big a chunk out of that. And if you add another 5 minutes for walking from your destination stop to work, then you've already significantly overshot your max commute time, even without allowing any time for traveling on mass transit. This is why you don't see pedestrians traveling very far in Simulator A.
The above analysis applies when you're using a perfect pathfinding heuristic; things just get worse when you use a higher heuristic.
Yeah, even 15 would be reasonable. I was just throwing that out there. It doesn't really matter what you choose to use, since too much reality gets in the way and it doesn't fit the mapsize very well. Still, need some kind of frame of reference so we can relate to the real world. I have been trying to stop myself from making those kinds of comparisons once you guys helped me to get my head around some of the finer points of the insanity called the traffic simulator. I didn't expect to see them walking far either. Of course I would think it should take a lot of congested roads to get sims to walk further since fastest route should win out, shouldn't it? Interestingly even though I set my max commute higher (24 vs 17) I expected my sims to walk the same or less than Jasons since I set the speed back to 3.5 but they seem to actually walk (very) slightly more (like a couple tiles in the same city).
Quote from: z on October 25, 2009, 03:50:35 PM
That's fine, but if you want to have a really useful comparison, and one that will help you with your own traffic simulator, you should try building an identical city from scratch using Simulator Z v1.2.
I would but as you pointed out this city is too small. It really wasn't "the test" just some screwing around. The thing I've seen is that Sim Z makes traffic in a city this size pretty irrelevant, even with a poorly designed network. I'm also shifting my testing focus a because of a few things you pointed out. 1 that you really did do a lot of the comparison and 2 Just what am I trying to accomplish? I need to define that more closely because it isn't just a "I'll whip up a testcase and let it run a few hours and see what I get" building it takes a lot more time than running it. 3 I also need to have some fun in between so as to not just burn out and walk away accomplishing nothing. Right now I don't have a city large enough for Z, and the way I keep obliterating and rebuilding them it's going to be a while lol. This was giving general observations about A since it was the first time I had used it.
Quote from: z on October 25, 2009, 03:50:35 PM
Be very careful here. There's really not much room for changing this without creating problems. For best results, the top speed should be about 1.3, the bottom speed must be 0.3, and there should be exactly six pairs in the table, with no three adjacent points on a straight line. For the reasoning behind the last two requirements, read Amit Patel's work.
Great, why weren't you here a few hours ago when I jacked it up to 9 pairs :P
Well at least I did keep top end at 1.3 (was tempted to go for 1.5, in fact I think thats what I was using in my earlier version) but I got the bright idea to set it to .01 at 400% congestion. I guess I should change that. I'll have to check it out, I've seen y'all mention it in other discussions and so it piqued my interest; it's on my todo list (which gets longer by the minute) Until I have time to do so I will defer to your greater knowledge and trust your judgement and tone it down. To be honest I was thinking all those extra pairs I was adding were probably going to just cause the thing to bog down or at best not even have any truely useful effect. I'm making enough trouble for myself right now that I don't need that kind. Especially since it'll probably be the kind that doesn't blow up in my face until a month from now.
Quote from: z on October 25, 2009, 03:50:35 PM
Again, it would be very useful to compare your results against those of Simulator Z's. But I should warn you that a lot these changes are being made without understanding how these properties are linked. You might get lucky, though... :)
Not sure what that is in reference to. Probably something stupid I said. That is why I am making these changes though, to learn how they are linked. I bang on stuff til it breaks and then I look at the pieces and try to figure out at what point it broke. As you yourself have said, you can't believe everything the internal documentation says. As far as Prima guides, haven't owned one in a long time. Back in the day, before internet forums and wikis were so prevalent Prima guides were one of your limited options but most of them were decent. As the years have gone by I find them only good for a few things (namely propping up your monitor a few inches or for when you unexpectedly run out of toilet paper). Unfortunately no one has put together a really kickass wiki, or even really good documentation of what does what it says it does, what doesn't, etc, etc.
Quote from: z on October 25, 2009, 03:50:35 PM
I gather that this is with using Perfect Pathfinding, yes? It sounds to me like you're slowly rebuilding Simulator Z on your own.
Still, just changing to Perfect Pathfinding will increase bus usage. Otherwise, the Sims can always use cars.
Yes, I am using the "perfect pathfinding"
You know next I'm going to be bugging you to know more about how the PH works :P
&ops You caught on! :-\ The one thing that I am really having trouble with is if I should call it Z++ or Z.net , what is your opinion? $%Grinno$%
LOL. Sorry, I couldn't resist.
I want to make something that works differently though. Something more optimized for a smaller region, lower population citys, and very challenging. You made Z for huge regions, high population, and well I am not in a position to judge whether or not it is challenging at those levels but at the scale I am aiming for it hasn't shown itself to be so far. Like I said though, I am not looking to compete with you. It seems most people here like to do CJs/MDs/whatever you call them which are all about large scale recreations and pretty pictures but not really about playing the game. What use is a to scale airport that takes up an entire large city tile when it doesn't work regionally? Don't get me wrong. I love looking at the MD pictures, and even reading some of the storys, especially the ones where they talk about their design theory as they built it. But doing that myself? Nah, not for me. Tomorrow if I'm bored at work I may even take some google map sections of some of the citys I have lived in and put some game overlays on them and show statistics why I think it would be less painful to have my fingernails pulled out one by one than build any of them to scale. And I've lived in some interesting places, NYC, Seattle WA, Charleston SC, St Louis Missery (ok so that last place is not very interesting)
Quote from: z on October 25, 2009, 03:50:35 PM
If you're going to do simulator testing that's going to have real meaning, you shouldn't add in extra mods like this. They really throw in doubt the meaning of much of your results. Proper testing means limiting the number of variables changed to an absolute minimum.
I know. And to change them once a test has begun certainly would. As it stands, I think I said somewhere up there the other day, considering how much time I am going to be stuck looking at this city I might as well play it with a fairly representative set of mods. (Sim)Life without Peg's container port and marina is just not a (Sim)life worth living after all. Still I cannot deny it will skew results somewhat, but like someone (I think you) said, we have finite resources. The next question after a nonbiased test would be, well now how is it gonna work with the mods I actually use. I think so long as I disclose everything used as well as what was done and keep the variables from test to test the same (not change mods between different simulator runs) whatever test results I get are valid. In other words, noone is interested how it works in vanilla, because noone plays vanilla.
Quote from: z on October 25, 2009, 03:50:35 PM
Where do you find these? If these are in that mod you're referring to, that's just another reason not to use that mod, as it will definitely interfere with any simulator testing results.
I would also like to strongly second Jason's comments about CAM. This is a widely-used and well understood mod, and the traffic simulators are designed to work with it.
RELAX! You worry too much lol. I was just pointing out that I peeked those values in those exemplars (the developer exemplars), they weren't poked. Bones only changed the 1 variable, which raises the desireability threshold before the particular type will grow. Defaults have the thresholds set to the same values for both growth and decline. I'm no expert but I think that is a bad thing as it would cause flapping. Bones1 set the growth threshold much higher so that something won't evolve and then immediately devolve because the neighborhood is marginal. Jason said that what Ripplejet did for CAM is derived off of said work. Believe me I have had my game screwed up plenty by blindly downloading and installing, if I know how to do anything it is take someones mod and compare it to the original and see what was changed...it is how I have learned.
Quote from: z on October 25, 2009, 03:50:35 PM
Could you explain what you mean here? The capacities as stated in the examplar are what is used.
The dataview plugin, for A&B, the capacitys in the ltext files (what displays on screen) do not match what is in the traffic simulator exemplar (for A at least). Z's is correct as far as I remember. It is probably only cosmetic, just me nitpicking again...and also finding something else to learn.
Quote from: jplumbley on October 25, 2009, 04:17:44 PM
There was no change in the pathfinding heuristic therefore this would have no effect on the actual pathfinding between current Simulator A and the modified Simulator A. The pathfinding heuristic will have the exact same effect since it was completely unchanged.
I understand; I was trying to explain some of the observed differences between Simulators A and Z.
QuoteIf you read later on, ldog made changes to how he was playing the game which could easily have contributed to his problem with abandonment.
Reading his responses to the point you just made, the wealth levels involved didn't match up, making that seem unlikely. But there is some room for doubt here, as interactions can get complex. That's why I encouraged ldog to repeat the entire city with Simulator Z.
QuoteI hope you start taking a step back soon and realize that Simulator A is not as bad as you are so set out to make it.
Please understand that I am not claiming that Simulator A is "bad"; the fact that so many people used it for so long with very few complaints would seem to be evidence enough that it's not. I'm just trying to see where things can be improved, which is exactly what you did when you built Simulator A. :)
Oh, now a long post from ldog while I'm writing this. I'll have to get to that later...
Quote from: z on October 25, 2009, 05:30:20 PM
I understand; I was trying to explain some of the observed differences between Simulators A and Z.
Reading his responses to the point you just made, the wealth levels involved didn't match up, making that seem unlikely. But there is some room for doubt here, as interactions can get complex. That's why I encouraged ldog to repeat the entire city with Simulator Z.
Please understand that I am not claiming that Simulator Z is "bad"; the fact that so many people used it for so long with very few complaints would seem to be evidence enough that it's not. I'm just trying to see where things can be improved, which is exactly what you did when you built Simulator A. :)
Oh, now a long post from ldog while I'm writing this. I'll have to get to that later...
LOL yeah, we are crossposting each other. Jason slipped that one in while I was writing my latest novella.
The wealth levels probably don't match up because the idiot who stated them (me) honestly wasn't paying close enough attention. I know I am longwinded but you guys really need to read my disclaimers. I didn't consider it a valid test of anything and didn't draw any conclusions from it other than that it was really wierd. As we've all agreed it is really too small and too limited to be vaild for anything. I need to repeat the other night and pay more attention. Fortunately the city is still saved in the same state it was prior and I posted the list of mods I was using at the time otherwise I'd have no clue. So I will rerun it. I will also rerun it with Z so everyone is satisfied, but I can pretty much tell you what is going to happen because it is almost the same as 1 of the 3 citys I originally had in a region I was playing in when I first started using Z. Many people will walk very far. They will also ride the buses. But congestion will be pretty much nonexistant.
I know you two are a bit competitive with each other but this wasn't "the test" it was just a bit of fun and some general observations with a bit of humor injected into them but they weren't valid comparisons to say one was better or not. It was sorta a prereq for me since I played with Z already but had not played with A to get a feel for A. So I know what to expect. Although it does go as proof that I am learning something that I knew to expect certain things by looking at the exemplar before I even fired up the game.
??? :o You claiming that Z is bad? I'd hope not since you wrote Z. Don't ya hate typos...
Quote from: ldog on October 25, 2009, 05:54:26 PM
??? :o You claiming that Z is bad? I'd hope not since you wrote Z. Don't ya hate typos...
Oops. And I even reread that, checking for mistakes. Sigh... ::)
Anyway, off to build a couple of new simulators, but I'll be baaaack. And yes, I realize we haven't got valid comparisons out of these tests, at least so far. It might be useful if we did at some point, although that's up to you. :)
Ok, I think I found the answer.
It was in the CAM manual. When Jason started talking about the CAM it of course prompted me to go off and start looking at it.
As I said earlier, the CAM is probably one of the best documented projects here. Very early in my downloading I grabbed it, read through the manual, decided it wasn't for me, but that there was still a lot of good stuff in it. Some of it was well enough documented that with SC4tool and ilives in hand between the 2 programs I was able to figure out exactly what I needed to do to incorporate some of those features that I did want. One of those things was the industrial jobs. (you guys don't know how lucky you are, I just deleted a very large paragraph of unecessary, and probably uninteresting background info :P )
So I have my little mod which adjusts the industrial jobs to CAM specs. Looking at the appendix in the manual manufacturing has far less jobs than dirty. So the answer is: (drumroll please)
I'm pretty sure I did this myself and it should have happened even if I didn't change the traffic sim and it really should happen no matter which traffic sim I use.
Even though I only did a few buildings and then waited for new buildings to grow before I bulldozed more, that made the city unstable. The full effects of my educational system hadn't been reachedyet either. There were also some residential and commercial lots on high density that hadn't hit stage 8 yet.
I played this city for a night, mainly to get a feel for A. Then the next night I was going to start my new big test city based on 3RR map but I decided since this was already built let me drop the sim in and see what it does, especially since I was tired after laying out grids all day with the game paused and I still wasn't even half done. If you will both remember (at the top of the page, many many words from me ago) I thought in that city performance was a lot more interesting, and I was seeing a lot more about how A actually worked.
I also came to the realization that I was going to have to do a much better job building the city to get any kind of meaningful results. It was going to take a lot more time, and having realized that was when I said I needed to start putting plugins that I would normally play with back into the game and start building that city as if I was "just playing the game". It has to have numerous and varied paths, multiple transit options, large population (I think I am quoting you again Steve). I am not by any means giving up but what I anticipated as being something I could do in a few days is more like a few weeks (probably months if I don't stop finding all these distractions) so for me to see it through I will have to enjoy doing it, and of course as my threshold of boredom lowers over time what would have been bearable for a weekend is unbearable for a longer duration, which is what the job requires.
Quote from: z on October 25, 2009, 07:32:11 PM
Oops. And I even reread that, checking for mistakes. Sigh... ::)
Anyway, off to build a couple of new simulators, but I'll be baaaack. And yes, I realize we haven't got valid comparisons out of these tests, at least so far. It might be useful if we did at some point, although that's up to you. :)
You snuck in while I was writing again.
New sims? Yay! Are they RTMT type sims? huh? huh? huh?
See above, I'll get there (me and my big mouth)
Go check out my thread; they're posted now.
A European mod. Cool. Not that I would use it cause I'm not well...European, but I was just thinking the other day I bet the Europeans have a totally different take on traffic than we do and I was wondering why they didn't have their own traffic simulator.
And a...a harder Z mod...I feel all warm and fuzzy now. You decided it would be easier to rewrite the traffic plugin than read any more of my never-ending posts?
I'm not giving up that easy! But I will certainly have to try it out. Should be interesting. In a nutshell I guess that is what I've been trying to say; it isn't that your simulator doesn't work well, it works TOO well.
Now you just made more work for me. Yet another simulator to try out.
Ok, that's it I'm off to bed! Before someone else holds up something bright and shiny that catches my interest.
Quote from: ldog on October 25, 2009, 09:50:49 PM
And a...a harder Z mod...I feel all warm and fuzzy now. You decided it would be easier to rewrite the traffic plugin than read any more of my never-ending posts?
Yes. :D
Well, not really. Actually, this has been planned for quite a while. I think it would be useful to go back in my thread and reread
this post (http://sc4devotion.com/forums/index.php?topic=5382.msg269878#msg269878). This shows exactly which properties of Simulator Z will be changeable in the NAM Tool. By changing these, you can make the simulator arbitrarily difficult - you can easily make it too difficult to successfully play any city, if you want. Since the new NAM Tool isn't ready yet, try taking Simulator Z and adjusting just those properties. (If you adjust the network capacities, they all need to be adjusted by the same proportion; the same goes for the bus speeds.) Let me know if you can't get the perfect simulator for you from these adjustments, and if not, what's missing. I try to please. ;D
Been a busy day at work so not a lot of time for reading.
Still going through old posts and also some of the offsite A* stuff.
How did...Mott(it was Mott as best as I can determine)...arrive at .003 as the perfect PH ?
Whatever happened to Mott btw? Is he still around?
If PH= 1/speed of fastest travel type (this would be monorail in all the sims I have seen so far) then doesn't it always change?
.003 would be the perfect PH for a monorail speed of 333, .004 for 250, .005 for 200, etc
I am guessing this is not the correct formula, as it seems Mott started a lot of the discussions and so he threw out ideas that were close but further development by himself and Jason, and then later Steve refined?
I am thinking some of the threads I've been reading even from page 1 actually started elsewhere but it is hard to determine the chronological order of several years of traffic simulator discussion.
Tropod was actually the first person to use .003 as the Perfect Pathfinding number, unless there's someone earlier in the forums over at ST who came up with it. As I gather you've noticed, Mott originally came up with .003, but then ended up with a variable formula, which didn't make sense to me, based on the way that A* works. So I did experiments. LOTS of experiments. And sure enough, I can say with complete certainty that the proper value for Perfect Pathfinding (at least within a few percent) is .003, the same value that Tropod used, and that Mott initially decided on. From Mott:
Quote from: mott on October 16, 2007, 03:37:46 PM
Conclusion:
The "better" pathfinding version of the NAM plugins still allows some zig-zagging in my experience. The "perfect" version (heuristic 0.003) doesn't inherently use nearly as much CPU or RAM as it's advertised to in most cases, finds the optimal path in just about every case possible, and will actually receive a performance improvement from the "speeding mod" whereas the default Maxis value would not. It may actually exceed Maxis's performance in many common cases with that mod. Stick with the 0.003 heuristic for now, I'd say.
Everything Mott says here is correct. Unfortunately, he never implemented this in his simulator, not even the alpha versions. Simulator Z follows Mott's advice exactly here.
To answer your other question, Mott was around only for a few months. He appears to have left shortly before the release of Simulators A and B; Jason would know more details.
Quote from: z on October 26, 2009, 03:15:17 PM
Tropod was actually the first person to use .003 as the Perfect Pathfinding number, unless there's someone earlier in the forums over at ST who came up with it. As I gather you've noticed, Mott originally came up with .003, but then ended up with a variable formula, which didn't make sense to me, based on the way that A* works. So I did experiments. LOTS of experiments. And sure enough, I can say with complete certainty that the proper value for Perfect Pathfinding (at least within a few percent) is .003, the same value that Tropod used, and that Mott initially decided on. From Mott:
Everything Mott says here is correct. Unfortunately, he never implemented this in his simulator, not even the alpha versions. Simulator Z follows Mott's advice exactly here.
To answer your other question, Mott was around only for a few months. He appears to have left shortly before the release of Simulators A and B; Jason would know more details.
Oh, I didn't think of looking at Simtropolis, but it would make perfect sense discussions started there, since that is the older of the 2 sites.
I've only just started reading about A* and so I am getting a little ahead of myself but if the perfect heuristic value is tied to the lowest terrain entry cost, and our lowest terrain entry cost is 1/speed of fastest network... &ops :angrymore: I forgot to multiply by 1.3 for our speed to congestion ratio...which in Z gives us... ::) 0.0030769230769230769230769230769231 or .003 in practical terms :-[
Hey Steve, I bet you didn't know that when you randomly selected .003 that it was the perfect pathfinding heuristic for your simulator? What incredible luck that wasGood job :thumbsup:
[/sarcasm]
Hey...look how easy that was, a couple short(er) posts from me, you only had to reply 1 time and I understand it.
Since everyone around here seems to like using first names, I'm Lenny by the way.
Interesting http://simcity.ea.com/about/inside_scoop/traffic.php
Well to me anyway, I'm assuming you and Jason have read it.
Quoth the raven "The Sim has to be able to do things like walk in the opposite direction from work, enter a bus station, come back out in a bus, and travel over the same tiles he just walked on." and "it may be worth it for a Sim to walk in the wrong direction in "
Something I seem to remember y'all saying was never observed in vanilla. No wonder with their PH so high. I'm still trying to find formulae I can understand, because it seems like some final operation was left out. Like taking the square root or something. Which was why I brought up the formula Mott posted cause it's some kind of derivative that I can understand.
This h(n) = |xa − xb| + |ya − yb| not only produces a large number but it also doesn't produce anything consistent. So it doesn't make sense to me. The forum won't display it properly, but it is x with a little a, meaning a variable named xa (it is not x multiplied by a) which is our source X coord, subtract the dest X coord, also take the source y and subtract the dest y and then add them together. The brackets around it just mean to take the absolute value (so a negative number is treated as if it were positive). So either something is missing or we take that value and then plug it into some other formula that I haven't found yet. That is how it is presented though.
We all know the original PH was far from perfect, I wonder if it was even admissible, I am still looking for how that is calculated.
Also, I don't understand how .003 can be "THE" perfect PH if it is tied to lowest terrain entry cost? If you change your highest speed then you have just changed the perfect PH (again by Mott's formula).
For you to verify it by experiment, your experiment would have to have been to count how many tiles a particular trip took along what network and how congested it was to figure out how long it actually took, and then to count all the alternate paths it could have used and also figure out how many time units that would take and compare them, after taking into account travel preference, trip starting cost, etc, etc. That is an AWFUL lot of squinting at tiles and making mathematical calculations. Just to figure out 1 single trip. Of course you'd want a bigger cross section than just 1 trip. You would also have to redo it every time you made a change to the sim. How many MONTHS did that take you?
Something else also occurred to me. The pathfinder does not need to be perfect. This is a traffic simulator, traffic does not use perfect pathfinding. So somewhere between the admissible PH and the perfect PH is really all that should be needed to make the game work well.
Quote from: jplumbley on October 26, 2009, 07:34:22 PM
No Mott hasnt been around for a long time. Noone knows what happened he just stopped posting.
That actually sounds like a plausible formula to figure out "perfect pathfinding" and it would make sense due to the fact that it is defining the minimum tile cost allowable in the Simulator and telling it to compare all routes to that increment.
If this truely is the case then 0.005 would be "perfect pathfinding" for Simulator A due to the fact that monorail speed is 175.
I agree with this statement, Simulator A includes "better pathfinding" instead of "perfect pathfinding" because not everyone takes the "perfect" route to work. Myself, I have about 4 or 5 different routes I take to work or home from work because I don't want the aggravation of driving with the morons on the highway. Many of these routes take me longer, in fact a couple take me almost twice as long as my 45 minute trip but I would still rather take them than deal with the morons.
This is why I believe "perfect pathfinding" is unrealistic for my purposes and the intent of Simulator A. In fact, after reading that post on the SC4 site (that I never knew existed) I am tempted to even raise the value a little bit more. It is at 0.009 and based on your little formula, 0.016 would be the max it really could go with that being the value of the Road cost per tile for cars. So, thinking about it.... 0.009 doesnt sound like a bad place after all. And it has worked well so far.
I'm sorry I am too tired to break out all the quotes and replys but you can figure out which part is in response to which.
This is also only if I am correct, which I am not convinced one way or the other at this point. I am taking it as a given for the moment that Mott's formula is correct. If was Mott wrong then I am wrong. If Mott was right, I could still be wrong. I have only barely skimmed A* and I could be jumping to incorrect conclusions.
But hell, Maxis set it to .09 and the game didn't blow up, it just sucked. So you can't really hurt anything changing it a little. Don't forget to multiply by 1.3 though! 0.0043956043956043956043956043956044, or .004
I still haven't figured out a formula for admissible ph.
Quoth the Raven,
"If the heuristic function is admissible (meaning it never
overestimates the minimum cost to the goal), then A* is also, like Dijkstra, guaranteed to
find the shortest/cheapest path. It is also of great advantage to use a heuristic that
underestimates the minimum cost as little as possible, as this will result in fewer nodes to
be examined" and "Nevermore"
This is from Daniel Rolf Wichmann, who other than being associated with the University of Auckland Dept of Computer Science, I don't know if he was a professor, a student or the janitor. I did download his document from Amit Patel's site though, so I would guess he is as trustworthy a source as Patel.
So now we have to sit down and figure out a formula for overestimating the minimum cost to the goal and then we can determine admissible pathfinding heuristics.
Also don't forget that it is assumed it is off the LOWEST cost. While I admit I was wondering just that same thing, what if you went with the perfect PH for roads for example, but I suspect it makes things run crappy, or at least the MT. Think about why would the monorail usage in vanilla be bad, when it is the fastest network there is.
Now, for an experiment I think one could set the perfect ph based around roads and then strongly priveledge MT. That should either cause car use to be high until the congestion gets bad and then MT fills in (which would be kinda cool) OR it will just make the simulator go down the rubbishter.
Like I said though you can't make it any worse than Maxis did with the PH unless you go higher than them.
Quote from: z on October 25, 2009, 10:44:06 PM
I think it would be useful to go back in my thread and reread this post (http://sc4devotion.com/forums/index.php?topic=5382.msg269878#msg269878). This shows exactly which properties of Simulator Z will be changeable in the NAM Tool. By changing these, you can make the simulator arbitrarily difficult - you can easily make it too difficult to successfully play any city, if you want. Since the new NAM Tool isn't ready yet, try taking Simulator Z and adjusting just those properties. (If you adjust the network capacities, they all need to be adjusted by the same proportion; the same goes for the bus speeds.) Let me know if you can't get the perfect simulator for you from these adjustments, and if not, what's missing. I try to please. ;D
This is out of sequence but I don't see the props in that thread (although I think I know which thread you meant to link, where you did outline a lot of them)
There are some interesting things from the post you did link though(reposted here for ease of discussion):
* A Bus Usage Multiplier, which would allow the player to control the relative usage of buses in the traffic simulator. The initial setting would be 1, which would reflect the current usage level, and this value would be calibrated in tenths, with a range of 0.1 to 9.9. (Zero doesn't actually work as expected if valid paths are available.)
* A Highway Bus Lanes checkbox, which would simulate the existence of bus lanes on highways, although of course the automata would not reflect this. But this last fact would not necessarily be obvious; you could also call it a carpool lane, to explain the presence of cars, and some buses would be traveling in other lanes anyway. This could be combined with the Bus Usage Multiplier to produce a multiplicative effect.
* Allowing the players to tweak the monthly cost of all the networks. Although the purchase cost for network tiles is accessible, it's often tied up in exemplars with properties that are changed by other mods, so it's risky to modify those exemplars. But the monthly costs exist completely within the traffic simulator. And realistically, cities don't have bundles of cash sitting around for big construction projects anyway. So the monthly costs can be considered payments on interest-only bonds that the cities issue to build the networks. These costs can be made more or less expensive to suit the player's preference, and each network can be tweaked individually.
* Similarly, the players could adjust the fares for each travel type any way they wanted. As an example, you could make your ferries traveling riverboat casinos, and charge the Sims §100 just to board. That would solve your financial problems fast. This wouldn't deter the Sims from taking ferries; they just don't know the value of money.
These are variables that I haven't mentioned but have been thinking about, because ultimately part of tuning the traffic sim for a well balanced game includes adjusting the prices. The playstyle needs to suit the engine. For example you making the subways more expensive is a way to tell the player who was used to over-extensive subways "Hey! You don't need to build all those miles of subway anymore with this sim, in fact you are gonna go broke if you do". So it sends a clear message about one of the things that makes your simulator distinct.
* The intersection effect could be changed, effectively making more or fewer stoplights and stop signs in cities, making traffic flow smoother, or making a complete mess of it.
This I have been adjusting, in all directions lol. It is also one of those things you can very quickly and clearly see the effects of. Good times!
* The commute time graph scaling could be changed by the player. This is useful because the proper scaling depends on the type of region that the player builds; specifically, it is dependent on the number of inter-city commuters.
TBH, I still am having trouble figuring out how this works. The internal documentation doesn't make a lot of sense. Initially I thought you should divide 255 by your max commute time and there is your multiplier (or less if you want to just simulate a certain number like Maxis did, which is what I was talking about when I was throwing out time questions and referencing 2.5 hours or 3 hours ) but fiddling with it seemed to just produce randomness. I noticed Sim Z and A both use 25 even though they both have very different max commute times.
* Finally, the amount of air pollution emitted by vehicles could be tweaked by any amount in either direction.
Where do you control that? Or are you talking about the clean air ordinance?
Speaking of vars, where is the traffic/noise coefficient? Is that another one like the PH that my reader might be calling another name?
Some words of warning from my side, based on extensive experimental results:
- The value for perfect pathfinding, as implemented in SC4, has absolutely nothing to do with speed or any values in the CvS curve. It is always .003, regardless of whether or not the city has monorails or just cars. Remember, we don't know what type of normalization or anything else is going on inside the simulator engine. Theory here is good only so far as it is backed up by experimental results.
- The problem with raising the pathfinding heuristic higher than .003 is not that the Sims will not take the absolute best route to work (although that's true). The problem is that as soon as you raise it above .003, you get increasing numbers of Sims who find no paths to work, even when such paths are available. This means that as soon as you start going above .003, you start getting abandonment due to commute time, and the higher you go, the more abandonment you get.
- Values of the PH above .003 don't give more random paths; none of the values give random paths. The paths are always deterministic; the Sims will follow the same ones again and again. But the higher above .003 you go, the simpler the paths become, which makes them look less random.
Quote from: z on October 26, 2009, 10:35:04 PM
Some words of warning from my side, based on extensive experimental results:
- The value for perfect pathfinding, as implemented in SC4, has absolutely nothing to do with speed or any values in the CvS curve. It is always .003, regardless of whether or not the city has monorails or just cars. Remember, we don't know what type of normalization or anything else is going on inside the simulator engine. Theory here is good only so far as it is backed up by experimental results.
- The problem with raising the pathfinding heuristic higher than .003 is not that the Sims will not take the absolute best route to work (although that's true). The problem is that as soon as you raise it above .003, you get increasing numbers of Sims who find no paths to work, even when such paths are available. This means that as soon as you start going above .003, you start getting abandonment due to commute time, and the higher you go, the more abandonment you get.
- Values of the PH above .003 don't give more random paths; none of the values give random paths. The paths are always deterministic; the Sims will follow the same ones again and again. But the higher above .003 you go, the simpler the paths become, which makes them look less random.
But this can only be determined mathematically. Any other kind of experiment, such as just watching how it runs and making observations will let you determine that you have a value that works well but not that it is the perfect value. I am not discounting what you are saying either, just because Maxis made it possible for us to tweak a bunch of things doesn't mean it shows the whole picture. For example, I strongly suspect the ferrys have their own seperate pathfinding engine. There also really isn't any way for us to tell what kind (if any) of subsampling the pathfinding engine does and some other A* things that you are no doubt familiar with.
I thought about that (no paths) as well but what I am talking about is a SMALL margin of error.
I'm just saying I think it isn't important to have the perfect ph, just to be close.
Quote from: jplumbley on October 26, 2009, 09:15:24 PM
Eeeks! Warning.... You can change the budget costs a little bit with the networks, but you don't want to change them too much. If you start making them too high, you will start throwing the balance the entire budget system, which would include taxes and/or building values of every building in the game. If you ended up modifying the transportation costs too much then you would have a choice of compensating either threw modifying the tax system which may involve delving into demand (don't go there).... Or doing a lot of editting of Building Exemplars to raise the Building Values so that you produce more taxes based on higher building values.
It may seem like a harmless thing, but to be honest I don't think anything other than capacity should be in the NAM Tool. Even then, I think we should just be providing a prooven set of options of different Simulators, instead of letting an end user who has never read one of these threads modify anything in the Simulator. If anyone has such the desire to modify something, they have the Reader and a lot of information at their disposal on what each property does and how to use the Reader. We should make it easier by adding choice, not by making a tool that makes it easier to screw up the game. It will just become a tech support nightmare.
Oops, almost missed this.
Yeah, I know. You can make small changes without tweaking the rest of the game, but after that you are talking about editing many parts of the game. I'm actually considering modding many aspects of the game besides the traffic sim but y'all see how easily I go offtopic and if I started talking about those things in this discussion we would be completely derailed. Just suffice it to say that when I start talking about things like this, you and Steve can rest assured that I have considered the implications to the rest of the game engine.
As far as the NAM tool I will leave that to you guys and the rest of the NAM team.
Part of the reason I moved out of the NAM thread is my traffic sim will likely not be NAMpatible. I really don't use a lot of the features in the NAM. The only thing essential to me is diagonals.
The NAM is mostly about eye-candy and since the map is only so big there is only so much eye-candy you can use. So for example while wider highways and avenues may be very visually appealing and realistic, they also take up too much space for me. Then there is the GLR and the RAM. Besides their visual effects, they add a lot of complexity that I just don't need.
So those are also some of the reasons I want to build my own traffic simulator. It will never be a competitor to Z, A or any other traffic sim, in fact as Steve has basicly said it would be a waste of time. I do see a niche to fill though, and that is to provide completely different options, even if I am the only one who chooses to use such option. In fact because it is probably of such limited appeal that is why I am willing to do it myself. Also if it prompts you and Steve to reexamine your own work and say "maybe there are some new things I can put in A" or even if you reaffirm that "Z is a finished product and there isn't one thing I would change in it" plus if we've all enjoyed this discussion (I hope) then it was not time wasted on anyones part.
Quote from: ldog on October 27, 2009, 08:02:06 AM
But this can only be determined mathematically. Any other kind of experiment, such as just watching how it runs and making observations will let you determine that you have a value that works well but not that it is the perfect value.
Yet without the source code, we can't determine it mathematically. (There's some indication that the .003 value may have been obtained from Maxis, although in a roundabout way.) Experiments may not determine the absolute perfect value, but I've done enough of them, under enough circumstances, to come within a few percent, as I mentioned previously. (This was part of my job for 25 years.) Newton's law of gravitation was obtained solely by experiment; he himself admitted that he had no idea how gravity actually worked. And Einstein came along a few centuries later and showed that Newton's law was not exactly correct, but it was awfully close. The gravitational constant, the speed of light - there are many constants in science that have been determined with great accuracy purely by experiment, and for which even today there is no theory to explain them.
Quote
I thought about that (no paths) as well but what I am talking about is a SMALL margin of error.
I'm just saying I think it isn't important to have the perfect ph, just to be close.
How small? How close? In different applications of A*, you have more wiggle room. But my experiments showed that in SC4, you start running into trouble as soon as you depart from a value of .003.
And what's wrong with using .003 in any case? I see no disadvantage to it whatsoever, only advantages. And the feedback from users has all been along those lines.
I'm not trying to be aggressive or defensive here; I would just like to ask some pointed questions. I'm used to doing work that can be justified with a large amount of rigor, and even if you're designing a simulator solely for your own use, I think you'll find that such rigor will serve you well.
Quote from: z on October 27, 2009, 12:06:59 PM
Yet without the source code, we can't determine it mathematically. (There's some indication that the .003 value may have been obtained from Maxis, although in a roundabout way.) Experiments may not determine the absolute perfect value, but I've done enough of them, under enough circumstances, to come within a few percent, as I mentioned previously. (This was part of my job for 25 years.) Newton's law of gravitation was obtained solely by experiment; he himself admitted that he had no idea how gravity actually worked. And Einstein came along a few centuries later and showed that Newton's law was not exactly correct, but it was awfully close. The gravitational constant, the speed of light - there are many constants in science that have been determined with great accuracy purely by experiment, and for which even today there is no theory to explain them.
If you had said "I think this is the perfect pathfinding heuristic" or even "I know I am pretty close to the perfect pathfinding heuristic" I wouldn't even challenge it.
When you say things like "complete certainty within a couple percent", it is not something I am going to just accept as a given, especially when you just say "I've done extensive testing" without going into detail what your test methods were. You make the perfect pathfinding heuristic sound like it is a religion.
...and then others have come along and said Einstein was not exactly correct, and on and on. The development of science has not stopped, it is an ongoing refinement. As we learn more, we can become more accurate. Also as things develop the tolerance range for inaccuracy becomes smaller.
Didn't Einstein also say something along the lines of "We don't truly understand anything if we can't explain to a 3 year old."
Of course I don't see the point of explaining computer science to a 3 year old, but if we look at a 3 year old as if they were an adult, we could replace 3 year old with "an idiot with a very short attention span".
Quote from: z on October 27, 2009, 12:06:59 PM
How small? How close? In different applications of A*, you have more wiggle room. But my experiments showed that in SC4, you start running into trouble as soon as you depart from a value of .003.
As I said no higher than the admissible value. How small and how close I couldn't say without knowing the range between admissible and perfect. I also admitted I haven't figured that out yet.
I think very small and very close. Yours is the only one that uses a value low though (I will let other people draw the inferences). Also if that is the case then I would think it means .003 is not the perfect ph, but the edge of admissible. We know Maxis default wasn't admissible because the sims won't take a longer route even when it would be quicker.
Quote from: z on October 27, 2009, 12:06:59 PM
And what's wrong with using .003 in any case? I see no disadvantage to it whatsoever, only advantages. And the feedback from users has all been along those lines.
Pathfinding performance may not be optimal. CPU performance may not be optimal. I am not throwing that out there because I care much about it (it just needs to be tolerable) just answering your question truthfully and objectively.
From a practical standpoint, there is nothing wrong with it. This your experiments can conclude. Simple experiments can conclude this. Very simple ones. Like just playing the game simple. Every person who has used your simulator (myself included) can attest that .003 is an admissible ph. Everyone who has played with Jason and Mott's and probably all the other ones would also say that .009 is admissible as well.
What is wrong is conclusively calling it the perfect ph, especially for all circumstances.
Quote from: z on October 27, 2009, 12:06:59 PM
I'm not trying to be aggressive or defensive here; I would just like to ask some pointed questions. I'm used to doing work that can be justified with a large amount of rigor, and even if you're designing a simulator solely for your own use, I think you'll find that such rigor will serve you well.
That's fine. I am not either. I certainly appreciate your feedback. You originally said you would meet me halfway. You have gone much farther.
Even if I think you don't know everything, I certainly think you know a lot more than I do. And you have turned out a traffic simulator that is very useable to very many people. Part of why I am being such a pain in the ass is because in my work experience, proper (one could say rigorous) planning makes doing the actual work go very smoothly. Poor planning makes mountains out of molehills.
Quote from: ldog on October 27, 2009, 03:37:37 PM
When you say things like "complete certainty within a couple percent", it is not something I am going to just accept as a given, especially when you just say "I've done extensive testing" without going into detail what your test methods were.
You don't have to. And I'd be happy to go into detail about my test methods were it not for the time issue. The tests are extensive. (I seem to recall mentioning that my time was limited...) There is a point where this may come before the NAM Team, in which case I will go into my testing methods in detail.
QuoteYours is the only one that uses a value low though (I will let other people draw the inferences). Also if that is the case then I would think it means .003 is not the perfect ph, but the edge of admissible.
No; fully a third of Tropod's simulators used the same value. This is the value that causes improper abandonment due to commute time to disappear, and if you look through the various threads with comments about Simulator Z, you will see that the users concur.
QuoteEveryone who has played with Jason and Mott's and probably all the other ones would also say that .009 is admissible as well.
There are plenty of people who have said that Simulator A with its value of .009 produces too much abandonment, and if you look through the threads, you will find them. Here's just one sample quote, from
sumwonyuno:
QuoteSince I started using NAM, I've used a variety of the included simulators (and tweaked them to my liking), experimenting with capacities, speeds, commute distances, etc. I settled on Simulator A when that came out as an option.
Ever since I bought SC4 Deluxe, I've been trying to recreate the Hawaiian island of O'ahu in the game. Late last year, I ran into problems with abandonment (because of eternal commuters from removing the Residential Halver) and traffic simulation (neither optimal IMO nor vaguely resembled RL). Then I found z's thread, and I received help from both my problems in there. Without Simulator Z, I don't believe I could have finished building the island because decent multi-tile commutes would not be possible without it.
Because SimCity is not real life, there are game limitations (no traffic sim at the region level) and the simulator isn't custom-tailored, traffic isn't going to act the way I want it to. Simulator Z has done a fine job of being the best thing out there (yet), to get the traffic simulator to contribute postively to the overall SimCity game experience.
QuoteWhat is wrong is conclusively calling it the perfect ph, especially for all circumstances.
Higher values cause abandonment, which is essentially the result of a bug. Lower values simply increase CPU and memory usage. That's why the .003 value is called "Perfect Pathfinding" (starting long before me). :)
Quote from: z on October 27, 2009, 05:24:51 PM
You don't have to. And I'd be happy to go into detail about my test methods were it not for the time issue. The tests are extensive. (I seem to recall mentioning that my time was limited...) There is a point where this may come before the NAM Team, in which case I will go into my testing methods in detail.
I know doing the kind of proper testing would take a tremendous amount of time.
Detailing the methods would also take quite a bit of time.
I recall that as well and I also recall saying that I respect your time.
So I will drop the issue (for now anyway :P )
When/if it comes before the NAM Team, please make that information available to me as well though?
Quote from: z on October 27, 2009, 05:24:51 PM
Higher values cause abandonment, which is essentially the result of a bug. Lower values simply increase CPU and memory usage. That's why the .003 value is called "Perfect Pathfinding" (starting long before me). :)
You feel it is a bug, Jason feels it is a feature. I haven't put enough time and thought into it to have a strong opinion, but I feel a little bit is a good thing, a lot is a bad thing.
I know other people started calling it perfect pathfinding before you did, I was asking if you just took their word for it or you verified it.
A week ago I didn't know what perfect pathfinding heuristic actually meant. You were correct in your initial assertion that "I didn't have a clue" at the time, of course my initial assertion was just as correct, since like Newton in your example it really didn't matter if I had a clue or not, I could still observe certain effects and do certain experiments (no matter how limited).
Of course having read about A* which I am still no expert in, you and I both know the perfect pathfinding heuristic isn't called that just because it works good (how good? really good...mmmmmhhhhh...dat's good!) </Jimmy Walker impression>. It is an absolute value. I really don't think it is possible to nail down the perfect ph by in game experiments without an incredible amount of work..and probably stripping as much as possible out of not just the game but the traffic simulator controller as well.
Admissible values for the pathfinding heuristic are a whole nother story. They are the range of ph between perfect and where the game is fubar. You would think that Maxis would have used a value that was at least admissible but I think we can all agree they didn't.
Quote from: ldog on October 27, 2009, 05:51:21 PM
When/if it comes before the NAM Team, please make that information available to me as well though?
Yes, I will be happy to do so.
QuoteAdmissible values for the pathfinding heuristic are a whole nother story. They are the range of ph between perfect and where the game is fubar. You would think that Maxis would have used a value that was at least admissible but I think we can all agree they didn't.
There's a very simple explanation for this. At the time the game came out, almost seven years ago, .09 was the lowest Maxis could go on PCs of that day (the minimum requirement was a 500 MHz Pentium III). Tropod came along with his simulators a while later, when most PCs were better. He made a third of his simulators use the original PH, as their were still a lot of old PCs around; a third used a "Better Pathfinding" heuristic, which was suitable for most of the PCs of that time; and a third used Perfect Pathfinding, which was usable only by leading-edge PCs back then.
Now a number of more years have passed, and any PC can use Perfect Pathfinding, especially with the tuning I put into Simulator Z that makes it run several times faster than Simulator A using a .009 PH. So that's why the .003 value is standard throughout Simulator Z.
Could be. I'm not even going to argue with you for a change :P
So I was short on humor today. I "know" that's why we have all those views of the thread even though it is just the 3 of us, people just come for my bad jokes :satisfied:
So noticing what a bunch of old geezers we are around here...
This was probably a marketing slogan Tilted Mill should have considered:
"Sim City Societies: This is not your fathers Sim City"
I decided I had better put in some play time today (I didn't yesterday, between reading, posting and the wife demanding some time)
Of course I had to tweak my vanillaish simulator a bit first. Still undecided on the PH. I decided to go with .005 for now. I made all the rail MT (rail, sub, el, mono) not affected by traffic. I also left their capacitys at defaults (if y'all remember I doubled the roads/ave/hwy/etc). So 1/200 since the monorail runs at stated speed is .005 I know what you are gonna say (about the PH) but I think it makes more sense to see how it does with a less than perfect PH and then switch to the perfect PH instead of viceversa.
I didn't make the no congestion change because of the PH of course. Just an idea I had to try out. Giving the MT a lower capacity but no congestion it "should" be possible to tune it to produce the desired effect, which of course may have no noticeable difference on game play...but it's a thought.
Another theory I've got about MT is related to the travel type preferences. All things being equal (you didn't have a desire for your different wealth sims to have different prefs) I'd think you would only need car and fastest. If the traffic is bad on the road (and when isn't it) then the MT should be fastest route. Of course I do think the different wealth levels should have different preferences. I just conservatively (10% total) tweaked these today. R$$$ no pref for MT, extra 10 for car. R$$ also no MT pref, another 10 for car. R$ 10 less for MT, 10 more for fastest. Of course I will eventually wind up with values closer to yours and Jasons in all likelihood. Being as we really shouldn't be building much MT until the roads are overloaded it should usually win by virtue of being fastest route.
Of course I've got a bad plugin installed again. The game is locking up my computer entirely after a random amount of time. So I didn't get to do much playing :(
I know, I'm going to stray away from the thread, but I've been referenced.
I admit I haven't delved that deeply into the traffic simulator as much as you all. I've read things here and there, but I don't claim to be able to say anything about it with much credibility. I have done some big mistakes in my region that causes problems in my region with respect to demand and eternal commuters. I know the simulated behaviors in the game are interconnected. So I understand that abandonment is caused by numerous factors.
Referring back to when I had used Simulator A, I had abandonment problems with the Capitalis region. It wasn't because of a lack of jobs. I was trying to make Honolulu in the game, and I built the development and transportation to mimic RL. But, I understand that the game isn't meant to be RL. The game has its differences with RL with respect to transporation network capacity and residents/jobs. I understand that the game must be understood in terms of one city tile (X km by X km).
So the result of my region is an exaggeration compared to RL, and the transporation network is overwhelmed. Since the transportation network capacity is exceeded (over 300%), many commuters in certain parts of the city tile can not get to their jobs within the maximum commute time, and the buildings in that certain area abandon. These areas of the city tile that abandon are areas where all shortest path to available jobs are way over capacity.
I have to agree with jplumbley on the difference in commute time contributes to lessen the abandonment problem. I don't discount all the other things that z has done to tweak the traffic simulator to make it run faster. With Simulator Z the max commute time is raised high enough that Sims can get to that closest job, despite congestion.
I like that the sandbox effect of Simulator Z has helped me build my region. Though, from the standpoint of game mechanics, the lack of abandonment in existing conditions doesn't disprove other things are wrong. There are instances where there are jobs and residential demand in the same city tile, but new housing development abandons. Also, since commute times are so high, commuters will gladly crowd (unintended) neighbor connections because it's the closest job (sending commuters to the "wrong" city tile), while job buildings with no workers are common when they are far away from residential and neighbor connections.
Quote from: jplumbley on October 27, 2009, 09:12:48 PM
I would like you to proove this...
That's certainly a reasonable request. I will do so, but in the NAM thread, where the rest of the team will see it, since we are discussing what to do with the simulators long-term. It will also take me a little while, as I'm currently in the middle of a computer build. But I promise you that I will address this thoroughly before resuming my RTMT work, so it won't be that long.
QuoteI have not had any problems what-so-ever with abandonment in my cities due to the PH being higher than yours.
This is quite understandable, and my experience is that if you build cities that work well with Simulator A, you generally won't get that problem. Even in my cities, the abandonment happens only in certain areas. But in certain situations, it can be bad enough to make a stable neighborhood unsustainable. Again, I will elaborate more on this later, and explain the experiments that were done to show that this was specifically due to the value of the PH.
QuoteAbandonment is not caused by one simple factor, it is caused by many, mostly Commute Time and Congestion in your City.
Definitely. I would say that at least two thirds of the abandonment I have seen has been due to commute time limitations, which are then exacerbated by congestion. And this, of course, is one of the things that
sumwonyuno is saying. I think we're all in agreement here. My experiments here always tested only one variable at a time, as that's the only way to isolate the cause of the problem. Again, I will go into details later.
QuoteAnd if you want to do this test there is absolutely no way you can compare Simulator A and Z you must do it with one or the other.
Absolutely. And that's what I did.
So it sounds like we're in basic agreement about how to proceed. I will get back to you as soon as possible with more on this.
Oh, I'm pretty confident Steve meant his public Traffic Simulator Z Development (http://sc4devotion.com/forums/index.php?topic=5382.0) thread, in the NAM Place, as opposed to this thread which is in MODding Game Simulators Help requests.
I know I said I would leave this alone but, since you guys are gonna argue it anyway...the more I read about A* the more I think we (starting with Tropod and going all the way down the line to me) are all wrong.
Ok, so I found the Manhatten Heuristic formula stated reslightly at http://www.policyalmanac.org/games/heuristics.htm
The equation, where abs = absolute value, is:
H = 10*(abs(currentX-targetX) + abs(currentY-targetY))
Now 10 I am completely certain within a couple percent :P (sorry Steve, I couldn't resist) in this instance is our lowest terrain cost, because this was a sidebar to an article where the author had only 1 terrain cost, which was 10. This is the formula that I quoted earlier, except that it was missing "multiply by lowest terrain cost"
Going to quote Patel here, since his work was considered by everyone who came here before me and one could say is part of the foundation of this community's understanding of the traffic simulator.
"So we have an interesting situation in that we can decide what we want to get out of A*. At exactly the right point, we'll get shortest paths really quickly. If we're too low, then we'll continue to get shortest paths, but it'll slow down. If we're too high, then we give up shortest paths, but A* will run faster.
In a game, this property of A* can be very useful. For example, you may find that in some situations, you would rather have a "good" path than a "perfect" path. To shift the balance between g(n) and h(n), you can modify either one. "
Also, it is too long to quote but http://realtimecollisiondetection.net/blog/?p=56 in a nutshell for those of you not interested enough to read it, it just supports "my" theory that the perfect pathfinding heuristic is irrelevant (in so far as actually using it; it is still worth knowing because it gives us a baseline). Now I feel no personal attachment to any of my (mostly half-baked) theories, so I am not just presenting this because it supports what I said. Right now I just care about how things work, I don't have time to get an ego about it, there'll be plenty of time to do that after the work is done :P
I do need to point out thought that most of the other sources I am reading they talk a lot about domain specific knowledge being more important than pure pathfinding.
Some of this is applicable to SC4 but most of it probably isn't. It is more relevant to pathfinding AI for wargames. Where one might want to give a bonus (seek and destroy) or a penalty (avoid combat) to things like enemy units along the path, or penalize open terrain (stick to cover).
Some of these bonuses and penalties in SC4 are clear to see, the travel preference for instance, and then the costs that go with them (or rather the costs are a penalty, the preference tells us when we should apply them). We give a penalty to using the non-preferred method of transportation. Which in effect is already throwing in "a bit of randomness" (yes, I know damn well there isn't a bloody thing that is random about any of it; it is simulating the appearance of randomness...so don't start telling me how wrong I am), one or the other would clearly be the best path but we are skewing it in favor of taking a path that isn't.
Intersection and turn capacity. Which by the way I just found a problem with them being linked and what seemed to be common design theory here.
If you raise the intersection capacity to accomodate the fact that 2 networks are there, hence giving a bonus instead of a penalty, you also do the same to turns. Whereas you certainly want turns to have a penalty (note: Steve scaled his back away from what was considered accepted...and now I understand why)
I am not sure what congestion vs speed should be considered. On the one hand the highest bonus we apply one could consider to be the base (1.3 x speed...such as for calculating PH, making it almost a part of the basic formula) or we could just look at it as a bonus/penalty system as well. Of course how we choose to look at it is not important; it is how the game engine looks at it.
And back to our main man Patel again for a bit:
http://theory.stanford.edu/~amitp/GameProgramming/Heuristics.html
I am not going to quote this whole article because again it is long, it is all very good reading for anyone interested in the subject of A* but probably not so much for someone that just cares about SC4.
Of course I always enjoy a good chuckle:
"At the other extreme, if h(n) is very high relative to g(n), then only h(n) plays a role, and A* turns into BFS."
I love this guy.
I'm going to skip the rest of the section on heuristic for the moment. It has the usual formulas (which none of us seem to understand). I'll get back to it later.
Instead going to speed vs accuracy. This section is very interesting, a lot of it talks about things that once again don't really apply to SC4. For instance if you had plains and mountains but you don't want it to try quite so hard to go around the mountains so you actually use a heuristic that is not the lowest cost, but instead in between. We don't really have this kind of condition in SC4. UDI may be able to go offroading but traffic as we know it cannot. We don't want the engine to try to avoid using a particular kind of "terrain" (network in our case).
Some quotes:
"The choice between speed and accuracy does not have to be static. You can choose dynamically based on the CPU speed, the fraction of time going into pathfinding, the number of units on the map, the importance of the unit, the size of the group, the difficulty level, or any other factor. One way to make the tradeoff dynamic is to build a heuristic function that assumes the minimum cost to travel one grid space is 1 and then build a cost function that scales:
g'(n) = 1 + alpha * (g(n) - 1)
If alpha is 0, then the modified cost function will always be 1. At this setting, terrain costs are completely ignored, and A* works at the level of simple passable/unpassable grid spaces. If alpha is 1, then the original cost function will be used, and you get the full benefit of A*. You can set alpha anywhere in between."
Could be the variable we know as pathfinding heuristic is actually alpha. Would support Steve (Tropod, Mott) in that it is a constant no matter what the speeds we set in the exemplar are. If this is true, it isn't technically accurate to call it the pathfinding heuristic (it is actually a value in a formula to determine the pathfinding heuristic). I know also that it was Maxis in the internal documentation that called it that but as we all know the internal documentation does lie from time to time (and time and time again). Still want to know why my game calls it something else. Is it reader versions or is it USA vs international version?
"You should also consider switching from the heuristic returning the absolute minimum cost to returnin the expected minimum cost. For example, if most of your map is grasslands with a movement cost of 2 but some spaces on the map are roads with a movement cost of 1, then you might consider having the heuristic assume no roads, and return 2 * distance."
Now this. THIS is a lot more applicable to SC4. Replace the word grass with roads and the word roads (above in his quote not down here :P) with Monorail (or maybe even Subway/El or rail). That would support using the road (admissible...sometimes) heuristic instead of the faster (perfect) heuristic.
Last minute edit (and last peep out of me for the night, promise, closing the browser after this)
Forgot to mention that last page of reading also confirmed what I said above about the A* Manhattan Heuristic formula, 10 in the example above is indeed "D" which is minimum cost for moving from one space to an adjacent space aka minimum terrain entry cost. Just don't ask me why it is D instead of some other letter. Patel says it is D and that is good enough for me.
So to reiterate:
h(n) = D * (abs(n.x-goal.x) + abs(n.y-goal.y))
I also know some of this stuff was already quoted by Mott in discussions with Jason. Probably by Tropod and Steve as well. Excuse my laziness but it is a lot easier to reiterate it here than try to sift through old closed threads, which would probably result in me attempting thread necromancy on an unprecedented scale. Plus I have a much higher retention if I write (or type) it out than just reading it alone. So consider it indulging one of my (many) quirks. Thanks.
So a funny thing happened today...j/k...I'll spare y'all
Today just going to keep it short.
A final point that needs to be added to the above (not for Steve or Jason but anyone else who may be interested and following along) of A* theory and how it relates to us.
Also this is not to say that the above presented material is complete nor necessarily accurate.
One of the general rules of A* is that it will ALWAYS find a path (so long as there actually is a path). Period. So how can what Steve and Jason are arguing about be true? How can the traffic engine cause abandonment in the first place?
Yes, it is true. Well then what about what I just said above? Also true. How can both statements be true?
In other applications of A*, like wargames in my above examples, the route will be found. Again, no ifs, ands or buts. A unit of course is likely to have a finite amount of movement points per turn so It also may take many turns to reach the destination.
In SC4 we don't have this luxury. We've got 1 turn (a single pass of the traffic simulator) to get to our destination and back. Network speeds are our terrain costs. Our "movement points" are our max commute time. From a practical standpoint in SC4 if one can't find a route that one can complete in 1 turn then one could say that we cannot find a valid route (even if not technically accurate).
I am sorry if this is so basic as to be elementary to everyone but me. As I did say in the beginning this is "traffic sim for noobs". Steve and Jason being our resident experts are the teachers here, even if I am the one asking the questions and being a downright unruly student.
Quote from: ldog on October 29, 2009, 05:54:57 PM
One of the general rules of A* is that it will ALWAYS find a path (so long as there actually is a path). Period. So how can what Steve and Jason are arguing about be true? How can the traffic engine cause abandonment in the first place?
Yes, it is true. Well then what about what I just said above? Also true. How can both statements be true?
A little bit of logic will tell you that there's exactly one way that both statements can be true: SC4's implementation of A* isn't exactly what Amit is describing. And that's actually the case.
Quote from: z on October 29, 2009, 06:14:08 PM
A little bit of logic will tell you that there's exactly one way that both statements can be true: SC4's implementation of A* isn't exactly what Amit is describing. And that's actually the case.
My little bit of logic was in the next paragraph. You are quoting me out of context.
I also explained how both statements are true but in a different way.
There go those words like "exactly one way" and "actually" again. Words that imply absolute certainty.
Unless you've seen the source code...
I disagree.The things that you have said could be exceptions, to paraphrase you "who knows what other kinds of calculations Maxis does in the executeable" , I have found relevant information about how these kinds of exceptions are valid and can be handled in A*. Although Amit may be the most read so far, he is not the only A* source I am reading.
So far nothing I've seen or that you guys have said during development of your traffic simulators proves that SC4 somehow breaks the rules of A*.
Now to read Jasons post.
Quote from: jplumbley on October 29, 2009, 06:48:06 PM
It is a theory, but to be honest I think this is how the game really deals with pathfinding, abandonment and how they two together act to effect other parts of the game. It is probably by no means a "perfect" description of how it works, but a general idea and I am sure there are other things that are not taken into consideration that take this basic theory and make it more complex under the same basic prinicpal I have just described.
I didn't quote your whole post for brevity (lol me brief? :P )
I think it is a valid theory.
It also points out an error I made above; although that error doesn't necessarily invalidate what I said.
The algorithm CAN choose an "invalid" route. The algorithm does not know what is an "invalid" route or a valid route (no route is of course a seperate condition, such as we bulldoze all the roads, which is the 1 time when the algorithm can't find a route, any route). What makes the route valid or "invalid" would take place outside of the algorithm. Possibly in another part of the game. It could be what you suggest, it could be something as simple as "throw out any path not completed during a run" which probably doesn't even require much if any extra code. If they don't save the calculated but uncompleted route from run to run. It could also be done a few other ways (not going to enumerate them all), among them the way Steve says it is done.
Once again, none of it conflicts with A* theory. What the other parts of the game engine do with decisions the traffic simulator has made still don't change the A* algorithm, which we can take as a given that the game uses. The same as we can take for a given that it is 4-path (Manhattan) and not 8 or 16.
Looking back just around here and simtropolis again, I still haven't come across Tropod. I guess just a direct search for him would be more fruitful.
Rereading Mott's theory yet again, it still seems very sound (which is the basis of Z and A) but he stops short of answering how the perfect PH of .003 was calculated (Steve pointed out this was likely said by Tropod, and I believe him, I just haven't found it yet is all).
Also Mott himself alluded to having a very strong mathematics background. I don't know about you two, but I myself have no formal education beyond trig, geometry, algebra and calculations specific to electrical and electronic engineering that might be calculus (but are probably just trig) and some other calculation specific to computers and network engineering (except for some log functions probably none of that calculus either).
Now I can still puzzle out a lot of things that are beyond my education level, and of course I can punch numbers into a calculator and punch other buttons when directed to, but it is still going to take me some time to plot out some adjusted errors to work with. Right now that is what I am interested in because I am curious to see those values and where they stand in relation to .003 but if anyone has a linky handy I would also like to see how .003 was decided upon. Otherwise depending how busy I am tomorrow ( they actually expect me to do work at work, the nerve of some people ??? ) I will hopefully find it.
I also agree, we don't need to understand the whole theory either. I am just trying to understand as much of it as I think is reasonably possible in a short period of time.
Ultimately if I go in and just start monkeying around as I have been doing; well this isn't work. If I make a bunch of bad decisions it isn't going to cause financial loss, breach of SLA, or even the kind of inter-departmental political debacles that seem to happen even when everything does go well...the worst that can happen is my computer will crash.
Quote from: ldog on October 29, 2009, 08:58:29 PM
Looking back just around here and simtropolis again, I still haven't come across Tropod. I guess just a direct search for him would be more fruitful.
Rereading Mott's theory yet again, it still seems very sound (which is the basis of Z and A) but he stops short of answering how the perfect PH of .003 was calculated (Steve pointed out this was likely said by Tropod, and I believe him, I just haven't found it yet is all).
Try this topic http://www.simtropolis.com/forum/messageview.cfm?catid=24&threadid=54310
Tropod says in it
QuotePathfinding Heuristic; 0.003000 (original value is actually 0.090000 - the lower the value, the more CPU intensive it is, but the pathfinding is more accurate)
:)
Quote from: catty on October 29, 2009, 11:28:10 PM
Try this topic http://www.simtropolis.com/forum/messageview.cfm?catid=24&threadid=54310
Tropod says in it
:)
Thanks Catty.
It looks like that puts me 1 step up and 2 steps back lol.
I still cannot find any post that says HOW .003 was determined.
Everything I read just references this as a given. Yet at some point someone in the community had to have presented how they came up with that number.
I am about ready to give up on the simtropolis forum.
Also even at one point it seems that it was Wouanagaine who introduced the pathfinding heuristic to Mott: http://sc4devotion.com/forums/index.php?topic=2665.0
So I begin to think the posts with the information I seek was lost to database troubles.
Knowing Tropod, his approach was fairly thorough.. I expect he simply lowered it until it gave consistently good results and left it at that.. For him with his equipment at the time, he probably saw no improvement in the RESULT based on lowering it further.. Perhaps you might try the same experiment with your equipment. An experiment of this nature is likely a funtion of how much detail and time one wishes to put into the experiment and how sophisticated your tools for measuring the result is.. the same problem we have today.. The test has to be in the application, not in the math.
Quote from: ldog on October 30, 2009, 09:40:56 AM
So I begin to think the posts with the information I seek was lost to database troubles.
An awful lot got lost last year when Simtropolis was hacked, have a read of this topic in the Omnibus (unfortunately the links its referring to I haven't been able to locate anywhere, but it does show the testing they were doing)
http://www.simtropolis.com/omnibus/index.cfm/Main.SimCity_4.Commute_Time_and_Pathfinding_Report
:)
Quote from: SC4BOY on October 30, 2009, 09:50:08 AM
Knowing Tropod, his approach was fairly thorough.. I expect he simply lowered it until it gave consistently good results and left it at that.. For him with his equipment at the time, he probably saw no improvement in the RESULT based on lowering it further.. Perhaps you might try the same experiment with your equipment. An experiment of this nature is likely a funtion of how much detail and time one wishes to put into the experiment and how sophisticated your tools for measuring the result is.. the same problem we have today.. The test has to be in the application, not in the math.
The thing is understanding the math can at least get us very close. So when ultimately we have to determine by experiment, we can cut down the amount of experimentation needed to obtain satisfactory results. I don't necessarily want to duplicate his (or Steve's) experiments. Especially if I can understand how such experiments were done and it is good enough for me then there is no need. I can do other experiments that assume the results of those experiments as "givens". I am not doing this just to be a pain in the ass to Steve or anyone else here in the community.
As some of the values I want to work with are not the perfect PH but instead derived from it, even if I didn't dispute that .003 was the perfect PH, I still need to know how the number was arrived at.
It is just my approach. In the end I may decide that there is no need for me to do a lot of the planned experimentation, or even to make my own traffic simulator. I may just find that Z or A or even B are the best compromise between one that does exactly what I want and what is actually attainable within the game engine. I will at least be a "well-educated consumer" . I want to give it my best effort though.
Quote from: catty on October 30, 2009, 10:48:46 AM
An awful lot got lost last year when Simtropolis was hacked, have a read of this topic in the Omnibus (unfortunately the links its referring to I haven't been able to locate anywhere, but it does show the testing they were doing)
http://www.simtropolis.com/omnibus/index.cfm/Main.SimCity_4.Commute_Time_and_Pathfinding_Report
:)
Yeah, it seems a great wealth of information was lost. Not just about the traffic sim, but the whole game.
Thanks for that link. It's definitely interesting and hey! lots of pictures, a picture is worth a thousand words as "they" say.
Even if it doesn't provide the answer, I think when I piece it together with Mott's theory I may be able to figure out the other things I am looking for (see above reply to SC4BOY)
I also have other questions even if I am not asking them at the moment, and that thread also answers some of them.
So I had some time to sit down and read that omnibus article Catty linked me.
Wow, it's old. The information in it is pre-RH even. A lot of it is what was thought at the time but proved wrong (the charts especially, related to some of my very first questions about time).
The pictures and their accompanying text however are interesting.
For anyone who is just starting out trying to understand the traffic simulator but doesn't want to spend hours pouring over A* theory (or reading all my drivel) if you want a very quick visual on exactly what the effects of having a very high inadmissible pathfinding heuristic are, go look at those pics.
The stuff on return trip routes ()what()
I ran some simple tests based on part 2 using owr. :o
None of this has changed. I didn't even realize it, and probably wouldn't have without doing this simple test because in a normal city it is much harder to observe if you aren't specifically looking for it. The owr is kinda useless. Now I see why Steve and Jason don't even consider having to equalize it for NWM to be an issue.
Wish someone would have pointed this simple fact out to me lol.
Something else occurred to me. Is it possible some of the information I can't find is because it was discussed in NAM team private forums?
For example the earliest occurrence I can find of perfect PH == .003 it is quoted as "the NAM teams value"
Is there anyone from the NAM team who was around "way back then" still active that could shed some light on this?
I know you've obviously been on the NAM team a long time Jason but I am guessing this predates even you and Mott?
Quote from: jplumbley on October 30, 2009, 08:27:51 PM
Back in the early days of Tropod, Darkmatter, Buggi, the7trumpets, etc Many discussions took place using MSN, and there is some discussions in a NAM Team thread at Simtropolis that is private. In all honesty, that thread if it still exists does not get used anymore and I have never actually seen it, just know of it's existence.
There is no known way how 0.003 was originally concieved. I would certainly quote the info for you if I could.
Yeah, I figured as much.
I will try a little more to figure it out from A* theory before I just move on, like I said to Steve, I don't consider the perfect PH as some kind of holy grail.
At some point I need to get the ball rolling.
Thanks again Jason.
I did have access to the aforementioned private thread at ST. It's in a partially archived state and is near impossible to get to now, though I've managed to save a .pdf of it. The earliest posts, however, date to March 2006, well after the "Perfect Pathfinding" simulator (Simulator E) had been developed, and there's absolutely no discussion at all of the traffic simulator.
-Alex
Ok so...I need to get started on laying out goals for my new traffic simulator. A planned project proposal and statement of work if you will.
A few posts ago I was seriously re-evaluating do I really even need to do this? Maybe I don't. Maybe some of my "hey, has anyone tried this? has anyone even thought of this? lets try this" actually has been thought about, and tried, and found to not work. So maybe one of the existing simulators while not ideal for me are the closest thing possible. I've devoted far too much time to learning the theory to not do anything with it. I've also in a way devoted far too much of Jason and Steve's time to my learning as well. So I also in some way owe it to them to at least try to do something useful with all this information. Even if all I find is that there really isn't anything new that can be done. No different ways to do things.
I also am not done learning theory to my satisfaction. Still some things to finish up, so consider this a very rough first draft.
***This is going to be very long, even for me. Also this is not some big "hooplah" about what is going to be the next latest and greatest traffic simulator. Not even close. Many of you may want to skip this. It is mostly for my own guidance, which I could just as easily put in a Word doc but I present here for anyone who may be interested.***
Now without further ado:
TRAFFIC SIMULATOR L
Why?
Why build yet another traffic simulator? Why not just use one of the existing ones?
Why not Z? I feel with its bias towards high commute and high population that it is geared for a playstyle that is not mine. What one could infer I think could make Z "better" would not make Z "better". It would make Z not Z. Z is well-suited for what it was designed to do. It is done to Steve's satisfaction and many other peoples satisfaction as well. It is done. As I am not a believer in "one-size fits all" it does not have to be for everyone. It does not have to be for me for me to still think well of it. In a nutshell even though I won't use it, if I had a friend just starting to play the game who was going to use the CAM and who wanted to build a large to scale region, and they asked me which sim do I pick? I would recommend Z.
Why not A or B? While I feel they are more suited for my playstyle, I do feel that there are some tweaks based off of Steve's research and development that could be made to them. Ok, so why not just leave it to Jason or better yet help Jason to tweak A since he has expressed continued interest? This possibility is not mutually exclusive to building my own. I can build my own and still give Jason whatever help I am able (and that he wants).
Also something that applys to all current simulators. They are all part of the NAM. As such they are bound by certain design restrictions. They must be compatible with the NAM. They must make compromises to allow some of the very creative things the other NAM team members are doing. So this brings up one of my other reasons.
To NAM or not to NAM
What are you saying Lenny, you don't like the NAM? :o Don't be silly. I do like the NAM, very much. I especially like the diagonal and orthogonal roads. The NAM adds a lot of much needed eye-candy. Some people might dispute it is eye-candy. It is all functional so how can you call it eye-candy? A lot of it is functional eye-candy. As the NAM proves, you can make it look like the road is going wherever you want it...however it doesn't change the fact that this is still Manhattan A* and we can only move in 4 directions. Now all that being said of course, don't think that I look down on eye-candy. Quite the contrary, I love eye-candy just as much as the next person. I love eye-candy so much I play with Adams very smooth slope mod, which makes me drop a string of F bombs everytime I try to lay a bridge and half the time I try to lay any other kind of network. Why do I suffer through that? Because I LOVE the way the smooth slopes look. I HATE the way the default slopes look. Does it change the way my traffic network works? Not one bit. In the end it is very much about eye-candy.
However, I do feel that because of that there are some possibilitys that might have been overlooked or that weren't overlooked but had to be abandoned for the NAM. We don't have the source code. There is only so much Maxis made accessible for us to change (and even then before other people made tools that accessibility was much less than today). We change what we can change and then after that it comes down to kludgy work arounds and tradeoffs.
Let me make one thing clear. I am not knocking anyones work. Any of you who has produced anything to share with the rest of the community deserves gratitude and respect for it, no matter how large or small the content was. You have shared with all of us at least 1 more choice for something we may want in our game and this community and others like it have kept this game alive 6 years after its release. Many of these "kludges" are the result of brilliant out of the box thinking and lots of time and effort on the creators part and I do not trivialize any of it. Still it all comes down to tradeoffs. We can't have everything. Some choices invalidate others (incompatibility). Sometimes our computer cannot handle all of the things we might like to add to the game. Sometimes there just isn't room for everything we might like in a 256x256 tile map.
That being said, my goal is not to be inNAMpatible. If I can be NAMpatible then all the better. The thing is by designing a traffic simulator completely removed from the NAM the only rules I have to follow are of the game itself. No holds barred. Once that is done then I will see what compromises I have to make to make it NAMpatible and then I have to pick and choose what is more important to me. Maybe I won't have to make any and I am making something out of nothing.
One of the initial reasons for this decision I have already pretty much invalidated already a couple posts ago.
Isn't it kind of selfish wanting to design a simulator just for yourself? Why should anyone in this community waste even a minute of their time with me?
No. It would be if I were unwilling to share it with everyone else. It would be selfish if I wanted someone else to spend a lot of time making it just for me. That is not my intention at all. I will share it with anyone who wants it. Further I will share my research with anyone who wants it.
Part of being a successful modder (successful anything really) is setting expectations.
I am setting my expectations. There are many different reasons people take up modding. To some people it is very important that their mod be appreciated and used by as many people as possible. Most people don't start out that way, but somewhere along the line for many people it starts to turn into something akin to a popularity contest, and noone likes to lose. Modding also tends to become much less fun then. When done solely for other people it becomes almost like a job. I won't bore y'all with the details but this is not the first game I've modded.
So foremost I do this for fun. Fun being relative of course, this is fun for a borderline obsessive-compulsive geek like me. Second because I see a need, no matter how small. It's a niche to fill. I am not looking to "compete" with the "big guys". Most of you are very happy with your current traffic simulator. Many of you probably think I am nuts just for being so obsessive about it. I have found over the years that not many people share the same view of fun that I do. So I am willing to fill the niche, even if I am the only one in it. Now of course being human like the rest of you, sure I would love it if other people thought I had something good and used it. There is no denying that. I just will not be disappointed when that number of other people turns out to be something like....oh...I dunno...3? Also if the only fruits of my research are to help someone else make something far better than I can, then even that is good enough for me. So no, I don't approach this with a selfish attitude. I just approach this with goals that set me up to be "successful".
Overall design objective
To achieve a fun, challenging, highly playable, realistic traffic simulator within the scale of the game. With emphasis on the single city as opposed to the region.
Design prioritys
It must not make the game less fun. Fun is the overriding principle. Challenge..well challenge is part of fun for me so maybe being redundant.
It must also not make the game less playable. So it must be "highly useable". Of course there isn't a lot of leeway in this part. A large part of the traffic simulators usefulness is transparant to the end user so....I probably need to sleep and finish this in the morning...it has to work well. Yeah, I am not making much sense at this point, least of all to myself. Time to wrap this up quickly for the night.
Realism? I enjoy a degree of realism, not at the expense of the other factors that make a game. If I loved realism so much I wouldn't be playing computer games. Still the idea of a simulator generally is to simulate something that is real. In as much as I can make it seem more realistic without making it less fun or useable (computer must run at an acceptable rate) realism should be strived for when possible.
Scale? There isn't anything we can do about city tile size. We can complain all we want that we can't build a realistic city in a 4km square, but in the end we must live with it. So we can cope in various ways. My way would be to make the 4km square seem larger.
Ok, I will finish for the night here, tomorrow to start drilling down into specifics.
Quote from: Tarkus on October 30, 2009, 09:43:47 PM
I did have access to the aforementioned private thread at ST. It's in a partially archived state and is near impossible to get to now, though I've managed to save a .pdf of it. The earliest posts, however, date to March 2006, well after the "Perfect Pathfinding" simulator (Simulator E) had been developed, and there's absolutely no discussion at all of the traffic simulator.
-Alex
Well thank you very much for looking Alex.
If nothing else at least I know I can stop searching there.
Happy Halloween!
Quote from: ldog on October 30, 2009, 11:02:07 AM
The thing is understanding the math can at least get us very close. So when ultimately we have to determine by experiment, we can cut down the amount of experimentation needed
Welp, as they used to say when I was growing up, "When all's said and done, there's a lot more said than done." I doubt the testing took more than 2 hours or so.. a binary search will zero in on a result very quickly I expect.. :) As I mentioned I expect a
quantitative tool is not readily available or even much topic of speculation; so you run it a bit, look at it.. and it's "hmmm... go or no-go?" So how do you decide? What's good enough?.. what increment +/- gives measurable difference? etc
Quote from: SC4BOY on October 30, 2009, 11:02:48 PM
Welp, as they used to say when I was growing up, "When all's said and done, there's a lot more said than done." I doubt the testing took more than 2 hours or so.. a binary search will zero in on a result very quickly I expect.. :) As I mentioned I expect a quantitative tool is not readily available or even much topic of speculation; so you run it a bit, look at it.. and it's "hmmm... go or no-go?" So how do you decide? What's good enough?.. what increment +/- gives measurable difference? etc
I don't really understand what you are trying to say. Of course I just rolled out of bed and coffee is still brewing.
*some time later*
Ok, so you saying you are a man of action. Too much talking going on here for you :P
I enjoy theory just as much (maybe more) as application. As far as discussion though, theory is where we say a lot more than do. Application doesn't involve a lot of saying, it is really just about doing, but it is at the point where there isn't so much left to talk about.
2 hours, true/false find the answer very quick...No, absolutely not. Using that method we can find values that work well in the game and we can find values that work poorly in the game but we cannot determine the perfect pathfinding heuristic in that manner. It isn't a "feel good" value, it is a strictly defined value.
As far as what's good enough. For purposes of above discussion nothing I am going to find apparantly. The source code which we will never see.
For practical purposes? Like I said, I don't have to know. My OCD decided it was interesting for its own sake. I have done my due dilligence in trying to find out how others came to the conclusion and now I move on.
Or in other words;
One does not need to use the perfect pathfinding heuristic; one simply needs to use a pathfinding heuristic that works
Ok, so picking up where I left off last night.
???
As it became clear even to me, I wasn't making much sense by the end.
A little more about what I mean by "scale".
To paraphrase Mott "even though the map scale is 16m per tile, the rest of the games engines are still using SC3K scale" I am still trying to understand all the implications of that statement, because there are many. One of the scales is population density.
I am cite an old post made by David Edgren, who no doubt is familiar to everyone here.
http://www.simtropolis.com/forum/messageview.cfm?catid=36&threadid=74819&STARTPAGE=33&FTVAR_FORUMVIEWTMP=Linear#941626
Scroll down past all the pretty pictures to the charts. This was all very interesting to me.
The numbers may be right or wrong, but this was all part of the design theory that led to the 3RR as we know it.
I don't know the game well enough to know if these are realistic figures for vanilla or not. I suspect many of you, even those who have been around a long time really don't know anymore either. The CAM, tons of downloaded buildings that have widely varying capacities, job mods, etc. The figures become very skewed.
Part of my play and design philosophy very closely follows Davids early on. At some point though, David realized that he had to scale out the region to much larger proportions to achieve what he wanted with it. Now I don't know about the rest of you but considering that the 3RR is such a huge project that it has its own section here I think everyone would agree it was a huge success. As I said early on, I personally think it is one of the most beautiful maps I have ever seen (one that my experiments with a 1/4 reduction does not do justice to).
Now the scaling out is also a turning point in philosophy. Obviously I am not questioning Davids decisions. I also am not looking to strictly adhere to and mimic what other people have done. This is not done for the sake of a "3RR what if" In the end I just take what I like and go with it. For myself, for my own play, scaling out the region is not a viable option. It is just too large for my personal preferences, so instead I must look in a different direction. If I am unwilling to scale the map out, then I must scale the game down. I don't need the CAM I need...the TAM! The Tiny addon mod. There is no such mod though.
That also brings up another major mod point. Your play strategy is going to vary greatly if you have the CAM installed or not. Now other than the fact that I don't want to make the population denser or the buildings larger, there are a great many other things I like about the CAM. Ripplejet is a prime example of one of the many great innovators in this community. As mentioned earlier I have remade pieces of the CAM for my own use, and since that discussion with Jason about it also installed some pieces of it as is. I won't ever be putting in the large buildings though.
So one of the fundamental design decisions for me is that the traffic simulator can completely break at a population density that can't be achieved under the conditions for which it is intended. I expect it to work as designed, with populations from 100 to...we are going to take David's figure of 400k for now. I really need to go and decide what that number should be. To me a great map is about half "waste"...water and mountain. So that affects my figures. Also I should still allow for the possibility that it should function as designed even when stressed to the limit (we have a large tile with no unbuildable terrain).
This of course does not discount intercity commuters by any means either. As I said I don't want a bias for commuters from all over the region. I am not all that impressed with the regional play. That being said I am not trying to eliminate it. So our networks must be able to handle a "reasonable" amount of inter-city commuters as well. Reasonable of course by my own definition. I admit I have not figured that out yet either.
Now sure you should be able to exceed these limits, and it may work, but I would expect you to have to have an unsustainable network. So if some masochist wanted to use it with the CAM they would have a treasury that would bleed money.
I am going to transition from scale into realism a bit now.
One of the other things about the scale of the city map vs the scale of the rest of the game engines and how that stacks up against realism, is that as many others have shown (again I will refer the reader to the original 3RR CJ at Simtropolis, starting around page 31...I am sorry I don't have the patience right now to wait for Simtropolis database so not gonna link)
David through overlaying some real world maps onto game maps shows us one of the fundamental flaws in the scale that don't allow us to achieve reality. We build transit systems that are far "larger than life" in the game, because we have to. Also even though in general the 4k large map is still too small to realisticly have all kinds of highways crisscrossing it and every form of MT; what fun would it be if we didn't have a need for it. So because of design flaws in the game our map has been shot to hell. We of course again have to make tradeoffs between reality, fun and what the game engine is capable of.
Now one of my little issues with reality and MT. To anyone who has rode MT in NYC, a few things are clear about overcapacity. Some people say how can you operate the road, rail, etc at over 100% capacity anyway? I will not bore y'all with a dissertation on the general real world applications of capacity and overcapacity. So strictly speaking about MT...to the average NYer, most of the buses, subways and indeed the LIRR are packed well over design capacity during rushhour. Indeed we have often been packed into cars like sardines standing on each others toes. God forbid someone farts! This is overcapacity as it relates to MT.
Yet it does not cause congestion on the network to any appreciable degree (well...leave the buses out for the moment). Sure the trains may run off schedule a bit (mmmk, yah, like they ever run on time anyway :P). The higher volume of people getting on and off means the train stays in the station a bit longer as we override the doors. The amount of trains we run also varies by time of day. We put more trains at shorter intervals during rushhour, but theoreticly (there is an engineer out there reading this no doubt who is going to tell me how wrong I am, I can feel it) it doesn't add to network congestion in the SC4 way. It would if we added too many trains, so therefore we would have to slow them all down, but I have not observed this as a passenger. When the train is actually moving as best I can ascertain it still goes the same speed it goes at rush hour or at 3AM. Now forgetting all the more complicated things, because we know the traffic simulator is far too simple an engine to handle things like schedules, extra trains, long stops. These extra things also wouldn't really add more fun to the game if they were exposed to us, just more work. Also the traffic engine basicly ONLY runs at rush hour. It simulates a commute to work (in fact as we've found it doesn't really even simulate a commute back home, it cheats!)
So one of the things I want to try that I haven't seen done is making the MT (non bus) run at a consistent speed throughout. I think I can scale back capacitys and still achieve game balance. So that el may be at 400% capacity, but it is still going to run at the same speed. So it doesn't need as high a capacity as the roads do to be in balance. Of course now I am have to adjust other parts of the system to compensate for these changes, so we still get the right balance of cars vs buses vs mt. For the people who would just say "well fine, go turn off affected by traffic and try it" it isn't just that simple. I am not going to get valid results with just that simple change. I've learned that much so far. For the people (probably Steve :D ) that would say "it is an awful lot of work to go through for something that in the end probably will make no noticeable difference"...you are probably right lol. I want to try anyway. Who knows what I will find. Maybe I will find it does not work but it will give us all some new insight into MT.
I have more ideas of course but I think I have gone on enough for one day.
Quote from: jplumbley on October 31, 2009, 12:46:14 PM
Actually... You are right the Simulator runs a route once, but it does the whole round-trip not only the "to work" portion. This is why the Max Commute Time pertains to the whole round-trip. A proof of this would be if you used an avenue or a OWR. The Sim will travel from work in the morning using the right side of the Avenue, but on the return trip home he will then use the left side of the avenue to return (a completely different tile and therefore route).
In other situations, I have had some really strange trips in some of my commute testing in the past... One that comes to mind I thought was actually really interesting. I had a highway, overloaded it as much as I could and when I did, I added a train line. The trains at either end allowed for car to train and train to car transit switches. One thing I observed was Sims travelling to work using the highway, but then using the trains on the way home going from work to the train station by car, then using the train (I guess driving onto it like you can on the TGV between London and Paris), then leaving the second train station in their cars back home. That was the first time I ever noticed such an event in commuting. And it wasn't just one Sim doing it it was a lot of them.
Ok, so now I am confused again. That experiment on the omnibus showed that the route is only calculated to, then we just take that time and double it, to simulate the trip back home. There has to be a valid route back home (the highway only allowed us to get to work, we had to go another way home) but it still doubled the highway time. You could make some crazy ass route with streets for the return trip and it didn't effect the commute time. Meaning the engine assumed it was going to take exactly the same amount of time to get home as it took to get to work, regardless of the actual route.
As I said in my reply to Catty, being as this was all pre-RH I thought surely they must have changed this. I ran that little test myself. I even used owr for part of it. My little test got the same results as the original test. If you query a building of course it doesn't show the roundtrip. It only shows the morning. From playing I somehow was under the impression that depending which volume view (morning or evening) you had selected it would show the routes either way from the building query, but in the little city of 10 people it clearly didn't. So that's what I meant when I said the engine cheats.
Are you saying ignore all that and just go off the volume graphs?
Quote from: jplumbley on October 31, 2009, 12:46:14 PM
The only thing I have to say about this, I'd have to go back a look at the Simulator file again, but the problem I am questioning is, if the Traffic type is unaffected by traffic then how is the game limiting the capacity? The CvS curve is essentially the thing that limits Capacity on a network by diminishing the Speed on a give route and eventually when it reaches the 30% Speed threshold, prevents any other Sims from travelling that route. This is why Buses are a "cheat" because they ignore capacity completely.
I thought somewhere around 400% capacity no matter what other factors the network gets saturated? That was one of my assumptions.
The other thing though is since the train (I'm going to just say train when I mean: rail, sub/el, mono) networks are the fastest, they are already priviliged by the pathfinder. So we can use the other methods to take some of that away and still have them run as desired. I think...I am still trying to work out the details of course ;)
So if that key assumption above is wrong, I think it may still be possible to achieve the desired effect. Of course it might not matter either way, might just result in everyone and their mother riding the train. Or no one at all riding the train.
The other reason I feel we have some "play" in achieving this again comes down to gameplay style. MT is expensive. In general a city doesn't add a MT system just because they want one. They often don't add one when they need it. It often has to wait until they REALLY need it. Of course by the time they get it, it is generally inadequate because they need more. And so it gets expanded. But once again the expansion doesn't keep up with the growth. And so we either wind up with an inadequate system that takes some pressure off the network or we (in rare cases) wind up with a system that works almost perfect but then costs a tremendous amount to maintain. I know this is still a somewhat simplistic view (some professional city planner is laughing his ass off right now).
The bus is a bit different isn't it? It doesn't add to congestion but it is still effected by it.
Oh...yah...I see what you are saying. You can add all the buses you want to an already overpacked road.
The thing is the bus is still going to be slowed down by the congestion so it will also become a less desireable route.
Well, like I said, we can only attain so much realism before either A: it is no longer fun or B: things break horribly
I have some ideas about that as well. I think there is some range where the bus preference can be tuned to "keep it real homie". Somewhere in some combination of the bus speed, travel strategy and starting trip cost. Again it is more theory than anything at this point.
The car is the slowest form of transport. It is least favored (well, besides walking) by the pathfinding engine. Especially once congestion starts taking hold. So the things we have to do to encourage more realistic car use are actually pretty heavy handed when you think about it. I think that creates the leeway to screw around with the MT more.
Quote from: ldog on October 31, 2009, 01:42:16 PM
As I said in my reply to Catty, being as this was all pre-RH I thought surely they must have changed this. I ran that little test myself. I even used owr for part of it. My little test got the same results as the original test. If you query a building of course it doesn't show the roundtrip. It only shows the morning. From playing I somehow was under the impression that depending which volume view (morning or evening) you had selected it would show the routes either way from the building query, but in the little city of 10 people it clearly didn't. So that's what I meant when I said the engine cheats.
The game it turns out generates a query.txt file in the Program files/Maxis every time you query something, this contains a lot more information than the "query", I've found it very useful information to have, especially when testing "$Deal"$
for details on how it works see the query.txt topic here
http://sc4devotion.com/forums/index.php?topic=8870.0
:)
Quote from: catty on October 31, 2009, 02:09:16 PM
The game it turns out generates a query.txt file in the Program files/Maxis every time you query something, this contains a lot more information than the "query", I've found it very useful information to have, especially when testing "$Deal"$
for details on how it works see the query.txt topic here
http://sc4devotion.com/forums/index.php?topic=8870.0
:)
???
()what()
Wow thanks again Catty. :thumbsup:
Quote from: ldog on October 31, 2009, 01:42:16 PM
If you query a building of course it doesn't show the roundtrip. It only shows the morning. From playing I somehow was under the impression that depending which volume view (morning or evening) you had selected it would show the routes either way from the building query, but in the little city of 10 people it clearly didn't. So that's what I meant when I said the engine cheats.
Actually, it just acts in a confusing manner. You're right in that the query tool doesn't always show the same commute period as the volume view. But you can see the evening commute; there's a little pair of radio buttons at the bottom of the query tool legend in the upper right of your screen that lets you select the commute period.
The fact that the volume view and the query tool can be out of synch is definitely a poor design. But you can still get the evening commute data.
Quote from: z on October 31, 2009, 05:01:50 PM
Actually, it just acts in a confusing manner. You're right in that the query tool doesn't always show the same commute period as the volume view. But you can see the evening commute; there's a little pair of radio buttons at the bottom of the query tool legend in the upper right of your screen that lets you select the commute period.
The fact that the volume view and the query tool can be out of synch is definitely a poor design. But you can still get the evening commute data.
Uhhhhhhh...ok...so lemme see if I get this straight.
So basicly between what you and Jason are saying. Plus what I've usually observed in game which also contradicts that other test (even though it was done in game as well).
The volume view is the only way to see the evening commute.
The volume view because I only had like 10 residents in that very limited test just wasn't enough to show me anything. Odd though that I could see the freight trucks from just a 2x2 ind-d.
Even still can't ever really trust anything the game shows because all the graphs and views besides being generally inaccurate are also buggy ???
It's these little things that are generally irrelevant when playing that make modding such a joy sometimes ::)
Things that you thought you saw when you were playing you realize you didn't really see when you are testing.
The wife wants me to watch a movie with her so it'll have to wait until later.
Quote from: ldog on October 31, 2009, 06:10:23 PM
The volume view is the only way to see the evening commute.
No; when using the Route Query Tool, clicking the Evening Commute button under its legend will show you its data for the evening commute, which of course is a different type of data from the volume view's.
QuoteEven still can't ever really trust anything the game shows because all the graphs and views besides being generally inaccurate are also buggy ???
I have found the volume data view info and the route query tool info to be quite reliable. The congestion data view is fairly reliable, but not completely.
[I haven't read everything as it was posted, so I'm just getting to some of this.]
Quote from: jplumbley on October 31, 2009, 12:46:14 PM
The CvS curve is essentially the thing that limits Capacity on a network by diminishing the Speed on a give route and eventually when it reaches the 30% Speed threshold, prevents any other Sims from travelling that route.
What was actually found by experiment was that 30% was the lowest speed that could be used in the CvS curve without triggering the congestion display bug. However, it does not prevent any other Sims from travelling that route; the lower speed just makes other routes more attractive to the pathfinder, and the extent of this is determined by the pathfinding heuristic. If you run Simulator Z Classic in a large city, you can see that routes can be made to carry arbitrarily high amounts of traffic, even after they reach the 30% speed threshold.
Quote from: z on October 31, 2009, 07:01:32 PM
No; when using the Route Query Tool, clicking the Evening Commute button under its legend will show you its data for the evening commute, which of course is a different type of data from the volume view's.
I have found the volume data view info and the route query tool info to be quite reliable. The congestion data view is fairly reliable, but not completely.
The evening commute butto... *looks up in right corner* ... :'( ... ... ... :angrymore: ... &hlp
:angrymore: :angrymore: :angrymore: ... :angrymore:
I knew about this. I did really. I've used it in game. This is of course why I thought I recalled being able to see both directions.
I don't know how I forgot this. Ok, so they did change some things.
The commute time being the same? Display bug then or it is just doubling the morning trip instead of adding the actual morning and evening trip?
I did just go back in and verify with roads and a highway by placing and bulldozing the highway ramps at different times to force different routes during each period.
I can confirm that the commute time is based off the morning. Whatever change I make to the evening route makes no time difference. It doesn't matter if it is slower or faster.
I'm sorry if this is something one of you went over as well, the first time I noticed this was in that Omnibus article Catty linked.
I obviously need to slow myself down because now it isn't even about not knowing things, it is about being stuck on stupid.
Quote from: z on October 31, 2009, 07:01:32 PM
[I haven't read everything as it was posted, so I'm just getting to some of this.]
What was actually found by experiment was that 30% was the lowest speed that could be used in the CvS curve without triggering the congestion display bug. However, it does not prevent any other Sims from travelling that route; the lower speed just makes other routes more attractive to the pathfinder, and the extent of this is determined by the pathfinding heuristic. If you run Simulator Z Classic in a large city, you can see that routes can be made to carry arbitrarily high amounts of traffic, even after they reach the 30% speed threshold.
So there isn't any hard cap then. Hrmmm. &Thk/( So maybe there is some tuning that will make my MT idea work, but not as much wiggle room as I had initially hoped.
I would have to arbitrarily make the car more attractive, without it killing MT use altogether. And then they are just gonna prefer whichever MT method is closest and fastest. Come to think of it what was wrong with Monorail in vanilla again? &Thk/( This probably isn't going to work.
Quote from: jplumbley on October 31, 2009, 12:46:14 PM
In other situations, I have had some really strange trips in some of my commute testing in the past... One that comes to mind I thought was actually really interesting. I had a highway, overloaded it as much as I could and when I did, I added a train line. The trains at either end allowed for car to train and train to car transit switches. One thing I observed was Sims travelling to work using the highway, but then using the trains on the way home going from work to the train station by car, then using the train (I guess driving onto it like you can on the TGV between London and Paris), then leaving the second train station in their cars back home. That was the first time I ever noticed such an event in commuting. And it wasn't just one Sim doing it it was a lot of them.
You know I had to read this a second time to catch this for some reason.
That is pretty incredible. I didn't think the game engine allowed it.
Cool.
Quote from: ldog on October 31, 2009, 09:55:47 PM
The evening commute butto... *looks up in right corner* ... :'( ... ... ... :angrymore: ... &hlp
:angrymore: :angrymore: :angrymore: ... :angrymore:
I knew about this. I did really. I've used it in game. This is of course why I thought I recalled being able to see both directions.
Don't feel too bad about this. I did the exact same thing. It's basically a poorly designed interface.
QuoteThe commute time being the same? Display bug then or it is just doubling the morning trip instead of adding the actual morning and evening trip?
I'm not quite sure what you're referring to, but the route query tool will often give the same numbers for morning and evening commute, simply because they often are the same. (That confused me for a while.) But they are often different too.
Quote
I did just go back in and verify with roads and a highway by placing and bulldozing the highway ramps at different times to force different routes during each period.
I can confirm that the commute time is based off the morning. Whatever change I make to the evening route makes no time difference. It doesn't matter if it is slower or faster.
Again, I'm not completely sure of your reference, but the game is designed to calculate commute times only for the morning commute. For the evening commute, all that is necessary is that there be some valid route from the Sim's job to his or her home; the length of the route is irrelevant.
And now to answer a question of Jason's:
QuoteThe only thing I have to say about this, I'd have to go back a look at the Simulator file again, but the problem I am questioning is, if the Traffic type is unaffected by traffic then how is the game limiting the capacity?
It doesn't. Travel types that are unaffected by traffic effectively have unlimited capacity; their nominal network capacity is meaningless.
And going back through to the previous post...
QuoteFor the people (probably Steve :D) that would say "it is an awful lot of work to go through for something that in the end probably will make no noticeable difference"...you are probably right lol.
Oh, I would never say that! $%Grinno$% In fact, I went through much the same line of reasoning as you did when I came up with the final rail capacity numbers for Simulator Z, as discussed in
this post (http://sc4devotion.com/forums/index.php?topic=5382.msg204681#msg204681):
QuoteBut what about the rail numbers?... Look at what the nature of congestion is for car traffic versus something like subway traffic. With car traffic at rush hour, the more cars you put on the road, the slower everybody goes. This is reflected in the Congestion vs. Speed curve. Yet for subways, the more people you have traveling by subway, the more crowded the subway cars get. But they don't go any slower. If you have huge crowds of people waiting for a subway train, it may take a few seconds longer to get on and off at stops. But while the subway train is traveling, which it spends most of its time doing, it always travels at the same speed, regardless of the time of day, which is totally unlike cars. So the effect of traffic volume on speed is quite different with rails than with road traffic. This is reflected in the relative capacities of the two types of transportation. For example, the new Second Avenue Subway in New York City is designed for a daily capacity of 600,000 people. Meanwhile, directly above the subway line is Second Avenue itself, a four lane, one way avenue. According to the quote above [in the original thread], this avenue will carry about 1000 cars/lane/hour, or 4000 cars per hour. But in rush hour, it's going to carry a lot less, as traffic barely creeps along in Manhattan during rush hour. So the subways (as well as the other rails) can carry vastly more traffic than the roads, especially during rush hour... And if anything, my rail numbers should be even higher than they are to be realistic. But once again, realism has to be balanced with what works for SC4, which means that these numbers should be low enough to give some challenge.
In fact, in rush hour, it may take more than a few seconds longer for people to get on and off trains. Trains spend more time in the station; the average train speed is reduced. With really bad congestion, trains are sometimes so packed that you can't get on the current one and have to wait for the next, again increasing commute time.
So there is a form of congestion affecting rails that reduces speed; it's simply far less than that for cars or buses. I took this into account by increasing the ratio of rail capacities to that of other network capacities.
Quote from: z on November 01, 2009, 03:05:55 AM
Again, I'm not completely sure of your reference, but the game is designed to calculate commute times only for the morning commute. For the evening commute, all that is necessary is that there be some valid route from the Sim's job to his or her home; the length of the route is irrelevant.
I was saying I had just verified this myself ;)
This was new information to me, somehow it had not managed to come up in our discussion.
So taking above discussion into consideration.
It is highly doubtful my original course of action for MT would provide the desired effect.
Looking at another approach, let me put the congestion back on the trains, and then do what Steve has done and make the capacity higher.
Ok, so how do I keep the overall use still within a lower limit than the figure we have to use for capacity?
Stations? I know y'all have said they are buggy as hell, but still the station does at some point have an absolute capacity.
So if I stuck with lower station capacity then I should be able to get the same effect?
Or is that where the bugs come in. Does the pathfinder not know that the station can't accept anymore people and just keep trying to route through it anyway?
That is something I think I can verify with testing at this point so off to play I go.
Quote from: ldog on November 01, 2009, 07:22:44 AM
Or is that where the bugs come in. Does the pathfinder not know that the station can't accept anymore people and just keep trying to route through it anyway?
That is something I think I can verify with testing at this point so off to play I go.
Look forward to your test results, this is something that came up in RTMT testing and it will be interesting to see if you get the same/similar results to us or even more interesting something completely different :)
quote from Z
QuoteAs I mentioned earlier, it appears that all stations have a fixed limit that is a multiple of their capacity; this multiple has been observed to be as low as four, but has also been observed to be higher than that. In this case, it appears to be a little over six - the first time I've seen it as a nonintegral value. But it means that once approximately 68,000 Sims have passed through the station, it will accept no more for the rest of the day.
Cathy
Hello Idog, :)
Just wanted to introduce myself..
My name is Brian, and I have done a lot of testing for Steve with past versions
of Sim Z.. Ive followed this from where it started back in the sim Z development thread.
and now with the creation of this new thread here.. You have certainly generated a lot of
interesting discussion here which can only benefit those interested and who chose to read this..
I just wanted to offer my encouragement to you in what you are undertaking here...
You certainly have 2 of the best teachers the game has ever seen in the area of traffic
research in Jason and Steve...
thanks, Brian
Quote from: catty on November 01, 2009, 08:40:59 AM
Look forward to your test results, this is something that came up in RTMT testing and it will be interesting to see if you get the same/similar results to us or even more interesting something completely different :)
quote from Z
Cathy
*pokes his head out of the game*
It might be a few days lol. Been building all day. Haven't even taken it off of pause yet. And still not even half done building.
It would probably help if I didn't start building a city from scratch every time I redefine the test parameters but I don't trust my data when I switch engines midstream, because of little things like we saw earlier in the discussion. As I get better at this I hopefully won't feel the need to do this every time.
Thanks for that bit of info about the stations. I seem to remember reading that, but as I think if I have proven anything so far it is how absent-minded I am.
I really appreciate all the help you've given me. :)
Hello Brian, thanks for the words of encouragement. Nice to meet ya :)
Evenin' Jason ;)
What did I come out here for again? Oh yeah, rock texture replacement.
*back into game* $%#Ninj2
So to clear up some of what was posted around when I got all flustered since I realized I was an idiot and forgot where the morning/evening commute button was...
In regards to one of the links Cathy provided: http://www.simtropolis.com/omnibus/index.cfm/Main.SimCity_4.Commute_Time_and_Pathfinding_Report
I went ahead and reran that test. I don't know if this is all well known stuff or not, it is very relevant for someone just starting into the traffic simulator.
I'm sure Steve and Jason understand this well but I still wasn't clear what I was trying to say above. Sorry no pictures (posting from work), but I will refer to the pictures in the Omnibus.
Even though this was pre-RH it intrigued me.
So looking at section 2, figures b & c we can see that our total commute time =(morning commute x 2). It does not matter if our route home is shorter, longer or the exact same length. The game is going to assume as long as we have a valid route home (see figure d) that it only takes the exact same amount of time to get home as it took to get to work. Now never having played pre-RH I don't know but I believe there was no route query tool correct? So we could only guess what routes sims were taking but we couldn't actually see like we can now.
So I ran the same series of tests myself. Posted. Realized I am an idiot (I get that astonishing revelation a lot, and yet it never ceases to amaze me %wrd ). Ran the tests again.
We all know the commute time graph is buggy. Steve and Jason know it very well. I admit I am still trying to figure out some of the finer points of just how buggy it is.
So as much as we can trust what the commute graph tells us, I also verified that changing the evening route does not affect the commute time.
Taking the highway both ways, I had X minutes (we know the number is wrong but I am going by the position of the line on the graph). Demolishing the ramps allowing us to take the highway home and forcing using roads, streets, etc. The commute time was still X minutes. Forcing traffic to go the other way, rebuilding those ramps and demoing the ramps that led to work, resulted in the commute time going up to Y minutes. I played around with it in various other ways and still the results were the same, only changes to the morning commute route made any difference in the total commute. Using the route query tool (once Steve reminded me where the mode button was ::) almost done beating myself up for this I promise) I was able to verify that they indeed do take the evening trip on the other road, but it doesn't seem that the time is ever calculated for that route. The pathfinder assumes it is just going to take the same amount of time it took you to get out in the morning.
Now I don't know if this is just one of the afore-mentioned commute graph display bugs or if it is the way the game actually does figure out how long it took. I am assuming Jason and Steve are well aware of this based on above discussions but I just want to make sure I've got it straight now. My questions in above posts and therefore the answers given were not so directly to the point.
Mini-update on testing.
I of course got bored and had to let the game run a bit last night.
Still nowhere near done filling the tile out.
I let it run about 2 years. Population reached 15k. I've got a good mix of highway with avenues and roads feeding in, streets on the blocks and some heavy rail. Nothing else at the moment.
No congestion of course as the network is designed for a much larger city than we have grown to. I am seeing a lot of no job zots though which I thought was odd.
Commute time shows around 40 minutes, which I thought was odd too. I don't have out of towners so I thought the numbers were supposed to be somewhat accurate still.
I used a multiplier of 1 so I thought I should get 1 to 1 for my commute time units. Obviously this is not the case since my max commute is 24. Also as there is no congestion whatsoever and we are cruising at network speed x 1.3 I don't see why the commute time would be long.
Now the internal documentation doesn't make a lot of sense on it. I can't remember it offhand well enough to quote it. As is common, it is an 8-bit register, and that is why we see that number we see so often in the computer world mentioned, 255 (count 0 as a number and we get 256). At first I thought what was meant was that it would go up to 255 minutes. So one could divide 255 by their max commute time and use that number as a multiplier. That doesn't seem to work. I thought let me just take it as the raw number and leave it at 1. That doesn't seem to work either.
Hi Lenny :)...
Just finished reading your last post here and this is great work and testing you have done here..
and I had no idea about the finding you have found about commute times.. Obviously we can wait for replies
from either Steve or jason to verify one way or the other whether as you said ..if this is yet another bug having
to do with the "commute time graph". or if you feel bored while your waiting, I have idea you can try or I may
even try it.. if I get tired of waiting for one of their replies :-\
Ok here is my idea...
Im sure you are aware that a regular Query on any occupied building will quantify how long commutes are..
So the 3 categories are short , medium and long, and i suppose if you want to call abandonment caused by
commute time , the 4 th category thats fine.. Anyways what you can do is first verify a shorter route with a
typical out and back commute to and from work using the same routing .. ( i would chose a route that is
relatively longer which would be close to falling into the medium commute category..).. than in the way you
were doing in your testing I would than force a different return route.. My idea here is to force a super long
return route.. And than you would than check with a query to see if this changes the route description to
either medium or long .. I think meanwhile since i have some very large cities to look at with some quite complex
routes .. i know many of them have different and longer return trips from work because I recall seeing them..
Ill simply check some of them and see how the length of trip is quantified.. ( short, medium or long..) ?
Obviously the drawback to this would be if the regular query is bugged in terms of quantifying the length of
commutes..
If we dont either from either jason or Steve for awhile, perhaps ill post again :),
Thanks brian
Quote from: ldog on November 02, 2009, 12:50:51 PM
I used a multiplier of 1 so I thought I should get 1 to 1 for my commute time units.
If you by that mean the property
Trip Length to Minutes Display Multiplier,
then I believe several tests have shown that it isn't used at all.
Whatever value you give it, the multiplier stays at 25.
Quote from: ldog on November 02, 2009, 12:50:51 PM
Commute time shows around 40 minutes, which I thought was odd too. I don't have out of towners so I thought the numbers were supposed to be somewhat accurate still.
I used a multiplier of 1 so I thought I should get 1 to 1 for my commute time units. Obviously this is not the case since my max commute is 24. Also as there is no congestion whatsoever and we are cruising at network speed x 1.3 I don't see why the commute time would be long.
Now the internal documentation doesn't make a lot of sense on it. I can't remember it offhand well enough to quote it. As is common, it is an 8-bit register, and that is why we see that number we see so often in the computer world mentioned, 255 (count 0 as a number and we get 256). At first I thought what was meant was that it would go up to 255 minutes. So one could divide 255 by their max commute time and use that number as a multiplier. That doesn't seem to work. I thought let me just take it as the raw number and leave it at 1. That doesn't seem to work either.
Based on the documentation you're quoting, it appears that you're making the mistake that RippleJet points out. The game never looks at that property in the simulator. I already pointed you to the explanation of the commute time graph which is in
this post (http://sc4devotion.com/forums/index.php?topic=5382.msg189449#msg189449); it sounds like you read part of it, but you may want to reread it. The commute time graph can be made perfectly accurate for a region containing a single city, but you've got to figure out by experiment what the proper scaling factor is, which must be done by experiment for your particular traffic simulator. There may be a formula for determining the scaling factor, but I've never seen it. To quote Tropod:
QuoteAbout the Commute Graph; ignore it. It serves no real purpose really, especially more so if you have neighbour connections. The fact that there might be such a low Commute according to the Commute Graph, is pointless really, as it is by no means accurate nor indicative of the actual Commute Times undertaken by individual Sims. All it is, is a city average.
Quote from: RippleJet on November 02, 2009, 01:06:02 PM
If you by that mean the property Trip Length to Minutes Display Multiplier,
then I believe several tests have shown that it isn't used at all.
Whatever value you give it, the multiplier stays at 25.
Quote from: z on November 02, 2009, 01:55:57 PM
Based on the documentation you're quoting, it appears that you're making the mistake that RippleJet points out. The game never looks at that property in the simulator. I already pointed you to the explanation of the commute time graph which is in this post (http://sc4devotion.com/forums/index.php?topic=5382.msg189449#msg189449); it sounds like you read part of it, but you may want to reread it. The commute time graph can be made perfectly accurate for a region containing a single city, but you've got to figure out by experiment what the proper scaling factor is, which must be done by experiment for your particular traffic simulator. There may be a formula for determining the scaling factor, but I've never seen it. To quote Tropod:
That would answer that part. I am sure I do need to reread that. I think I understand better now, that is what the seperate traffic exemplar I asked you about the other day is for correct?
I was starting to catch on since you and Jason both left it at 25.
The thing is I thought I also read that even though we cannot trust the numbers that the shape of the graph was still somewhat accurate, at least until we get intercity commuters.
Or like I was saying in the other reply, the relative values should still have some kind of accuracy? At least in relation to each other.
eg. the commute time, whatever it is, goes up..we can trust it that traffic is getting worse...we throw down a highway and now the commute time goes down, because we just provided a faster route.
Are you saying we can't even trust it when it indicates the above?
What Brian was refering to is my prior post right before the one Ripplejet is answering.
I guess I shouldn't make posts right after each other, I was trying to keep unrelated information in a seperate reply.
First one was a seperate test, second one is first impressions to the bigger test I just started.
Quote from: ldog on November 02, 2009, 02:14:18 PM
What Brian was refering to is my prior post right before the one Ripplejet is answering.
I guess I shouldn't make posts right after each other, I was trying to keep unrelated information in a seperate reply.
First one was a seperate test, second one is first impressions to the bigger test I just started.
Naw you did fine IDog-- it was my fault really for being lazy and not putting the relevant quote I was replying
to in my posting.. i do appreciate both tage and steve's replies of course.. But I was hoping to get a reply back
from Steve , concerning the experiments you and I are running as to whether or not the commute times are
calculated only based on the morning commutes rather than some kinda average of both the morning and evening
commutes.. In the latter event it would have to be than the "buggy" commute time graph which they are referring to in the above posts, which would be calling the confusion on this..
OK, now as long as you trust these regular queries which show the
(quantitative commute lengths.. the short, medium, and long commute trips) early indications just from checking through some of the commutes in my largest city do seem to indicate that the traffic sim does in fact
calculate the commute trip lengths based on the morning commutes only.. Although i didnt find enough to test
to be absolutely sure of this.. More precise testing is needed unless Steve already know the answer to this ?
Thanks, brian
Quote from: ldog on November 02, 2009, 02:14:18 PM
I think I understand better now, that is what the seperate traffic exemplar I asked you about the other day is for correct?
Yes.
QuoteThe thing is I thought I also read that even though we cannot trust the numbers that the shape of the graph was still somewhat accurate, at least until we get intercity commuters.
Yes, as a citywide average.
QuoteOr like I was saying in the other reply, the relative values should still have some kind of accuracy? At least in relation to each other.
eg. the commute time, whatever it is, goes up..we can trust it that traffic is getting worse...we throw down a highway and now the commute time goes down, because we just provided a faster route.
Are you saying we can't even trust it when it indicates the above?
With only a single city in a region, what you say is generally true. But at one point, Tropod says that adding mass transit tends to make commute times go up. He doesn't elaborate, but I have always found his analyses to be extremely accurate. If this is indeed the case, then it certainly does cast even more doubt on the usefulness of this graph - which is what Tropod said in my previous quote.
QuoteI guess I shouldn't make posts right after each other, I was trying to keep unrelated information in a seperate reply.
In general, double posting is heavily discouraged on this site. I think there's a rule regarding it, but I can't find it right now. Double posting is defined as two adjacent posts in the same thread on the same day. Instead, people are encouraged to simply edit their first post. I think it's even acceptable to repost it, if you want people to see your new addition. The fact that I can't find this rule certainly shows that such a rule is easy to miss, but now you know.
Quote from: z on November 02, 2009, 03:06:34 PM
In general, double posting is heavily discouraged on this site. I think there's a rule regarding it, but I can't find it right now. Double posting is defined as two adjacent posts in the same thread on the same day. Instead, people are encouraged to simply edit their first post. I think it's even acceptable to repost it, if you want people to see your new addition. The fact that I can't find this rule certainly shows that such a rule is easy to miss, but now you know.
Actually, there is no such specific rule... $%Grinno$% ...just this general one:
Quote from: jeronij on November 05, 2006, 06:02:56 AM
SC4D does not allow inappropriate member conduct on the forums. This includes, but is not limited to: posting spam, posting hostile comments, "flaming" of any sort, posting simply to increase post count, and so on.
As long as "enough" time has elapsed from the previous post, and considering whether the content in the new post provides new (as opposed to additional or supplementary) information, I'd say that Lenny's double posts in general have been according to the rules (otherwise I would have intervened by now). Maybe the "mini-update" earlier today could have been added to the previous post though...
Also, considering the lengths of some of the posts that Lenny (and Jason and particularly Steve) have made, it sometimes would even be better to break them up into shorter posts, which would be easier to grasp, one subject at a time... ::)
Quote from: b22rian on November 02, 2009, 02:32:58 PM
Naw you did fine IDog-- it was my fault really for being lazy and not putting the relevant quote I was replying
to in my posting.. i do appreciate both tage and steve's replies of course.. But I was hoping to get a reply back
from Steve , concerning the experiments you and I are running as to whether or not the commute times are
calculated only based on the morning commutes rather than some kinda average of both the morning and evening
commutes.. In the latter event it would have to be than the "buggy" commute time graph which they are referring to in the above posts, which would be calling the confusion on this..
OK, now as long as you trust these regular queries which show the
(quantitative commute lengths.. the short, medium, and long commute trips) early indications just from checking through some of the commutes in my largest city do seem to indicate that the traffic sim does in fact
calculate the commute trip lengths based on the morning commutes only.. Although i didnt find enough to test
to be absolutely sure of this.. More precise testing is needed unless Steve already know the answer to this ?
Thanks, brian
I know, I was just snapping that off before I left work so I got into a rush.
Ripplejet answered the second posts question and Steve confirmed and expounded on it. Reading between the lines a little he also says "Hey dumbass, we went over this already, I thought you did your homework" ...I did it, I just didn't understand it lol. I think I grasp it now. At least the part Ripplejet very clearly explains. Of course some of why I ask stuff that was explained in other posts is because Steve really does explain pretty well what he is doing, but without going into specifics.
What I really meant to say was, "Hey Steve, I hope you saw the post before as well, cause I'm looking for your commentary on that as well"
Also I just didn't have time to reply to your prior post (not going to requote it) before I ran out the door but I think if I understand you correctly then I think it is a great idea.
@Ripplejet
Thanks for clearing the rules up.
Yeah, like I said I originally was going to make them one post but then I thought for clarity I should seperate them.
Sometimes it is a hard call to make about when to break up a post or not.
Hopefully I will get into a rhythm eventually where I am not posting all day and in 20 different directions at once.
uhh almost forgot @ Steve thanks for clearing those up. What do you think of the Omnibus thing? I know we talked a little about it the other night but I don't know how coherent I was.
Quote from: ldog on November 02, 2009, 03:44:32 PM
@ Steve thanks for clearing those up. What do you think of the Omnibus thing? I know we talked a little about it the other night but I don't know how coherent I was.
What do I think about it? Well...
The "Commute Times Ten Bug" appears to be intentional on the part of Maxis. They didn't really want people to know that Sims were limited to only three minutes to get to their jobs. Now multiply that by ten and you still have on ly 30 minutes. But throw in the neighbor connections and their effect, and that's enough to sufficiently confuse everyone.
The "Pathfinding Engine Shortcomings" are what happens when you don't use Perfect Pathfinding (by definition).
As for the "Unrealistic Mass Transit Speeds," the goal is to make the results of the game look realistic, and the internal numbers are of secondary importance. But coincidentally, Simulator Z does take the basic advice here, although not using the exact numbers. Cars are now faster than buses, and rail speeds have been reduced. This was done because it produces a more accurate simulation, and a better-running simulator.
The commute time is always counted cumulatively (door-to-door); the pathfinder wouldn't be able to compute the best paths otherwise. This was proven conclusively by RippleJet's experiment a year ago. In my own experiments with the commute time graph, I also verified this.
The problem with MT's making the commute times rise is that the pathfinder is always supposed to find the fastest path (and with perfect pathfinding, it does). The only explanation I can think of for a rise in commute times due to MT use is yet another bug in the commute time graph, which would not be surprising.
For whatever it's worth... when we tried to cure the prop pox earlier this year, we decoded parts of the savegame format (SC4 files).
The commute path for each lot is saved in the end of the Lot Subfile (Type ID = 0x09BD5D4A), with the following structure:
| DWORD | Count of Commute Blocks (number of destinations commuted to from here) |
| DWORD | Count of Commute Paths (usually 0x00000002 = morning and evening, 0x00000001 for freight) |
| DWORD | Count of Bytes in the Path |
| BYTES | Commute Path (1 |
| DWORD | Number of Commuters |
| BYTE | Unknown, 0x00 or 0x03 |
| BYTE | Unknown, 0x00, 0x01 or 0x02 |
| BYTE | Unknown, 0x08, 0x09, 0x0A or 0x0B (0x00 if the commute path has disappeared) |
| BYTE | Unknown, 0x00 or 0x03 (0x04 if the commute path has disappeared) |
| SINT16 | Commute Destination, X Tile (2 |
| SINT16 | Commute Destination, Z Tile (2 |
| FLOAT32 | Trip Length |
| DWORD | Unknown (3 |
1)Structure of Commute Paths:
| BYTE | Starting Traffic Type (see below) |
| BYTE | Path Start Tile X (network in front of the lot) |
| BYTE | Path Start Tile Z (network in front of the lot) |
| Commute legs, repeated for each transit switch |
| BYTE | Transit Switch 0x4T (T = Traffic type, see below) |
| BYTE | Length of Path (Count of quads) |
| QUAD | Path Direction (0 = West, 1 = North, 2 = East, 3=South) |
| QUADS | 00b (repeated 0, 1, 2 or 3 times, in order to fill the last BYTE) |
Traffic types are in the same order as in the Traffic Simulator:
- 0x00 = Walk
- 0x01 = Car
- 0x02 = Bus
- 0x03 = Passenger Train
- 0x04 = Freight Truck
- 0x05 = Freight Train
- 0x06 = Subway
- 0x07 = Light Rail
- 0x08 = Monorail
2)Destination TileA job located in a neighbouring city has the XZ coordinate of the border crossing.
- A job located in the western neighbour has an X coordinate of -1 (0xFFFF)
- A job located in the northern neighbour has a Z coordinate of -1 (0xFFFF)
- A job located in the eastern neighbour has an X coordinate of 64 (0x0040), 128 (0x0080) or 256 (0x0100), depending on the size of the city
- A job located in the southern neighbour has a Z coordinate of 64 (0x0040), 128 (0x0080) or 256 (0x0100), depending on the size of the city
If the commute path has disappeared (e.g. work demolished or redeveloping), the X coordinate becomes 0xDFA8 (-8,280).
3)UnknownFor residentials; often 2, but I've also seen e.g. 9 and 11. Always 16 for industrials.
If the commute path has disappeared (e.g. work demolished or redeveloping), this DWORD becomes 0x0012FC70.
Quote from: RippleJet on November 02, 2009, 11:05:25 PM
...
| QUAD | Path Direction (0 = West, 1 = North, 2 = East, 3=South) |
...
Well that validates my findings earlier in the Query.txt thread. I wonder why an entry of four possible values needs a quad for storage.
A quad is two bits, which can take only four values, 00b, 01b, 10b and 11b.
Four quads make up a BYTE, hence it's naming.
Ahh, thanks. I was thinking of quad words &ops (I need to be more specific on terminology).
Quote from: catty on October 30, 2009, 10:48:46 AM
An awful lot got lost last year when Simtropolis was hacked, have a read of this topic in the Omnibus (unfortunately the links its referring to I haven't been able to locate anywhere, but it does show the testing they were doing)
http://www.simtropolis.com/omnibus/index.cfm/Main.SimCity_4.Commute_Time_and_Pathfinding_Report
I continued to have a look around for the links this report was referring to, and found information concerning this report and other problems on the official SimCity site in the BBS from the
@the7trumpetsQuoteI am one of the people who did a lot of work testing the commute engine, and compiled the work of simtropolis members in the 'commute time and pathfinding report' which described many issues in the commute engine.
http://simcity.ea.com/bbs/messages.php?&openItemID=&threadID=0f9d1749cdef413a65f10da4ebbd5044&directoryID=261&startRow=1#49308a9b642b1988479cb0a79a33c5cb
continuing to have a rummage around the old posts, there are a number of bugs being reported including this one
QuoteLastly, the commute time that is displayed in the query box for residential buildings has been determined to contain a bug. Once a building gets a 'long' commute time, it will always have it, even if all of the sims in that building were to get jobs across the street. Maxis is aware of the problem, but it is only visual. It does not actually affect the commute time.
just how relevant any of these old posts are  :-\  but it makes for some interesting reading :)
Quote from: catty on November 03, 2009, 12:19:38 AM
I continued to have a look around for the links this report was referring to, and found information concerning this report and other problems on the official SimCity site in the BBS from the @the7trumpets
http://simcity.ea.com/bbs/messages.php?&openItemID=&threadID=0f9d1749cdef413a65f10da4ebbd5044&directoryID=261&startRow=1#49308a9b642b1988479cb0a79a33c5cb
continuing to have a rummage around the old posts, there are a number of bugs being reported including this one
Quote
Lastly, the commute time that is displayed in the query box for residential buildings has been determined to contain a bug. Once a building gets a 'long' commute time, it will always have it, even if all of the sims in that building were to get jobs across the street. Maxis is aware of the problem, but it is only visual. It does not actually affect the commute time.
just how relevant any of these old posts are :-\ but it makes for some interesting reading :)
Oh this is very relevant Catty...
in that it throws a bit of a "wrench" into using the commute lengths displayed when you preform a "query", in terms of using that to ascertain whether length of commute times are a product of both the evening and morning commutes or whether the game just calculates all the morning commutes alone and than assumes the return commutes from work to be the same routes..
Thanks a lot for this Catty !
Brian
That's a real treasure, Cathy - thanks for bringing it to our attention! I found a few especially interesting nuggets that I'll report on a little later on.
A word of caution - these posts were written before the release of Rush Hour, and the patch that followed that release. So a lot of the bugs reported in the posts no longer exist.
Quote from: z on November 03, 2009, 04:33:17 AM
A word of caution - these posts were written before the release of Rush Hour, and the patch that followed that release. So a lot of the bugs reported in the posts no longer exist.
:thumbsup: its still a bit like rummaging around in a old attic, you know most of its junk or out-of-date, but its also interesting history at the same time :)
Quote from: b22rian on November 03, 2009, 03:58:44 AM
Oh this is very relevant Catty...
in that it throws a bit of a "wrench" into using the commute lengths displayed when you preform a "query", in terms of using that to ascertain whether length of commute times are a product of both the evening and morning commutes or whether the game just calculates all the morning commutes alone and than assumes the return commutes from work to be the same routes..
Neither, actually. As mentioned above, the round trip commute times are always double the morning commute time; this was verified by experiment by ldog, and is mentioned in the Prima Guide.
A word about the Prima Guide: It has many mistakes in it (I've found a few myself), but I'd say it's about 95% accurate, and it contains a huge amount of information about the game all together in one place. I don't know of any other single source that does this. I would strongly recommend it as a beginning text for understanding how the game really works.
Quote from: catty on November 03, 2009, 12:19:38 AM
I continued to have a look around for the links this report was referring to, and found information concerning this report and other problems on the official SimCity site in the BBS from the @the7trumpets...
As I mentioned before, this is really fascinating stuff - I wish I had more time to read it all. At least as important as the posts from the7trumpets (one of the game's all-time greats) are the posts from MaxisFrank. He was quite possibly the last Maxis employee to communicate officially with the SC4 community.
Since there's a lot of material in these posts, I thought I'd summarize some of the things that caught my eye that are particularly relevant to what we're doing now:
Everybody in these posts seems quite fed up with the Maxis traffic simulator, for reasons which should be quite obvious to us. A suggestion is made by the7trumpets that Maxis use a pathfinding algorithm based on something like A* - the original simulator works so poorly that it wasn't obvious that that was what they were already doing. MaxisFrank's response is apparently the first time the community found out that A* was being used. From MaxisFrank:
QuoteWe're already using a modified version of A*. The problem is that intersections as node based calculations won't work due to the insane number of possible nodes in a city. This is due to the fact that most buildings have jobs and thus are possible destinations (nodes). We considered this, but had to rule it out.
Unfortunately, he doesn't say anything more about what they actually do, but this should give some insight into Maxis' A* implementation.
The pathfinding heuristic was a topic of great debate even back then, and it appears that the7trumpets was actually the author of the first "perfect pathfinding" patch, a term that appears in these posts. Specific values as low as .005 are mentioned, and it is likely based on other posts here that the7trumpets patch actually used .003, and that this value was determined experimentally. I have not come across the exact specifics to support this, and I am not sure that they exist on this board.
The question as to why Maxis used a value of .09 is answered directly by Maxis Frank, though:
QuoteBy the way, the reason why the heuristic is set at 0.09 instead of lower is for performance reasons. The lower you make this the smarter the traffic sim gets, but the longer it takes to complete a traffic cycle. If you've got a buff machine, drop it and be happy. If your machine is emitting smoke and screaming at you to make it stop, turn it up a bit :)
And an interesting response from toroca:
QuoteI can understand the pathfinding heuristic being set higher to speed up performance, but surely you could find a middle ground that allows for both good pathfinding and good performance? As it is now, that value is so high that pathfinding virtually doesn't exist. Sims do NOT take the fastest route to work in almost any situation; rather, they take the most direct, in terms of shortest possible distance. this results in ridiculously overused streets, crowded roads, empty highways, and underused mass transit systems.
Surely there's a better way to improve performance than by crippling the pathfinder? the7trumpets' pathfinding modd doesn't have THAT much of an impact on performance... I think the worst was a 45% slowdown, and that was only with the PERFECT pathfinding mod. In my case, the slowdown was MAYBE 15%, which is MORE than tolerable since it means sims actually look for the fastest way to work instead of the most direct. Few of my streets are overcrowded, and my highways are heavily used, for the first time since I bought the game.
So much good new info.
Thanks everyone joining in the discussion.
I'll have to go read that article.
I'm also glad to see a bit of the query.txt topic showing up here; I've been following that with fascination since Cathy brought it to my attention and thinking about how it relates to traffic.
Of course so has Steve who has already answered some of the questions that topic raised.
Quote from: z on November 03, 2009, 02:18:53 PM
Neither, actually. As mentioned above, the round trip commute times are always double the morning commute time; this was verified by experiment by ldog, and is mentioned in the Prima Guide.
Thanks Steve,
I knew you had mentioned it some place.. for some reason I was having trouble finding it.
Course it wasnt the answer myself or probably any of us were hoping for.. Obviously we would like the
game to me as accurate as possible.. But it is, what it is..
I know for a fact i have routes where the return trips from work are different routes from those going to work. I admit i do not know the % of the route discrepancies versus identical routes to and from home..
Also I suspect the distances of the route discrepancies would not vary much.. I suppose if there was a large
variance between them, than this would indicate a highly inefficient transit system &Thk/(
thanks again brian ..
Quote from: b22rian on November 03, 2009, 03:45:27 PM
Course it wasnt the answer myself or probably any of us were hoping for.. Obviously we would like the
game to me as accurate as possible.. But it is, what it is..
Yeah, we are all a bit obsessed. Considering that little gem my A* research pointed me to on SC4s site, Maxis had much less lofty goals.
This was the first SC that even had pathfinding in the traffic engine, so they were happy just to add it, forget perfecting it.
If we were actually getting a SC5 we might get better.
Although honestly I think what the community has done with SC4 over the years it probably is still more than we would have gotten out of an SC5.
Quote from: b22rian on November 03, 2009, 03:45:27 PM
I know for a fact i have routes where the return trips from work are different routes from those going to work. I admit i do not know the % of the route discrepancies versus identical routes to and from home..
Also I suspect the distances of the route discrepancies would not vary much.. I suppose if there was a large
variance between them, than this would indicate and highly inefficient transit system &Thk/(
Well the reason it was relevant to me was mainly because of the kind of things you could do with one way roads. Otherwise it is a fairly safe assumption they made that most people return home the same way they go to work. Jason being a notable exception :P Although...I admit even I take a slightly different route home generally. Of course this is mainly due to local congestion patterns. Sometimes it is just over a 5 minute difference but it is enough for me. &Thk/( I guess as much as possible I try to use perfect pathfinding myself ;)
Once again, for practical purposes it is probably irrelevant but something I found interesting (summary for those among us not interested in theory :P ).
Test mini-update for the day (last night's play actually). I didn't make a lot of progress. Was still noting anomolies. So I started a couple other tests (I had the sense not to slag the started one this time though). I still don't understand why I am seeing abandoned due to commute time when I have a highway and train system that has no congestion and the zones are far less than half a large tile apart. No Steve, I'm not using .003 for ph. Using .009 ...incidentaly 82x1.3=106.6 and 1/106.6~0.009 ... theoreticly if we find an open highway we stop looking for a better route. I still get a fair amount of train use as well. Even though I am still not convinced about .003 at some point I will switch it up and see if it makes a difference. I think some of my problem is trying to force such an unnatural growth and I wonder, if there actually is no job available for those sims does it still report due to commute time? I have not seen any commercial or industrial abandonment yet, just residential, mostly R$ , some R$$ but no R$$$ (paying better attention this time). Of course I am still far from saturating the train stations; adding more MT at this time would only make it worse. I've still got quite a bit of building to do before I get any kind of MT related results.
Anyway, in the middle of an assets audit at work so updates will be kinda sporadic from me this week.
Quote from: ldog on November 03, 2009, 04:59:32 PM
I still don't understand why I am seeing abandoned due to commute time when I have a highway and train system that has no congestion and the zones are far less than half a large tile apart. No Steve, I'm not using .003 for ph. Using .009...
There's your answer. You might want to bump up your priority of checking .003. Just a suggestion... ;)
Quote from: ldog on November 03, 2009, 04:59:32 PM
Yeah, we are all a bit obsessed. Considering that little gem my A* research pointed me to on SC4s site, Maxis had much less lofty goals.
This was the first SC that even had pathfinding in the traffic engine, so they were happy just to add it, forget perfecting it.
If we were actually getting a SC5 we might get better.
Although honestly I think what the community has done with SC4 over the years it probably is still more than we would have gotten out of an SC5.
Test mini-update for the day (last night's play actually). I didn't make a lot of progress. Was still noting anomolies. So I started a couple other tests (I had the sense not to slag the started one this time though). I still don't understand why I am seeing abandoned due to commute time when I have a highway and train system that has no congestion and the zones are far less than half a large tile apart. No Steve, I'm not using .003 for ph. Using .009 ...incidentaly 82x1.3=106.6 and 1/106.6~0.009 ... theoreticly if we find an open highway we stop looking for a better route. I still get a fair amount of train use as well. Even though I am still not convinced about .003 at some point I will switch it up and see if it makes a difference.
Oh, there is no question in my mind were better off with what has transpired, in terms of traffic sim research.
First our pioneers , tropod and the 7 trumphets and later through the work and research of Mott, jason, and
of course especially steve.. From not just ability but on account of all their hard work and dedication we now
use some pretty darn good traffic sims.. when compared to the original maxis traffic sim.. &apls
from what i gather with what you have done so far.. i would say your main problem is having the PH set to
.009.. Although sure I encourage you to do as much testing on lower Ph values as you have time for.. i do
trust steve , tropod and others that .003 is a pretty good setting for PH.. but try some other Ph settings
as well and see what you come up with .. keep in mind that by using this thread you have created to keep
us up to date on your testing results , not only furthers what your trying to accomplish but it quite helpful to
those interested in traffic, in general.. as you know many of the areas in traffic are quite complex and theoretical so the more testing we can do, the better !!
thanks brian
Quote from: ldog on November 03, 2009, 04:59:32 PM
if there actually is no job available for those sims does it still report due to commute time?
Yes
Quote from: ldog on November 03, 2009, 04:59:32 PM
I have not seen any commercial or industrial abandonment yet, just residential, mostly R$ , some R$$ but no R$$$ (paying better attention this time).
Commercials and industrials would never become abandonded due to lack of workers.
They can actually keep operating even if nobody is working there... $%Grinno$%
Commercials may abandon due to low customers though,
which would happen if there's no traffic on the networks nearby.
Quote from: RippleJet on November 03, 2009, 10:42:25 PM
Yes
Well that is what I am inclined to believe at the time; that it isn't the pathfinder being stupid and not finding a job, the job just isn't there to find.
I am currently testing with .003 at the moment to see if it makes a difference.
Quote from: RippleJet on November 03, 2009, 10:42:25 PM
Commercials may abandon due to low customers though,
which would happen if there's no traffic on the networks nearby.
Which would be when it says "abandoned due to lack of demand" correct?
Quote from: ldog on November 04, 2009, 07:22:18 AM
Which would be when it says "abandoned due to lack of demand" correct?
"Lack of demand" can be several reasons, e.g. if the demand is actually negative, but more often if the desirability of the lot has fallen below the abandonment threshold.
The number of customers as such is a factor in the desirability, but not the only one.
I cannot remember for sure if "lack of customers" alone can be a reason shown for commerical abandonment... %confuso
Correction:
Together with
metasmurf (tack Andreas!) we checked all available reasons for abandonment.
There are only five of them in the game:
- Abandoned due to lack of power
- Abandoned due to lack of water
- Abandoned due to low desirability
- Abandoned due to commute time
- Abandoned due to low demand
The third one is the one that you would get due to low customers in a commercial building, or due to any other desirability factor being too low (all in all, for any RCI type due to the desirability falling below the abandonment threshold).
The fourth one is the only one that you'd normally get in residentials, unless you cut off power or water.
The fifth one is the one you'd get if the overall demand for that RCI type is negative, and that can occur for all RCI types.
Thanks for that list Rip.
I'm still trying to get results with the different pathfinder, since as ...
Quote from: z on November 03, 2009, 05:21:14 PM
There's your answer. You might want to bump up your priority of checking .003. Just a suggestion... ;)
Somehow, I just knew you were going to say that. I must be psychic (or is it just psychotic? :-\ )
Then again we all knew that, you knew that too ;)
Still too early for me to tell. Wish you could swap on the fly and have the changes take place instantly since I'd like to examine the same particular point in time with the different engine, but rubbish in one hand and want in the other...
I am seeing more interesting routing though. Sims are taking the long way around some places, even though at a glance it would seem to not be a faster way; with no or minor congestion on the main routes. They are using every possible road to get where they are going. Still I am going to give the engine the benefit of the doubt that it really is a faster route, and even if it isn't well hey we wanted to see those people doing like Jason described how he goes home so I can chalk it up to that.
The thing is it REALLY makes no sense. The "better pathfinding heuristic" should still be overkill for the choices and availability presented. This would tend to prove what Steve and others have said, and prove to me that it really is "alpha" as I said earlier in the thread. Of course it is far too early for me to conclude anything; just speculating on my observations at this point.
As far as traffic simulator caused abandonment; if this is indeed what I am seeing and not just a case of there isn't actually a job for them to find, then I do agree with Steve that it is bullshit....errr...a bug. I know I said above I wasn't of a strong opinion about it. I am now. I really went overboard with the traffic network from how I would normally play in an attempt to get the test city to approximate what I expect it might look like after I had spent a long time playing it. The highway network is massive overkill, with rail thrown in for good measure. While I haven't sat down and counted out the tiles, there is no way they could run out of time without it being a bug.
But I am getting ahead of myself here...maybe like I said there just was no job to be found.
Quote from: ldog on November 04, 2009, 03:01:00 PM
I'm still trying to get results with the different pathfinder, since as ...
Somehow, I just knew you were going to say that. I must be psychic (or is it just psychotic? :-\ )
Then again we all knew that, you knew that too ;)
Still too early for me to tell. Wish you could swap on the fly and have the changes take place instantly since I'd like to examine the same particular point in time with the different engine, but rubbish in one hand and want in the other...
Think its great your Experimenting with different Ph's, Lenny :thumbsup:
try to keep in mind ,the larger your city , the bigger your population, and the more complex your transit
system becomes.. i think the more differences your going to notice using the different PH settings..
umm, im not sure you mentioned how large a city this test city is in terms of population ?
thanks for the update,
Brian
Quote from: ldog on November 04, 2009, 03:01:00 PM
Wish you could swap on the fly and have the changes take place instantly
You can certainly speed them up a lot. Simply demolish all the abandoned buildings. You should get new buildings growing fairly quickly. This tends to be a lot faster than waiting for the abandoned buildings to become reoccupied, for reasons that RippleJet can explain far better than I. You'll get new buildings whether or not the problem has been solved, since the old ones weren't abandoned due to lack of demand. If the problem has been solved, the new ones will stick around; if it hasn't, they'll become abandoned, too.
QuoteI am seeing more interesting routing though. Sims are taking the long way around some places, even though at a glance it would seem to not be a faster way; with no or minor congestion on the main routes. They are using every possible road to get where they are going.
Yes, that sounds like perfect pathfinding in action to me. The routes generated are much more complex than for higher values of the PH, which is what Jason said he likes. The routes often do look surprising, especially if you have a complex traffic network, but if you do the actual calculations, you should find that they actually are the fastest. By using so many different routes, the Sims avoid creating congestion as much as possible, as congestion significantly lengthens commute time.
QuoteThe thing is it REALLY makes no sense. The "better pathfinding heuristic" should still be overkill for the choices and availability presented.
My recent experiments are providing results to the contrary. For example, I have been accumulating evidence (which I will present later) that the entire cause of the abandonment in Nate's city was that the PH was too high. Since Nate's city was on a medium tile, all of his jobs were less than half a large tile away from his residences. So when you said, "...the zones are far less than half a large tile apart," I thought, "Well, if he's even mentioning half a large tile as a job distance, there are going to be problems." Throw in a complex traffic network ("I really went overboard with the traffic network from how I would normally play"), which causes the complexity of possible paths to shoot way up, and a value of .009 for the PH just isn't going to cut it.
QuoteBut I am getting ahead of myself here...maybe like I said there just was no job to be found.
Everything RippleJet has said here on this topic is correct, as usual. However, if a city is built at all intelligently, it's actually rather difficult to run out of jobs. It's still possible that you're short a few, although I think that's unlikely. We'll soon see, won't we?
I have recently come across a little bit of evidence that the Perfect Pathfinding number may be slightly lower than .003. It definitely isn't higher. But it may be something like .0028, or even .0026. Unfortunately, the city that provided that evidence is now long gone. If you demolish all your abandoned buildings and any of the new ones become abandoned, you might try using a PH slightly lower than .003 and see if that helps. You have an excellent test case here, and there's an opportunity to pin things down more exactly that rarely occurs.
Quote from: z on November 04, 2009, 04:09:24 PM
You can certainly speed them up a lot. Simply demolish all the abandoned buildings. You should get new buildings growing fairly quickly. This tends to be a lot faster than waiting for the abandoned buildings to become reoccupied, for reasons that RippleJet can explain far better than I. You'll get new buildings whether or not the problem has been solved, since the old ones weren't abandoned due to lack of demand. If the problem has been solved, the new ones will stick around; if it hasn't, they'll become abandoned, too.
My recent experiments are providing results to the contrary. For example, I have been accumulating evidence (which I will present later) that the entire cause of the abandonment in Nate's city was that the PH was too high. Since Nate's city was on a medium tile, all of his jobs were less than half a large tile away from his residences. So when you said, "...the zones are far less than half a large tile apart," I thought, "Well, if he's even mentioning half a large tile as a job distance, there are going to be problems." Throw in a complex traffic network ("I really went overboard with the traffic network from how I would normally play"), which causes the complexity of possible paths to shoot way up, and a value of .009 for the PH just isn't going to cut it.
Everything RippleJet has said here on this topic is correct, as usual. However, if a city is built at all intelligently, it's actually rather difficult to run out of jobs. It's still possible that you're short a few, although I think that's unlikely. We'll soon see, won't we?
I have recently come across a little bit of evidence that the Perfect Pathfinding number may be slightly lower than .003. It definitely isn't higher. But it may be something like .0028, or even .0026. Unfortunately, the city that provided that evidence is now long gone. If you demolish all your abandoned buildings and any of the new ones become abandoned, you might try using a PH slightly lower than .003 and see if that helps. You have an excellent test case here, and there's an opportunity to pin things down more exactly that rarely occurs.
Well I don't have a tremendous amount of abandonment. I just think it is at a point where there shouldn't be any. Of course it is much more noticeable right now than my prior playing because I am specificaly on the lookout for just these kinds of things. The network isn't so much complex (it is certainly still too simple to fully test a traffic simulator as a whole) as it is way more than this city currently needs. I don't know about how intelligently it is built either, like I said it is very artificial compared to how I build when playing. Normally I would build out continuously from a core, not plop down multiple cores with an unsustainable (cost-wise) transit network such as it is. I think the highway network alone ran me half a million to build. I haven't even gotten it to a point where I feel it is reasonable to throw buses into the mix, let alone sub/el and mono. I don't really buy the not enough jobs thing either, although I have to do a little more investigating before I can dismiss it.
I'm sorry Brian I don't remember the pop offhand, it is still pretty low. I want to say 160k but I will go verify it tonight. Last night I put that city aside and I went back to playing a few medium tiles, per thy451's gamespot guide (which is pre-RH by the way), which was how I started learning to play. I find it useful to go back to for quick(er) tests, because I know what to expect from those city builds, so they give me a good baseline to compare to. Now I also got a bit of abandonment in "D'urberville" with .009 , I switched to .003 but it hasn't been enough years I think. I still had some abandonment and I think I even had some new abandonment since changing. I'm also pretty sure that there it isn't a case of not enough jobs. If it were R$$$ I was losing, then I would be inclined to think it could be, but it is R$ and R$$ so I am not buying it. I do have a bit of traffic (there are just roads and streets right now) but nothing even my little traffic simulator (which looks amazingly similar to B hard at the moment) can't handle. Moving on to "Aureliano" starting fresh with .003 I'm pretty sure I didn't have any abandonment there (but then I had a lot of commuters). Of course the game locked the computer up as usual around 1AM and I decided it was time to go to bed.
It is becoming more evident to me that we are dealing with a variable pathfinding heuristic calculation internally, which explains (to me anyway :P ) how we can have a perfect pathfinding heuristic that is independent of the "terrain entry cost". I would still love to know how Tropod figured that out originally, but I am about at the point where it is good enough for me. I will still consider the value we know as pathfinding heuristic to be "alpha" but that is really somantics at this point.
I think I'd go so far as to say at this point for someone just starting down the road I just started down a few weeks ago, if you are only interested in pathfinding as it applys to SC4 then don't even bother reading up on A* (I still found it highly interesting and worthwhile reading but that is me). All we can do is make educated guesses about what Maxis did internally. As Steve kinda said "it goes against what I understand about A* but this is what experimentation proved" (that was paraphrased not an actual quote) and Jason, who said he didn't really get into A*, but it certainly didn't stop him from making some of the biggest contributions to traffic simulation as we know it.
Now having said that, learning a bit of A* theory has helped me to be able to understand what I see going on enough to speculate on a lot of things. Like I said to SC4boy, it does help cut down on the needed experimentation time.
I want to point out that because of that theory some of the observations I've made so far are enough proof to me to accept certain things but I am not making any claims that what I have done so far in any way constitutes thorough testing. Or in other words I've proved a couple things good enough for my own satisfaction but I couldn't at this time provide proof to anyone else (except the morning commute time thing, that was pretty conclusive...again not anything someone else didn't say already either). It wouldn't be enough proof even for myself except that it corroborates a lot of what Steve, Jason and the others before them have said.
And the tests go on...
Quote from: ldog on November 04, 2009, 03:01:00 PM
I am seeing more interesting routing though. Sims are taking the long way around some places, even though at a glance it would seem to not be a faster way; with no or minor congestion on the main routes. They are using every possible road to get where they are going.
I should be a little more explicit in explaining what's happening here. You know how Sims spread out on the RHW? What you're seeing here is that same effect, writ large. In other words, it's the speeding premium. This premium makes Sims prefer routes that are just a little less busy than the ones they would otherwise take, even if there's no congestion.
I had first set the speeding premium in Simulator Z to be 10%, as such a premium is good for the pathfinder in that it helps provide tie breaking for A*. But this wasn't high enough to get spreading on the RHW. Simulators A and B were using 40%, and although that seemed high to me, I didn't have RHW in my older cities to test, so I just went with it, knowing it would work. I did mention to people that I thought it was high, though, and it was later determined that 30% worked well enough, so that's what's currently used in Simulators A and Z. I still think it should be lower if possible, at least for Simulator Z - 20% sounds about right to me - but testing would have to be done to make sure that this would still result on proper spreading on relatively short stretches of the RHW that were carrying light traffic. And if 20% turned out to be too low, I'd want to try 25%. If you want to do some experiments along these lines, feel free - they would be quite helpful.
The CvS curve was one of those things foremost in my mind when I was referring to Jason's greatest contributions.
(not discounting all the above, it's just pretty clear and well explained so I don't have anything to add)
I have of course been playing with my own adjustments to it.
Now one thing that keeps sticking in my mind about the pathfinding heuristic, and why it doesn't behave the way one would think it should after reading a bit of A* that no one seems to bring up:
Everyone talks a bit about the effects of changes to terrain entry cost in terms of how much further around the pathfinder will go then to find another path, and the effects of the heuristic on that but not about when it shouldn't bother to go around.
For example my reasoning for using .009 as my initial ph had nothing to do with it being the generally accepted "better pathfinding heuristic".
It is the theoretical ph for an uncongested highway in the current simulator "L" .
To put the math into words, the instructions to the pathfinding engine in effect should basicly be "If you find an open highway then don't bother looking for a better route"
I was going somewhere with this. %confuso Anyway. I still have some ideas but of course the abandonment thang throws a wrench into the thing.
Again, nothing Steve hasn't said.
So anyway, Gridlockshore pop 40k. This is happy news actually. It means I played for quite some amount of hours without hitting the save button (cause I am almost positive within a few percent that my last pop was much higher), so I should be able to get a closer approximation of what I had happening a few nights ago and see if I get the same abandonment issues with the ph of .003
Got to read all those old Maxis posts Cathy found for us. Really interesting stuff. I'm inclined to agree with Toroca. 7T rebuffed that by bringing up the listed minimum requirements, but I don't think Maxis tried very hard to find a suitable compromise for ph. As we've all seen, .09 gives us BFS.
Yes, at the the time that I came on the scene, it was generally believed that the PH was incapable of optimizing properly for speed. But of course, it is.
Meanwhile, I was able to reconstruct my testbed where I thought there was some evidence that .003 was higher than Perfect Pathfinding, and I now have some evidence that this is true. I had a few buildings that would repeatedly abandon at that PH, yet none of them do at .002. I'll now try to narrow this down further.
Quote from: z on November 05, 2009, 03:17:59 PM
Yes, at the the time that I came on the scene, it was generally believed that the PH was incapable of optimizing properly for speed. But of course, it is.
Meanwhile, I was able to reconstruct my testbed where I thought there was some evidence that .003 was higher than Perfect Pathfinding, and I now have some evidence that this is true. I had a few buildings that would repeatedly abandon at that PH, yet none of them do at .002. I'll now try to narrow this down further.
Very interesting
Quote from: z on November 05, 2009, 03:17:59 PM
Yes, at the the time that I came on the scene, it was generally believed that the PH was incapable of optimizing properly for speed. But of course, it is.
Meanwhile, I was able to reconstruct my testbed where I thought there was some evidence that .003 was higher than Perfect Pathfinding, and I now have some evidence that this is true. I had a few buildings that would repeatedly abandon at that PH, yet none of them do at .002. I'll now try to narrow this down further.
Well Steve,
i wish I could help you out with testing this.. But using sim Z with its PH of .003,
is evidently just too good in my cities.. I scarcely can find any abandonment due to commute time
at all.. Despite the fact i have one city nearing 2 million population and 2 other cities over a million in
my region.. :P
Quote from: b22rian on November 05, 2009, 04:20:56 PM
But using sim Z with its PH of .003, is evidently just too good in my cities.. I scarcely can find any abandonment due to commute time
at all.. Despite the fact i have one city nearing 2 million population and 2 other cities over a million in
my region.. :P
That's why I love using the South Side of Chicago as a testbed - it truly is "the baddest part of town." Many prototypes of Simulator Z died here, long before the world ever saw them. So it also has the nickname "The Graveyard of Traffic Simulators." If you can make it in the South Side of Chicago, you can make it anywhere.
Just ask Barack Obama. ;D
Regarding the PH...
Quote from: ldog on November 05, 2009, 03:44:19 PM
Very interesting
But it gets even more interesting. Basically, all I did was take the original release version of Simulator Z (v1.0) and run it on the Near South Side. Sure enough, as I remembered, it had more problems with abandonment than the current version (1.2). As I mentioned, these disappeared completely with a PH of .002. But with the next value I tried (.0025), a very small amount of abandonment started coming back.
When I reran the current Simulator Z under the same conditions, I got the same amount of abandonment at a PH of .003 that the v1.0 version produced with a PH of .0025.
How do we explain all this? Is the value for perfect pathfinding affected by other things in the simulator? I don't think so. In fact, I'll still stick with the value of .003 for the perfect pathfinding value until proven otherwise. The definition of perfect pathfinding in A* is that all the paths found will be the fastest ones possible. It doesn't guarantee that paths will be found, because standard A* assumes that paths will
always be found (if they exist) for all values of the PH. We have found that Maxis uses a modified version of A*, but we don't know all the details of how it's modified. Clearly, they have put a limit on how much time the pathfinder will spend looking for paths - that's the only way you can get abandonment in a simulator like Z, where the maximum commute time is effectively unlimited. But we have been assuming that the perfect pathfinding value is given unlimited time to find paths. Although this would seem reasonable, we actually have no direct evidence that this is the case.
Why the difference in abandonment between versions 1.0 and 1.2 of Simulator Z? The change happened in v1.2; I noticed it at the time. And one of the main changes in v1.2 is that I adjusted various MT speeds downwards. ::) This made the simulator perform significantly better in a number of ways; reduced abandonment was just one factor.
So travel type speeds seem to affect abandonment; they may have a direct effect on what the perfect pathfinding heuristic is as well, or these two factors may not be connected. It would take a lot more testing to see what's really going on here. Based on my experiments, I could probably get rid of all abandonment in Simulator Z by lowering the PH to .0025. But this would slow down the game noticeably, and as Brian's report shows, I'm not sure that this problem is seen often enough to warrant that. It may also be that I can get rid of this last little bit of abandonment by adjusting the travel type speeds further, although I'm reluctant to do that as well without other reasons. For now, I'll just leave everything as it is.
Quote from: z on November 05, 2009, 11:09:38 PM
... It may also be that I can get rid of this last little bit of abandonment by adjusting the travel type speeds further, although I'm reluctant to do that as well without other reasons. For now, I'll just leave everything as it is.
I think it would be more realistic to have a little bit of abandonment in your city, in a five minute walk around my neighbourhood we have a partially abandoned factory, about a dozen houses and a shop that has only just be reopened as a restaurant after being empty and boarded up for the last five years
:)
Quote from: catty on November 06, 2009, 12:21:22 AM
I think it would be more realistic to have a little bit of abandonment in your city
I'd agree with that! :thumbsup:
A simulator that doesn't lead to any abandonment isn't based on RL... ::)
Yes, that makes sense to me too.
It also means that I don't have to do any more work in this area. ;D
Of course, there are other ways to get abandonment too, if you like to have a lot of it... ;)
Quote from: catty on November 06, 2009, 12:21:22 AM
I think it would be more realistic to have a little bit of abandonment in your city, in a five minute walk around my neighbourhood we have a partially abandoned factory, about a dozen houses and a shop that has only just be reopened as a restaurant after being empty and boarded up for the last five years
:)
I agree here.. Im fine with a "little bit " of abandonment ... it gives me another little challenge and gives
me something else to work on.. Of course having to deal with it too much would be a pain :thumbsdown:
So for me so far anyways.. PH of .003 looks like a pretty good setting..
Quote from Z ..
That's why I love using the South Side of Chicago as a testbed - it truly is "the baddest part of town." Many prototypes of Simulator Z died here, long before the world ever saw them. So it also has the nickname "The Graveyard of Traffic Simulators." If you can make it in the South Side of Chicago, you can make it anywhere.
Yes actually I saw in another thread your chicago region was over 7.5 million.. my Florida region just
went over 5 million last night.. Thats a pretty big population difference 2.5 million.. i also recall from some pics
you have some amazing dense areas in this region :o
So its understandable you would have some abandonment problems in some spots..
Brian
Quote from: z on November 05, 2009, 11:09:38 PM
Regarding the PH...
But it gets even more interesting. Basically, all I did was take the original release version of Simulator Z (v1.0) and run it on the Near South Side. Sure enough, as I remembered, it had more problems with abandonment than the current version (1.2). As I mentioned, these disappeared completely with a PH of .002. But with the next value I tried (.0025), a very small amount of abandonment started coming back.
When I reran the current Simulator Z under the same conditions, I got the same amount of abandonment at a PH of .003 that the v1.0 version produced with a PH of .0025.
It makes sense. Even if we assume a variable ph formula, I would think there is still some range of values that would need to be adjusted according to terrain entry costs.
The thing about "Maxis using a modified version of A*" I highly doubt the algorithm they use is any different than any other A* implementation. It would take more math skills than I have to prove or disprove this of course. Speaking strictly of the pathfinding algorithm (as a distinct piece of the traffic simulator) A path will always be found if one exists, regardless of the ph, even if that path is to Quote Patel "BFS". The ph function is purely a matter of when to accept the path you've found or to keep looking for a better one. When all is said and done it really is a pretty simple thing.
Now what happens outside the algorithm is a different matter. Even though the traffic simulator is a pretty basic and limited thing, how it interacts with the rest of the game is where it gets complicated. Looking back on some of my earlier theory and conclusions, they are of course wrong. Steve has said as much. Of course being thickskulled..uhh...thorough..yeah, being the thorough person that I am I had to prove it wrong for myself. I still don't think the underlying A* mechanics of SC4 are all that different than any other A* application. The big difference is in the application itself. We aren't just trying to route a unit around the map, and then all the other interactions with said unit will take place within the absolute certainty that that unit is indeed in that particular spot on the map at the time. The traffic simulator is it's own little world here. So while I still find the theory valid, I was making incorrect comparisons between how A* interacts with a turn-based wargame and how it interacts with SC4.
So kinda like Newton in Steve's earlier example, we know and can see the effects of "nearest destination attractiveness" (this is what ph is called when I look at the exemplar) even if we don't truly understand it (because for all intents and purposes we know it's the ph, but it doesn't work the way ph is supposed to).
Now the key point where I am saying I was wrong is that the correct pathfinding heuristic value to use was not as narrow a range or as important as we were making it out to be.
Apparantly it is. While I still agree with the basic premise most of you are also stating, that some abandonment is tolerable. What my experiments showed me thus far is an "undocumented feature" aka "a bug". What I am seeing proves to me that Steve is correct about the abandonment being an issue. Within the parameters I set in "L" and the networks available there is no good reason why I should have had any residential abandonment. I really am not buying my own "no job actually available" defense. I really don't think I can prove conclusively one way or the other if there is or is not a job available either. Like Steve, I can prove lowering the ph stops the abandonment. The question still remains, why? Why indeed...
Quote from: z on November 05, 2009, 11:09:38 PM
Clearly, they have put a limit on how much time the pathfinder will spend looking for paths - that's the only way you can get abandonment in a simulator like Z, where the maximum commute time is effectively unlimited. But we have been assuming that the perfect pathfinding value is given unlimited time to find paths. Although this would seem reasonable, we actually have no direct evidence that this is the case.
This may help us explain why. It makes a lot of sense. I don't think any of us (you included) were assuming unlimited time, but we were assuming the time given within the max commute time at least.
So like I said above, given an acceptable path that can make the trip there and back within the limits of commute time, it seemed safe to assume that the trip shall be made. Not so, as we've seen.
Maybe there is some arbitrary limit somewhere in the executeable that we can't do anything about. Possibly it does have something to do with those values I mentioned in the developer exemplars. Maybe it is somewhere else, in some other exemplar. It's safe to say the max commute time doesn't determine it; or at least not directly in the way one would think it should.
I haven't been back to "Gridlockshore" to try it with .003 but I expect I will not see the abandonment; or at least see less. I so far have not seen any abandonment in any of my other concurrently running experiments, "D'urberville" started clearing up immediately, and while there is still a bit of abandonment left, I expect it to clear up in a couple years (didn't want to bulldoze as Steve suggested).
Currently I've started building another large tile "Gridlockcity" because one thing I did realize trying to use my shrunk down 3RR clone is that I am wasting far too much time "fighting the map". Between my perfectionist streak, the very strict slopemod that I choose to use, the roughness of the map...it is all far too much distraction (and we've all seen how well I handle distractions :P ).
So I decided to go far simpler, full flat boring map, built some grids, dropped the rest of the map into the water and called it "good enough". I'll be able to hit a larger population faster, which is needed to test the things I had stated I was going to be testing in the first place.
Sorry for the doublepost.
I'm trying to find some discussion about te lots, specifically entry cost and capacity.
I don't want to necro the sticky in the NAM section from Mott, especially since I seem to recall reading far more recent discussion on the topic.
Specificly I've been wondering but too busy to ask; has a consensus been reached on what formulas to use for these values?
Last I remember reading it seemed to be heading that way.
IIRC, I wound up going with .96/speed for in-line stations (el, mono, etc) and I wanna say .02 for off-line (bus, train, etc) which seemed to be what was heading towards becoming the prevailing standard. I haven't touched the RTMT lately since they would throw my tests off (even though I would love to use them...they just make life so much easier). Although since I've got so many of y'all RTMT team members here, let me ask, are y'all satisfied that the stations act identicly to the network segment they are on or is that still an ongoing tweaking process? In other words, that road-bus station, does it impact the traffic up, down or act just like a normal road segment does?
I also remember seeing capacity suggestions but not any kind of formulas or even a good rule of thumb. I've seen a lot of Steve's capacity suggestions but I take them in the context of simulator Z's network capacitys as well; in other words they are too high for my current scenario. As I said I am using default station caps currently for testing, but I'm always considering the future.
Oh, and thanks btw Steve for that confirmation about the trip starting cost stuff :)
I did a large series of experiments addressing just this question, and I have been spending the past few days writing them up. They should appear in my development thread late tonight. Both of you might want to see what these show before constructing new experiments.
Quote from: z on November 06, 2009, 04:42:11 PM
I did a large series of experiments addressing just this question, and I have been spending the past few days writing them up. They should appear in my development thread late tonight. Both of you might want to see what these show before constructing new experiments.
Ok great Steve,
Ive been looking forward to this for awhile now.. :satisfied:
Quote from: jplumbley on November 06, 2009, 04:23:21 PM
Hey Lenny... I am curious about this PH thing... You guys have proved in Simulator Z that it causes abandonment at higher values. I still do not get abandonment in the way you guys are showing, but of course I am using my Simulator A, is it possible for you to test a City with Simulator A and show this effect happening?
The thing I am wondering is if the "perfect" pathfinding value is effected by other properties as well, which may or may not make this value a value that changes from one Simulator to the next. The speeds will probably have an effect on this, maybe max commute time as well? A and Z have some very different values in them, and maybe something in Simulator Z is making the PH value more sensitive, or maybe my play style just fits well with Simulator A, that I simply don't run into the same issue you guys have found.
I just want to understand what the difference is and why it effects you and not me.
Remember, I am not using Z. I am using "L alpha .003" which at the moment is something between vanilla and B but with .003 ph. My speeds are all vanilla, I have a max commute of 24, mt commute of 10. I adjusted the CvS, ICE (intersection congestion effects) and transit type preferences to values that are different than all other simulators but I consider them pretty conservative.
I was not out to prove anything about the PH when I started these tests; I had considered it an issue I was going to put on the shelf for the moment. However observing the abandonment and the inevitable suggestion of lower the ph (remember I started at .009) which I decided to do since I was intrigued at this point, and I figured if nothing else it would stop Steve and Brian from trying to "convert me to .003" :P . I'm pretty confidant if I drop A in I will observe the same effect.
I do have a reason why I agree with Steve about this being a bug AND that I can believe you when you say you don't see abandonment problems with A yourself.
When you have 2 different things that you know both to be true and yet they conflict with each other then you have to bridge the gap.
What you and Steve have been debating are actually 2 seperate issues.
Much like you no doubt, whenever I had abandonment prior I considered it for the same reason; obviously this is a sign from the traffic gods that my network sucks, and I must make amends. So shoring up deficiencys in my network and/or zone placement and the traffic gods smile upon me again; the abandonment resolves itself. If you don't lay out your city well then you should have problems. Where and when this is the case you and I are in total agreement.
However what Steve has been asserting all this time, and what I am observing at the moment as well has nothing to do with this. My network is adequate for a city easily 10 times the size it is (probably more even). There is NO congestion anywhere. I have highway and rail going from each section. The longest commute distance I would roughly estimate at about 500 tiles (there and back). Just like A my parameters should allow a full 1024 tile commute on an avenue (in fact you should be able to do 967 tiles on an uncongested road), nevermind a highway or rail. Obviously something is amiss here.
Now normally I play in a similar mindframe to you. In building these test cases I am trying to very quickly build very large citys so I am playing in an artificial style (for myself at least). Had I been playing normally I either A: wouldn't have noticed the abandonment or B: written it off as poor citybuilding on my part, but it would never occur to me that the traffic simulator was to blame.
Now it isn't a very serious bug I suppose; as the consensus seems to be a bit of abandonment is tolerable, even if it is for no good you could get banned for thating reason (LOL, I just had to see what the profanity filter was going to do with that one...I admit it is something I have been wondering for weeks now...very clever it is). A bug it is nonetheless. At a minimum it means there are other things in play here that none of us understand. Although lets see what Steve has to show us, maybe his new theory panned out and he figured it out.
If Steve doesn't answer all our questions then I would be happy to try it out with A, Z and whatever else y'all would like. Although it may take me a few days to get to it.
Well, having read http://sc4devotion.com/forums/index.php?topic=5382.msg286055#msg286055 sheds a bit of light on the situation.
Of course now that leaves us with how to tune according to the newly discovered relationship.
I still think the traffic effect and trip length effect values in the developer exemplars tie in to this somehow, but I am not even about to start playing with them at this point in time.
They have some complicated looking values and I don't have a clue where to start.
It makes sense if you think about it; how can you make the commute time affect desireability without causing abandonment. Also it has to be scaled to the different wealth levels of course.
So today I finally isolated my crash and burn problem to *drum roll* the no-cd crack I was using. Imagine that </sarcasm>. Luckily I always backup the non-cracked exe for times like these. Hasn't crashed once all day. The convenience of not mounting the disc is outweighed by the convenience of not rebooting the computer every 5 minutes. Which was the point it was getting to around 200k pop.
Still getting quite a bit of new abandonment, even with .003 ph but then max commute is 24. Traffic is still not bad enough in my opinion. I expect to see the traffic get far worse before it starts causing abandonment like this. The situation of course is worse since I got a bunch of overeducated shits for sims. My fault for making the city too nice. So off to raise the max commute and see how that goes. Bus and train use is still not high enough (to get the kind of data I am looking for), I have the odd stations that are a bit over 100% use but most of them are very low.
A couple recent thoughts on buses, but still not enough useful data so this is still theory. Steve's new Euro sim and the total lack of change in bus use so far shown by testers got me thinking. If the bus is effected by congestion then the speeds should be set higher...I think somewhere between whatever your car speeds are as the lowend and the original Maxis ratio car/bus speed as the top, especially if you want to get more use. If leaving the bus not effected by congestion, then I think the speed needs to be lowered, max the same as the car, probably lower. This isn't backed up by any kind of testing; it is just what I think is a good set of values to start testing within.
I'm also thinking I need to drop caps back down a bit, at least for testing purposes.
Quote from: ldog on November 07, 2009, 05:31:54 PM
So today I finally isolated my crash and burn problem to *drum roll* the no-cd crack I was using. Imagine that </sarcasm>. Luckily I always backup the non-cracked exe for times like these. Hasn't crashed once all day. The convenience of not mounting the disc is outweighed by the convenience of not rebooting the computer every 5 minutes. Which was the point it was getting to around 200k pop.
I use Alcohol 52% to play SimCity and never have had a problem with it
QuoteThis CD & DVD emulation software allows users to create a virtual CD / DVD drives, and play CDs & DVDs without the need for the physical disc
its €22.30 EUR or 27.00 USD to buy and the home page is
http://www.alcohol-soft.com/
:)
Quote from: jplumbley on November 07, 2009, 05:39:30 PM
I was only looking for a test from an unbiased tester is all, and you are that guy. I did not realize you were using your "Sim L". There are many reasons why I may not get the same results, one being the way I play, another being that I don't grow to millions of Sims in one city tile, others may be other differences within the Simulator values. And, since I have problems at the PH value of .009 in achieving the results you guys have found, then I need someone I trust has a good understanding of what is happening.
So please dont take the request as me "doubting" your or Steve's observations. I am curious, but fail to achieve the same abandonment issue.
I have not been trying to argue Steve's assertions, just trying to understand them more clearly. It is difficult to get unbiased answers out of him. I want to understand why I do not find the same problems as he does, not refute his assertions. To me it seems that play style has a big effect on how the PH affect the pathfinding system since we see two completely different outcomes. And if that is the case, then obviously there could very well be differing values of the PH which would determine "perfect" pathfinding depending on play styles or maybe even "difficulty". And again if this is the case, and it does show that more "efficiently" designed networks systems can satisfy higher PHs that maybe this would be what determines the "difficulty" of the Simulator. But, then since everything effects everything else in the Simulator, maybe there are other things that effect the sensitivity of the abandonment issue you guys have discovered.
The thing is, there were many people that used Simulator A and did not have this problem when using .009, atleast not in the scale Steve showed in his post earlier this week. One being Nate, who posted his results for Steve. I think there is still a lot that needs to be discovered on this issue, beyond the fact that it happens, but in the realm of why it happens in one city but not another. I am just trying to analyse and throw out some ideas on what is occuring. And one thing that jumps out is the play style.
I understand. I will try to go ahead and run it tomorrow.
You should definitly read Steve's big post from last night if you haven't though. Nevermind, you did. Saw your response.
I am sure playstyle has a lot to do with it. Based on our conversations you and I share playstyle "ethics" but remember I have much less experience at playing the game than you or most people. The longer you have been playing this game the less choices you had. You played the game pretty much on vanilla and mods came out slowly I would imagine. When you got new mods you had time to absorb them. Y'all also didn't have all the tools available that we do now. And then of course the current mods are not the mods they were a few years ago. Everything has evolved. This would give you a far different perspective than I have. Such as it is, I have less preconcieved notions based on how I used to play and how things should act. For example, you probably place stations, entrance ramps, bus stops, etc at certain intervals you know work under your usual conditions. Then you can compare the effects of whatever changes you made to how things used to work and how they now work. I am just placing them where I think should be a reasonable distance, not by the way the game works, or has worked, but by the way I am trying to make it work. Also right now since I am trying to very quickly create a big city, I am slapping things down in a somewhat crazy fashion. The city costs about 70k a month to run, it only brings in 20k...you do the math. This is not normal play, not by any sense of the word I can imagine.
Once again you gotta remember, Perfect pathfinding heuristic is not a feel good value, it is a strictly defined absolute value. "There can be only one!". One we still don't know for that matter.
The question you mean to ask is "What is the proper number to use for ph, and in what circumstance?"
Even with Steve proving the effect of the ph and then tieing it to max commute time, and my results own tests validating that (to me at least) that still does not answer that question definitively (again to me at least). Your entire second paragraph is still very pertinent thought process. Right now I am concerned with trying to get together some kind of unified theory of how the fool thing works and what kind of options we really do or don't have with it. Even though I am screaming "BUG! Run for your lives! Aghhhhh!" right now, I haven't ruled out that in the end this may be the only way to set a difficulty level. What sense is there in having all red congestion everywhere and not having to suffer anything from it besides the annoying "a chaos of cars" constantly?
Quote from: catty on November 07, 2009, 06:24:03 PM
I use Alcohol 52% to play SimCity and never have had a problem with it
its €22.30 EUR or 27.00 USD to buy and the home page is
http://www.alcohol-soft.com/
:)
Daemon tools lite here, free ;)
I alternate between both programs though.
Sometimes I am far too lazy even for that lol. When I built this computer I went a bit nuts. I got 3x 146 GB WD Raptors in a stripe, it cost an arm and a leg compared to probably the terrabytes I could have got in 7200k RPM drive, but I got a need for hd speed. I also try to keep it always under half full so space is always at a premium. The ESATA drive I have for archives tends to overheat and screw up frequently so I don't leave it on when I don't need it.
But yeah, it was a much simpler solution to just throw the isos on my C:\ than deal with all that :D
Quote from: ldog on November 07, 2009, 06:37:40 PM
I am sure playstyle has a lot to do with it. Based on our conversations you and I share playstyle "ethics" but remember I have much less experience at playing the game than you or most people. The longer you have been playing this game the less choices you had. You played the game pretty much on vanilla and mods came out slowly I would imagine. When you got new mods you had time to absorb them. Y'all also didn't have all the tools available that we do now. And then of course the current mods are not the mods they were a few years ago. Everything has evolved. This would give you a far different perspective than I have. Such as it is, I have less preconcieved notions based on how I used to play and how things should act. For example, you probably place stations, entrance ramps, bus stops, etc at certain intervals you know work under your usual conditions. Then you can compare the effects of whatever changes you made to how things used to work and how they now work. I am just placing them where I think should be a reasonable distance, not by the way the game works, or has worked, but by the way I am trying to make it work. Also right now since I am trying to very quickly create a big city, I am slapping things down in a somewhat crazy fashion. The city costs about 70k a month to run, it only brings in 20k...you do the math. This is not normal play, not by any sense of the word I can imagine.
Yup this is quite an important point you raised here.. experience playing the game means a lot..
I have improved a lot in many areas of the game , just from playing quite a bit and the old (trial and error)
system still works believe it or not !
Thanks , brian
Quote from: b22rian on November 10, 2009, 03:41:25 AM
Yup this is quite an important point you raised here.. experience playing the game means a lot..
I have improved a lot in many areas of the game , just from playing quite a bit and the old (trial and error)
system still works believe it or not !
Thanks , brian
Yeah, that is why I have been (relatively) quiet lately. I'm spending a lot more time testing than in the reader now.
I just came to the conclusion that transit enabling lots just for the hell of it is pretty assinine. Sure it looks cool to have cars driving in and out of them but it screws with the simulator.
Some people may not care, and that's fine for them. Myself, I'd prefer to have things that look cool but don't break the game. So I've been doing a bit of editing of quite a number of my favorite lots.
What else, what else? I've found settings that I pretty much like so just been trying to put them through some more rigorous testing, and tweaking the odd bit here and there to learn more about how things interact.
Ahhh! I took what Steve did with the clean air ordinance, and I dropped the var into the car smogging ordinance set it to .7 (I started at .9 and then dropped from there a few times) and removed the default effect. It looks promising actually. The overall citywide pollution reduction of the car smogging act remains the same at that level, but it only changes the traffic pollution and not the industrial. It still needs some testing to see that the effect remains consistent but so far I am very pleased with the result. It is subtle but noticeable; it does not remove all the traffic pollution but you can see the colors change to a more muted yellow and the radius decreases a bit. If you had the car smogging ordinance enabled prior to making the change, the air pollution graph stays about the same level (if you didn't have it on then you will of course see a reduction when you do).
Well in light of Steve's recent experiments regarding the max commute time, I started thinking about how I could jack the commute time up and still keep the same overall balance I was looking for.
So I thought let me try lowering speeds. Talking walking down to 1, we then divide everything else by 3.5 . I then multiply my max commute and mt commute by 3.5 giving me 105 and 70.
Things worked pretty much as expected, there was a slight drop in MT use, but since I rounded everything up to keep whole numbers (train I might have rounded down...am at work), and so highway got a boost to 24 (23.4 was calculated) most of the others came in closer and their rounding only added 0.15, so it was not a surprise.
Now I went back and redid my stations patch, demolished all my stations and replaced them with stations that were updated to new values. MT use plummeted. I was puzzled for a bit but then I realized prior I was using .02 for which is not .96/pedspeed but a value that others (Cogeo?) found works as a compromise. Using .96/1 (which is .96) of course was disastrous. So for tonight I will change it to .07 and try that out, or maybe I will just leave it.
Another thing I am...
... we had a server blowup in the meantime and here it is 2 hours later from where I left off and I forgot what else I was going on about.
Hopefully this post is coherent, I'm heading home ;)
So I got home and instead of playing I got to rereading the infamous te switches and you discussion.
I also got to thinking more about the effects of the prefered commute strategys, the trip starting cost modifiers and the max mt commute time.
Instead of doing more testing I wound up opening up Excel and trying to chart out some commutes.
I really wonder that the max mt commute time is not what it has been described as by various people but instead exactly what it says it is; the commute trip max time for an mt prefered sim.
The math proves the above can't be right; the bus especially would never be used over a car, even with the higher default speed ratio; nevermind A & Z with them lower
I have tried it out with keeping the original Maxis ratio (6:4 so 24 and 16, 30 and 20) I have tried setting it the same as my max commute, I have even tried with it set at 10 (when I had regular max commute time of 24 or 30) when I was taking it as Jason had said somewhere that it was "the max time sims will spend walking to stations"...I thought 10 seemed reasonable since it meant they would walk 35 tiles, so divide by 2 for morning/evening, divide by 2 again for each end (home to station, station to work) which meant to me about an 8 tile walk on each leg. In game it has been pretty hard to pin down the exact effect, there are just too many variables in play. Well at least I got it narrowed down to either A. The max distance sims will walk to stations or B. The max amount of time they will spend on the bus/rail. Having found that commute time calculations only apply to morning commute explains why I could not determine anything consistently. Research on this continues. and on the next page we find out Max MT commute time is an unused value
Now when you consider the default starting trip cost for a car under MT prefered is 1.95, that means in vanilla a sim will go only 3.65 time units by car (don't forget car also always has a .4 overhead tacked on it from another var) so making the MT trip only 4 seems reasonable. The bus even with its higher speed is still slower most of the time on the same network (I figured a 3 TU walk and 1 TU MT ride for average...if we only had to walk 2 TU then the bus wins). It would explain why the sims will not walk far at all in vanilla, especially for the bus. So it would seem an MT prefered sim expects a faster commute. And we also find out all this is incorrect as well, because the values are some kind of relative weight that I am still trying to determine a better explanation of how they work
Now car and fastest prefered will spend longer commuting but then with the penalty to walking for car prefered only being .1 I don't see how it makes much difference between the 2 types.
All things being equal (congestion, etc, etc) on the shorter MT prefered length trips I calculated ave beats rail, highway beats all. I have calculated the longer trips, but once again how many minutes you have to walk is what really makes or breaks MT.
Ok, so who gives a rats ass about the vanilla traffic sim? Where am I going with this? For one thing, my spreadsheet proves to me Maxis designed the traffic sim around the medium tile. Probably for performance reasons. No surprise there, just look at the maps that came with the game. Also it proves the traffic sim needed to be scaled out x4 In light of my recent commute time experiments drop this multiplier to x2 at a minimum to make a city of any size in a large tile viable. No surprise there either. Sims A and B are basicly that,the traffic sim scaled out x4. In most places. Some vars of course were not touched at all. Z on the other hand of course is scaled out even bigger, but virtually nothing is untouched.
Now I even tested for a while with no network preferences whatsoever for any wealth type (everyone was at fastest prefered) and it didn't seem to make much difference so it probably isn't all that important. Hell they might even be more broken vars for all I know. They aren't
Still, I wonder though about the ratios for these other values, if they should be scaled out as well. They shouldn't
A few other unrelated thoughts:
Speeds and commute time, forget reality. We've seen it doesn't apply. Proper ratios to each other are all that matter to give you the effect you want. It isn't like you can actually see the network speeds when playing the game anyway. I don't think the automata are affected :P The commute time graph...well...we all know how buggy it is anyway. So who really cares how long it says the commute is? The map scale really should have been 32M per tile instead of 16 and then things would be a lot more sensible (yeah, yeah, Mott basicly said this too....so far I regurgitate a lot of old information...although I like to think I am expounding on it at least a little ::) ) Pretending that is what it is and scaling everything else accordingly would work well except for 1 small thing...the network tiles become ridiculously large. A 32M wide road? Preposterous. Even with the sidewalk included.
Network capacitys? Here is something that really drives home to me at least how much playstyle does effect and is effected by the simulator. What determines the needed network capacitys? How dense you pack your peeps...zone density, building sizes (CAM, etc) and here's a big one *drumroll* blocksize! How big you make your blocks, which then sets the ratio of zoned land/network segments is going to have a huge effect on what is a reasonable capacity. So one has to determine what one considers a reasonable population density in order to set network capacitys properly.
So speed and commute time are really questions of scale (and other things as Steve would be quick to point out, but not going to get into those right now but also not discounting their importance) and network cap is a question of playstyle & building capacitys.
Also I know Cathy and probably Brian and others were interested in my findings on station capacity; I haven't given up on that. I just don't have anything conclusive yet and I think these other issues might be related to it as well. So far I have gotten several stations to high 300s but nothing over 400% yet. Running the numbers through excel I am starting to see why I haven't saturated them yet, even after putting the rail capacitys back to double (but leaving the stations at default).
Being as I can't sleep I just keep finding things to add. Still working on that spreadsheet; for those hoping to get some flashy sheet that has it all broken down into formulas, I'm sorry to disappoint but it is already getting quite tedious. I'm getting it close enough to do a little more tuning for my next test (which will be soon). It will be a long time (if ever) before I have anything that could be considered a useful general reference.
One thing however just dawned on me. If we scale the trip starting cost up for car, then we can use higher transit switch entry costs and it should mitigate or even neutralize the penalty. Who cares you say? What's the point if we're just going to make it irrelevant? Because we should then be able to eliminate the pedestrians shortcutting through the TS without causing a detrimental effect on MT use.
Quote from: ldog on November 12, 2009, 11:19:57 PM
So I got home and instead of playing I got to rereading the infamous te switches and you discussion.
I also got to thinking more about the effects of the prefered commute strategys, the trip starting cost modifiers and the max mt commute time.
Instead of doing more testing I wound up opening up Excel and trying to chart out some commutes.
Also I know Cathy and probably Brian and others were interested in my findings on station capacity; I haven't given up on that. I just don't have anything conclusive yet and I think these other issues might be related to it as well. So far I have gotten several stations to high 300s but nothing over 400% yet. Running the numbers through excel I am starting to see why I haven't saturated them yet, even after putting the rail capacitys back to double (but leaving the stations at default).
hey Lenny,
really interesting post here..
Im very glad you had time to read this thread ! .. In my mind the best and most famous thread in
devotion history :o
I think ive read through it like 6 times ???
There is just a treasure drove of information in there for those who love traffic !
As to the station capacity maxes..
Yes, that is one of the more interseting topics to be sure.. I know Steve has stated that there is quite a
lot of variance amongst stations as to how far over capacity you have to go for each to render them
over their capacities for their daily commutes.. As i have 3 cities over a million , i really should help you
out with some testing in this areas.. i should be able to come up with something and of course I will tell
you about the results I get..
Hope you will continue to keep this thread active as you continue to enlighten all of us with your findings
and diligent testing you have faithfully done..
Thanks Again, Brian
And now, the moment you've all been waiting for:
*drumroll*
It's picture time!
In my insanity I decided to start an MD for this, so for your viewing pleasure I present:
http://sc4devotion.com/forums/index.php?topic=9382.msg287921#msg287921
Y'all can skip the theatrics and head down to the 2nd post to see the latest test results.
@Brian
I guess it is required reading for the RTMT team eh.
I think I am catching up to you, that might have been my 6th time reading it as well.
Good stuff, good stuff.
:angrymore:
Reminds me I forgot to mention my MT station patch in the MD, I guess it isn't really relevant.
Speeds did not change from 1 sim to the next this time so I didn't need to redo any TE cost modifiers (yet...)
That will be one of the next things I work on though.
After I rework my spreadsheet ::) in light of my recent findings.
It's ALL in the math baby.
Quote from: ldog on November 12, 2009, 11:19:57 PM
...Also I know Cathy and probably Brian and others were interested in my findings on station capacity; I haven't given up on that...
:thumbsup:
Something else you might find interesting to read, I certainly did, was the last post Mott made
Quote from: mott on November 12, 2007, 01:58:04 PM
There's a clear explanation of RULs, written by the person who invented them, at:
http://www.mathematica-users.org/webMathematica/wiki/wiki.jsp?pageName=Road_rules
A quick read through this page will explain why it takes so long to get the new networks working properly. ;)
The link is still valid and is on "Utility and Road Network layout in SIMCITY 3000"
:)
Quote from: catty on November 14, 2009, 12:34:45 PM
:thumbsup:
Something else you might find interesting to read, I certainly did, was the last post Mott made
The link is still valid and is on "Utility and Road Network layout in SIMCITY 3000"
:)
Fascinating. I have been confining myself to the traffic simulator for the moment, but I'm interested in all aspects of modding (except BATing, I have the artistic skills of a gnat, and that is probably insulting to gnats) Besides, it is always interesting to read when the devs say something that is actually technical instead of just marketing crap (or worse, backpedaling on why they can't fix something). You probably just saved someone in the NAM team from a bunch of stupid questions in the near future :thumbsup:
Now I just need to find a bootleg of Mathematica :o
(joking)
Quote from: ldog on November 14, 2009, 01:30:49 PM
Fascinating. I have been confining myself to the traffic simulator for the moment...
One more link I promise and this is from the Transit Switch Entry Cost - Discussion Thread, if you haven't already read it, its worth taking a look especially at this post :)
Quote from: CLR1SC4D on May 31, 2008, 10:37:41 PM
Sorry about the long time between responses. Other than the normal reasons like being busy I have been further testing the commute engine to better understand it, and isolate parameters so that I am dealing with only one at a time.
@dedgren: Thank you. CLR, Chris, or Christopher is fine.
While working with the commute engine exemplar to refine information on "Transit Switch Entry Cost" I have come across some interesting info and discrepancies between what has been posted and what the tests are showing. If I am missing something, or the test information can be repeated/confirmed it would be good to know. (If this would be better posted in new thread or in the commute engine tweaking thread started by Mott let me know and I can post there or it can be moved.)
All the information was gathered with experiments where each Sim had the same network travel length by setting up a city in some form as below (except for point 4):
R C
R C
B==B==B
R I
R I
Where:
"R" = Residential Zone
"C" = Commercial Zone
"I" = Industrial Zone
"B" = Bus station
"=" = Road
In some scenarios the bus stations were replaced with roads or changed in size. Most scenarios the bus stations did not provide jobs. Also some experiments had a road looping around the top.
As the bus station in the middle was increased in length, with all other parameters remaining the same, the Commute Time increased proportionally to the increase in number of bus station lot tiles and the "Transit Switch Entry Cost".
Below are the summarized results in no specific order. Information related to transit switch entry cost has been bolded.
1.) Commute Time displayed can be calculated by:
Commute Time = INT{[ SUM(Tiles Transversed/Transit Speed) + SUM(Transit Station Tiles Transversed/Transit Switch Entry Cost)/0.96 ] * 24}
cont...
Thank you, Cathy for finding yet another important thread. Chris's experiments were excellent, and really helped show what was going on. The final equation is where the formula TSEC = .96/speed was derived from. And the 24 is the adjustment to the commute time graph scaling factor to make the graph correct in cities with no neighbor connection.
Quote from: catty on November 14, 2009, 02:22:43 PM
One more link I promise and this is from the Transit Switch Entry Cost - Discussion Thread, if you haven't already read it, its worth taking a look especially at this post :)
THAT is the post I knew I had read but was losing my mind trying to find again a few days ago.
Once again Cathy, thank you very muchly :D
Oh, by the way, if you happen to see my mind floating anywhere among some old post, can you kindly link it back to me /wrrd%&[sigh]
This is one of those prime examples of a thread that is confusing, especially when you are new and trying to read every thread you can find that might have some bearing on your interest. Some of the information is good, some is bad, some I still don't know about.
It also ended a year ago, yet it still isn't really clear if a consensus was reached or not.
While I'm not disputing the formula (for the moment, too tired to really evaluate it....although he is missing a parenthesis...typo I assume) I still can't figure out how it was determined. Maybe when I reread the post again in the morning with fresh eyes and mind.
Since most of last night was spent reading and writing pms, I thought I would start the morning with a bit of testing.
I took my vanilla with .003 ph and added 0/1.3 to the beginning of the CvS. Surprisingly it had very little effect on commute times or abandonment (we do have quite a bit more since we switched from L to V, there is only so much the pathfinder can do; however this city was intended to have problems, so if they all went away then I would know I overshot my goals for the traffic sim)
Since this didn't produce any notable results I decided to throw an extra subway line from the CBD down to the LERS block in the bottom just to see what happened. I did actually get the downtown subway station (shown in yesterdays pics) to reach 515% but it bounced up and down several times. I didn't feel like letting it run long enough to fully stabilize and since adding this extra line changes our baseline for future tests I exited without saving.
I'm going to go back in and try out 600 max commute time (and the 1.3 CvS topend) and see what we get.
And the friggin thing ran for about 3 years on cheetah before it locked my computer up again. :'(
Removing the no-cd hack lessened the frequency of this happening but did not eliminate it. As I said in another post, my computer while it is getting old (I tend build a new one about every 3 years) I can still pop in any new DX10 game and run it full bells and whistles, even heavy shadows and high antialiasing, without a stutter. Older DX9 games are another story. It wouldn't be so bad if the game just CTD but the locking up is making me nuts. Time to run it in a virtual machine methinks.
So anyways, as expected the commute time started creeping up and the abandonment started going away. Downtown sub station actually hit 545%. Of course I really don't think it is possible to determine if the pathfinder keeps trying to fling people at it or not once it fully saturates. Not in this city anyway. I probably could setup some specialized test scenario and look for abandonment that would probably be caused if that was the case, but for now there are too many other things to experiment with that are more important than finding out if rails could be set to be not affected by congestion and station cap used to control them. I did do some limited tests last week with it turned off that I didn't talk about; results were inconclusive.
I still prefer the bus the way it is. I also think the speed for it needs to be left higher than cars, my spreadsheets show (at least for vanilla and some derivitives I have concocted, I have started putting in values for other simulators as well, but haven't analyzed them closely enough) that the break even point from having to walk to the station actually eats up the speed advantage very easily. Testing also doesn't show absurdly high bus use, however I may place bus stations farther apart than what is considered normal. Walking speed and max commute time also make a huge difference. So does TS entry cost and starting commute times. Then throw in CvS, all the other possible differences and the whole thing becomes extremely complicated.
Then take the fact that a bus holds how many people? 100? 150? 200? I really can't remember, I haven't rode a bus in many years. In NYC during peak times the buses get crammed as full as possible. When I lived in Seattle I also remember that most of the buses there were the accordian in the middle type...they were like double size buses. I've never seen one packed quite as full as a NYC bus but then if actual safety capacity was not routinely exceeded in NYC I would have to say it was a much higher capacity bus that Seattle had. So if 1 bus is like 100 cars, then how many buses do we expect on a given road during a commute trip in SC4? If we said like 20 buses, at 150 people per, that is 3000 people riding the bus through a given segment. While that would mean there are more bus passengers on the road than cars with low capacity settings, I don't think it is unrealistic, and I have yet to see my bus volume on a given segment go higher than car. Yeah, I said the R word again. Anyway, it is just something to think about, there is no correct or incorrect answer here. This I firmly believe is one of those things that comes down to personal preferences.
Oh, by the way, back to the car smogging ordinance again. I had been playing with the change, when I switched to vanilla for the above tests I didn't add it. Now being as all my industry is HT the only air pollution I have is from traffic. With the car smogging not effectively functioning as emission controls the way Maxis made it, my pollution has of course gone up. All the more reason I think it is very useful to make the change (provided it doesn't break anything). I still don't know what a reasonable reduction % is either, a quick search and skim through some materials on emissions hasn't produced the kind of quick and easy answer that we need. I see they talk mostly about reduction of 1 type of pollutant or another, and the figures seem to be anywhere from 20-80% (it also ranges by which standard you are under and what year that was of course as well). For our purposes all we need to know is the overall reduction in pollution it should grant. Also there needs to be a suitable penalty to enacting it, I don't feel that anything should be a get out of jail free card.
Let me reiterate, even though this is the same parameter Steve added to the clean air ordinance, his was a different reason that has nothing to do with the car smogging. He greatly increased the volume of traffic and the pollution scaled with it. However that pollution didn't scale properly and he felt the need to do something about it. Ideally we should be able to directly change the car pollution levels but I would assume this is something not accessible to us so his solution was to do the next best thing he could find, to add that effect to the clean air ord, something I would assume most people pass sooner or later in all their cities. I feel it was a very good solution.
A little tidbit about speed, it has been stated in other posts that the speeds are in KPH. Then they are also about 10/16 of what I would generally consider reasonable realworld speeds (in other words multiply by 1.6)
1 KMpH = 1000Meters/60minutes= 16.666666666666666666666666666667 METERS PER MINUTE!!!
How big are our tiles in SC4? About that big.
Like many Americans, I have trouble relating the Metric system to the physical world. So I tend to think in SAE units when I need to eyeball something.
3.5 MpH sounds like a reasonable walking speed, however that is 5.6 KMpH.
5.6/3.5=1.6
If we take all the other speeds in the stock game and multiply them by 1.6, we get:
Steet 34 , road 50 , ave 64, highway 131, rail 176, subway 240, monorail 320 KMpH
or
Steet 21, road 31, ave 40, highway 82, rail 110 , subway 150, monorail 200 in MpH
()what() ??? :o
??? So the speeds Maxis tried to use are actually in MpH.
???
:-\
Once again, someone else may have said this. I remember reading a post here and it was concluded the speeds were in KMpH. I don't remember seeing anyone making that relationship.
At any rate, like I said in Gridlockcity, there's nothing wrong with double checking someone elses work.
Actually I had to do a doubletake, I thought maybe I just got confused going back and forth between metric and SAE, but the math checks out.
Not like it really matters anyway, I just thought it was interesting.
The important thing to remember is, it is tiles per time unit. km/h
So why that little exercise anyway? You seem to recall me saying take reality and throw it out the window.
I probably did say something like that. Still, even when we want to depart from reality, it is good to have a reference.
Actually though, I am looking to scale reality into SC4's reality (as long as we don't conflict the prime directive; the game must be fun).
When we want to scale, we need to have proper ratios. So I started putting a bit more thought into speeds.
Subway is way too fast. 60 MpH is more like it, and that is under optimal conditions. The NYC subway averages about 18 MpH (because of stops) or so I have read (I haven't been on the wretched thing in even longer than I've been on a bus) of course because traffic is so horrid, the subway is still the way to go.
Another strange irony of my life, the thing that is one of the banes of my existence is the thing I am trying so hard to make a more accurate representation of here. It makes me sick when I think about how many hours of my life have been wasted sitting in bumper to bumper traffic. I must need my head examined taking this on as a fun project.
Street and road are about right. Street speed limits tend to be about 15-25 mph, road 25-35. Ave...that's a bit on the low end. 40-55 is more like it. Highway, well highway speed limits here run the gammut from 55-80 (at least last I remember they used to be as high as 80 in the western part of the country, I've been back on the east coast for a good 9 years now)
Trains, I really don't have much experience with trains. A little googling and light reading, I think 110 is fair for the class of rail our rail is. Monorail, if we consider it HSR then 200 is fair. (Europeans would beg to differ I'm sure) I know there are much higher record speeds and indeed some of this information is a bit dated, but then in 2003 it was probably closer to the truth.
I haven't mentioned the El since I consider it an extension of the subway, of course one does not have to look at it that way or keep the speeds the same (I think Jason didn't, although probably because the light rail uses the El settings)
I have of course left bus out of the discussion since as we all know the bus speed being higher than car was part of a balancing act on Maxis part. Since you have to walk to get to the bus and walking is much slower, the bus needed some juicing up. The higher your max commute, the less advantage the bus needs and that is probably why others have slowed the bus down.
I've also not mentioned trucks and freight trains since their relationship is only to each other. However trucks go as fast as cars and the speed of 150mph for a freight train also is consistent with the same source that gave me 110 for a passenger train.
Of course I have gone into a bunch of useless theoretical babble as usual.
It doesn't matter what you set your speeds at, you won't see it in game, except the commute time graph, which we can rescale to whatever we want, and of course it goes crazy when we have commuters anyway.
The useful thing here is that aside from the subway I find the ratios to be good enough for a starting point. (y'all like that bold? I think I'm going to start doing that around when I make a point so that people who don't want to read through all my pages of droning on can skip to the point) It was something Maxis didn't bone up too badly.
We will probably tinker with these ratios later in order to keep balance among transit types as we like. We may even wind up with the same speeds as A or B or Z or something completely different.
If we give the subway a much higher network capacity, then we can set the speed to 60 and still keep it competitive (with badly congested roads, but then if your road network is not badly congested, why are you building subways anyway?) Hell, maybe, just maybe we could set the subway to not have congestion, it certainly would make the congestion map a lot more readable.
So tonight I decided I wanted to do some testing to find out the exact effects of the trip starting time, and to further see if I can get the stations to work properly with an entry cost of .96/walking speed.
I took set all travel preferences to 100% fastest method. Took out the CvS and intersection/turn effects as well (set everything to 1.0 basicly neutralizing those vars).
Interesting effect. Of course with all roads (I did this in a medium tile on a new city) and these settings effectively the pathfinder does no work, because the shortest route is also the fastest route.
A couple side effects though, I got a commute time of 0. The congestion display always shows green. The "chaos of cars" and the like messages will showup when the volume is at 600% (like on my busiest intersections). The worst intersections had combined morning/commute volume of over 9000 cars, this is more than 900% capacity. While I have not tested this, I have a suspicion that there is a ceiling on volume. (the same way as transit switches will max out eventually at some point)The game also ran extremely fast on Cheetah speed, I couldn't even tell when the traffic simulator ran by speed slowdown as you normally can.
Now for the second (very short) test I changed only the CvS to go to .3 speed at 300% congestion. On the first run all congestion everywhere went to red. By the second run of the simulator I started getting massive abandonment. Average commute times also instantly shot up.
Third test I am put a more normal CvS curve back in, 0%/1.3, 100%/1.0, 200%/.65, 300%/.30. Which of course put the city back to normal. Average commute quickly leveled out at 2.75 (I believe I have it scaled to 1:1) and I let the city run a good while. It is now 46 years old and it has been pretty stable for the last 10 years but work comes early and I am tired so that will be it for the night.
Hopefully tomorrow I will be able to make some progress.
Quote from: ldog on November 15, 2009, 06:15:18 PM
1 KMpH = 1000Meters/60Seconds= 16.666666666666666666666666666667
1 h = 60 min = 3600 s ::)
1 km/h = 1000 m / 3600 s = 0.27777778 m/s
Quote from: RippleJet on November 17, 2009, 11:28:40 PM
1 h = 60 min = 3600 s ::)
1 km/h = 1000 m / 3600 s = 0.27777778 m/s
And
0.27777778 m/s ties in with what the Prima guide has down as the walking speed across a tile
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Ffarm3.static.flickr.com%2F2513%2F4113973651_a2a8db43ec.jpg&hash=ebcdef43fb6a383593e49f9cbc70418de4d51732)
The Prima guide is worth getting if you don't already have it and its only $9.99 USD from Prima Games.
I'm starting to sound like a saleswoman, so I'm heading off to bed
Goodnight
:sleeping:
Thanks for yet another relevant citation, Cathy. You're absolutely right, although it's a little confusing because the two .27's refer to two different things. ???
I recently sent a PM to Lenny enumerating many and various sources that speeds are in kph and time is in minutes; this is one more source that I had forgotten about. And I'll also second Cathy's recommendation about getting the Prima Guide.
Quote from: RippleJet on November 17, 2009, 11:28:40 PM
1 h = 60 min = 3600 s ::)
1 km/h = 1000 m / 3600 s = 0.27777778 m/s
:angrymore:
Uhhhhhhh...big oops
:-[
But keep reading, because my embarassment is over a typo I made in sharing the information, not an error in my calculations. I also went back and made the needed corrections, so what I stated is correct and consistent with itself.
Quote from: z on November 18, 2009, 03:27:16 AM
...You're absolutely right, although it's a little confusing because the two .27's refer to two different things...
I know, It was way past my bedtime when I posted ;D
and now its way past time I should be getting ready for work ...
Uhhhhhmmmm....ok, did not properly write what I figured but it still stands.
The formula I posted is meters per minute. Because our time unit is 1 minute.
So you would take the formula Tage posted and then multiply it by 60 to put the time into minutes, giving the 16.666666666666666666666666666667 I refered to.
Steve if you want to publicly challenge that figure, then like I said in my pm I think that is fine.
I am not going to get angry over this. I don't believe you are going to get angry. And as long as everyone else following along knows that no one is getting angry at each other then public argument (aka debate) is fine. As I said at the end of the last flamefest, as long as we all remain respectful of each other, then disagreement is no harm, no foul. We are here to have fun. No one needs to take any of this crap personal.
I am doing a lot of just plain braindumping (brainfarting ?) here and I hold to very little as fact. Even my observations so far are simply not enough to prove anything other than very simple things (the things done in very controlled experiments).
The speeds that they used, if we all agree that a tile is 16m and the time unit is 1 min and they are indeed the speed in Kph, then the speeds are give or take about 10/16 realistic reasonable speeds.
Even if I was wrong with my math, which I do not believe I was, then even still the above statement is true.
Prima guides rarely have correct technical information. They are meant to be playing guides not a technical reference to the game. I really do not put much stock into anything printed in them.
Since Prima has already gotten enough of my money over the years and I do not feel I have gotten my moneys worth, I am not about to send even another single dollar to them.
I stand behind what I said as a valid theory until someone mathematicly proves me wrong.
Continuing our testing from where we left off last night;
We find our hero beset with traffic from all sides ??? ...
I did 2 quick tests, about 5 years each (I saved each time though...so we have aged the city 10 years). For the first I set the trip starting cost for car to 2 (we started with .4) and for the second I went even higher to 3.
Remember this is not what I have been referring to as "Simulator L" this is the stock traffic controller stripped down even further at the moment. So we still have a max commute of 6.
What were the effects? Avg commute time rose slightly to about 3. I really wasn't expecting it to have much impact; I don't remember where but I do remember someone (I think it might have been Tarkus even, although it probably was Steve) saying that the trip penalty is subtracted from the max, not added to the actual trip. This would tend to confirm.
Also the pedestrian traffic rose quite a bit (we only have roads at the moment so there are only 2 choices, walk or drive). Mainly in the very congested areas where work was also near enough to walk to in 6 minutes :P or less (commercial and hospitals)
Next we'll do a bit more testing adding MT into the mix. As soon as I figure out which method(s) will give me the most bang for the buck (as far as ease of observation for comparison vs value of data gained) Stay tuned!
I decided to go with bus for the moment. I layed down a few central routes that covered about 1/3 of the city. I got some bus use. Pedestrians went up a bit as well of course. Nothing extreme. It did eliminate the flapping abandonment cycle I had on the far east side (the last row of residences would go to no job, abandon, refill constantly on their own). Effect on commute time was negligible. I let it run that way about 12-14 years. Then I covered the entire city with bus routes, and let it run the remainder of 20 years (so 6-8 years like this). Car shot down to less than half. Bus and peds were actually slightly above car. Congestion on all roadways went to green. Commute time dropped to 2.75
Heading back to the reader and dropping the starting trip cost down to 2.0 the city looked more normal. Car use rose back up, bus/ped dropped. Congestion did not return to pre-bus levels but there was a fair bit. This is with a TE cost of .274 (.96/3.5). Believe it or not I actually still found an instance of shortcutting across the bus station. Commute time actually dropped slightly back to 2.5 again. I let it run for 10 years. We are up to 80 years now.
Past my bedtime once again, but tomorrow I will try setting the starting trip cost back to its original value of .4 . I bet my bus use will go to hell. Anyone care to wager?
As expected going back to .4 trip starting cost by travel type for car made the bus use and walking in general plummet. There was still some bus use of course, and sims would take the bus quite far, they just were not going to do much walking.
For the next test I set everyone to MT preferred 100%. So by default now we have a trip starting cost for cars of 2.35 (.4 for being a car plus 1.95 because we prefer MT). As expected, traffic volumes and patterns went back to pretty much what they were before (with a starting trip cost of 2 for cars) Then I quickly tested again with the MT starting cost for car at 0.1 bus use plummeted, traffic went back to about what it was under fastest preferred.
For anyone who is wondering what the hell I am trying to do here; I am verifying that various parameters actually work as documented (or even work at all for some of them) and also that making changes to them produce the results one might reasonably expect them to
So in the current battery of tests to do still there is Max MT commute time and trip starting costs for car preferred (where we make walking even less desirable).
These are crude tests to determine working yes/no and make observations about the general effects. We will get to deciding how to make use of such parameters and refining the magnitude of changes and the cause/effect to them at a later date.
Quote from: ldog on November 19, 2009, 07:42:25 PM
For anyone who is wondering what the hell I am trying to do here; I am verifying that various parameters actually work as documented (or even work at all for some of them) and also that making changes to them produce the results one might reasonably expect them to
This is a very noble effort, and well worth doing. However, I should simply mention my own experience here, which is that the same parameter can act in radically different ways depending on the settings of other parameters, and also which city is being run. This led to some real surprises in some of the tests I've done. Some parameters are obviously affected by this more than others; some are not affected at all. Trip starting costs (both versions) were one of the worst offenders here, with their effects varying from huge to almost nonexistent, depending on the factors I mentioned.
Quote
So in the current battery of tests to do still there is Max MT commute time and trip starting costs for car preferred (where we make walking even less desirable).
I am very curious about Max MT commute time, as my limited tests were not able to give me a completely satisfactory answer here. At this point, I believe it's the maximum length of any single MT segment, where "walking" counts as MT. But I haven't had the chance to fully test this out, so I will be interested to see what you find.
Quote from: ldog on November 15, 2009, 07:47:08 AM
Then take the fact that a bus holds how many people? 100? 150? 200? I really can't remember, I haven't rode a bus in many years. In NYC during peak times the buses get crammed as full as possible. When I lived in Seattle I also remember that most of the buses there were the accordian in the middle type...they were like double size buses. I've never seen one packed quite as full as a NYC bus but then if actual safety capacity was not routinely exceeded in NYC I would have to say it was a much higher capacity bus that Seattle had. So if 1 bus is like 100 cars, then how many buses do we expect on a given road during a commute trip in SC4? If we said like 20 buses, at 150 people per, that is 3000 people riding the bus through a given segment. While that would mean there are more bus passengers on the road than cars with low capacity settings, I don't think it is unrealistic, and I have yet to see my bus volume on a given segment go higher than car. Yeah, I said the R word again. Anyway, it is just something to think about, there is no correct or incorrect answer here. This I firmly believe is one of those things that comes down to personal preferences.
Yup i agree with all this .. But i might point out as far as the game is concerned this is all based on perspective
and how one sees buses in the game.. For me when im doing my route queries , the bus number only indicates
to me how many sims are using the buses.. it has nothing to do at all with how many buses are on the road ways
Although if I had to guess i would assume most people playing seeing the bus numbers, think that means numbers
of buses.. which is fine.. this is all a game and we see thing in the perspective of how we want to see them really, and than play the game accordingly.. if you want to see that as meaning 1 bus carrying xxx amount of
sims , sure thats fine.. But that is not what it represents mathmatically, to the traffic sim..
Brian
Quote from: z on November 19, 2009, 11:50:33 PM
This is a very noble effort, and well worth doing. However, I should simply mention my own experience here, which is that the same parameter can act in radically different ways depending on the settings of other parameters, and also which city is being run. This led to some real surprises in some of the tests I've done. Some parameters are obviously affected by this more than others; some are not affected at all. Trip starting costs (both versions) were one of the worst offenders here, with their effects varying from huge to almost nonexistent, depending on the factors I mentioned.
This is very true. I am sure you would agree that the trip starting costs have a
very strong relationship to the max commute time.
Quote from: b22rian on November 20, 2009, 04:22:27 AM
if you want to see that as meaning 1 bus carrying xxx amount of
sims , sure thats fine.. But that is not what it represents mathmatically, to the traffic sim..
LOL, no that is not at all what I meant though.
You are correct of course, the traffic sim simply sees the amount of sims using the bus, the same way it sees the amount of sims using the car.
Just like we don't have any carpooling mechanism we don't have a bus mechanism.
For instance it would be logical to assume that when we have multiple residents of the same building going to the same job that some of them would ride together.
There is just no way for the simulator to account for that, and once again if it was capable of it, it would really gain us nothing except added overhead.
Quote from: ldog on November 20, 2009, 09:44:19 AM
This is very true. I am sure you would agree that the trip starting costs have a very strong relationship to the max commute time.
Yes, I would agree, but most of my testing of these properties was done with the max commute time fixed at its current level in Simulator Z. The effect of these properties still varied all over the place.
Quote from: ldog on November 20, 2009, 09:44:19 AM
LOL, no that is not at all what I meant though.
You are correct of course, the traffic sim simply sees the amount of sims using the bus, the same way it sees the amount of sims using the car.
Just like we don't have any carpooling mechanism we don't have a bus mechanism.
For instance it would be logical to assume that when we have multiple residents of the same building going to the same job that some of them would ride together.
There is just no way for the simulator to account for that, and once again if it was capable of it, it would really gain us nothing except added overhead.
yes, i 'm with you lenny..
Sorry, if I mis- represented your comments ..
I too wish that buses could be represented in the game in the way you are describing..
But it would require some major modifications in the transit modding of the game in order
to pull it off..
Brian
Quote from: z on November 20, 2009, 01:02:00 PM
Yes, I would agree, but most of my testing of these properties was done with the max commute time fixed at its current level in Simulator Z. The effect of these properties still varied all over the place.
Yeah, I don't think if I ever figured out a formula for it that it would be anything simple. Probably something beyond my skills. We need Mott back :'( .
Is there a mathematician in the house?
One thing I can say for sure, it is certainly
not anything so simple as I originally thought, like if we double max commute then we double starting cost, etc.
Since I went out and got drunk last night I didn't do anymore experiments.
Don't drink and mod! The sim you save might be your own.I will pickup where I left off the other night (as soon as my head stops pounding)
Quote from: b22rian on November 20, 2009, 07:30:34 PM
yes, i 'm with you lenny..
Sorry, if I mis- represented your comments ..
I too wish that buses could be represented in the game in the way you are describing..
But it would require some major modifications in the transit modding of the game in order
to pull it off..
Brian
No problem. Even though I got a laugh out of it, that is 1 more way someone could choose to look at it.
Like I said there are no right or wrong answers for this question. Even though our "grown-up" toys are much more sophisticated, we still need to make use of what made our simpler toys fun when we were children; imagination.
What I am aiming for here is some crude rule of thumb for myself as to how many bus sims vs how many car sims is "about right".
However you choose to see it, you have to answer that question for yourself before you can determine if your simulator is functioning properly or not (at least as far as bus usage).
I think it would be an extreme strain on the traffic simulator if it had to actually account for vehicles and fill them with passengers.
It would likely be something
much more complicated than just slipping in a flag that says "X passengers = Y bus"
The game probably would have shipped with a PH of 9.0 instead of 0.9 ;)
I'm sure Steve could explain it a lot better than I could.
Picking up from where we left off on Thursday night, just thought of something. I didn't verify if the plain old trip starting cost affects MT preferred or if it is only for fastest method preferred.
So I'm going to go ahead and crank it up to 4.4
I ran the sim for several years. No change whatsoever. Opened up the reader just to be sure I had saved the change (I had).
So it would appear starting trip cost by travel type applies only to fastest method preferred travel type. So we can be completely sure later I will run the same tests again with 100% car preferred.
Now I have gone ahead and changed everyone to 100% car preferred.
For the first test, we leave the other parameters alone. So the starting trip cost for walking under car preferred is 0.1
As expected car use shot through the roof. Pedestrian use exactly matched bus use (I had to uncheck bus volume to see ped volume). So they walked only to from bus stops and minimally at that.
Commute times went up, since we made the traffic worse again.
I let the city run a good 12 years (bringing us up to the year 100) and saved it. I wanted to get it good and stable. Interestingly enough I got the rolling abandonment (or flapping as I refer to it) on the East side again. No job zot. Traffic sim run. Abandon. Traffic sim run. Rebuild. Traffic sim run. Find a job. Traffic sim run. No job zot. Rinse and repeat. So commute time, volume, population all jittered slightly through the whole period but it is otherwise as stable as it can be.
Quote from: z on November 20, 2009, 01:02:00 PM
Yes, I would agree, but most of my testing of these properties was done with the max commute time fixed at its current level in Simulator Z. The effect of these properties still varied all over the place.
Don't know if this is relevant or not, but in this link
http://www.gamefaqs.com/computer/doswin/file/561176/23133
which is on "Transportation in SimCity 4" he says in it
QuoteThe commute works in adding up the total travel times of all the tiles used for a trip, taking into account multipliers for traffic intensity and busy intersections. The total is then rounded up to the nearest integer in minutes, and put in average with the rest of the totals that were drawn in that cycle.
I've read something similar in another topic, but can't now find the link to it :-[
I don't know about that particular quote, but I took a quick look through the rest of the document and found a number errors in it (some major). So I wouldn't rely on what's said there without confirmation.
Ditto what Z said. It was pre-rh, I think it was also pre anyone actually hexing the traffic controller.
Quote: As of Patch 2, there has not been any real algorithm to make your sim-motorists
understand which route is the "quickest."
Completely incorrect. As we all now know (due to many other peoples efforts) that it just worked so poorly with the .9 ph that it sure seemed to be true.
A lot of misinformation through the whole thing. It does show how far we've come.
I am not sure if he is speaking of the actual commute time or the display graph either. I am also not going to try to evaluate the correctness of either right now.
Does bring up a relevant point though.
In the last several posts where I am speaking about several different vars that have the words commute and time in them and I hope I have been careful enough in differentiating (my $5 word for the day) which one I am talking about when. I will go through and edit as needed later.
More test schtuff
I went ahead and cranked the old "trip starting cost by travel type" to 4.4 and running for a few years, I observed no difference whatsoever.
So I think we can conclude that it really should read "trip starting cost by travel type for fastest method preferred"
Moving along I put that back the way it was and I set the pedestrians starting cost under car preferred up to 4.1 and go run it a few years, which as expected all but terminated the bus.
So I have verified that all 3 are working, and by inference also that our travel type preferences all work.
Steve, someone, anyone...please let me know if y'all think I missed something.
Next for the fun stuff. WTH "Max mass transit strategy trip length" really means.
Quote from: ldog on November 21, 2009, 02:18:55 PM
Ditto what Z said. It was pre-rh, I think it was also pre anyone actually hexing the traffic controller.
Oh well
You win some, you lose some and some don't even make it over the goal ;D
Quote from: z on November 19, 2009, 11:50:33 PM
I am very curious about Max MT commute time, as my limited tests were not able to give me a completely satisfactory answer here. At this point, I believe it's the maximum length of any single MT segment, where "walking" counts as MT. But I haven't had the chance to fully test this out, so I will be interested to see what you find.
Well I've tried 4 (default), 6 (equal to default "regular" max), 12 (to see if it would go further than the regular max) and 1 (to see if it hurt MT)
So far I have not observed any effects from any changes. It
could be another unused var although I think perhaps I will need a different testbed.
While I was confidant in this testbeds suitability for the previous tests, I find it questionable for this one (although changing it to 1 really should have caused a noticeable change)
Quote from: ldog on November 21, 2009, 05:50:31 PM
Well I've tried 4 (default), 6 (equal to default "regular" max), 12 (to see if it would go further than the regular max) and 1 (to see if it hurt MT)
So far I have not observed any effects from any changes. It could be another unused var although I think perhaps I will need a different testbed.
While I was confidant in this testbeds suitability for the previous tests, I find it questionable for this one (although changing it to 1 really should have caused a noticeable change)
Yes, I never got any changes I could really pin down to that variable either, and I was thinking that there was a good chance that it was just unused as well. You might want to try setting it to zero - I would think that that should give you a pretty clear answer. If you've still got Sims using MT at that point, I think we can pretty safely call it unused. Your test using a value of one is certainly pointing in that direction.
Quote from: z on November 21, 2009, 05:56:51 PM
Yes, I never got any changes I could really pin down to that variable either, and I was thinking that there was a good chance that it was just unused as well. You might want to try setting it to zero - I would think that that should give you a pretty clear answer. If you've still got Sims using MT at that point, I think we can pretty safely call it unused. Your test using a value of one is certainly pointing in that direction.
Oh yeah, great idea :thumbsup: Glad I checked back here before I started setting up a new test.
Had no effect. I thought just to be extra sure that it maybe wasn't for the MT pref, I set everyone back to fastest.
Bus use dropped to what it was supposed to be (based on last fastest pref run) so once again the 0 MT had no effect.
Now I thought it odd that my average commute time actually jumped up .25 minutes on the graph, being as before we were on MT pref and now we were on fastest.
The city stabilized after 1 year at the new volume levels, although I let it run for 5 just to be sure. By the way, my scalar value is 0.041667 (1/24) am I correct in assuming that that should give me a 1:1 ratio and the value that you used in Sim Z was because it suited whatever you wanted to accomplish (which was not a 1:1)?
Also, I got a better look at my shortcutters, I have a few places near the local commercial where there is (crappy ascii art coming):
----- where - is road, c is commercial, r is residential and b is bus station
c-b-r
So I had some sims from that R worked at that C and well it made perfect sense for them to walk across the bus station. Which means the TE cost I used of 0.274286(.96/3.5) is somewhere between dead on accurate and less than the cost of going 2 more tiles. I bring this up since I had some mass service declines after changing the TE costs in Gridlockcity to similar values. Although I was testing with walking speeds of 1, which otherwise worked fine (I divided all other speeds by 4 (which actually made walking relatively faster), multiplied max commute by 4 (or 16 total since I was already x4...for a max ct of 96) and my volume levels remained exactly the same) but apparantly a TE cost of .96 is not something the game likes $%Grinno$%.
I guess this also is my segue way to my next phase of testing.
This is gonna be so not fun. If I cloned a bunch of stations with different times I would still need to modify ltext files for each as well or I would never know which is which right?
I am pretty positive a lot of people have said all over the forum stations have to be demolished and replopped everytime you make changes and my own experiences confirms that as well.
It still seems to me like no consensus was ever reached on what TE costs should be. For RTMT it is pretty cut and dry; .96/car speed of whatever network segment that station sits on.
Best I can determine .96 was what Chris found to be the value through experimentation? His methods did seem pretty thorough though (I think he did actually count tiles and such...going from memory at the moment), so I am pretty comfortable accepting it.
I know Cogeo found different values but he never says which sim he was using, which would of course totally change his results, since he gave direct values not formulas.
Anyways, I can see I am starting to ramble (yeah,yeah don't I always) into run-on sentences and I am fading. So I will go snuggle up to the wife and call it a night.
Tomorrow...we get to test...honey-do's ??? ... yes, honey-do's :( sometimes a mans got to do...what his woman says he's got to do... "$Deal"$
Hopefully I'll get a bit of simulator time in though. ;)
Quote from: ldog on November 21, 2009, 07:55:21 PM
By the way, my scalar value is 0.041667 (1/24) am I correct in assuming that that should give me a 1:1 ratio and the value that you used in Sim Z was because it suited whatever you wanted to accomplish (which was not a 1:1)?
The value of .04 sounds familiar; I determined the 1:1 ratio experimentally, as I wasn't sure what effect max commute time had on it. (It turns out that it has none.) This gives you a 1:1 ratio as long as there is no traffic with neighbor cities. The value in Simulator Z was adjusted so that it gives a value of approximately 1:1 for cities in a region with an average amount of intercity traffic; intercity traffic raises the average commute time way too much. There's a whole lot of variation here though, even in a single region, so the numbers can only be approximate for connected cities.
QuoteThis is gonna be so not fun. If I cloned a bunch of stations with different times I would still need to modify ltext files for each as well or I would never know which is which right?
I'm not quite sure what you're asking here.
QuoteI am pretty positive a lot of people have said all over the forum stations have to be demolished and replopped everytime you make changes and my own experiences confirms that as well.
It depends on which changes you make. If you're changing numbers like the capacity or the TSEC, then yes, you have to replop.
QuoteIt still seems to me like no consensus was ever reached on what TE costs should be. For RTMT it is pretty cut and dry; .96/car speed of whatever network segment that station sits on.
One point everyone agreed on is that you never want to have the TSEC be zero. My own feeling, after lots of experiments, is that things work out best if the TSEC is .96 divided by the speed of the fastest travel type that actually passes through the lot. You'll get some speedy pedestrians, but I've never seen this have an effect on the game. On the other hand, if you set the TSEC too low (e.g., for pedestrians), this can slow down MT enough to discourage the Sims from using it.
When doing these calculations, you don't have to worry about through subway traffic, as subways pass under stations rather than through them. This effect is actually simulated in SC4, and is the reason you don't see any subway to subway transit switches in standard TE lots.
Quote
Best I can determine .96 was what Chris found to be the value through experimentation? His methods did seem pretty thorough though (I think he did actually count tiles and such...going from memory at the moment), so I am pretty comfortable accepting it.
Yes, I believe that's true, but it's also possible to derive this number directly from the fundamentals. Each square is 16m, so a small tile is 1.024 km long. Assume you're traveling at 1 kph. That means it would take you 1.024 hours to cover a small tile. But there are 60 minutes in an hour, and 64 squares in a tile, so to get minutes per square, you have to multiply 1.024 by 60/64, or .9375. When you do this, you get exactly .96.
I think that this is the first time this number has been derived from theory; it's nice to see that it matches experiments.
QuoteI know Cogeo found different values but he never says which sim he was using, which would of course totally change his results, since he gave direct values not formulas.
Cogeo determined his results experimentally.
Quote from: ldog on November 21, 2009, 02:18:55 PM
I went ahead and cranked the old "trip starting cost by travel type" to 4.4 and running for a few years, I observed no difference whatsoever.
So I think we can conclude that it really should read "trip starting cost by travel type for fastest method preferred"
...
Next for the fun stuff. WTH "Max mass transit strategy trip length" really means.
The "
trip starting cost by travel type and the
Max mass transit strategy trip length rang bells or in my case links with me, and I ended up on the old
Sims 2 Modding Information Database in the section for "For any and all information for the Simcity4 modding crowd (MODD Squad etc.)" looking at the exemplars list, this is probably a repeat of information you already have ;D
http://old_wiki.modthesims2.com/FullList
Quote<property num="0xa92356bc" type="Float32" name="Trip Starting Cost by travel type" desc="Starting overhead cost in time for each travel type"></property>
<property num="0xea8c3cdb" type="Float32" name="Trip Starting Cost by travel type for Mass Transit" desc="Starting overhead cost in time for each travel type for mass transit preferred trips"></property>
Quote<property num="0xea7b5f06" type="Float32" name="Max Mass Transit Strategy Trip Length" desc="Max time in raw trip length that the mass transit preferred strategy will go using mass transit"></property>
:sleeping:
This corresponds to the XML file that's reference by Ilive's Reader, so this is what you see in the description pane of the Reader in the bottom right.
Quote from: z on November 21, 2009, 11:48:16 PM
This corresponds to the XML file that's reference by Ilive's Reader, so this is what you see in the description pane of the Reader in the bottom right.
Wait a minute...(yeah I know you mentioned the XML file before but it kinda slipped by me)
I guess I was under the impression it was directly read out of the data files, hence the references to "internal documentation"
The reader is pretty much just a specialized hex editor when you get down to it. I'll have to go poke around now.
Quote from: z on November 21, 2009, 08:46:26 PM
When doing these calculations, you don't have to worry about through subway traffic, as subways pass under stations rather than through them. This effect is actually simulated in SC4, and is the reason you don't see any subway to subway transit switches in standard TE lots.
??? I never thought about it that way. I thought it was just another mistake on Maxis part. I've actually changed some of the stations quite a bit. Although going through my file, I left the subway station alone. Possibly because the subway station is one that works inline and offline (you can make the track run through it or you can put it next to the track and let it connect).
Outside-to-Inside,All Sides,Walk,Walk
Outside-to-Inside,All Sides,Walk,Ride Subway
Inside-to-Outside,All Sides,Ride Subway,Walk
Inside-to-Outside,All Sides,Walk,Walk
Inside-to-Outside,All Sides,Walk,Ride Subway
So we have to walk in. Then we can walk out or take the subway out. We can also walk in and become a subway but then we can only walk out. That shouldn't work, and yet we know the stations work. Since the subway can't enter the switch; unless of course what you said is true ;)
Quote from: z on November 21, 2009, 08:46:26 PM
Yes, I believe that's true, but it's also possible to derive this number directly from the fundamentals. Each square is 16m, so a small tile is 1.024 km long. Assume you're traveling at 1 kph. That means it would take you 1.024 hours to cover a small tile. But there are 60 minutes in an hour, and 64 squares in a tile, so to get minutes per square, you have to multiply 1.024 by 60/64, or .9375. When you do this, you get exactly .96.
I think that this is the first time this number has been derived from theory; it's nice to see that it matches experiments.
I can make that even simpler. Derived from my formula from the other day (correctly stated of course)
16/16.666666666666666666666666666667= 0.96000000000000000000000000000038
:D
By the way, the other day when I said "oh, looks like Maxis tried to use MPH" that doesn't mean I think the sim works in MpH (it doesn't even work in KmpH) what I meant by that is when whoever over at Maxis sat down and decided to put the tile speeds in they probably sat there with a chart of speeds that were in MpH and plopped in the numbers. That is all I meant, nothing more, nothing lessQuote from: z on November 21, 2009, 08:46:26 PM
Cogeo determined his results experimentally.
I know. I don't know which traffic simulator he was using though. Very relevant as his observations would change greatly.
Quote from: catty on November 21, 2009, 10:29:48 PM
The "trip starting cost by travel type and the Max mass transit strategy trip length rang bells or in my case links with me, and I ended up on the old Sims 2 Modding Information Database in the section for "For any and all information for the Simcity4 modding crowd (MODD Squad etc.)" looking at the exemplars list, this is probably a repeat of information you already have ;D
http://old_wiki.modthesims2.com/FullList
:sleeping:
Yup, those are the props we were working with.
<property num="0xa92356bc" type="Float32" name="Trip Starting Cost by travel type" desc="Starting overhead cost in time for each travel type"></property> should be amended to read:
<property num="0xa92356bc" type="Float32" name="Trip Starting Cost by travel type" desc="Starting overhead cost in time for each travel type for fastest method preferred trips"></property>
And "0xea7b5f06" can go into the bin next to "0xca76013b" aka "trip length to minutes display multiplier" cause both props have the same effect. ;)
Today Steve and I had a chance to discuss a few things about speeds, commute time, tsec and trip starting cost via pms.
It was mostly further details and clarifications and some of the finer points.
For tonights experiments I decided to drill down a little more into trip starting costs.
They don't work like any of us thought.
It isn't in minutes or any other time units I can see.
I am not going to go into a lot of detail tonight. I did many short tests (this test city stabilizes itself to any changes I have made so far to the traffic simulator in about 3 passes, so not even a full year, although I always let it run for several)
I tested under both fastest preferred and MT preferred methods. I set both walking and car starting costs to 3, 4, 5, 6, 12, 112. Even setting it to 112 did not stop everyone from going to work. I was still seeing commutes of as much as 4 minutes minimum (because I am not going to sit there and count every tile nor figure out how congested it was; I did note plenty of car routes that went over 100 tiles by road, and there was congestion in places).
I did one last test with walking at 0 and car at 101.95 . Walking and bus shot way up, car shot way down. Even more extreme than previous tests, but it still didn't swing it all the way.
So it would seem the trip starting cost is some kind of weighting mechanism and not a penalty to travel time.
Quote from: ldog on November 23, 2009, 07:04:54 PM
Today Steve and I had a chance to discuss a few things about speeds, commute time, tsec and trip starting cost via pms.
It was mostly further details and clarifications and some of the finer points.
For tonights experiments I decided to drill down a little more into trip starting costs.
They don't work like any of us thought.
It isn't in minutes or any other time units I can see.
I am not going to go into a lot of detail tonight. I did many short tests (this test city stabilizes itself to any changes I have made so far to the traffic simulator in about 3 passes, so not even a full year, although I always let it run for several)
I tested under both fastest preferred and MT preferred methods. I set both walking and car starting costs to 3, 4, 5, 6, 12, 112. Even setting it to 112 did not stop everyone from going to work. I was still seeing commutes of as much as 4 minutes minimum (because I am not going to sit there and count every tile nor figure out how congested it was; I did note plenty of car routes that went over 100 tiles by road, and there was congestion in places).
I did one last test with walking at 0 and car at 101.95 . Walking and bus shot way up, car shot way down. Even more extreme than previous tests, but it still didn't swing it all the way.
So it would seem the trip starting cost is some kind of weighting mechanism and not a penalty to travel time.
Hey lenny,
This is a great area for you to explore, research and test.. I know we did some testing on this awhile back..
Steve probably mentioned this in your correspondence with him ... My recollection was it was much the same
as you described here in your post.. meaning in the tests i recall it had much less an effect on the game that I
thought it would myself... Definitely an area we need to re- explore i think . Steve mentioned in an e-mail to me
he wanted me to do some testing for him.. After reading your post here, Im hoping its in this area in which you
are now looking into here..
Thanks, brian
Quote from: b22rian on November 24, 2009, 03:36:28 AM
it had much less an effect on the game that I
thought it would myself... Definitely an area we need to re- explore i think . Steve mentioned in an e-mail to me
he wanted me to do some testing for him.. After reading your post here, Im hoping its in this area in which you
are now looking into here..
Oh, it has a very strong effect. My tests showed it can completely change the preference of walking/car. It just doesn't work anything like the xml describes.
I was very tired last night and I had limited time.
Sometime this week I will try to do more detailed experiments and make some pictures and maybe we can get a better idea of how it works.
Whatever it is Steve has you testing, I will be very interested to see the results of as well.
Hi Lenny and Steve and anyone else that's following this topic
No links today
I started opening up the traffic simulators to have a look at the various settings so I could follow comments like
QuoteI set both walking and car starting costs to 3, 4, 5, 6, 12, 112. Even setting it to 112
But with 29 traffic simulators in the latest NAM plus the original MAXIS version it gets a bit confusing, so for my own interest I added all the traffic simulator values and what simulator it belonged to, into a excel spreadsheet so I could see everything all on the one screen.
On the off chance that's useful to anyone else, I have zipped it up and attached it to this post
:)
Cat, you may want to collapse column A and put each simulator in it's own column (so A would just have the variable and following columns the values) would make it easier to read and make comparisons. I'd do it but I don't think I have upload rights.
The differences in easy/med/hard/low/high from each other are only in network capacities as far as I know (within A to A, Z to Z, etc)
Also the park and rides the only difference should be pedestrians are the only type able to reach destination. So you don't need to make yourself crazy looking between them.
Quote from: ldog on November 30, 2009, 11:51:15 AM
The differences in easy/med/hard/low/high from each other are only in network capacities as far as I know (within A to A, Z to Z, etc)
There are also slight differences in the value of the Customers/Traffic Noise Coefficient in the various levels of Simulator Z.
QuoteAlso the park and rides the only difference should be pedestrians are the only type able to reach destination. So you don't need to make yourself crazy looking between them.
These will also be disappearing as separate simulators, probably in the next NAM release; users will have the option to convert their simulator to Park & Ride via the NAM Tool (which they can do currently).
Thanks for the clarifications Steve.
I also have to say, you were right about the speeds.
Even though the only thing it is truly relevant for is TSEC, the whole thing was bugging me still. Also some tests Jason brought up, which were where the conclusions that the max commute time could be exceeded came from (if you thought speed was tiles/minute). I started thinking maybe the peds were actually being affected by the 1.3 CvS except the numbers still weren't right.
I did a bunch of tests to see how it worked out. I did walking speed of 10 on road, started with max commute of 1 and went to 2, 3, 4, 5. Then I went to 10. Then 20. Results came out fairly close to kph.
So I figured out a test to be almost exact. With a speed of 1.6 kph and a max commute of 60, that is 1600 meters, which divides neatly into 100 tiles.
And I got 100-101 tiles of road, no more. If it were 1.6 tiles/minute at 60 minutes that would be 96 tiles.
So now that we've got that settled, my next question is, how is TSEC affected by CvS?
Also, correction to the commute time graph, it is 25 to 1 not 24 to 1 like Chris thought. Actually his whole formula doesn't make sense since I can put in numbers that break it. So a traffic graph plot scale of .04 (which is 1/25) is precise provided there are no intercity commuters. Although the multiplier in the traffic simulator doesn't work as we all know, it is correct at 25. Perhaps Maxis used that value pre-RH? Does anyone have a non-deluxe version? I'd be interested to see the traffic simulator exemplar from it.
Quote from: ldog on November 30, 2009, 07:01:23 PM
Thanks for the clarifications Steve.
You're welcome!
Quote
I also have to say, you were right about the speeds.
I'm glad you discovered that on your own, experimentally. Chris came up with this experimentally as well. And now you've saved me a whole long post on the issue. ;D
QuoteSo now that we've got that settled, my next question is, how is TSEC affected by CvS?
Unfortunately, the TSEC is rather inflexible, so it can't accommodate the changes in speed dictated by the CvS. But in practice, the number of squares affected by the TSEC is small enough that the CvS can simply be ignored, and the nominal network speeds used.
Quote
Also, correction to the commute time graph, it is 25 to 1 not 24 to 1 like Chris thought. Actually his whole formula doesn't make sense since I can put in numbers that break it. So a traffic graph plot scale of .04 (which is 1/25) is precise provided there are no intercity commuters. Although the multiplier in the traffic simulator doesn't work as we all know, it is correct at 25. Perhaps Maxis used that value pre-RH? Does anyone have a non-deluxe version? I'd be interested to see the traffic simulator exemplar from it.
Yes, as I mentioned, the .04 was a familiar number to me; I remember at the time thinking that it was interesting that it was so exact. So I agree with you that this implies a 25 to 1 ration for the commute time graph. Chris was close; I think his experiments were not quite precise enough to get the exact number here. But he certainly got the .96 right on the head.
As we are now both in complete agreement about the various issues mentioned in these two posts, and our results were both obtained experimentally and independently, and the speeds in particular confirm Chris's experimental results, I hope that these results can be taken as being established fact from now on. It would certainly make things easier for others in the future. ;)
Quote from: z on November 30, 2009, 07:38:08 PM
Unfortunately, the TSEC is rather inflexible, so it can't accommodate the changes in speed dictated by the CvS. But in practice, the number of squares affected by the TSEC is small enough that the CvS can simply be ignored, and the nominal network speeds used.
That's what I was thinking as well. Unfortunately it makes things more complicated.
Cutting across corners is not so bad. However what I have seen I do think is something much more serious.
Y'all know how much I love Peg's work. Peg really likes his network-enabled lots. The marina in particular I have had trouble with. I have not edited the lots themselves to remove the network segments but I have tried removing all TS props from the buildings, I have also tried with various TSEC. Results are very inconsistent. I think it has something to do with not just the TS props but also which base lot was the template. The base marina itself as well as the parking lot I have gotten to behave but the yacht club, sport fishing and guest services nothing seems to work.
The problem is that all traffic will divert through the lot. So I have a parallel road running alongside. Congestion will be red on both ends but green in the middle. The lot will of course go red, and in some cases they will even abandon themselves due to commute time (these are CS job lots).
Quote from: z on November 30, 2009, 07:38:08 PM
As we are now both in complete agreement about the various issues mentioned in these two posts, and our results were both obtained experimentally and independently, and the speeds in particular confirm Chris's experimental results, I hope that these results can be taken as being established fact from now on. It would certainly make things easier for others in the future. ;)
It does, although you could have saved us both a lot of time and trouble if you'd have just cited your test results instead of a bunch of otherwise generally useless documentation :P
Still, I suppose it needed to be done, because reading through all the posts here, even though most people tend to agree with you about the speeds, none of them took it into account in their traffic simulator tests. People need to realize that 1km/h is not 1 tile minute, it is 1.04 tiles per minute. While that may seem close enough that I am just splitting hairs, as my tests show it is enough inaccuracy to make otherwise normal test results seem strange and this has no doubt caused many an argument on these forums. It also accounts for some of the discrepancies between different peoples tests.
As for my reality assessment about MPH. One last attempt at clarification. If we take all the vanilla speeds and pretend they are in mph, then convert them into kph, the speeds seem more or less realistic. Considering those speeds come out much closer to what has been used in A, B, Z you really can't disagree.
So firmly knowing the speeds were in km/h we can explain it either as they thought it best to scale it down because of the mapsize (except looking at the game as a whole it is safe to say Maxis had no friggin concept of the words "consistent scale"), the speeds they chose just made the simulator work better (which y'all don't seem to agree with),
or (and this is my personal favorite) the meathead that put the speeds into the simulator screwed up and forgot to convert his mph to km/h.
Just like we can make up some explanation that stretches suspension of disbelief even more (like Lucas did) for why Han Solo bragged he could do the Kessel run in less than 12 parsecs, even though the parsec is a unit of distance not time, instead of just saying "hey, he was in the bar for hours, he was drunk out of his mind and he didn't know what he was saying"
At any rate, yes, children, speeds are in km/h, now let me sing you a song about it...
Say! Hey everybody, have you seen my ba..." errr...nm [/Chef impression]
Quote from: ldog on November 30, 2009, 07:01:23 PM
Perhaps Maxis used that value pre-RH? Does anyone have a non-deluxe version? I'd be interested to see the traffic simulator exemplar from it.
As requested the Simcity 4 Traffic Simulator Exemplar Pre-RushHour
ParentCohort 0x00000000,0x00000000,0x00000000
Exemplar Type 0x00000010 Uint32 0 Simulator
Exemplar Name 0x00000020 String 0 Traffic Simulator
Monthly Traffic Density Reduction 0x29136788 Float32 0 0
Traffic Volume Per Population 0x491332E6 Float32 0 2
Max speed by Network for walking 0x491332E7 Float32 8 3.5,0,0,3.5,0,0,0,0
Max speed by Network for driving 0x491332E8 Float32 8 31,0,82,21,0,0,0,0
Max speed by Network for a bus 0x491332E9 Float32 8 46,0,100,31,0,0,0,0
Max speed by Network for a train 0x491332EA Float32 8 0,110,0,0,0,0,0,0
Max speed by Network for a truck 0x491332EB Float32 8 31,0,82,21,0,0,0,0
Max speed by Network for a frt train 0x491332EC Float32 8 0,150,0,0,0,0,0,0
Max speed by Network for subways 0x491332ED Float32 8 0,0,0,0,0,0,0,150
Travel strategy percent WealthNone 0x4953E8A3 Uint8 3 0x00,0x00,0x64
Travel strategy percent Wealth$ 0x4953E8A4 Uint8 3 0x50,0x14,0x00
Travel strategy percent Wealth$$ 0x4953E8A5 Uint8 3 0x1E,0x00,0x46
Travel strategy percent Wealth$$$ 0x4953E8A6 Uint8 3 0x0A,0x50,0x0A
Freight traffic scaling factor 0x49A2E8BE Float32 0 0.05
Nearest Destination Attractiveness 0x4A678060 Float32 0 0.09
Monthly cost for network tile 0x6A84493E Float32 8 0.1,0.03,0.5,0.05,0,0,0,0.30000001
Max roads funding percent 0xA92356AE Float32 0 120
Max mass transit funding percent 0xA92356AF Float32 0 120
Damaged road extra step cost 0xA92356B0 Float32 0 0.1
Income per tile by travel type 0xA92356B1 Float32 7 0,0,0.001,0.001,0,0,0.001
Mass Transit Usage Chance 0xA92356B2 Uint8 0 0x64
Network Traffic Capacity 0xA92356B3 Float32 8 1000,3000,4000,100,0,0,0,3000
Travel type generates traffic 0xA92356B4 Bool 7 False,True,False,True,True,True,True
Travel type can reach destination 0xA92356B5 Bool 7 True,True,False,False,True,True,False
Maximum distance from origin to network 0xA92356B8 Uint32 0 0x00000001
Congestion vs Speed 0xA92356B9 Float32 8 0,1,1,1,2,0.64999998,3,0.30000001
Commute trip max time 0xA92356BA Float32 0 6
Intersection and Turn Capacity Effect 0xA92356BB Float32 3 0.69999999,0.80000001,0.89999998
Trip Starting Cost by travel type 0xA92356BC Float32 7 0,0.40000001,0,0,0,0,0
Job Scaling Constant 0xA92356BD Float32 0 1.20000005
Population Background Traffic 0xA92356BE Float32 3 0.05,0.2,0.2
Travel type affected by traffic 0xA92356BF Bool 7 False,True,True,True,True,True,True
Transit Switch Entry Cost vs. Budget 0xCA5F7821 Float32 4 0,2,100,1
Trip Length to Minutes Display Multiplier 0xCA76013B Float32 0 25
Trip Starting Cost by travel type for Car Pref 0xCAD64136 Float32 7 0.1,0,0,0,0,0,0
Max Mass Transit Strategy Trip Length 0xEA7B5F06 Float32 0 4
Trip Starting Cost by travel type for Mass Transit 0xEA8C3CDB Float32 7 0,1.95000005,0,0,0,0,0
Enjoy
:)
thanks a lot Catty &apls
this is really appreciated and quite interesting too I might add..
also i appreciate all the hard work you have done research wise in making
this an even more interesting thread, than it already is..
Brian
Thanks once again Cat.
So nothing was different, except of course what was added in RH. My curiosity is satisfied at least. Mostly. I wonder if some of the unused vars were used back in the day. Not really important I guess. Although it might explain why some statements made by early pioneers which we know are wildly inaccurate might not have been at the time. :blahblah: (look ma, I found more smileys; they even made one especially for me)
Just to be a little extra sure and also to see that the CvS works proper (at least at 0% congestion anyway) I repeated last nights final test with cars tonight.
1.6 km/h x 1.3 = 2.08 km/h
2080 m / 16 m = exactly 130 tiles
How far were we willing to travel by car in 1 hour? Exactly 130 tiles.
It's like...science...and...stuff ;)
So anyways...(yeah, I like saying that, a lot :P )
Being as I got a disc from our friend in Hawaii last night, it is time to install Capitalis and see what we can learn.
So regularly scheduled programming will be interrupted for a bit.
I know, I know...what will all y'all do with all that extra freetime on your hands.
&opr
I wonder who's that friend. ()what()
I'm glad that you'll be working on my region. I haven't had the time to work on anything Simcity since last Wednesday and I won't have time until at least next week Monday.
So I figure this thread is past due for an update. (skip down to the bold part if you want to bypass my off-topic rambling and go directly to my on-topic rambling :P )
I'm sure y'all have no doubt seen a few posts in Z's threads (because it is a given that anyone interested in the subject matter here is interested in the subject matter there as well) some of which would carry on into here but there is no point reposting them here as well.
Not much to say about Capitalis. So far I haven't found anything different than Z but I still haven't spent as much time testing with it as it deserves. Intercity commutes throw quite a monkey wrench into the works in general. Things I can easily observe and duplicate with 100% certainty go out the window the minute we add a neighbor city to the mix. In short I don't feel I am able to comment with any accuracy at present time.
I added East Gridlock along next to Gridlockcity so I could learn a bit more in my own sandbox. What I did wind up quickly learning about was a bit more about how the census and workforce drives work. No new discoveries here, it just gives me a better understanding of a lot of what Tage and Nate do, and I actually understand what is said in the CAM related discussions now.
Other things learned along the way that really have nothing to do with traffic. Education and healthcare facilitys are quite inadequate in capacity; even with no CAM and no custom buildings. Recycling center even though the efficiency icon never moves and the numbers reported are useless, they do indeed lose efficiency if you don't plop another down every 25k pop (which also should be raised). Megalots and crime is a joke. Even with a deluxe station plopped down next to them the crime is out of hand. This is even still after modding them to be a bit more effective. Once again nothing new here; it just reinforces points others have made.
Getting back to traffic I've been thinking about capacity more lately. For one thing getting more skyscrapers in really shifts the balance. For another recent discussions with Steve and also some recent rereading of old posts got me more to thinking about reality and how it applies (as well as how it doesn't apply) here. I'm not going to link any of them; most of y'all are no doubt familiar with the relevant threads. One old post that was particularly interesting for network capacity was Jason's thoughts on capacity in the release thread for A&B. It helped me visualize and break down capacity a bit further for myself. Now as Steve is quick to point out, in the realworld increasing speed increases volume and he is quite correct (I may not know jack about traffic engineering but I know a little bit about physics ;) )
Speaking strictly about cars (well and I guess trucks, but not buses) for the moment; a network segment is 16 meters long. That means at a deadstop we can only fit about 3 cars per lane. Now conveniently our lowest speed is 30% (CvS) so for arguments sake let's say that at 0% congestion (of course 1.3 speed is generally agreed upon so I will have to go back and fix this later) that sims don't tailgate like the rest of us and maintain something of that proper interval Jason mentions so we only have 1 car at a time per lane per tile. That way when we go overcapacity and slow down we can assume people start crawling up each others tailpipes and then we can have more cars on that segement without violating the time-space continuum. Makes sense too. At 85mph (yeah, I got a lead foot) I try to keep as far away as possible from the car in front of me (and I get out of the way for the jerk behind me if he isn't so mindful; and when is he ever ::) ) yet the more traffic and the slower we are going the smaller an interval I will keep. At 5mph I will ride the next guys arse because a 5 car interval at that speed is just stupid and tends to inspire roadrage in the people around you. With me so far? Good.
Now as y'all remember 1 Km/h is 1.04 tiles per minute. For arguments sake lets just say 1 tile. So we've got 1 car per minute per Km/h of speed. Or 60 cars per hour or 1440 cars per day. Still with me? So with a speed of 50 on a 2 lane network we are talking 6,000 cars per hour. Now if we hit full congestion we are at 30% speed, or 15 km. At that speed we could have only 1800 cars per hour, but since we close ranks we can fit about 5400 cars, and I guess that is close enough that we can fudge the rest (besides none of the preceeding calculations were precise either...I also still haven't corrected for 1.3 speed CvS...in fact that makes it worse, because we actually start at 65 km/h and so 7800 cars). Of course one of the problems with that is to get to that amount of congestion we generally need to exceed network capacity greatly. Quite the paradox on our hands.
Of course how does the game see this? Well let's see. Once a car passes through a network tile per simulator run it is there (as far as congestion goes) if it passes the same tile on the trip home, it is there twice. The game takes the total amount of cars passing through a segment per run and calculates congestion as if they were all present at the same time (at least I think it does; it is possible the return trip counts for display but not actual congestion, or doesn't count until the next run at least, who knows). Not very realistic I imagine. Especially when you are simultaneously going to and coming from work. As far as I can tell (both going by what seems to be generally accepted here as well as my own observations) network capacity in SC4 is per day. This means realisticly we could use much higher numbers, but then of course it also becomes much harder to get our CvS curve to do its job.
Then of course we have to think about population density. Especially since I think once again it is agreed that population density in SC4 is much higher than reality. Yet, traffic only calculates 2 trips. Home to work. Work to home. No other trips. The non-working members of the household don't ever go anywhere either. Maybe they even each other out. I know all the little bast...*cough*...darling children on schoolbuses and teenagers with cars going to HS, stupid bit...*cough*...soccer moms driving to/from school and shopping and wherever else they go all day cause plenty of traffic around here. There is a very noticeable difference in traffic patterns depending if school is in or out (note to self: do not buy next house where single main artery is shared with large highschool)
So what makes some sense then? &Thk/( We could take it as a function of our max commute time, or our max commute time*2, or maybe how many minutes it would take to cross a large (game large) city or just what we consider a reasonable commute period going at said speed. I don't know (yet).
It is something to think about.
I have gotten way too behind in this thread. At least that matches everything else in my SC4 work. ::)
Quote from: ldog on November 30, 2009, 08:53:58 PM
Y'all know how much I love Peg's work. Peg really likes his network-enabled lots. The marina in particular I have had trouble with. I have not edited the lots themselves to remove the network segments but I have tried removing all TS props from the buildings, I have also tried with various TSEC. Results are very inconsistent. I think it has something to do with not just the TS props but also which base lot was the template. The base marina itself as well as the parking lot I have gotten to behave but the yacht club, sport fishing and guest services nothing seems to work.
The problem is that all traffic will divert through the lot. So I have a parallel road running alongside. Congestion will be red on both ends but green in the middle. The lot will of course go red, and in some cases they will even abandon themselves due to commute time (these are CS job lots).
I addressed this a little in my PM to you, but I'll expand on it here. Basically, such lots are intrinsically problematic, since what needs to be done to prevent shortcutting depends the environment in which they're placed.
But I don't understand the abandonment due to commute time - that's a property of residential lots, and you said these were CS job lots. ()what() If there's only one network present, it should be possible to set a proper TSEC for the lot. But if there are two or more networks, you may be out of luck.
QuoteAs for my reality assessment about MPH. One last attempt at clarification. If we take all the vanilla speeds and pretend they are in mph, then convert them into kph, the speeds seem more or less realistic. Considering those speeds come out much closer to what has been used in A, B, Z you really can't disagree.
Yes I can. ;D It's true that the pedestrian speed of 3.5 and the car speed of 31 sound quite reasonable for speeds. And 31 mph quite conveniently translates to 50 kph - exactly the speed used in Simulator Z. But then you get to highways, with a speed of 82, which is a bit fast for a highway. But it's when you hit the rails that this theory really fails. You end up with subways and el rail at 150 mph, which is more than twice the maximum speed of these vehicles. But there is a reason that these numbers are spread out like this, which I'll explain in excruciating detail in an upcoming post.
Quote from: ldog on December 10, 2009, 09:24:03 PM
Speaking strictly about cars (well and I guess trucks, but not buses) for the moment...
Yes, you are correct here, and I had considered in my calculations that due to car spacing, speed really isn't directly proportional to volume. However, how much it differs, it's hard to say, and it varies from city to city based on driving habits. In Boston, they drive almost bumper-to-bumper at highway speeds. If you're more than one car length from the car in front of you, someone will cut in. So for simplicity's sake, I've chosen to ignore the spacing effect. Considering that stoplights and stop signs aren't emulated properly at all in SC4, and worst of all, network speeds can drop no more than 30% of nominal, I don't think the spacing effect has much of an impact. The simulator as a whole just isn't that precise.
QuoteOf course how does the game see this? Well let's see. Once a car passes through a network tile per simulator run it is there (as far as congestion goes) if it passes the same tile on the trip home, it is there twice. The game takes the total amount of cars passing through a segment per run and calculates congestion as if they were all present at the same time (at least I think it does; it is possible the return trip counts for display but not actual congestion, or doesn't count until the next run at least, who knows).
Your initial statement is correct. The return trip does count toward congestion.
QuoteAs far as I can tell (both going by what seems to be generally accepted here as well as my own observations) network capacity in SC4 is per day.
This is correct.
Quote...
So what makes some sense then? &Thk/( We could take it as a function of our max commute time, or our max commute time*2, or maybe how many minutes it would take to cross a large (game large) city or just what we consider a reasonable commute period going at said speed. I don't know (yet).
It is something to think about.
I'm afraid you lost me here. What's the "it" you're referring to? ()what()
Quote from: z on December 11, 2009, 12:28:25 AM
But I don't understand the abandonment due to commute time - that's a property of residential lots, and you said these were CS job lots.
&idea I wonder if those particular lots got some resi prop mixed in. Really it is the only thing left to explain their strange behavior.
Quote from: z on December 11, 2009, 12:28:25 AM
Yes I can. ;D It's true that the pedestrian speed of 3.5 and the car speed of 31 sound quite reasonable for speeds. And 31 mph quite conveniently translates to 50 kph - exactly the speed used in Simulator Z. But then you get to highways, with a speed of 82, which is a bit fast for a highway. But it's when you hit the rails that this theory really fails. You end up with subways and el rail at 150 mph, which is more than twice the maximum speed of these vehicles. But there is a reason that these numbers are spread out like this, which I'll explain in excruciating detail in an upcoming post.
I knew you would :P
I did mention the sub and el, think I mentioned the highway too :P
I'm looking forward to the excruciating details...sounds...painful :thumbsup:
Quote from: z on December 11, 2009, 12:28:25 AM
Yes, you are correct here, and I had considered in my calculations that due to car spacing, speed really isn't directly proportional to volume. However, how much it differs, it's hard to say, and it varies from city to city based on driving habits. In Boston, they drive almost bumper-to-bumper at highway speeds. If you're more than one car length from the car in front of you, someone will cut in. So for simplicity's sake, I've chosen to ignore the spacing effect. Considering that stoplights and stop signs aren't emulated properly at all in SC4, and worst of all, network speeds can drop no more than 30% of nominal, I don't think the spacing effect has much of an impact. The simulator as a whole just isn't that precise.
It isn't a matter of the simulator not being that precise; it's more like the simulator is way out in left field. My guess is network capacity in the real world and network capacity in the simulator have almost nothing to do with each other. The spacing effect to me is more just a way to rationalize it somewhat.
Quote from: z on December 11, 2009, 12:28:25 AM
Your initial statement is correct. The return trip does count toward congestion.
This is correct.
I'm afraid you lost me here. What's the "it" you're referring to? ()what()
My bad, was getting sleepy towards the end.
The "it" is trying to figure out some kind of formula for "somewhat realistic" network capacity for SC4.
For example even though capacity is per day, one could say our day is however many minutes our max commute is. So Simulator Z 1.3 with a max commute of 600 has a 10 hour "day". Of course since the return trip doesn't count towards time but does count towards congestion, we may or may not want to consider the "day" double max commute or 20 hours in this case. We could also look at it as a function of how many minutes it would take to cross an entire city on given network and derive some value from that. And then quite possibly we might just ignore the time completely because in the end it comes down to what works. There still has to be some ratio to define relationships to keep given simulator consistent with itself.
Oh, almost forgot. Since I had shared it with Steve via pm but forgot I never posted it.
Been playing with intersection and turn capacity effect. Intersections have a very strong effect on congestion (in the real world). Those effects also reach out pretty far away from the intersection itself. So I wanted to see if I could spread the wealth a bit and I added in extra values. First one, then two. So I wound up with a value of: 1.000000,0.600000,0.700000,0.800000,0.900000
As we all know, the intersection tile itself capacity is already halved (at least for an intersection of same networks) so that 1.0 can be read as 0.5, so we go from half up by 10% each tile away up to 90%. I'm sure the values could use more work but the important thing is it doesn't break anything and seems to work properly. I've been using those values for a few weeks now. I have plenty of intersections that overlap each other and it would seem the game just properly applies the highest penalty applicable.
Quote from: ldog on December 11, 2009, 08:29:09 AM
My guess is network capacity in the real world and network capacity in the simulator have almost nothing to do with each other.
This is pretty much correct; a lot of this follows straight from the fact that population densities in SC4 are much higher than in the real world. Also, a lot of deciding which network capacity is appropriate has to do with personal preference; how much congestion does the player want to see?
QuoteThe spacing effect to me is more just a way to rationalize it somewhat.
But when you have spacing that varies by city, and in some cities (such as Boston) highway spacing is not really different from road spacing, I don't think you can come up with a general formula.
Quote
The "it" is trying to figure out some kind of formula for "somewhat realistic" network capacity for SC4... And then quite possibly we might just ignore the time completely because in the end it comes down to what works.
After spending a lot of time trying to do the former, I ended up settling on the latter. I don't think the former approach really works, especially when you take into account varying user preferences.
QuoteThere still has to be some ratio to define relationships to keep given simulator consistent with itself.
Yes, and it turns out that that relationship is far more important than we suspected, as I'll be showing in that post that I mentioned earlier.
Quote from: ldog on December 11, 2009, 08:27:18 PM
Been playing with intersection and turn capacity effect. Intersections have a very strong effect on congestion (in the real world). Those effects also reach out pretty far away from the intersection itself. So I wanted to see if I could spread the wealth a bit and I added in extra values. First one, then two. So I wound up with a value of: 1.000000,0.600000,0.700000,0.800000,0.900000
I tried this too, although with lower values. At first, it seemed to work fine. But when I looked at the congestion map and the actual network usage more closely, I found problems. Road squares that had only a few Sims on them (and no subway underneath) on no subway underneath were showing up as completely red. I've long known that the congestion map is slightly buggy, sometimes showing congestion where there is none, or vice versa. Expanding this array apparently exacerbates this problem, at least with the numbers I tested. I would have liked to use a larger array, but in light of these results, I'm going to stick with the current one, at least for now.
Quote from: z on December 11, 2009, 10:08:11 PM
This is pretty much correct; a lot of this follows straight from the fact that population densities in SC4 are much higher than in the real world. Also, a lot of deciding which network capacity is appropriate has to do with personal preference; how much congestion does the player want to see?
Although I agree with everything else you said here; I don't think population density has anything to do with why network capacity SC4 != network capacity real world. Of course I could be wrong; like I said I don't know enough about traffic engineering. So I am looking at this from a general physics view; which I am also no expert in but I know enough that it makes sense (at least to me)
Quote from: z on December 11, 2009, 10:08:11 PM
But when you have spacing that varies by city, and in some cities (such as Boston) highway spacing is not really different from road spacing, I don't think you can come up with a general formula.
I've driven a lot of places in the continental US; It doesn't vary much honestly. I'm sure we were all taught various rules of thumb about keeping a proper interval between us and the car in front of us; and yet I would say that very few people follow those rules. Tailgating, regardless of speed, sadly is not the exception; it is the rule. Being SC4 is somewhat more utopian it could be used.
But ok, lets forget spacing...so 3 cars per tile not moving. Now let's look at worst case scenario in the traffic sim, using a road speed of 50 as our example again.
So 50*0.3= 15. We can only get 90 cars per minute through that road tile (and that is per lane so assuming both directions). That is the absolute maximum. 129,600 cars in 24 hours if that road were used nonstop (and of course with no intersections; no stopsigns or lights, etc). We'd also need to divide it by 3 or 2.5 (depending where your 0.3 mark is) or maybe even 4 or more (because as we've seen capacity is actually unlimited)
Quote from: z on December 11, 2009, 10:08:11 PM
After spending a lot of time trying to do the former, I ended up settling on the latter. I don't think the former approach really works, especially when you take into account varying user preferences.
Yes, and it turns out that that relationship is far more important than we suspected, as I'll be showing in that post that I mentioned earlier.
Well you can't take varying user preferences into account in 1 traffic simulator exemplar; they either prefer those settings or they prefer some other.
I'll be looking forward to that post.
Quote from: z on December 11, 2009, 10:08:11 PM
I tried this too, although with lower values. At first, it seemed to work fine. But when I looked at the congestion map and the actual network usage more closely, I found problems. Road squares that had only a few Sims on them (and no subway underneath) on no subway underneath were showing up as completely red. I've long known that the congestion map is slightly buggy, sometimes showing congestion where there is none, or vice versa. Expanding this array apparently exacerbates this problem, at least with the numbers I tested. I would have liked to use a larger array, but in light of these results, I'm going to stick with the current one, at least for now.
That's too bad. Like I said I only eyeballed it, I didn't write down numbers and whip the calculator out to be sure. It is possible mine doesn't work properly either, and of course it is possible that the actual values used are the problem. I'm a bit confused about the subway bit; I'm going to chalk it up to a typo and you just typed it twice. So it should read "road squares that had only a few sims on them and no subway underneath were showing up as completely red". Correct?
By the way, do subway intersections get affected the same way as any other intersection?
Can you tell me more about the congestion map bugginess? My experiments with the CvS showed me that the congestion map is strongly tied to CvS values.
I'm also still very anxious to hear more about what you meant by applying only to one side (in your last pm).
Quote from: ldog on December 12, 2009, 08:14:30 AM
Although I agree with everything else you said here; I don't think population density has anything to do with why network capacity SC4 != network capacity real world.
It's simply that since the buildings contain more people, the networks have to carry more people.
QuoteBut ok, lets forget spacing...so 3 cars per tile not moving.
That's RL cars. But over in my development thread, I showed that the actual capacity of all networks is infinite, and you concurred. I believe I mentioned there that that means that vehicles take up no space, because there is no limit to the number of vehicles you can have on a given tile. (Yes, that means that vehicles in SC4 can violate the Pauli exclusion principle. :o) To have a consistent world view inside the game, the fact that vehicles actually have zero size has to be taken into account in all calculations.
QuoteI'm a bit confused about the subway bit; I'm going to chalk it up to a typo and you just typed it twice. So it should read "road squares that had only a few sims on them and no subway underneath were showing up as completely red". Correct?
Yes; apparently the rate of brain cell death continues to accelerate. &mmm
QuoteBy the way, do subway intersections get affected the same way as any other intersection?
I'm pretty sure they don't. Each network has a flag indicating whether or not it is subject to the intersection effect, but that flag is somewhere outside of the traffic simulator.
QuoteCan you tell me more about the congestion map bugginess? My experiments with the CvS showed me that the congestion map is strongly tied to CvS values.
When it's working properly, it is strongly tied to those values. But occasionally, certain squares will show something like five Sims on them, yet be completely red, and stay red through many iterations of the traffic simulator. Or a square may be at 150% of network capacity, and show up as completely green. These cases are usually rather rare, though.
You might wonder what happens when you have multiple networks passing through the same square. From what I have seen, the congestion display shows the congestion of the most congested network on that square, which makes sense.
QuoteI'm also still very anxious to hear more about what you meant by applying only to one side (in your last pm).
What I meant was that the intersection effect applies only to the squares leading up to the intersection, and not to the squares leading away from it. You need either one-way roads or avenues or highways to see this clearly, but it applies to two-way roads as well.
Quote from: z on December 12, 2009, 10:05:57 PM
It's simply that since the buildings contain more people, the networks have to carry more people.
That doesn't change the nature of capacity; it just means more is needed.
Quote from: z on December 12, 2009, 10:05:57 PM
That's RL cars. But over in my development thread, I showed that the actual capacity of all networks is infinite, and you concurred. I believe I mentioned there that that means that vehicles take up no space, because there is no limit to the number of vehicles you can have on a given tile. (Yes, that means that vehicles in SC4 can violate the Pauli exclusion principle. :o) To have a consistent world view inside the game, the fact that vehicles actually have zero size has to be taken into account in all calculations.
Yes, but at the same time it makes this all kind of pointless. They couldn't cause congestion if they take up no space either.
Traffic engineering is complicated enough; Quantum mechanics is where I draw the line. :P
(I know, I know, I started it with the time dilation joke :'( )
Quote from: z on December 12, 2009, 10:05:57 PM
I'm pretty sure they don't. Each network has a flag indicating whether or not it is subject to the intersection effect, but that flag is somewhere outside of the traffic simulator.
When it's working properly, it is strongly tied to those values. But occasionally, certain squares will show something like five Sims on them, yet be completely red, and stay red through many iterations of the traffic simulator. Or a square may be at 150% of network capacity, and show up as completely green. These cases are usually rather rare, though.
You might wonder what happens when you have multiple networks passing through the same square. From what I have seen, the congestion display shows the congestion of the most congested network on that square, which makes sense.
Interesting. I have skimmed all the data display tweaking posts of course but I haven't delved deeply into them yet.
I don't think I've seen the effects you describe but then I haven't been on the lookout for them and it is probably easy to miss.
I have been wondering about that, especially with the subway under road if it were added or seperate. I try to avoid running them directly under road so I can view each.
Quote from: z on December 12, 2009, 10:05:57 PM
What I meant was that the intersection effect applies only to the squares leading up to the intersection, and not to the squares leading away from it. You need either one-way roads or avenues or highways to see this clearly, but it applies to two-way roads as well.
&Thk/( This would be a good thing right? So if you had an intersection of 2 OWR the capacity is only reduced on the 2 sides leading in?
Except how do you tell on a 2 way road which side is which? Even more complicated when you have an intersection of 2 2 ways, which makes it 4 ways.
Quote from: ldog on December 13, 2009, 09:55:51 AM
That doesn't change the nature of capacity; it just means more is needed.
Or more MT... that's how I prefer to see it... ::)
Consider Manhattan without subways... $%Grinno$%
In response to my point about the intersection effect being one-sided...
Quote from: ldog on December 13, 2009, 09:55:51 AM
&Thk/( This would be a good thing right?
It's hard to say. In RL intersections, the effect is asymmetrical, but it is there - vehicles don't immediately resume their top speed as soon as they leave the intersection. But on the other hand, the slowdown is much greater leading into the intersection.
QuoteSo if you had an intersection of 2 OWR the capacity is only reduced on the 2 sides leading in?
That's correct.
QuoteExcept how do you tell on a 2 way road which side is which? Even more complicated when you have an intersection of 2 2 ways, which makes it 4 ways.
You do this by finding intersections where morning and evening commute traffic is asymmetrical, and by using the traffic volume view and the route query tool, you can verify this effect.
Quote from: RippleJet on December 13, 2009, 10:01:48 AM
Or more MT... that's how I prefer to see it... ::)
Me too.
Quote from: RippleJet on December 13, 2009, 10:01:48 AM
Consider Manhattan without subways... $%Grinno$%
We ()borg() can't! The city grinds to a halt. If they were gone and there were no replacement there'd be more abandonment than you can shake a .09 PH at!
Quote from: z on December 13, 2009, 09:09:56 PM
In response to my point about the intersection effect being one-sided...
It's hard to say. In RL intersections, the effect is asymmetrical, but it is there - vehicles don't immediately resume their top speed as soon as they leave the intersection. But on the other hand, the slowdown is much greater leading into the intersection.
D'oh! Yeah, that's true. I observe it every day on my 26 mile each way commute. The light is green and yet there we sit for many seconds, because these :angrymore: southerners (love all y'all really I do; just not behind the wheel) cannot find the gas pedal in a timely fashion. When the intersection is really backed up if you are enough cars back you literaly sit there when the light is green and start moving towards it when the light is red ::) The lights seem to be so poorly timed that the only way I ever see a greenwave effect is if I am the lead car at the last light and no one gets in my way. ()sad()
Quote from: z on December 13, 2009, 09:09:56 PM
You do this by finding intersections where morning and evening commute traffic is asymmetrical, and by using the traffic volume view and the route query tool, you can verify this effect.
I've seen it, especially more noticeable with my longer array. :-\ I guess since I didn't crunch any numbers I assumed it was just because the assymetrical numbers (I did run querys, just not add them, multiply by intersection effect and check against CvS) were not causing the same congestion. I'll have to check it out, but good find :thumbsup:
Oh, just a thought from above on capacity, since our vehicles don't take up any space, should they even be required to slowdown at intersections?
And now we bring you simulator Q, the first and only traffic simulator built entirely using Quantum mechanics! $%Grinno$%
No southerners were permanently harmed in the making of this post
Was looking through some of my "patches" for things that since there is no doubt I will use them always I am just going to directly modify the games dat files directly.
The fix for the Grand railroad station is contained in an LUA file with many interesting things. Among them are tuning constants for just about the entire game. I thought these were of direct interest:
--TRANSPORTATION
tuning_constants.RAIL_CONGESTION_HIGH = 80
tuning_constants.LONG_COMMUTE = 100
tuning_constants.SHORT_COMMUTE = 10
tuning_constants.TRAFFIC_CONGESTION_VERY_HIGH = 320
tuning_constants.TRAFFIC_CONGESTION_HIGH = 220
tuning_constants.TRAFFIC_CONGESTION_MEDIUM =140
tuning_constants.TRAFFIC_CONGESTION_LOW =40
tuning_constants.AIRPORT_EFFICIENT_LOW =50
tuning_constants.AIRPORT_EFFICIENT_MEDIUM =75
tuning_constants.AIRPORT_EFFICIENT_HIGH=90
tuning_constants.STATION_UTILIZATION_LOW =5
tuning_constants.STATION_UTILIZATION_MEDIUM =30
tuning_constants.STATION_UTILIZATION_HIGH=60
Oh and also this one:
tuning_constants.MAX_FREIGHT_TRIP_LENGTH = 256
Now whether they work or not is another matter, and then what the effects of adjusting them if they do work might be...
I, for one, am interested to see if these changes in these constants result in anything constructive. :thumbsup:
Those are just constants used in advisor records (e.g. those fluff news that appear in the news ticker window).
As an example,
the following is an extract from the LUA advisor script adv_transportation.lua
(SimCity_1.dat, TGI 0xCA63E2A3, 0x4A5E8EF6, 0xFF7ED4B5):
------------ Advice record ----
--Traffic Jam On Side Street Has Local Sims Stewing
a = create_advice_transportation('8bf09867')
a.trigger = "game.l_street_congestion_h > tuning_constants.TRAFFIC_CONGESTION_VERY_HIGH+15"
--game.l_street_congestion_h > high
a.frequency = tuning_constants.ADVICE_FREQUENCY_VERY_LOW
a.timeout = tuning_constants.ADVICE_TIMEOUT_MEDIUM
a.title = [[text@abf03875 Traffic Jam on Side Street Has Local Sims Stewing]]
a.message = [[text@6bf03879 I've received complaints from several sims on <a href="#link_id#game.camera_jump_and_zoom(game.l_street_congestion_h_subject,camera_zooms.MAX_IN)">this street</a> that the traffic has become unbearable. For some reason, more and more drivers find it necessary to take this route to get where they're going - endangering local pedestrians. You could consider <a href="#link_id#game.tool_plop_network(network_tool_types.ROAD)">upgrading the street to a road</a> to handle the extra traffic, or you could encourage those drivers to take an alternative route by <a href="#link_id#game.tool_plop_network(network_tool_types.ROAD)">building a new road</a> or <a href="#link_id#game.tool_plop_network(network_tool_types.AVENUE)">avenue</a> nearby as a bypass.]]
a.priority = tuning_constants.ADVICE_PRIORITY_MED_HIGH
a.mood = advice_moods.BAD_JOB
------------ Advice record ----
--Local Road Reaches Limit - A Chaos of Cars
a = create_advice_transportation('2bf09aa1')
a.trigger = "game.l_road_congestion_h > tuning_constants.TRAFFIC_CONGESTION_VERY_HIGH"
--game.l_road_congestion_h > high
a.frequency = tuning_constants.ADVICE_FREQUENCY_LOW
a.timeout = tuning_constants.ADVICE_TIMEOUT_MEDIUM
a.title = [[text@2bf0387d Local Road Reaches Limit - A Chaos of Cars]]
a.message = [[text@2bf03881 Ouch! #city# has been experiencing some serious growing pains lately, Mayor. We've been getting chronic delays and recurring accidents on <a href="#link_id#game.camera_jump_and_zoom(game.l_road_congestion_h_subject,camera_zooms.MAX_IN)">this stretch of road</a>, and more and more drivers are getting road rage. The whole area is becoming a traffic nightmare, and we need to do something to relieve the strain. You could upgrade the road to an extra-wide <a href="#link_id#game.tool_plop_network(network_tool_types.AVENUE)">avenue</a>, which would probably require some expensive demolition. You could make this road two lanes <a href="#link_id#game.tool_plop_network(network_tool_types.ONEWAY)">one-way</a>, but you'd need to be sure you made another nearby parallel road <a href="#link_id#game.tool_plop_network(network_tool_types.ONEWAY)">one-way</a> in the opposite direction. Finally you could redirect the bulk of this traffic, bypassing these crowded roads, by beefing up capacity elsewhere in the vicinity.]]
a.priority = tuning_constants.ADVICE_PRIORITY_MED_HIGH
a.mood = advice_moods.BAD_JOB
------------ Advice record ----
--Big-Time Traffic Problems Hit Local Avenue
a = create_advice_transportation('6bf09be8')
a.trigger = "game.l_avenue_congestion_h > tuning_constants.TRAFFIC_CONGESTION_VERY_HIGH"
--game.l_avenue_congestion_h > high
a.frequency = tuning_constants.ADVICE_FREQUENCY_LOW
a.timeout = tuning_constants.ADVICE_TIMEOUT_MEDIUM
a.title = [[text@2bf03885 Big-Time Traffic Problems Hit Local Avenue]]
a.message = [[text@6bf0388a It's bumper to bumper out there, Mayor, and <a href="#link_id#game.camera_jump(game.l_avenue_congestion_h_subject)">this particular avenue</a> is in especially bad shape. Every day at rush hour it becomes a virtual parking lot as commuters stew. Perhaps it's time to consider some major upgrades? What if we constructed a <a href="#link_id#game.tool_plop_network(network_tool_types.ELEVATED_RAIL)">rapid transit line</a> to give these drivers an alternative commute? Or you might consider building <a href="#link_id#game.tool_plop_network(network_tool_types.GROUND_HIWAY)">a highway</a> to handle the extra volume. Both are big investments, and you'll need to be sure that you provide proper access, such as <a href="#link_id#game.tool_plop_building(building_tool_types.ELEVATED_STATION)">transit stations</a> or <a href="#link_id#game.tool_plop_network(network_tool_types.HIWAY_RAMP)">highway ramps</a> - to ensure they will be used.]]
a.priority = tuning_constants.ADVICE_PRIORITY_MED_HIGH
a.mood = advice_moods.BAD_JOB
Those constants only set the limits (triggers) on when these messages appear.
They have nothing to do with the simulation itself.
Quote from: RippleJet on December 16, 2009, 01:28:38 AM
Those are just constants used in advisor records (e.g. those fluff news that appear in the news ticker window).
Quote from: sumwonyuno on December 15, 2009, 08:43:34 PM
I, for one, am interested to see if these changes in these constants result in anything constructive. :thumbsup:
Apparently so - changing them can shut up the advisors! :D
Sorry to bump this, but I want in. What do I need to adjust the properties in the smiulator?
Your best bet is to use the Traffic Simulator Configuration Tool, which is launched with the NAM Traffic Subsystem (http://sc4devotion.com/csxlex/lex_filedesc.php?lotGET=2379). If you have any other questions on the NAM traffic simulator, please post them in the NAM Unified Traffic Simulator and Data View Help (http://sc4devotion.com/forums/index.php?topic=6812.0) thread. Thanks! :)