Menu

LEX File Exchange
EA Support Files
SC4 Wikipedia
Network Addon Mod
Dependencies
Chat
Welcome to SimCity 4 Devotion. Please login or sign up.

December 05, 2022, 04:53:23 PM

Login with username, password and session length

Downloads

Why are there no Lots in the NAM?

Started by Chrisim, January 11, 2009, 06:27:00 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

b22rian

I just wanted to take a break from the tech side of the thread to say a special thanks to both Chrisim and
Sim Goober.. First to Chrisim for your nice test you ran, it was quite informative and interesting..

Second thanks to Sim goober for volunteering to change his stations values for us , of which we are talking
about a lot of great stations !

Brian

z

This thread has been moving faster than I can post, so I think I'll use this opportunity to put in my two cents about entry costs.

I think that Chrisim's experiments and Cogeo's post point out clearly how entry costs work best.  According to Chrisim's earlier post, which he quotes:

QuoteA station plopped on rail track should have the same Transit Switch Entry Cost value as the time a train needs to drive along a rail track of same length.

I'm not sure if it was clear from Cogeo's post, but this was his motivation exactly when calculating entry costs for RTMT via experiment.  The question of shortcutting didn't enter into it.

The 1/speed formula gives a good approximation for a neutral value of the TSEC, but as CLR1SC4D showed, and I had found independently, .96/speed is exactly accurate.  If we are going to hardcode this, why not use the best number?

The one important question that still lies open is, Which speed do we use?  By this, I am referring to the fact that all three of the latest traffic simulators (A, B, and Z) have different speed tables.  For the slower vehicles, the differences aren't very great, and so the value of 0.02 for buses and cars works fine.  But in rails, there is quite a divergence in places, with A being the slowest and Z being the fastest.  Should we use one of these simulators specifically, or should we use an average of the three?

This question is important because it is tied in very closely with levels of rail usage, and how it is answered will affect those levels.  So first of all, what is the effect of rail speeds on rail usage?  As you'd probably expect, all other things being equal, the faster rails get heavier usage.  That's just a side effect of the way the traffic simulator is designed - it tries to get the Sims to their destination by the fastest route possible.  So Simulator Z's faster speeds are a big reason for its greater rail usage compared to Simulators A and B.  These are essentially the same speeds I started out with from the CAM traffic simulator.  I acknowledged on the first page of my simulator thread that the rail speeds were slightly higher than real life, but I also listed the reasons why I felt that was necessary.  One further reason has come to light in subsequent testing, which I described in a post to which I referred at the end of my previous long post in this thread.  I think it would be good to briefly summarize the situation here.  One user reported that he had a test city with a long avenue next to a monorail line.  As he expected, the vast majority of Sims took the monorail to work.  But when he replaced the avenue with a highway, everyone took the highway, even though the monorail was more than twice as fast!  Analysis of the situation showed that the Sims were actually doing the right thing, as the access time for getting to and from the monorail wiped out the monorail's speed advantage over the highway, which is only about 15 seconds if the test track is 64 squares long.  With the avenue, the monorail's advantage was closer to 45 seconds, which was enough to accommodate the additional access time, and so the Sims chose the monorail.  If the test track with the highway and the monorail were extended longer, eventually the Sims would switch to the monorail.  Note that all of this is using the higher speeds of Simulator Z.

Notice the small times involved here, despite the large speeds.  This comes down to the fact that even large tiles are only 4 km square, and very few routes use a significant fraction of that.  One of the crucial ways SC4 differs from RL is that routes tend to be shorter, often much shorter, and this is enforced by the size of the city tiles.  As a result, for the speed of a mode of mass transit to make a difference in the Sims' travel strategies, it must be significantly higher than the alternatives, due to the disproportionate effect that access time to mass transit plays in SC4.

