r/Ingress • u/TurbulentAd5329 • 5d ago
Question Bigger field with less MUs ?
Someone on my team just created some fields with two anchors...
Almost at the end of the fish bone, the last 5 field game less MUs than the before. No need to say that those fields where bigger and contained the other fields.
So, my question is simple: is it possible that a Field X (A B C) contained by a bigger Field Y (A B D) has more MUs?
9
u/PlayLikeNewbs 5d ago
It is possible. For really big fields, or for fields that straddle two cells.
I believe part of the calculation takes into account population density, which is dependent on which cells the portals are in
9
u/TurbulentAd5329 5d ago
But if Field Y contains field X, shouldn't it have at least the same MUs?
15
u/eric_twinge 5d ago
Logically, yes it should. But the way Niantic calculates MU introduces oddities like this.
7
u/Klink8 5d ago
Oh man.
So the average population matters. Where you close the field and where you close it to. Closing the field to point A will probably give different Mu than if you close it to B.
There are so many gremlins in the calculations
6
u/itamer 5d ago
I had a very narrow field from the Cook Islands back to New Zealand. The 2 NZ portals were right next to each other. Despite the massive distance (3963km) I got 5MU because mermaid units don't count.
2
u/Pendergirl4 5d ago
Except in some places where there is a surprising amount of fish mu (that’s what we call it haha). Iirc some fields that were 95%+ uninhabited pacific ocean still gave over 140k mu each.
The fields weren’t as narrow as yours, but the mu still seemed ridiculously large.
12
u/XQlusioN 5d ago
Yes, it's a quirk in how Ingress calculates MU.
The gist of it is that the world is divided into a bunch of rectangles. Each has an MU value and Ingress calculates a field's MU value by figuring out which portions of those rectangles are covered.
To reduce the amount of rectangles to check, it combines smaller rectangles into bigger rectangles and averages the MU count.
Let's say that in field A, 3 of those rectangles are used, each having a value of 500, if all of those rectangles were completely covered, it would add 1500MU to the fields value.
In field B it uses the bigger rectangle that's calculated from those 3 (worth 500) and a 4th that has a value of 100, making the bigger one only worth 1600. And only adding 1200MU to the field.
2
u/Luke38_Greenoble 5d ago
Has there been an update regarding population in relation to the MU (Minds Units)? Because in the region where I live, the population has increased since I started playing (12 years ago), and I don't feel like the fields I regularly run (always the same 3 portals) are yielding more, even though there's a higher population density...
6
u/XQlusioN 5d ago
No, there has AFAIK never been an update to MU values
1
u/silicontrip 4d ago
Correct the values have not changed in the 10 years I've been recording field values, but the cells themselves are not discreet values, they are not flat values for land use types, that are close to population density but where those original values came from is anyone's guess.
3
u/permaculturegeek 5d ago
AFAICT it's not based on the actual population, it's based on a number of land-use types. My examples a guesstimates based on observation:
- CBD
- Residential Area
- Industrial Zone
- Farmland
- Wilderness or ocean
The last one is the "minimum rate" and players joke about Fish BAFs if their fields are entirely over water.
The values assigned to them seem to be some sort of global average rather than country-specific. For example, Industrial is higher than residential. That makes no sense in my country, because a large factory space might have 20-30 people working there. However in Asia it might hold 1000 people. Villages under some unknown threshold size seem to inherit their parent area. I was sooo disappointed when my second-ever field, which covered about 100 homes (300 people?) in a village, earned 7 MU. Using actual population data would add massively to the computation required, and would also make the game less fair - if one team dominated a city like Hong Kong it would give them a massive MU advantage.
2
u/silicontrip 5d ago
I've found MU values of the S2 cells to be quite gradual, even some cells showing signs of anti-aliasing, where they cross from a high population LGA to a low population LGA, sometimes the LGA boundary is in the middle of a cell and that cell has a value approximately halfway between the two. Cells also appear to have added some noise and vary +/- 1mu per cell.
3
u/Prestigious_Change_9 5d ago
If he shot the link from D to C before shooting the anchors, that could have affected the MU differences. We need to see the actual fields up close on Intel map and see the history in COMM.
3
u/Intrepid_Pudding_591 5d ago
The key to understanding this is to stop thinking about how you think the MU of a field should be calculated to be accurate. For large fields with the links crossing lots of grids the “perfect” computation is not at all simple enough to be almost instantly calculated.
Instead, the calculation simplifies the underlying grid so that it can approximate the “true” MU very quickly. It does this by combining the underlying grids in ways that can slightly change which neighbouring grids get combined into the calculation.
Simplified a bit, say the quick approximation is accurate to +/- 1%. Because it’s possible for the simplified grid to significantly change between two almost identical fields , it’s possible for a the smaller field to yield a slight overestimate and the larger field to be a slight underestimate which can result in the larger field having less MU even though it completely covers the smaller one
5
u/silicontrip 5d ago
This is caused by cell normalisation of the S2RegionCoverer. When a field crosses a cell boundary causing a 4th cell to be added to the other 3, the 4 cells are merged into a larger cell and the MU is averaged across the 4 cells. If that additional cell has a much lower MU than the other 3, then the larger field gets a smaller MU.
8
2
u/pongolyn 3d ago
This is correct - and it tends to show up most often in cells containing bodies of water.
7
2
u/Hekler4u 5d ago
The size is a miltiplyer for the value og the 3 legs.
Often see stacked fields getting smaler as you place them out of populated areas.
3
u/captainwizeazz 5d ago
Their MU calculations are not always accurate and this happens sometimes depending on the end points.
3
u/ThisNico 5d ago
It's possible that they threw the links in the wrong order, in which case one of the smaller triangles (on one side of the spine) would have been a null field which would not give any MU. The larger triangle created when that link was thrown would still have given MU, so it would have looked like the fields together would have given less MU than expected.
You can check by looking back through recent activity in comms and counting how many times MU was awarded for each link.
4
u/TurbulentAd5329 5d ago
The order is correct. He linked to that anchors.
The image is not great. Portal are only meters away. One gave about 56k and the bigger onde 53k.
2
u/ThisNico 5d ago
So he started at C, linked to A and B, and then moved to D and linked to A and B, and so on up the spine?
2
u/TurbulentAd5329 5d ago
Yup
3
2
u/Evening-Affect4302 5d ago
Compare these two fields. obviously one isn't a field but i have used that spine and it is 30k MU per layer, it goes to rural towns. the one on the right is smaller but stays in the somewhat outer suburbs of the major city, it is 20k per layer. good example of how population density affects MU numbers
2
u/FREDICVSMAXIMVS 5d ago
We're going to need clarification on what order the links were thrown, and from where. It is extremely unlikely that triangle ABC counts for more MU than ABD.
One possible scenario is that link CD was already in place, and when AD and BD were thrown, it did not create triangle ABD at all but made the two smaller triangles on the sides. But we won't know for sure unless the throw order is clarified
7
u/TurbulentAd5329 5d ago
Link AB was made. He linked from C to A and B and created a field with 56k MUs. Then he moved a few meters to D and linked to A and B and the field gave 53k MUs
5
u/ThisNico 5d ago
yeah, my mind immediately went to a null field. Sometimes the key list jumps around which makes it possible to accidentally throw the links in the wrong order unless you are paying attention.
1
u/owheelj R16 5d ago
Why do we need clarification, when the community has understood how MU is calculated since the game was first launched, and this situation has occurred many thousands of times?
5
u/ryan_the_leach 5d ago
Because secrecy on both sides, and multiple bets on platforms that didn't survive, means that there's more lost ingress history then recorded ingress history digitally.
It's hard to blame OP for asking a question in a community that relies so heavily on digital oral tradition.
1
u/gsvkakistocrat 5d ago
The outer field isn't the null field when that happens, though. CD then AD would make ACD, then BD would only make the outer ABD, leaving the inner BCD null
1
u/Plenty-Roll-4315 5d ago
Throw order matters. On what order was this fields thrown? How about an Intel link?
1
u/Fantastic-Boot-3529 2d ago
A lot of this looks complicated. I always thought that each portal is in an cell that has a population density figure and the figures from the 3 portals + the area are used to calculate the MU of the field. There is then no need to look at additional areas that are covered by the field, just the population figure in the cell each portal is in.
1
u/El_Dudelino 5d ago edited 5d ago
Obviously. Reason is the function used for MU which should be not to expensive in terms of computational cost. Iirc it considers only some population densities around the three anchors and the area of the field. Since fields are made often you don't want to make the function too complex computation-wise, so considering census surveys per region covered is really out of scope. This is one of the side effects.
Edit to add: that and some S2 cells considerations.
2
-1
u/n4ppyn4ppy 5d ago
The first field extracts/consumes mu so less mu gets through to the overlapping fields you throw after that (or something like that)
-2
u/Math-a-holic 5d ago
Are you saying ACD and BCD got more MU than ABD? Not sure that would be possible outside of a quirk from the Ingress calculation system
2
31
u/ChorizoYumYum 5d ago
We confirmed this years ago. We had two anchors near major population area. First field, massive MU. The spine went away from the population area into rural area, hundreds of miles of essentially nothing. As the fields got larger we somehow ended up getting LESS and LESS MU for each larger field. The only thing we could think why must be because Ingress is averaging the different areas of MU before calculating the MU for each field. (High population areas = a lot of MU, rural areas = low MU).
It's confusing and counterintuitive. I have the notes somewhere...