• Welcome to SC4 Devotion Forum Archives.

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.

RippleJet

I have no problem settling for 0.029, if that would be the consensus of NAM.
That would actually be closer to Christopher's formula of 1.3435/Speed for buses on roads, ensuring no shortcutting would appear.

Road-top stations could probably still be given individual Entry Costs, depending on the network they're designed to be plopped upon.
However, those are special cases, and I'm sure Cogeo and Z can mod them properly.

On the other hand, would there be any benefits from separating monorail, subway and train stations from this 0.029?
Looking at Scott's comparison, I wonder if we could use lower values for there (based on Christopher's foluma),
e.g. 0.007 for monorail stations, 0.010 for subway stations and 0.013 for train stations.

I know there have been complaints about the monorail and rail usage not being high enough.
Maybe we could encourage these a little by reducing the entry costs, at least compared to bus stops?

This can easily be adopted in the "X Tool", which doesn't (yet) allow the creation of combo stations.
Even if combo stations could easily be added, it would still be simple to set the Entry Cost according to the slowest traffic type.

I also agree with you Jason, that testing is imperative. Not only for the sake of avoiding possible CTD's,
but also to check the functionality of stations (in relation to each other) with the suggested Entry Costs.

z

#21
It looks like yesterday was the wrong day to have a sick day.  I'd like to start at the beginning here and work through the thread, as I think that the large issued raised at the beginning have a big effect on the issues raised in the rest of this thread.  I'll start with Chrisim's first post.

Quote from: Chrisim on January 11, 2009, 06:27:00 AM
When developing Lots... there is no force to work together. Everybody can publish his stuff himself under his name.

And therefore, you don't find lots in the NAM. Only stuff depending on the controller shall be included in the NAM. The NAM is defined exactly as collection of all traffic network related stuff that depends on the controller, and nothing in addition.

What about traffic simulators?  They certainly don't depend on the controller.  So your definition of the NAM appears to be incomplete.  And in fact, you can replace the word "lots" in the first paragraph with "traffic simulators," and the statement still reads correctly.  Yet no one would deny that traffic simulators are part of the NAM, and a very necessary part at that.  TE lots are also required for the proper functioning of the NAM; a NAM without TE lots to go with it is of very limited usefulness.  And the fact that most of this thread is devoted to discussing what the properties of TE lots should be is an implicit admission of their importance to the NAM.  So if traffic simulators can be part of the NAM, why not TE lots?  And it's not just traffic simulators; the current version of the NAM contains a Traffic Congestion View, which is completely different from both network pieces and traffic simulators.  So even at this stage, Chrisim's definition of the NAM doesn't encompass everything in it.  Essentially I am proposing that we recognize this, and recognize that our users are better served by a functional definition of the NAM, instead of an implementation-dependent definition.  For example, a first pass at such a functional definition would be "Networks and everything that deals directly with them."  Or, even more concise and more focused on functionality, "Everything that directly deals with transit."  When it comes to transit, you come to the NAM.  That doesn't mean that the NAM should include every MT station ever built.  But it does mean, as people are implicitly recognizing in this thread, that for the NAM to work smoothly, it needs to have authority over all areas of transit.  It also means that the NAM should provide a complete basic package for everything it introduces.  I'll elaborate on this last point later.

QuoteNAM deals with Networks and Networks only. Not Lots. There is a distinct difference between the two, internally. Networks are handled differently by the game compared to Lots, Lots like those used for a building for example. As such, there is a completely different process involved in the handling & creation of Network Related items compared to Lots.

Yes, internally, lots and networks are handled completely differently.  (Then again, traffic simulators and data views form yet other categories.)  But the NAM is developed for the user, and I think an important question we have to ask is, What does the user really want, and what does he or she find easiest to use?

For example, look how Maxis organized the game.  The rail menu contains the rail and monorail networks, along with their associated stations.  Similarly, the miscellaneous transit menu contains a mixture of networks, stations, and network transtitions that happen to be TE lots.  The NAM team has continued to observe this grouping method; networks and TE lots are mixed together in the same menus.  Not only does this not bother the user, but it seems a natural way to organize things.  The underlying idea, which is an important one in any UI, is that features are grouped together by functionality, not by details of implementation.  And the fact that TE lots and networks are implemented completely differently is, to the average user, just an implementation detail, and of no concern to them.  As such, in a good UI, it is hidden.

Here is an example from my own experience of the consequences of exposing these implementation details to the user:  When I first downloaded the NAM, I immediately started using the GLR.  I noticed that there was a transition piece for GLR to elevated rail, but nothing for GLR to subway, which I really wanted.  I searched the STEX for the latter piece, but I missed it, either due to the way I phrased my search, or by not recognizing its name.  It was months before I found the piece, and until then, I used all sorts of awkward workarounds in my cities.

