NAM Demand Cap Relief for Neighbor Connections

[Kel9509 1,475]

In finalizing my Dept of Transportation query, I was looking into the way Demand Cap relief works for Neighbor Connections.  I found this old thread at SC4Devotion which discusses neighbor connections and how demand caps actually work, testing against the Prima Strategy Guide and noting that some errors exist.  In particular:

Quote

Cap Relief = baseCap * ( A + B*ln(c) + C*n/c ), where:

A, B, C = constants for each type of connection
c = total number of connections of this type in the city
n = number of neighbors this type connects to in the city

baseCap = the cap relief you get if this is the very first connection you make in the city.
- Elevated Highway: 160k
- Ground Highway: 100k
- Avenue: 32k
- Road / Rail: 10k
- Subway / Elevated Rail / Monorail: 20k

The first "ln" part of the equation covers the regular diminishing returns from more connections.

The second "n/c" part covers the bonus from making connections to new neighbors, along with again diminishing returns.

- highway/avenue: 0.65 + 0.9*ln(c) + 0.35*n/c
- road/rail/subway/elevated rail: 1.5*ln(c) + n/c
- monorail: 1.5*ln(n)

Errors are noted, in particular:

Quote

- Elevated Rail and Subway are counted together; they are the same type. Rail and Elevated Rail are independent.

- Monorail is bugged. Apparently, n is used in place of c, and this makes the second part of the equation useless. As a result, cap relief is obtained only from one Monorail connection to each city; further connections do nothing. Also, the very first Monorail connection in the city does nothing at all, it counts as 0; which is also in line with the equation. Furthermore, if you have another type of connection to a neighbor, making a Monorail connection to that neighbor has no effect at all!

- Ground Highway is similarly bugged. It uses n in place of c. But it still works if other types of connections are present to the neighbor. Still, another issue with Ground Highway is that it uses a baseCap of 100k, instead of 160k on Elevated Highways. Both highways are counted together as one type, and Ground Highways dilute the total cap relief you gain from highways. Thus, Ground Highways are strictly inferior to Elevated Highways in terms of cap relief.

My question is: I assume Realhighway neighbor connections provide the lowest form of Demand Cap Relief, if any?  As is, an initial connection to a neighbor for an elevated Maxis highway should provide 160,000 in demand cap relief.  But since RealHighway is based off of an unused network type in-game, does it provide any cap relief at all?

If RealHighway doesn't provide any cap relief at all, would it be possible for @memo's NAM.DLL mod to implement demand cap relief for RealHighway neighbor connections?  It might be easy because the neighbor connection for Realhighway still requires using the neighbor connection plop-piece for an actual connection to occur.

Similarly, could the NAM.DLL possibly fix the errors for Monorail and Ground Highway, as indicated in the linked post?  I haven't independently verified these issues or the equation proposed by the thread, but I have little reason to doubt them for now.

[Ulisse Wolf 4,426]

2 hours ago, Kel9509 said:

If RealHighway doesn't provide any cap relief at all, would it be possible for @memo's NAM.DLL mod to implement demand cap relief for RealHighway neighbor connections?  It might be easy because the neighbor connection for Realhighway still requires using the neighbor connection plop-piece for an actual connection to occur.

Technically, the patch for this issue already exists but is only available on CAM (from CAM 1.0)

 

[Kel9509 1,475]

40 minutes ago, Ulisse Wolf said:

Technically, the patch for this issue already exists but is only available on CAM (from CAM 1.0)

That is interesting.  I looked through the CAM documentation and did not see anything about this at all.  I thought that the neighbor connection demand caps were not set via exemplar, but through the executable (hence, possibly using the NAM.DLL).  But if they're in an exemplar and can easily be edited, why hasn't the NAM fixed this yet?

[Ulisse Wolf 4,426]

1 minute ago, Kel9509 said:

That is interesting.  I looked through the CAM documentation and did not see anything about this at all.  I thought that the neighbor connection demand caps were not set via exemplar, but through the executable (hence, possibly using the NAM.DLL).  But if they're in an exemplar and can easily be edited, why hasn't the NAM fixed this yet?

It is part of that series of Exemplar RCI that need to be edited only once because they are too powerful. The developers of CAM 1.0 introduced the fix first, and since then there has been a sort of stalemate between CAM and NAM.

https://www.sc4devotion.com/forums/index.php?topic=17318.msg505066#msg505066

[Kel9509 1,475]

34 minutes ago, Ulisse Wolf said:

It is part of that series of Exemplar RCI that need to be edited only once because they are too powerful. The developers of CAM 1.0 introduced the fix first, and since then there has been a sort of stalemate between CAM and NAM.

https://www.sc4devotion.com/forums/index.php?topic=17318.msg505066#msg505066

I see.  I can understand that in the past there was a stalemate, but with exemplar patching should that still be an issue nowadays?  You'd know better than anyone, but editing the RCI exemplars for demand caps for CAM to increase stages up to 15 can probably be done only for CAM, while the dirt road network demand cap amount can probably be separately handled by NAM, if done with proper exemplar patching.

This would make the NAM's Realhighway network work entirely as intended as a demand cap lifter for those who do not use CAM.

If it can be done, I propose that the NAM take over the dirt road demand cap in an exemplar patch.

Also, it'd be nice if the Ground highways and Elevated highways provided the same CAP relief.  Not sure if CAM (and hopefully NAM) has or can fix that issue that was previously identified as well.