That's the theoretical justification for the higher speeds.  For practical evidence, we can look at the identical test results obtained by Chrisim, Cogeo, and me.  Station entry costs affect just a small percentage of squares on a mass transit line.  If raising the cost slightly for those stations (thereby lowering the effective speed on those few squares) can have a big effect on the usage of that line, it is certainly easy to see how a change of speed that affects the entire line is going to have a much bigger effect.

Also, right now, most MT stations have a TSEC of zero.  Raising that number at all is going to reduce mass transit usage somewhat for all traffic simulators.  I think we want to minimize that reduction while still getting the benefits of the TSEC.  And I think that the best way to do that is to use the speeds of Simulator Z in the .96/speed formula.  Doing so does not give Simulator Z an advantage over Simulators A and B; it is in their interest as well to have a low TSEC for best mass transit usage.

RippleJet

Quote from: z on January 14, 2009, 12:11:02 AM
As a result, for the speed of a mode of mass transit to make a difference in the Sims' travel strategies, it must be significantly higher than the alternatives, due to the disproportionate effect that access time to mass transit plays in SC4.

An option would of course be not to raise the speed of MT, but reduce the speed of cars.

E.g. instead of having the rail speed of 150 compared to a car speed of 50, how about reducing that to 120 for the rail and 40 for the cars? And increasing the "Commute trip max time" accordingly.

From Maxis' simulator the speed of cars (on road), buses (on road), trains and monorails have shifted quite a lot:


Simulator   
    Car Speed
    Bus Speed
    Train Speed
    Monorail Speed
Maxis
31
46
110
200
A
60
55
100
175
Z
50
40
150
250

Maxis had the monorail speed at 6.45 times the speed of cars.
Simulator A reduces this to 2.92.
Simulator Z reduces this to 5.00.

Maxis had the rail speed at 3.55 times the speed of cars.
Simulator A reduces this to 1.82.
Simulator Z reduces this to 3.00.

Maxis had a bus speed at 1.48 times the speed of cars.
Simulator A reduces this to 0.92.
Simulator Z reduces this to 0.80.

Maybe one problem is that every custom simulator seems to want higher car driving speeds...

Basically, the Entry Cost shouldn't be that much dependent on the network speed.
It would be better if only one Entry Cost per type of station could be used.

The Entry Cost simulates the time it takes to buy tickets and wait for the MT to arrive.
Thus, like Cogeo said, it should probably be somewhat higher than the minimum speed to avoid shortcutting.
The lower the network speeds are, the more freedom we would have with the Entry Cost.
If the average road speed for cars is 31, the entry cost on train stations can be higher than if the cars are allowed to drive 50 or 60.

If the city decides to upgrade all roads (change simulator) to allow an almost doubled speed limit and average speed, then there is no doubt passengers will abandon rail, unless there's a superfast train leaving once a minute (higher network speed and smaller entry cost).


Unfortunately (naw, luckily) I'm about to leave for a 3-week vacation,
so I will probably not be able to take an active part in this discussion for some time...  ::)

z

Quote from: RippleJet on January 14, 2009, 02:23:06 AM
An option would of course be not to raise the speed of MT, but reduce the speed of cars.

E.g. instead of having the rail speed of 150 compared to a car speed of 50, how about reducing that to 120 for the rail and 40 for the cars? And increasing the "Commute trip max time" accordingly.

There are many, many reasons why this would not work.  Travel speeds are just hooked into too many other things in the game that would be thrown out of balance.  This is one big reason why the "5x Speed" simulators no longer exist; this would just create the inverse of the problem they had (among others).  "Commute trip max time" actually affects more than just commute trip max time, and this change would seriously mess up intercity travel.  And narrowing the range of speeds only compounds the problem of the affect of access time on mass transit.  I would expect mass transit usage to drop even further under this scheme, possibly drastically.

Quote
From Maxis' simulator the speed of cars (on road), buses (on road), trains and monorails have shifted quite a lot:


Simulator   
    Car Speed
    Bus Speed
    Train Speed
    Monorail Speed
Maxis
31
46
110
200
A
60
55
100
175
Z
50
40
150
250