Now, to everyone here, it's obvious why the GLR-to-elevated-rail piece was present in the NAM, while the GLR-to-subway piece was not.  The first is a puzzle piece, while the second is a TE lot.  But if you tell this to a typical user (who has probably never heard of TE lots), you may very well get a response such as, "So?  They perform the same function, don't they?"  And from a player's point of view, this user is absolutely correct; the two pieces are functionally equivalent.  The elevated rail is really no more like the GLR than the subway is, except at the implementation level.  So I think that it makes no sense to say to users, "No, we won't provide you with that transition piece because it's actually a TE lot.  But we'll provide you this other transition piece, because it's a puzzle piece."  To the user, both are network transition pieces, and both are functionally part of the network.  The user doesn't care about implementation details in this case, and shouldn't have to care.  Users simply want complete functionality with their networks, and it would seem to be the job of the NAM team to give it to them.

This is all I have time for now; I'll continue this later.  But first, I'll answer a simple but important question:

Quote from: jplumbley on January 12, 2009, 02:57:32 PM
Before we get into retro-fitting old Stations with new values.  I ran into a CTD issue with TE Lots approximately 9 months ago in March 08.  It was a while ago and its a little fuzzy so I dont know what exactly remember what the issue was.... I believe, if I remember correctly... That it was when changing the Transit Switches of a lot that was already plopped in-game.  This may not have an effect on the re-release of old lots, but it will have an effect if any of the old lots require updated Transit Switches.  I cannot go back and test this, because as stated above I do not have SC4 installed currently and well, I dont plan on installing it right now.  So, I would suggest whoever takes on this endevor that you test out the Transit Switches, Transit Switch Capacity and the Entry Cost properties before publically re-releasing any existing lots.

I do remember that the CTD was caused when you changed the exemplar of a lot that was plopped in-game before the changes were made.  By, reverting the exemplar back and re-entering the game the CTD was gone and you could bulldoze the lot and then make your changes.  As I said above, I believe it was the Transit Switches, but cant remember exactly.

This is an important question that Cogeo and I had to deal with when planning the next RTMT release.  I wanted to keep the same TGI IDs for everything, and simply change the exemplars, so that users could keep their old stations with the new release.  Cogeo expressed the same concern over the CTD problem as jplumbley does, but also couldn't remember the exact details.  So I did extensive experiments, plopping current stations, then changing, one by one, virtually every property in the examplar, and plopping the new stations.  I also changed the funding levels at many points in between.  None of this caused a CTD.

Further experimentation showed what the cases were that caused a CTD.  If a lot has a funding slider in its query, then if you change its exemplar without bulldozing the old lot, you will get a CTD when you attempt to move the slider on the old lot.  A classic example of this is the fixed opera house, or the private schools enhancement.  But since all TE lots have their funding controlled centrally, it never happens with them.

ScottFTL

Quote from: jplumbley on January 12, 2009, 02:57:32 PM
In any case, I would endorse the 0.029 value since it covers all networks and would be suitable for ALL TE Lots including Rail, Subway, etc.  This value would not need to change between Simulators because if you want to Standardize, you should base it on the slowest Bus Speed on Streets amongst all Simulators, since they really should not deviate to much from each other.

This seems like a good starting point, but I would like to clarify my understanding in this area.  For a network tile, the cost to travel is calculated by the formula 1/Speed.  If we apply the same formula to a TE lot, the cost to traverse the TE lot is the same as it would be to travel on the network.

If I am correct here, then this is the proper calculation for TE lots such as Road Top Mass Transit where you do not want to slow through traffic on the network.  However, I have the same questions as RippleJet...

Quote from: RippleJet on January 12, 2009, 04:18:10 PM
On the other hand, would there be any benefits from separating monorail, subway and train stations from this 0.029?
Looking at Scott's comparison, I wonder if we could use lower values for there (based on Christopher's formula),
e.g. 0.007 for monorail stations, 0.010 for subway stations and 0.013 for train stations.

I know there have been complaints about the monorail and rail usage not being high enough.
Maybe we could encourage these a little by reducing the entry costs, at least compared to bus stops?

In addition to reducing shortcutting, I believe we also want to replicate the real-world penalty for stations.  This is best illustrated with the example of commuter rail.  While an express train would pass a station at full speed, a local train would travel more slowly due to the time penalty of stopping at all stations.  So we would need to set the TSEC higher than the 1/Speed formula to reproduce this behavior.

While the value of 0.029 does meet this criteria, it could be too high in some cases.  For example, a monorail station with a TSEC of 0.029 would cost almost 6x more than the 1/Speed value of 0.005.  It seems like this could reduce usage, but obviously testing is required to validate the proper TSEC settings.

Quote from: z on January 12, 2009, 05:03:23 PM
Further experimentation showed what the cases were that caused a CTD.  If a lot has a funding slider in its query, then if you change its exemplar without bulldozing the old lot, you will get a CTD when you attempt to move the slider on the old lot.  A classic example of this is the fixed opera house, or the private schools enhancement.  But since all TE lots have their funding controlled centrally, it never happens with them.

It's good to know about this problem, even if it is a rare event.  Thanks for the information, Z.  I believe that users would have to delete and replop all transit stations anyway since the simulator will prefer the old stations with no entry cost.  I know there will be groans from some users, but fixing these stations could really add a new level to the game.  Sims would no longer simply prefer the network with the fastest speed - the layout would actually matter.

