• Welcome to SC4 Devotion Forum Archives.

NAM and commute time

Started by speeder, December 29, 2015, 05:20:19 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

speeder

I am making a mod designed to make the game more gamey (instead of you easily having infinite money after some years).

One variable the game takes in account for some stuff, is commute time.

I noticed that NAM commute time is ALWAYS 0, or 255, never any other value.

Also it is only 255 if there is no commute (ie: no jobs available on the city) or if the commute is to other city.

Why is that?

And can this be fixed somehow?

APSMS

255?

Max commute time in the NAM is 600 minutes. This allows Sims to walk to work all the way in the other corner of a Large City tile (8km morning commute, as there are no diagonals in the game engine--diagonals are masked stepped roads).

Shorter commute limits cause Sims to not be able to find jobs that they might normally have the ability to travel to, even within the same city. No negative effects are associated with having an inordinately long commute (well, lower desirability, but this is minimal). Extensive testing was done and essentially what was concluded was that the negative effects do not scale enough to consider including them in the game; it was mostly an all or nothing situation, and the demerits for long commute time (before shutting the job search down) were not strong enough to persuade the player to fix them, nor were they a good indicator of when a Sim was really out of work, and thus were detrimental to gameplay.

The default Maxis traffic simulator allowed a maximum morning commute of 6 minutes, but even Maxis devs felt this was a bit short, and so they multiplied the actual commute time by 25 before displaying it on the commute time graph. The NAM removes this modification, but because of the way the NAM handles commutes, the general recommendation is to ignore the commute time graph, as what it reports with a NAM install is generally inaccurate, and a poor indicator of the actual commute situation.

I have never had a 255 commute time with the NAM. 0 only shows up if there are no jobs in your city, also an unlikely situation (Power company provides some jobs, and jobless homes report null for commute time)
Experience is something you don't get until just after you need it.

My Mayor Diary San Diego: A Reinterpretation

speeder