Maybe one problem is that every custom simulator seems to want higher car driving speeds...

I don't think that's it.  I think that if you look at all three simulators under consideration, the car speeds of all of them are much more realistic than the Maxis speed.  To have an entire region where the maximum car speed is 31 kph (about 20 mph) is pretty unrealistic.  And to have bus speeds 50% higher than bus speeds everywhere - that doesn't make sense, especially when you consider all the stops that buses make that the game cannot directly account for.

Quote
Basically, the Entry Cost shouldn't be that much dependent on the network speed.
It would be better if only one Entry Cost per type of station could be used.

Yet all of the experiments quoted in this thread are in agreement that 1/speed (or .96/speed) produces the best results, reducing shortcutting while also minimizing the effect on transit usage.  But for basic stations, this still turns out to be one entry cost per type of station.  For combo stations, using the speed of the fastest network generally produces the best results.

Quote
The Entry Cost simulates the time it takes to buy tickets and wait for the MT to arrive.

In theory, yes.  In practice, if you stray far from the 1/speed formula you run into trouble, with teleporting on one end and abandonment of mass transit on the other.

QuoteThus, like Cogeo said, it should probably be somewhat higher than the minimum speed to avoid shortcutting.

The relevant quotes I see in Cogeo's post are, "I think it's pointless to attempt eliminating shortcutting, without taking into account the effect on the stations' usage," and "Why is shortcutting considered so evil finally?"  I agree with both of these sentiments.  The effect of even a small reduction in mass transit usage has far more effect on the game than shortcutting.

QuoteThe lower the network speeds are, the more freedom we would have with the Entry Cost.
If the average road speed for cars is 31, the entry cost on train stations can be higher than if the cars are allowed to drive 50 or 60.

That's true.  But your mass transit usage will be way down.  I can't see the point in doing this.

Quote
If the city decides to upgrade all roads (change simulator) to allow an almost doubled speed limit and average speed, then there is no doubt passengers will abandon rail, unless there's a superfast train leaving once a minute (higher network speed and smaller entry cost).

In testing, I have changed simulators from A to Z and back again more times than I can count.  I never saw the type of abandonment you describe, going in either direction.

In summary, I don't think this will work at all - I think it will only make things worse.  It's contrary to all the traffic simulator behavior I have seen.  If someone disagrees, they should do tests and present the results.

Quote
Unfortunately (naw, luckily) I'm about to leave for a 3-week vacation,
so I will probably not be able to take an active part in this discussion for some time...  ::)

Yeah, I would say luckily - vacations are always good!  Sorry to be so critical of your idea, but I thought I should report my experience.  Have a great vacation, and we'll look forward to your return. ;)

SimGoober

QuoteI don't think that's it.  I think that if you look at all three simulators under consideration, the car speeds of all of them are much more realistic than the Maxis speed.  To have an entire region where the maximum car speed is 31 kph (about 20 mph) is pretty unrealistic.  And to have bus speeds 50% higher than bus speeds everywhere - that doesn't make sense, especially when you consider all the stops that buses make that the game cannot directly account for.

One minor point to make here; Are we trying to make this more realistic or more functional?  It's been my experience that the game does not always allow for both.  For RCI stuff, I have found it best to make something look more realistic, but perform more functionally in game.  For example, if a building looks like a little shop in a low wealth area, it would probably employ 5 or 6 people in real life.  But to function well in game, it may employ 30 or more.  Several BATters have gotten caught up in this ongoing debate; and it never ends.

My suggestion would be to look at "upgrades" to these traffic related ideas as 95% functional, 5% realistic.  SimCity is not a perfect simulation; it is more utopian, and generalised.  In the above comment, a speed limit of 20 mph in an entire city is not realistic, but in an inner city, high density zoning, it is close.  That may be why that number was picked, as Maxis probably assumed everyone would want to end up in a high density, high population city.

The only way to make it more realistic I suppose would be to find a way to enforce variable speed limits in different areas...  :-\
When life just blows ... Fukitol!