z

#23
This is a continuation of my previous post.  The next topic I wanted to address is the relation of MT stations to the NAM.  I think that the discussions for setting standards for these stations in this thread are very important, and I'll be contributing to them in a little while.  But first I want to start off with some larger questions, and then work down to the details.

There are two main issues that need to be addressed with stations:  Transit Switch Entry Cost, and capacity.  There has been much discussion on the first, and I'll delay any comments here, other than to say that I think the one wrong number here for any station is zero.  Capacities are a somewhat simpler issue to address.  The first question to address is, How many capacity levels should there be for a given station?  Almost all stations currently have a single capacity level, which to a large extent just depends on the feelings of the developer.  On the other hand, the current version of RTMT has five capacity levels for each station - one for each traffic simulator that existed when it was released.  If you were to add versions for Simulators A and B, that would bring it up to eight versions, and if you add in versions for Simulator Z, that would bring it up to twelve.  This is similar to the problem RippleJet expressed earlier, except where he has one lot to change, RTMT has dozens.  Dozens of lots times twelve simulator versions equals unmanageability.  Cogeo and I were in complete agreement about this for the next version of RTMT; we both wanted to reduce the number of versions, not increase them.  So a lot of thought has gone into this that I think applies equally to other MT stations.

First, the whole notion of separate capacity versions for each simulator capacity was reevaluated.  Traffic simulators and TE lots are obviously fundamentally different in many ways, but there's one difference that's especially applicable here.  At any point in the game you can swap out one simulator and swap in another (e.g., a higher capacity version) with no ill side effects.  After a settling period, essentially no traces of the previous simulator remain.  But that is not how MT stations work.  You can certainly swap in higher capacity versions of the same station with no ill side effects, but the stations that are already in place retain their old capacity.  To get the higher capacity version, you have to bulldoze the old station and plop a new one.  Since this can be a huge amount of work in large cities, you really want to avoid doing this.  So for the next release of RTMT, we are going to have exactly two versions of each station - Low and High capacity.  The Low capacity version is designed for rural areas and/or small- or medium-sized towns; it is basically designed for regions where there will never be a need for a traffic simulator with a capacity higher than the Hard version of Simulators A or B.  The High capacity version of RTMT stations is designed for all regions above that limit.  The High capacities were originally designed to be sufficient for the old CAM simulator, which has capacities not too far from the Easy level of Simulators A and B, but testing has shown that these capacities are sufficient all the way up to the Ultra level of Simulator Z.  So one thing I would propose here is just a slight variation on what Alex proposed on the previous page:  For all Maxis stations, there would be exemplars made for Standard, Low, and High capacity versions, which would be included with the NAM.  The appropriate version would be automatically installed whenever a traffic simulator was chosen.  The Standard version would have the same capacity as the original Maxis version, but it would have its Transit Switch Entry Cost set to the proper value, whatever that is determined to be.  It would be used only when the user chose the vanilla Maxis traffic simulator.  For custom-made stations, the Standard version could be optional, as the vast majority of custom-made stations already have higher capacities than the Maxis ones.

If people are interested in this proposal, I can publish the capacities we will be using for Low and High in RTMT, and explain in detail how they were reached.  It's not a simple relationship, though:

Quote from: RippleJet on January 11, 2009, 07:28:08 AM
For proper working all station capacities should be increased in the same proportion as the network capacities have been increased.

Unfortunately, this doesn't work; especially with the higher capacity simulators, this would give you stations with a fraction of the capacity of what's needed.  My experiments showed that the relationship between network capacity and proper station capacity is quite nonlinear.  Also, things like station size need to be taken into account; the figures I have compiled apply only to stations that are the same size as the basic Maxis ones.  Large bus terminals and huge train stations are obviously going to have higher capacities than the standard-sized versions of these stations; it may take some work to figure out what these capacities should be (both Low and High, if that system is used).

Dealing with updating the Maxis stations is fairly simple compared to the problem of updating all the other stations out there, on the LEX and otherwise:

Quote from: Andreas on January 12, 2009, 01:50:38 AM
I was asking how we can get those stations updated that have been released over the past few years, and which have been downloaded by thousands of SC4 players from all over the world. I can easily update all stations at SimCityKurier, for instance, but the players would have to download them again, and update their plugins folders accordingly.

This is indeed a crucial issue, and although it's from a discussion entry costs, it applies equally to the capacities question.  And it would certainly seem to make sense to address both questions at once, as that would be much less work in the end.  Just as RippleJet has said that NAM, or someone working with NAM, should provide update packages for the ingame stations, I think that the NAM team is the most reasonable body to set and enforce standards for custom stations as well.

In my next post, I'll spell out my proposal for updating custom stations.  I'll end this post by addressing a question that RippleJet asked.

Quote from: RippleJet on January 12, 2009, 04:18:10 PM
On the other hand, would there be any benefits from separating monorail, subway and train stations from this 0.029?
Looking at Scott's comparison, I wonder if we could use lower values for there (based on Christopher's foluma),
e.g. 0.007 for monorail stations, 0.010 for subway stations and 0.013 for train stations.