I am not talking about the commute time graph (I didn't even remembered to look at that).

I am talking about the "Trip Length Effect" variable for example, it takes as input 0 to 255, and outputs in vanilla from +10 to -10 desirability in a residential area.

Also what you wrote (600 minutes being enough to WALK to the other side of the city) explains why I am having this bug with NAM installed: http://community.simtropolis.com/forums/topic/66626-using-nam-32-is-this-supposed-to-happen/#comment-1561227

APSMS

Depending on the traffic simulator level you are using (I use 1.2 times the medium setting), that "bug" is more likely the fact that transit speeds on roadways decrease with increasing usage. At 30% capacity the traffic moves at the rated speed (for Streets it's 30km/h, Roads are 50km/h), but this decreases [mostly] linearly with added usage.

Pedestrian traffic, on the other hand, doesn't decrease in speed (I think) with increased traffic, and thus remains constant at 15km/h. The numbers you see there are probably where the street traffic decreases speed to the same level as the pedestrian traffic. Also, there is a small startup cost to Sims using personal vehicles, to further promote the use of mass transit, and this can also affect the travel preference, especially when funneling traffic through one through-way like you showed in that picture. Shorter allowed commute times would have prevented most of the Sims from finding work at all, so this behavior is preferable to the alternative.

But that Trip Length Effect variable bit is new to me. I am going to have to learn more about it. This is not commute time, however. I suspect that this was done to remove the desirability effect from the Traffic Simulator, and relegate desirability to traffic noise alone, which incidentally is also how the game calculates "customers" in commercial businesses (in case you didn't already know that).

Of course, this could also be an oversight, though I doubt it. Maybe z could pop in and give his $0.02 about why the TS is setup that way.
Experience is something you don't get until just after you need it.

My Mayor Diary San Diego: A Reinterpretation

speeder

#4
All "Developers" (stuff that mostly CAM, or my MOD mods, thus making my mod theoretically incompatible with CAM) have various "Effect" variables, that control desirability.

Among them Land Value Effect, Park Effect, $, $$, $$$ proximity Effect, Traffic Effect, Trip Length Effect, school, hospital, pollution, etc...

All those "Effect" values accept from the game an input from 0 to 255, those also are used to display information (example: I assume that 255 "trip length" is "long commute", and 127 is "medium" and 0 is "short", and that the actual time is converted to that range 0-255 elsewhere).

On Vanilla, for $R for example, the land value go from 5 desirability bonus, to 0 (meaning cheaper land attract $ citizens).

Hospital go from -5 to 5 (not having hospital coverage -5, full coverage 5)

The Traffic Effect go from 2 to -2
But Trip Length Effect go from 10 to -10

This means that with NAM installed, NAM itself makes to a $ citizen all squares suitable land to buy for his house as if they had a hospital and no land value, that is a MASSIVE bonus, just by installing NAM you suddenly have "free hospital" in the entire city.

This problem is noticeable because of mansions, the game can replace a building in two cases:
1) Someone want to build something with more density (example: want to replace a house with a tower, or a tower with a even bigger tower).
2) Someone want to build something for a higher class citizen (a mansion for $$$ citizen can replace even huge towers, if they are $$ or $, $$$ commerce can also replace $$ and $ commerce in the same way).

So, NAM make everything 10 points more desirable, this is the bonus that the game uses to make $$$ seek higher priced land (maximum price land has 10 bonus in desirability for $$$ citizens), when your city is sufficiently developed, and desirability values are near each other, NAM bonus can trump the land value bonus, and suddenly you see mansions being spammed, and your high-rise $$ city turns suddenly into Paris, a flat looking $$$ city, and suddenly half of your citizens are gone, then business fail to find workers and they get dilapidated.

On my mod I removed the bonus, now commute time has 0 bonus, but still has penalty for high commute time, this made the problem lessened, but I wanted to be able to actually use bonus and penalty for correct commute times, thus why I asked if it can be changed.

Also today I noticed the traffic simulator config tool, I noticed it can change maximum commute time, I will test what happen if I set it to 120.

EDIT: a comment on the 10.000 pedestrians issue.

I still consider it a bug, if you have badly planned roads to the point that being a pedestrian is faster, it DOES make sense for people to go on foot.

What it DOES NOT makes sense is that people will walk 10 hours to work, it is a feature that people won't work if they can't walk to it fast enough, in my screenshot the correct behaviour would be the isolated residential area I made get abandoned due to poor connectivity with the rest of the city, requiring me to actually build better roads (including using NAM extremely wide roads if needed).

APSMS

The bigger issue is that for some reason the game considers some trips to take hours despite the fact that my neighborhood occupies an area larger than a large game tile. The point of the ten hour commute is to make the game less of a transit simulator, and more of a city builder. In real life, if that's the only way to get to work, then that's what people will do and it doesn't make sense, if jobs are available, for people not to work just because the commute was too long.

However, I agree that it should affect desirability, since this is how it works in the real world. Not sure what the reasoning there was.
Experience is something you don't get until just after you need it.

My Mayor Diary San Diego: A Reinterpretation

speeder

I am still testing with my mod test city.

Changing commute time to 120 had an interesting effect: high density far away from workplaces, DID got abandoned.

And fixing the city transportation (the entire city had only streets, because there was no reason at all to use anything else, and I was trying to be most money efficient as possible to test what happen with my mod), most of these buildings got people in it again.

But every single plot of the map now consider commute time "long", I will test other values, and also seek what actually converts commute time into "short, medium, long".

Also, the commute time graph, although I could not make sense of the unit it uses yet, does work (when the city had a "U" shape, the graph hovered around 3, connecting the U with a single street, made it hover around 2, adding subways and buses in a square shape around the city, made it drop and hover exactly around 1... but I am unsure if it is 1 hour, in that case the entire city should have medium commute time, or if it is 1 as in 100% of maximum commute time, in this case the things are happening as expected).

mgb204

A lot of information exists in this thread pertaining to the simulator. If you've not already done so, it's probably worth a look.

speeder

Yep, I "fixed" the commute time graph to the 0.04 value after seeing the docs, now I am seeing values that actually make sense.

The city I am using to test, has chronically long commute anyway, this is half expected, and half not.

The half expected, is that the entire city use only streets, with their 30km/h top speed.

The half unexpected, is that the destination finder (not the pathfinder) is... a bit weird, it do some half-assed effort in trying to get sims to near jobs, when you click on a building, you can see a sort of "maximum" radius where sims there will work, with similar maximum radius of near buildings, thus you won't see sims working across the city too much, yet, I never saw a building choose to put its sims to work right across the street, I even trying building commercial and residential zones right across from each other, and instead the destination finder just send the sims to work 2 hours away, and the new commercial zone get workers from 2 hours away too...

speeder

#9
Alright! I found some amazing information!



First, after a lot of hacking I found out that query.txt is a thing \o/

So, after finding out that, I went to generate query.txt for a variety of buildings, and read the data, and compare with the information in the game.



Things I found out.



1) the game knows the exact time a sim takes to travel around in hours, my big cities frequently average around 2 to 3 hours when well designed, matching with real world!