imperialmog

Is there a way to enforce variable speed limits in different areas? If there is a way to do that it would be great in terms of realism.

z

Quote from: SimGoober on January 14, 2009, 07:44:47 AM
One minor point to make here; Are we trying to make this more realistic or more functional?  It's been my experience that the game does not always allow for both.  For RCI stuff, I have found it best to make something look more realistic, but perform more functionally in game.  For example, if a building looks like a little shop in a low wealth area, it would probably employ 5 or 6 people in real life.  But to function well in game, it may employ 30 or more.  Several BATters have gotten caught up in this ongoing debate; and it never ends.

My suggestion would be to look at "upgrades" to these traffic related ideas as 95% functional, 5% realistic.  SimCity is not a perfect simulation; it is more utopian, and generalised.  In the above comment, a speed limit of 20 mph in an entire city is not realistic, but in an inner city, high density zoning, it is close.  That may be why that number was picked, as Maxis probably assumed everyone would want to end up in a high density, high population city.

The only way to make it more realistic I suppose would be to find a way to enforce variable speed limits in different areas...  :-\

This is an excellent point, and I agree with you completely here.  My approach has always been to start with realistic numbers, but modify them as necessary to get the best functionality.  And the best functionality usually ends up looking the most realistic to the players (at least with traffic), even though the numbers may disagree.  My point about realism in my previous post was simply to explain where the current car speeds came from.  On the other hand, my support for the .96/speed entry costs means that vehicles never even slow down for stations, much less stop.  That's about as unrealistic as you can get.  Yet it's required for best functionality.  My main argument with RippleJet's suggestion was not from a realism point of view, but from a functional one - it would break too many things.  Some I didn't even think of at the time.  For example, if you change speeds, you have to change network capacities, as capacity is directly dependent on speed.  There are undoubtedly other implications as well; I think that by the time you're done, you'd end up building a whole new traffic simulator - one that wouldn't have any better functionality than the current ones.

And yes, I've thought many times that variable speed limits would be great, but so far nobody has figured out a practical way to implement this. :(

RippleJet

Posting from the City Terminal in Stockholm, so this will be short... ::)

I don't think 31 km /h is that unrealistic either for big cities...
I believe most metropolises in the world have an even lower average speed downtown...
Wasn't that of London something lilke 10 km/h before the congestion charges?

Besides, since the cities in SC4 are smaller than in RL, with shorter routes from home to work,
sholdn't the speeds be smaller than in RL, rather than larger?


Regarding the advantage I was trying to explain about having smaller network speeds...

Consider a Sim searching for the fastest way to work...
The straight path leads to a railway station.
From there he can choose two equally long alternatives, rail and road, both being 40 tiles long.
In the other end, there are 3 more tiles from the railway station to his job.

In eiher alternative he would take the car to the first railway station.
Then he'd have to choose. Park the car and take the train or drive on?

With Maxis' Simulator the train would take 40/110 = 0.36
The walk from the train to work would take 3/3.5 = 0.86
Thus, the total time from the first station to work is 1.22

By driving he would get there in (40+3)/31 = 1.39
This means that he would take the train if each station
would have an entry cost of no more than (1.39-1.22)/2 = 0.085

Now, consider the city upgrading the roads and rails to Simlator Z.

The train would now take 40/150 = 0.27
And the walk to job would take 3/5 = 0.60
Total time from the first station = 0.87

By driving he would now get there in (40+3)/50 = 0.86
Thus, regardless of the entry cost of the station, he would probably not consider taking the train, unless road congestion makes that route considerably slower.

And Simulator A would be even worse...


This is all theory, but I hope it explains a little better what I meant was the problem when each custom simulator has (proportionally) increased the car speed more than the speed of any MT... and then trying to solve the problem of MT not being used by optimizing the entry costs of stations.

Now, I'm not trying to convince anyone to start changing the Simulators or even adding new ones...
I'm just trying to explain my feelings about some of the problems...