I know there have been complaints about the monorail and rail usage not being high enough.
Maybe we could encourage these a little by reducing the entry costs, at least compared to bus stops?

I would definitely recommend using the lower numbers for the rails.  In my experiments while building Simulator Z, I found that it did not take much at all to discourage Sims from using faster transport.  I explained some of my findings in this post; the Edits actually contain the most relevant information.

As for monorail and rail usage not being high enough, I found that some of this was due to reasons explained in the abovementioned post, while the rest was due to simulator bugs, which I fixed in Simulator Z.

Andreas

Another reason why there are no stations made by the NAM Team (at least not as part of the NAM) is the mere fact that the NAM Team members never were prolific BATters. Of course one could take existing models from other custom content creators, but in the entire history of the NAM, it was produced as "free of any dependencies". Comparing the NAM to the Rush Hour expansion doesn't really work as well, because RH is a full-blown expansion pack that doesn't have to care about other development groups, whereas the NAM is solely a transportation mod. I agree that it's not always clear (esp. for novice users), but from a technical point of view, the setup does make sense. In addition, browsing the LEX, STEX, PLEX, SimCityKurier or whatever download area will never give you an "all-inclusive" package like RH - there might be a nice set of suburban homes somewhere, but then you'll need an elementary school, a fire station, a few commercial lots and what not in order to complete your new suburb. Those are always individual uploads, so why it is so surprising that you'll have to download a GLR station separately as well?
Andreas

RippleJet

Quote from: z on January 13, 2009, 12:57:14 AM
Unfortunately, this doesn't work; especially with the higher capacity simulators, this would give you stations with a fraction of the capacity of what's needed.  My experiments showed that the relationship between network capacity and proper station capacity is quite nonlinear.

Is there any difference between ordinary stations and roadtop stations here?


Quote from: z on January 13, 2009, 12:57:14 AM
Also, things like station size need to be taken into account; the figures I have compiled apply only to stations that are the same size as the basic Maxis ones.  Large bus terminals and huge train stations are obviously going to have higher capacities than the standard-sized versions of these stations; it may take some work to figure out what these capacities should be (both Low and High, if that system is used).

Yes, both the size of the building and the size of the lot should have significance here.
Below are XML extracts from the "X Tool" giving the formulas for the Transit Switch Capacities.
These are extrapolated from those capacities Maxis gave their stations (Standard Network Capacities).

Bus Stop, Train Station, Garage
<eval name="TSCap" value="100*int((1000*sqrt(LotSizeX*LotSizeY)+Volume/10.)/100.)"/>

Subway Station, El-Rail Station, Monorail Station
<eval name="TSCap" value="100*int((2000*sqrt(LotSizeX*LotSizeY)+Volume/10.)/100.)"/>


Volume is the volume of the building: Filling Degree × Width × Depth × Height
LotSizeX and LotSizeY are the width and depth of the lot, in tiles.

daeley

I have the feeling there are two separate issues here, originally the question was "why are there no lots in the NAM", but it seems to me this is not the real core issue. In my opinion the core issue is: why are there no NAM standards for TE lots? I think the short answer to both questions would be:

a) because the NAM team decided they didn't want any lots in the NAM
b) because the issue was never adressed or discussed properly as is being done in this thread

I think this discussion is quite fruitful, and in fact a NAM standard for all TE capacities and entry costs would be a good thing. I also personally have the feeling that right now there are just simply too many traffic simulators out there and it's my personal feeling that maybe there is a need to select one or two "release" simulators and keep the others in the "experimental" tray.

Secondly, I'd like to chime in on Andreas' comment that comparing the NAM to Rush Hour is not fair: RH was made by a company to make money and is a full expansion, NAM is an addon made by hobby enthousiasts in their free time with no profit concerns. If they prefer not to put lots in the NAM, I can live with that.
1. Install SC4+RH
2. Install LEX (CD&DVD helps) and latest NAM + updates
3. Play the game
4. ? ? ? ?
5. Profit!

ScottFTL

Quote from: z on January 13, 2009, 12:57:14 AM
There are two main issues that need to be addressed with stations:  Transit Switch Entry Cost, and capacity.  There has been much discussion on the first, and I'll delay any comments here, other than to say that I think the one wrong number here for any station is zero.  Capacities are a somewhat simpler issue to address.  The first question to address is, How many capacity levels should there be for a given station?  Almost all stations currently have a single capacity level, which to a large extent just depends on the feelings of the developer.

Well said... "The wrong number for any station is zero."  I look forward to your contributions to the discussion about appropriate Transit Switch Entry Costs.

I agree that Capacity is another issue that should be addressed, and there are multiple issues when you start discussing Capacity.  Whatever the relationship between network and station capacity, it is a fact that the default capacities need to be modified to support the current and upcoming generations of traffic simulators.  Many custom stations were created with artificially high capacities in order to prevent congestion under the vanilla or previous generation traffic simulators.  It becomes more subjective, but the size of the station - including not just dimensions, but number of tracks for rail-based transit - is another factor to consider in setting proper capacities.