2) the "short, medium, long" variable shows based on the bonus, a bonus of "0" is medium, positive is short, negative is long... thus my mod "NAM FIX" that removed bonuses for short tripes broke the query tool (that showed that every single building had "long" commute time).

3) to calculate the bonus, the game takes as input a number from 0 to 255, to calculate that number this is the formula:  trip time in hours / traffic simulator max commute time * 255 (example: I saw a building with 364 hours of commute time, NAM maximum is set to 600, 364/600*255 = 154)

4) When commute time is "N/A", it shows in-game as the "unemployment" zot, and the commute time bonus input is fixed at 255.





Now the buggy thing: seemly commute time is also the maximum number for out of city trips, so for example most of my building had commute time of 2 hours, the building I mentioned before, with 364 hours of commute, had about half of its residents working in another city (thus the average of about half at 600 and about half at 2 ended being 364)

This DOES show on the commute graph, my city without any neighbours the commute time graph actually works fine when the scaling is set to 0.04, when my city had crappy designed it peaked at 6, and after I fixed most of it, it was down to 3, and after I introduced subways it got down to 2, this city can be further improved (every single land transport on it is "street", it has no roads).

But my well designed city, that HAS neighbours, the commute graph show as average commute time 90 hours, of course that makes no sense.





Now 2 notes

1, I am not sure the "Trip length" variable the query tool is showing me is in hours, maybe it is in minutes... (because if I remember correctly with the biggest map size a subway trip should take 6 minutes from side to side in diagonal, and people taking only the subway in my non-neighbourhood city takes "2" of time to make a trip to half of the map, thus maybe it is 2 minutes).

2, I am not really sure how the game calculate neighbour connection trip length, I am assuming it uses the maximum commute in the traffic simulator, but more testing is needed.


EDIT: Indeed, "trip length" is in minutes. Also, the maximum trip length is the maximum commute time set in the simulator .dat

Thus NAM default of 600 makes the commute graph completely useless (example: in a well designed city with neighbour connections, the local jobs will average 3 minutes, and foreign jobs are fixed 600 minutes, thus you might end with local jobs not showing in the graph at all).

I tested after fixing my own mod (so that commute times display "short, medium, long" correctly) to set NAM maximum commute to 120, I liked the overall result.

In a still develioping town, average commute on the graph was 3 minutes, on a massive city to the point of the "no-job" zot showing up, the average commute was 10 minutes, adding neighbour connections to that city bumped the average to 70 minutes, and the "no-job" zots disappeared.

Places that had actual workplaces nearby showed with the cheat dll a travel time avearging 2 minutes (the lowest was 1.2 minutes, highest was 4 minutes), while places in locations that create "no-job" zots (example: in a island city I made, all the commerce was on the north side, near the edge of the map, and I made a high wealthy residential area on a beach on teh south side, that beach immediately got abandoned after I changed NAM to 120, but after adding neighbours it got fixed), had travel time near NAM maximum (120)

if you add more jobs to the city, until foreign travel ins't needed, commute time actually drops...

in fact after understanding all this, I foudn the commute time graph very useful, it shows both transporation inefficiencies, and also shows that there are not enough local jobs, as you increase local jobs, the commute time drops.

z

#10
Congratulations on figuring out so much about the commute time, speeder:thumbsup:

It seems that you've found the answers to most of your questions, but I think I can answer a couple of more here.