It's a pity Maxis didn't implement the entry cost themselves, if 0.05 may indeed have been what they intended to use...

z

#48
I think I see your point here, and in principle, it makes sense.  The problems I found come in more complex cases, where what the Maxis simulator does tends to be less predictable.

Quote from: RippleJet on January 15, 2009, 01:35:28 AM
I don't think 31 km /h is that unrealistic either for big cities...
I believe most metropolises in the world have an even lower average speed downtown...
Wasn't that of London something lilke 10 km/h before the congestion charges?

Here in the U.S., I've seen downtown speeds that range from 40 kph to 50 kph.  In all the big (U.S.) cities I've been in, 50 kph is the most common speed outside the downtown core.  And as you get into the suburbs and farther out, speeds on the main roads tend to increase.  So I felt that in the face of a lack of variable speed limits, 50 kph was a reasonable average.

Quote
Besides, since the cities in SC4 are smaller than in RL, with shorter routes from home to work,
sholdn't the speeds be smaller than in RL, rather than larger?

This definitely makes a good amount of sense, and if I were building a traffic simulator from scratch, I would feel that this would be an alternative that needed to be investigated thoroughly for its practicality.

Quote

Regarding the advantage I was trying to explain about having smaller network speeds...

Consider a Sim searching for the fastest way to work...
The straight path leads to a railway station.
From there he can choose two equally long alternatives, rail and road, both being 40 tiles long.
In the other end, there are 3 more tiles from the railway station to his job.

In eiher alternative he would take the car to the first railway station.
Then he'd have to choose. Park the car and take the train or drive on?

With Maxis' Simulator the train would take 40/110 = 0.36
The walk from the train to work would take 3/3.5 = 0.86
Thus, the total time from the first station to work is 1.22

By driving he would get there in (40+3)/31 = 1.39
This means that he would take the train if each station
would have an entry cost of no more than (1.39-1.22)/2 = 0.085

Now, consider the city upgrading the roads and rails to Simlator Z.

The train would now take 40/150 = 0.27
And the walk to job would take 3/5 = 0.60
Total time from the first station = 0.87

By driving he would now get there in (40+3)/50 = 0.86
Thus, regardless of the entry cost of the station, he would probably not consider taking the train, unless road congestion makes that route considerably slower.

And Simulator A would be even worse...

Here you've got the Simulator Z speeds slightly wrong, enough to change the outcome in your example.  It looks like you got the speeds from my simulator thread.  The walking speed is my fault; I didn't update it when I raised it to 15 kph (which happened to double monorail usage).  I've updated it now.  But the 200 kph for passenger trains has been in there all along.  So using the actual Simulator Z numbers, instead of coming out in favor of the car, you get:

The train would now take 40/200 = 0.20
And the walk to job would take 3/15 = 0.20
Total time from the first station = 0.40

By driving he would now get there in (40+3)/50 = 0.86
This means that he would take the train if each station
would have an entry cost of no more than (0.86 - 0.40)/2 = 0.023

So that's a narrower margin than the Maxis one, but it still has the Sim taking the train.  And it still leaves room for an entry cost of .96/speed.

Quote
This is all theory, but I hope it explains a little better what I meant was the problem when each custom simulator has (proportionally) increased the car speed more than the speed of any MT... and then trying to solve the problem of MT not being used by optimizing the entry costs of stations.

Now, I'm not trying to convince anyone to start changing the Simulators or even adding new ones...
I'm just trying to explain my feelings about some of the problems...

It's a pity Maxis didn't implement the entry cost themselves, if 0.05 may indeed have been what they intended to use...

Again, I think your point is much clearer now.  But then there's also the issue of backward compatibility.  Right now, all cities are built with the implicit assumption that vehicles don't slow down or stop at stations.  Changing that behavior would adversely affect a lot of those cities.  It would also mean that if someone built cities with the vanilla Maxis game (which has no entry costs) and then moved to stations with relatively high entry costs, the working Maxis city could easily break.  Neither of these problems arise now, and by setting the entry cost at .96/speed, which means that vehicles travel through stations at the network speed, we can ensure that they don't arise.  And the fact that vehicles don't slow down or stop at stations is hidden from the user (as is the fact that all vehicles are actually single-passenger), so I don't see a compelling reason to use a different TSEC.