If we can keep the variations to a minimum as Z suggested, I think it is possible to update a fair amount of stations for both Capacity and TSEC.  I'd also like to point out that many stations have PIM defaults for other properties, such as Power Consumed 61 and Water Consumed 0.  I have also seen that many creators removed all pollution properties - and there are even a few station with improper transit switches.  However, aside from the transit switches, these are more annoyances than problems.

Quote from: z on January 13, 2009, 12:57:14 AM
My experiments showed that the relationship between network capacity and proper station capacity is quite nonlinear.

I'm wondering how you determined proper station capacity at all.  It seems quite subjective.  Is the capacity proper if it is extrapolated from Maxis stations?  Or is it a function of the network capacity?  I would imagine that you want a station to become congested when you reach a certain percentage of the network capacity, but that percentage would vary based on the size of the station.

Quote from: z on January 13, 2009, 12:57:14 AM
If people are interested in this proposal, I can publish the capacities we will be using for Low and High in RTMT, and explain in detail how they were reached.  It's not a simple relationship, though.

I would definitely be interested in how you reached the capacities for RTMT, whether in this thread or another one.

z

Quote from: z on January 13, 2009, 12:57:14 AM
Unfortunately, this doesn't work; especially with the higher capacity simulators, this would give you stations with a fraction of the capacity of what's needed.  My experiments showed that the relationship between network capacity and proper station capacity is quite nonlinear.

Quote from: RippleJet on January 13, 2009, 01:45:34 AM
Is there any difference between ordinary stations and roadtop stations here?

No, I tested both types of stations extensively and found that they required the same capacities, which makes sense to me.

Quote from: Andreas on January 13, 2009, 01:30:35 AM
Comparing the NAM to the Rush Hour expansion doesn't really work as well, because RH is a full-blown expansion pack that doesn't have to care about other development groups, whereas the NAM is solely a transportation mod.

I agree; both you and Daeley are right.  I was trying to make a certain point, but my analogy doesn't fit very well in retrospect.  I withdraw it.

RippleJet

Quote from: daeley on January 13, 2009, 02:05:44 AM
I have the feeling there are two separate issues here, originally the question was "why are there no lots in the NAM", but it seems to me this is not the real core issue. In my opinion the core issue is: why are there no NAM standards for TE lots?

That's a perfect analysis, Daeley! :)

Instead of making a comparison to RH, I'd like to make a comparison to CAM...

CAM does not include any new lots, and probably never will.
What CAM does include though, is a fix for certain in-game lots that needed to be tweaked in order to be CAMpatible.
In addition to this CAM has set up standards for how new CAMeLots should be modded for both old and new growth stages.

Contrary to Z, I don't think NAM would have to include new station lots, not even for the new networks that have been added.
What NAM should include though, is a fix for those in-game lots that need to be tweaked in order to NAMpatible.
NAM should set up standards for how new stations should be modded for both old and new transit networks and simulators.

The standards for CAMeLots are embedded into the "X Tool".
It's equally important that the standards for "NAMeLots" are embedded in the "X Tool" as well... ::)

z

My thoughts on these issues have been evolving through this discussion, as I have found it as fruitful as everyone else.  The CAM model was something that I was thinking more and more of myself, and I can say that at this point, I am completely in agreement with RippleJet's post directly above.  It seems like there is some consensus building here. :)

b22rian

#31
Quote from: z on January 13, 2009, 04:15:56 AM
My thoughts on these issues have been evolving through this discussion, as I have found it as fruitful as everyone else.  The CAM model was something that I was thinking more and more of myself, and I can say that at this point, I am completely in agreement with RippleJet's post directly above.  It seems like there is some consensus building here. :)

it is easily the best and most informative thread ive ever seen on devotion.. I would have to agree..

Quote from: daeley on January 13, 2009, 02:05:44 AM



I think this discussion is quite fruitful, and in fact a NAM standard for all TE capacities and entry costs would be a good thing. I also personally have the feeling that right now there are just simply too many traffic simulators out there and it's my personal feeling that maybe there is a need to select one or two "release" simulators and keep the others in the "experimental" tray.


I have to fully agree with this...
From having done extensive testing on all the traffic sims.. There are now clearly 2-3 traffic sims that stand out
above all the rest.. 2 of them are listed in the RHW thread as traffic sims, A and Z..and if the bug is fixed in traffic
sim B, than I would include that as a third option.. These 3 traffic sims have better path finding and there better
in other areas as well.. in addition each uses different difficulty settings..which should satisfy just about any gamer
The rest of the traffic sims out their to me are obsolete in
comparison.. and it makes no sense whatsoever for anyone to be using any of them.. So to me the first
step would be some "simplification" of reducing the number of traffic sims used to 2-3 .. and than go from there..

Quote from: daeley on January 13, 2009, 02:05:44 AM