[Ulisse Wolf 4,426]

1 minute ago, Kel9509 said:

If it can be done, I propose that the NAM take over the dirt road demand cap in an exemplar patch.

It's not easy even with Exemplar Patch because there is always a conflict between NAM and CAM. There has been discussion in the past, but nothing has been done because the files are too risky to modify.

[Kel9509 1,475]

2 minutes ago, Ulisse Wolf said:

It's not easy even with Exemplar Patch because there is always a conflict between NAM and CAM. There has been discussion in the past, but nothing has been done because the files are too risky to modify.

Then there should be an optional NAM patch for people who do not use CAM.  That way they can get the benefit of the demand cap relief.  

There are always risks.  But exemplar patching is the safest way to manage this nowadays because no core files are directly affected any longer.  If the I-R fix is ok as a standalone file, I'm not sure why this can't be.

[Kel9509 1,475]

I'd like to release a NAM-only patch for this issue, as an exemplar patch to update 0xA1F38C5.  I feel this is important enough that it should not be limited only to people using CAM.  I understand that there's probably a push to get people to use CAM 3.0 as much as possible, but it is not right that this fix be limited to CAM.  I just need to figure out the rest of the properties from 0xA1F38C5.  There are clearly entries which correspond to roads, rail, and highways, and zero-entries which probably are the dirt-road entries.  I just need to be sure.

I'd be interested in hearing from others on the NAM team on this issue as well.

[Ulisse Wolf 4,426]

Just now, Kel9509 said:

I'd like to release a NAM-only patch for this issue, as an exemplar patch to update 0xA1F38C5.  I feel this is important enough that it should not be limited only to people using CAM.  I understand that there's probably a push to get people to use CAM 3.0 as much as possible, but it is not right that this fix be limited to CAM.  I just need to figure out the rest of the properties from 0xA1F38C5.  There are clearly entries which correspond to roads, rail, and highways, and zero-entries which probably are the dirt-road entries.  I just need to be sure.

I'd be interested in hearing from others on the NAM team on this issue as well.

There was a discussion within the NAM team and the verdict is that we cannot find an ideal solution to this problem.

The issues encountered are

• If you use Exemplar Patch, then NAM depends on an external dependency, and no one on the NAM Team wants NAM to depend on an external mod.
• If you use the Exemplar Patch version, the CAM version will be overwritten, and we do not yet know the extent of the changes made from CAM 1.0 to CAM 2.1.1.
• If you create a dat file that contains modified Exemplar, this will create a conflict with CAM, and no one wants to return to the days when CAM and NAM were considered incompatible, as NAM will overwrite the CAM version.

Ideal solutions are being studied, also taking into account the change in the NAM architecture based on DLL Mods.

[Tarkus 6,932]

13 hours ago, Ulisse Wolf said:

• If you create a dat file that contains modified Exemplar, this will create a conflict with CAM, and no one wants to return to the days when CAM and NAM were considered incompatible, as NAM will overwrite the CAM version.

Fundamentally, the NAM and CAM weren't considered incompatible, particularly early in the going.  CAM 1.0, released in 2007, did include its own set of Traffic Simulator Plugins, which were designed by the NAM Team's jplumbley, who worked with mott/mayormot a few months later to develop the NAM's old Simulators A and B.  2007 was kind of the Wild West as far as Traffic Simulator plugins went, and got even more so as the Traffic Simulator Wars raged from 2008 to 2010, prior to the NAM Team streamlining things and officially adopting z1's Simulator Z (all five flavors of it) as the official NAM Simulator with the release of NAM 28 in May 2010.

jplumbley himself recommended that CAM users run the newer NAM Simulators instead of the CAM Simulators, and this was generally echoed by RippleJet and others involved with the CAM enterprise at the time.  I don't think the CAM Traffic Simulators really had much of a userbase after that.  Between Simulators A and B being incorporated into the NAM proper (starting with Version 23 in April 2008--they were first offered as a separate download in late 2007) and the end of the Traffic Simulator Wars, the NAM also still offered the original Standard, Better Pathfinding, and Perfect Pathfinding options, which were renamed as Simulators C, D, and E, respectively.  Simulator C was essentially no different from the Maxis simulator, save for specifying a speed for the DirtRoad/RHW network, so the CAM options were in fact a step up from that (they actually used the same Pathfinding Heuristic value--0.0465--as the NAM's Simulator D/Better Pathfinding, as jplumbley didn't believe in Perfect Pathfinding).

While the NAM officially only supported the simulators that were available under the team's banner at the time, up until 2009, pretty much every Traffic Simulator Plugin out there was considered at least NAM-compatible if it specified speed and capacity for the DirtRoad/RHW network--the CAM Simulators count in that regard.  However, the expansion of the RHW into multi-tile networking and the introduction of the NWM started changing the standards after that point, especially as the userbase for those plugins grew rapidly.  Simulators C, D, and E didn't meet those new standards at all, and B only partially did.  (Z does--and actually, A does as well, albeit without Perfect Pathfinding.)

CAM/NAM Traffic Simulator history aside . . . as Ulisse and I have been discussing, if unified settings can be agreed upon for the Neighbor Connection Demand Cap Relief for both CAM and non-CAM with NAM options, it should solve a lot of the issues and make something like this more viable.

-Tarkus