Nevertheless, you've certainly provided some interesting ideas for future simulator builders.  ;)

Tropod

This topic has come up quite a few times over the years. And it's always interesting to see/hear what others think about it  ;).
Many of you have valid points & good suggestions  :thumbsup:.


QuoteWhat about traffic simulators?  They certainly don't depend on the controller.

I just wanted to touch on this aspect here;
The NAM inner workings is by no means a complete document, and there's stuff that it doesn't even deal with that only Maxis would know about I would imagine. The idea behind it is to give people some idea of how it all works, not a comprehensive idea. Suffice to say though, that the controller(s) do depend on the simulator, albeit even if in a round about way (note that NAM relies on core functionality provided in the standard traffic plugin not given by stock game). And though many other aspects/areas of the game depend on the (various) simulators as well, it isn't detrimental to the point of specific functionality of the game not working if their not included. And the same could be said for Lots, Graphs, Dataviews, and many other areas/aspects of the game.
Essentially, it was/is/has-been a case of non-fundamental items that were not essential &/or could work as a stand-alone product, were not included - this, to a significant degree, goes towards people being able to do their 'own thing'. And so subsequently, Lots came under this umbrella. Not because they were Lots, but because the items in themselves could be provided as a stand alone product without requiring anything else in order to work i.e. they're not tied in functionally "directly" (all aspects of the game are tied in together, either directly or indirectly) to those files contained within the NAM. Anyways though.....



As for the issue itself:
The idea of some sort of NAM Lot department (NAM LD for short  %$payas)() sounds promising, something that deals only with standard/Maxis based TELs, that were released as a separate component (NALAM - Network Addon Lot Adjustment Modd  ???). And possibly/perhaps another additional separate component that dealt with NAM sponsored/approved TELs items specifically designed for the purpose of addressing these particular issues.


If I could make a suggestion; I was just browsing through the Traffic exemplar; and wondered if it would be worthwhile someone taking a look into the Trip Starting Cost by travel type for Mass Transit 0xEA8C3CDB property; it could potentially help address certain aspects of what's being discussed, and then again maybe not.



Ultimately, Maxis clearly designed the game the way they did. With us many a times wondering why why why......they (probably) had their reasons for doing certain things this or that way, but without knowing why they did something the way they did, we can only draw so much conclusion(s) from the files & tests.

Jonathan

Hey Tropod, look in the NAM private thread as theres been some discussion there about lots and a seperate 'Department'

Jonathan

z

Quote from: Tropod on February 18, 2009, 06:44:47 AM
If I could make a suggestion; I was just browsing through the Traffic exemplar; and wondered if it would be worthwhile someone taking a look into the Trip Starting Cost by travel type for Mass Transit 0xEA8C3CDB property; it could potentially help address certain aspects of what's being discussed, and then again maybe not.

When I was building Simulator Z, I discovered that this property was actually one of the most important in the whole simulator.  It has a large effect on the efficiency of the pathfinder, and a disproportionately large effect on monorail usage.  (I also discovered that monorails are sensitive to many things that other networks aren't.  I figured this had something to do with their being introduced in RH.)  The Maxis and Simulator A values for the second value in this property are 1.95;  Mott used 1, which is what I use in Simulator Z.  The lower this value, the more efficient the pathfinder; but on the other hand, as the value gets lower, less attention is paid to the Travel Strategy Percent properties.  (These two facts are undoubtedly related.)  I think the ideal value is a little over 1, and when I get time, I'm going to try to pin it down more exactly.  However, the effects of this property are quite orthogonal to the Transit Switch Entry Cost, and adjusting the former doesn't really help resolve any of the issues that were under discussion.