First of all, everybody wants to know, "Why 600 minutes for the max commute time?"

From empirical testing, I found out that there were two high commute time values that were especially noteworthy.

The first is 120 minutes.  Although it is possible to get anywhere in a large tile within a small fraction of this time, a value of approximately 120 minutes is required to minimize abandonment due to commute time.

The second is 600 minutes.  You may notice that at a city boundary, there is a certain probability that Sims will cross into the next city looking for jobs.  Theoretically, crossing over should cost nothing.  However, the probability of crossing over increases with maximum commute time, reaching a peak at around 600 minutes.  Higher values have no effect.

So the 600 minute value was chosen to improve region playability, and to minimize the somewhat arbitrary walls that were being set up by city boundaries.

Second, as for what makes for Short, Medium, and Long commutes, these numbers are derived by dividing the max commute time into thirds.  That's why with a max commute time of 600 minutes, all successful local commutes are Short.

As for the destination finder, yes, it definitely acts weird.  The behaviors you described were originally noticed by RippleJet, and described in my traffic simulator thread on this board.  A more detailed discussion, with examples, then branched off into its own thread.

The traffic simulator thread I mentioned also has various other experimental findings scattered throughout, such as the optimum scaling factor of .04 for local commute times that you mentioned above.

speeder

Oh, now I know the simulator settings are called "Z"

I spent the past few days trying to figure WHY the commute time bug (with abandonment) exists.

Found out two things you might find interesting: 1, the planned default commute time was 90 minutes, not 6, in fact if the game don't find the commute time property in the exemplars, it will use 90.

2, the game works with commute time only with floating point minutes, the only reason why you see it multiplied by 25 anywhere, is to make storing the graph easier.

SC4 graph system only understand integers, on a healthy small city with no neighours, is possible to have commute time to be below 1 minute (for example 0.7 or somethingl ike that), this when converted to integer, rounds to zero... thus the graph would end always showing zero.

Maxis solution was to multiply commute time by 25, THEN convert it to integer and store it on the History Warehouse, and THEN divide it again by 25 for display purses, this value they left being configurable in the end.

Also this is why if you tweak that value, and reload the game, it changes the graph in the appropriate manner.

z

Quote from: speeder on January 27, 2016, 11:59:03 PM
I spent the past few days trying to figure WHY the commute time bug (with abandonment) exists.

Found out two things you might find interesting: 1, the planned default commute time was 90 minutes, not 6, in fact if the game don't find the commute time property in the exemplars, it will use 90.

When I first started building Simulator Z, I thought that the small max commute time was the biggest factor in causing abandonment due to commute time.  But after about a year, I realized that the real problem was the setting of the pathfinding heuristic.  It was fixing this value that made the most difference by far in reducing abandonment.  With the proper pathfinding heuristic, even the default value of six minutes for max commute time works fairly well for most cities.

NCGAIO

#13
Quote from: speeder on December 30, 2015, 08:07:01 PM
Alright! I found some amazing information!

First, after a lot of hacking I found out that query.txt is a thing \o/

So, after finding out that, ........


as described here -  Query TxT    -  tiles traffic

with some graphical explanation - - Query tool informations -





Although that for some of the concepts there are certain inconsistencies when it comes with the simulator, especially in top speed, which bring a certain randomness to some who are treated as precise

The distance out of town is also considered to commute time but demand may also disregard this


speeder

How were the pretty graphics made? Some command, a mod, or the guy was that patient to draw?

NCGAIO

#15
Quote from: speeder on January 28, 2016, 02:01:10 PM
.... or the guy was that patient to draw?

really .... :D

I can guarantee that there would not be the minimal chance that I had the necessary patience to draw it all.

Using rendering parameters accepted by the original dll provided with some editing to include only the frames with the queries on the images

speeder

Now that you replied, the pictures showed up... I didn't even see them before.

I was talking about the pictures on Simtropolis.

NCGAIO

#17
Quote from: speeder on January 28, 2016, 02:51:07 PM

I was talking about the pictures on Simtropolis.

the answer was exactly about them

Quote
Using rendering parameters accepted by the original dll provided with some editing to only include the frames with the queries on the images


nc.