Secondly, I'd like to chime in on Andreas' comment that comparing the NAM to Rush Hour is not fair: RH was made by a company to make money and is a full expansion, NAM is an addon made by hobby enthousiasts in their free time with no profit concerns. If they prefer not to put lots in the NAM, I can live with that.

there is one other option that can be used ,that I havent seen mentioned much here... and that is for players
to change their own settings for both the transit entry costs and station capacities, using the "illive reader"..
I suspect that the majority of players truly interested in the content of this thread are able and capable of
doing this... If not,, its really as most of you know not difficult to do...
Obviously the discussion here is most fruitful in determining what those values should be, and Im most grateful for
it.. But I will defer i think in determining exactly whose responsibility it should be to change all those value for
the older stations.. to the more knowledgeable people engaging in this wonderful discussion.. If a helpful patch were developed at some point , sure that would be great.. and obviously,
I wouldnt be against the idea of some future standards being set by the NAM in so far as any new stations
being developed in the future... I see no problem with doing this..

thanks, Brian

RippleJet

Quote from: b22rian on January 13, 2009, 05:20:40 AM
But I will defer i think in determining exactly whose responsibility it should be to change all those value for the older stations.. to the more knowledgeable people engaging in this wonderful discussion.. If a helpful patch were developed at some point , sure that would be great.. and obviously, I wouldnt be against the idea of some future standards being set by the NAM in so far as any new stations being developed in the future... I see no problem with doing this..

Whoever starts making those patches, would have to be someone having (or getting) access to the "X Tool".
That way not only these properties would be corrected, but also all the others, e.g. pollution, consumption, civic jobs, etc.

b22rian

Quote from: RippleJet on January 13, 2009, 05:59:35 AM
Whoever starts making those patches, would have to be someone having (or getting) access to the "X Tool".
That way not only these properties would be corrected, but also all the others, e.g. pollution, consumption, civic jobs, etc.

Yup good point and I agree totally.. that these aspects would also be affected..  So might be a possibility
to make such a patch in the future and than the station capacities could be left up to individual players
using the illive reader to change according to what each would want..I still agree with Z that the capacities
are also quite important in all this RE: his excellent discussion about it above..

Brian

Andreas

Adding some presets for those values in the X-Tool would be a good idea; it would also help the average user (once the X-Tool is published) to modify his files accordingly. The Reader is not exactly for the faint-hearted, and even SC4Tool can be a mystery for some, as you have to specify your own values (the embedded building database should provide some guidelines, though). I think the actual values are not that much important, but it is more important that the values of all lots that you have installed are in line with each other. Otherwise, some stations might get overcrowded very soon, while others "don't work at all" in the very same spot.

As usual, this requires much explanatory work on our behalf, so both custom content creators and players pick up the necessary tools and adjust their work properly. Once we managed to spread out the tools among the public, it would be easy to tell them "pick the preset that is named after the traffic plugin you installed" and apply that to all lots that are installed.
Andreas

k808j

In reference to making a patch for the older transit stations via the NAM group, I believe that most members of the LEX and STEX would support it, because a lot of us don't know how to change values.  The problem is would the NAM members want to do this or should another group be form just to handle patches of all sort?

L i s t e n  T o  O u r  F a m o u s  T h e m e
http://www.supload.com/listen?s=PVfnXk">We Are Borg

ScottFTL

Quote from: RippleJet on January 13, 2009, 05:59:35 AM
Whoever starts making those patches, would have to be someone having (or getting) access to the "X Tool".
That way not only these properties would be corrected, but also all the others, e.g. pollution, consumption, civic jobs, etc.

Ah, how could I forget about the jobs?  All of those stations in the wild with 100 jobs!  I almost forgot because I check and modify everything before using in my game, but it is an awful lot of work.

I don't have access to the "X Tool" but I would not be opposed to this.  ;D  Seriously, I am willing and able to help with this effort once we have consensus on some standards.

cogeo

#37
NAM is defined as Network Addon Mod, and this speaks for itself. So this should answer the question "Why no Lots in the NAM". To me this was a very reasonable decision. NAM is network stuff, no stations. And this is quite unlikely to change now, as almost all NAM memvers are transit networks modders, though many (I would say "most") of them are certainly capable of making good-behaving station lots. However the definition could be relaxed to include some TE lots that are not literally stations, but serve other functions. For example, the GLR-to-Subway Transition could had been done by the NAM Team. It's not a station, but connects the GLR to the subway network, something that's really useful and realistic too (in many real cities the subway network extends to the suburbs as ground light rail - emerges to ground level; they are the very same trains that run underground and overground). It wouldn't be bad, if NAM contained such TE lots. On the other hand, I con't see why the double-decker El-on-Road Station is refered to as "NAM Station".

And some replies to previous posts:

As for the Transit Switch Cost, I think this should rather be capped to 0.05 (maybe somewhat higher, but not much). This value causes a noticable effect on the stations' usage. A value of 0.10 causes a severe effect (the station becomes far less attractive). A value of 0.20 or 0.30 makes stations almost unusable. And these are absolute values (not related to the lots' size). These are test results. There have indeed been cases of stations with unreasonably high TSEC settings, rendering them almost unusable by many players. This was the result of the attempt to eliminate pedestrian shortcutting (calculation based on the pedestrian speed and the lot size). I think it's pointless to attempt eliminating shortcutting, without taking into account the effect on the stations' usage. The shortcutting problem mostly concerns large station lots (eg St Pancras, Gare du Nord), especially if they are surrounded by roads (which they usually are). I can't really think of any satisfactory solution for such cases: a TSEC value that could considerably reduce shortcutting would be so high that the station would be completely unusable. Maybe the way to go would be accept some (or unfortunately most) shortcutting, consider the station usage only, and maybe increase capacity to compensate for the (estimated) increased usage reported. Why is shortcutting considered so evil finally?

Indeed, trackside stations may cause passing trains to be somehow "teleported" through the stations. Proper setting of the TSEC property can eliminate the problem. In my Rural Rail Stations Pack I have lots 3-, 4- and 6-tiles long. Each one has a different TSEC value, resulted from experimentation. As we don't have real knowledge of the internals of the traffic simulators, and furthermore not its actual implementation (the source code) I haven't bothered establishng a "theory", and prefered to experiment instead. I tested values in steps of 0.01, trying to find the minimum value for which this "teleporting" does not occur. And of course, this does relate to the lots' length.

As for RTMT, I don't know if this has become clear, but RTMT has no issues at all with shortcutting. This is because of the way RTMT stations are modded and used. They are plopped on top of road a.o. networks, and the only transit switching takes plaace at the north and south sides of the lot. Except for cases of very strange network layouts, the east and west sides normally have no adjacent roads, so what shortcutting can really take place on roadtop lots? Shortcutting is a concern for roadside lots, lots plopped at corners or between roads, etc. So the TSEC setting is far less significant here. I think it should be set considering are the (average) speed of all transit types running through the lots. Another thing to consider is that players may have plopped a large number of stops/stations along some roads, so a value higher than the that corresponding to the network speed could cause a significant increase in commute times.

RTMT stations capacities relate to the network capacities, as the through traffic is added to the stations' usage. This is a poor implementation by Maxis (subways don't have this problem) which I think originates from the tollbooth, the only roadtop Maxis lot: it has to report the through traffic as "usage", in order to collect fares based on the uasge (by employing the Transit Switch Entry Fares property). RTMT stations are not tollbooths (and the fares setting is of course 0). The "problem" is that the through traffic is considered usage. Therefore capacities must be increased by the estimated through traffic. So capacities for RTMT (currently) consist of two components, the "net" station capacity ("net" here doesn't mean "network", it's an adjective, the opposite of "gross") and another one that compensates for the through traffic. If you check the capacities in the menu and the query, you will notice that they differ. The former is the "targeted net capacity" (which is the same for all NAM capacities plugin), while the latter is the total ("gross") capacity. Maintenance costs are on par with the Maxis standards, that is $5/1000 pax for the "slow" transit types (bus, train) and $10/1000 pax for the "fast" types (subway, el/GLR, monorail), rounded (up) to the closest multiple of $5. Of course, this calculation is based on the net capacity, not the total one. This is explained in more detail in the RTMT readme. I don't know if this is going to be kept in the next versions. One may argue about the values (eg if the calculation of the estimated through traffic is correct), but I think the approach does make sense.

Chrisim

#38
Discussions are great but game tests are better. I wanted to understand the Maxis rail stations better and I wanted to create support for my arguments in my second posting in this topic:
Quote from: Chrisim on January 11, 2009, 02:23:54 PMFirst, railways stations plopped next to rail track should always have a zero entry cost.
A 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. For a four tiles long stations and a standard speed of 110, it is 4/110=0.036
I believe this equals Cogeo's formula.
If you put a larger number, rail traffic is penalized versus car traffic and less passengers will use rail, especially when many "ontop" rail stations are used and their spacing is dense. If the value is much too high, it may block rail traffic through the station.
A station with zero entry cost is a minor cheat because Sims will jump with infinite velocity through the station, but the impact on the overall traffic is small.
The test described below showed that my first argument was wrong. But it confirmed my other arguments: Cogeo's formula is fine, Mott's formula gives much too high values (rail traffic is penalized and car traffic increased). And a value of zero is not right, but not really a major problem.

Here are the details: I created the following test city that I ran from scratch for each scenario. No plugins except NAM, using the standard C simulator (the default Maxis simulator).

Industry and Commercial area is away from the residential area and these zones are connected by a single rail line on the left and a rail line parallel to a road on the right. The right picture shows how it looked like after three years: a test town, not beautiful.

For each scenario, I noted the rail usage on the patch between residential and commercial zones,

and car usage on the road, and the table on the right shows the results

TSEC is the transit switch entry cost, from 0 (Maxis), via 0.0091 (my default value 1/rail speed), 0.02 (Cogeo's standard), 0.0273 (3/rail speed, because the station is 3 tiles long), 0.2 to 1 (close to Motts value for this station).
Since I started the town from scratch each time, the houses, commerce and industry grew differently and this also had an effect on total traffic numbers. However, the trends are clear: For TSEC=0, the rail usage is highest. Car usage drastically increases with TSEC=0.2 and higher. So, the value's from Mott's formula, that is presently implemented in the X-Tool and that were used for the recent SFBT stations, these are too high because they reduce rail usage, in particular when rail tracks are close to roads.

Next step was to look closer at TSEC=0 which is Maxis' value for the station. When looking at the traffic volume display for passenger trains (left picture), there are blue colors indicating a good usage of railways, but at stations there is one white tile. When querying, it became clear: 269 trains passengers came from the south (bottom of picture), 273 were the first rail tile next to the station (apparently 4 boarded the train), on the second rail tile next to the station there were only 34 passengers and on the third rail tile next to the station, there were 341 passengers (same number as several tiles further in the middle between residential and commercial zones). The right picture shows the usage when clicking onto the station

It is obvious: 90% of the passengers leave the train to buy a newspaper or sandwich. Unrealistic. And worse, the pink arrows show that many passengers (about 300 according to the station usage) run through the station and board the train on the third tile. These are the short cutting pedestrians that are avoided by using Mott's formula.
Let's try the same with TSEC=0.02. When looking at the traffic volume display for passenger trains (left picture), there are blue colors indicating a good usage of railways and no white tiles at stations. When querying, 179 trains passengers came from the south (bottom of picture), 235 were the first rail tile next to the station (3 left the train and 59 boarded the train), on the second rail tile next to the station there were 239 passengers (4 more passengers boarded the train) and on the third rail tile next to the station, there were 242 passengers (3 more passengers boarded the train). 3+59+4+3 gives 69 passengers who used the station. Capacity is not a problem for stations next to the track. The vast majority stayed on the train and just very few passenger took a short cut through the station. The right picture shows the usage when clicking onto the station - on first glance there are may pink arrows suggesting short cutting, but the actual numbers are very low. Don't trust the arrows, an arrow may represent a single or hundreds of pedestrians.

The table above had shown that rail traffic is reduced more than car traffic, when going from 0 to 0.02. The fact that both were reduced is probably due to the fact that I started each scenario from scratch (empty town) and for each case it developed differently.

A large value (according to Mott's formula = the present X tool formula) prevents 100% of the pedestrians to take a short cut through the station, but it also significantly reduced rail traffic and encourages car usage. A medium value (in the order of 0.02, according to 2/speed) prevents most of the short cuts and causes a slight reduction of rail traffic. A value of zero is most eco-friendly, because rail traffic is highest, but most rail passengers leave the train, short cut through the station and board the train again. Although this is unrealistic, it's not a major problem for this special station plopped next to the rail track, as long as the capacity of the station is high enough. I will use 0.0091 (1/speed) for this station from now on, as best compromise, although I do expect much protests from the local newspaper and sandwich shops owners in these stations  ;)

I started testing one of Ill Tonkso's stations that is plopped on top of the tracks, but it became clear that the transit switch point values were wrong. Only cars could enter (no pedestrians) and only pedestrians could leave (no cars). Transit switch point values are very important and much more difficult to mod correctly than the transit switch entry cost or capacity ...

While I was writing this posting, Cogeo posted. It gives a much wider overview than my simple test that concentrated on rail and one type of station only, but to me Cogeo's conclusions sound right and consistent with my experiences (except that I insist that TE-lots do not belong into the NAM)

SimGoober

Ok, I wanted to chime in here as a BATter, as opposed to the many MODders who are figuring this thing out.  First off, thank god someone is figuring this out, and secondly, that it is not me!   :D

I get enough out of this discussion to understand it is important and worthwhile, but also learned that I am hopelessly behind in the tech end of it.

As a BATter, I can say that I tend to be a little defensive when people tell me what capacities my buildings should be.  Here, I am referring to RCI capacities, not traffic.  For the most part, the X-Tool provides good rounded numbers I agree with, though I tweak them here and there as necessity dictates.  Every so often, I get arguments that these are not "realistic" numbers.  My answer is that they seem to work best with the game simulator, which is why I use them.  I only state this to preface my next point.

For traffic enabled lots, or stations (of which I have several out there), I have always used default values, except capacity, which i used what I thought worked best in the game as I was playing it.  I can now see where the "standard" for these lots needs to be a little more set in stone, to keep the game balanced.  I have no problem agreeing to using these standards, and endorsing them.

As a BATter, with limited abilities in modding, I would appreciate and eventual guidebook of sorts to use as a basis for all newer stations.  For example, bus stations should be one of X number of sizes (small, medium, large?) and each should use these properties to be balanced with the current NAM release.  X-Tool can incorporate the base values here, but sometimes the creator of the lot needs to determine which level that lot is (small, medium,large).   That might be something else that could be incorporated into the X-Tool : Select the size of this station you want it to represent... (?)

Once this discussion is complete, and numbers are agreed to, I will volunteeer to update my older lots, and release updates as per the standards agreed upon.
When life just blows ... Fukitol!