The "link limit" of ZK v1.2.7.7 is different than "no link limit" of ZK v1.2.7.9. The "link limit" of ZK v1.2.7.7 is to prevent overpowering Felon , while "no link limit" of v1.2.7.9 is meant that the link isn't permanent. (the author of the code is not same people, thus ot explain this semantic issue)

In ZK v1.2.7.7 the link is always connected to a same nearby shield and Felon was set to have link-limit of 5. Other unit is set to maximum 1 link. You can see the visualization of link as always present and non-changing.

In ZK v1.2.7.9 the link only activate when unit want to share charge, and each unit connect 1 link to a random partner. Some unit might have additional link greater than 1 depended on whether nearby partner wanted to link to it or to other unit. This appear as flash of purple line.

The negative of ZK v1.2.7.7 is: the link is fixed & might connect to bad shield unit (bottleneck). The negative of ZK v1.2.7.9 is: Felon is not set to have 5 link, and link can randomly connect to bad shield unit.

What's the point of including the unit itself? To make charging slower (halved speed for grid of only 2 shields, speed penalty quickly diminishing the more nearby shields there are)?

So, if you wanted to use regen optimally, you'd want whatever is consuming your shield charge to be only connected to your group of thugs, and those thugs then (on the other side) connected to large shields.

The dynamic that any shield with charge > thug (max) charge does not benefit from thug regen is interesting, but not new iirc.
For example, large shields with thug/convict support will first recharge very quickly after taking a big hit (tac nuke/sniper shot), but then will recharge way slower when surpassing the thug shield charges.

On another note, the system as you explained means that if you have x thugs in one ball and an empty shield touching exactly one of the thugs, then charge rate to the empty shield goes down the higher x gets. I find that unintuitive at best and (mechanically) unreasonable at worst... Is that part of the design idea?

Edited my post with a few more questions.

We have some decent to excellent mathematicians/computer scientists around. If you clearly formulate design goals and intended rules/outcomes, people might be keen on devising algorithms for achieving just that, including run speed constraints.

I mean, you seem to be happy with the current shield link code, so maybe not in this case, but just think along the lines of the elo balance thread or OD fix.

Fealthas: Yes to all. I mean, aside from the fact that the "no sharing to higher than own max shields" was present before.

quote: a shielded unit cannot transfer shield power to a unit with a higher shield max past its own max shield value

This is because Thug's charging is free. If thug can push excess charge to Aspis, then you can basically charge Aspis for free! So it is disallowed.

If diminishing returns with higher shield count means that it is less desirable, then yes.

This goes back to xponen's local shield link change from about 9 months ago. First I will explain the behaviour from earlier. I will call the first system global shield link.

A network of shields is a connected bunch of shields (or more precisely; a maximal connected component of the graph). Global shield link acted on networks of shields without taking into account their shape. The charge distribution of this system was very simple. Every frame (30 times a second):

• Take the average charge of the shields in the network (charge sum)/(shields in network).
• Move every shield in the network 1% closer to the average.
• Track overflow (charge being given to low max capacity shields) and redistribute this to shields with spare capacity.

So to use my previous example you have a shield with 500 charge and a shield with 200 charge. The average charge is 350, 350-500

-150 and 200-350

150. Then the charges on the next frame are 498.5 and 201.5.

It was long thought that global shield link was a bit simple. In large porc games people could just make a single massive shield network. A lot of interesting potential problems in the shape of the network were being overlooked (such as bottlenecks and attacking points with poor shape). It would have been nice to make shield link local somehow but I had not written that gadget and did not spend much time considering the problem. I am not sure if I even got the point of realizing that the problem is poorly defined.

About 9 months ago xponen spent some time making shield link local and I accepted that he had done so without looking at it in depth. Then more recently there was an update to the way the links were drawn. I had a closer look at this change and ran a few tests to make sure the whole gadget worked. At this point I noticed strange behaviour.

I do not know the extent of what was wrong with the v1.2.7.7 shield link. My main test was 10 Thugs attached to a Felon all in a clump. In this test 5 of the Thugs were very efficient at moving their charge to the Felon (much more efficient than I recall) and the other 5 sat at about 40% shield. This behaviour lacks symmetry and is arbitrarily based on which unit happened to link up so it makes no sense. I don't want some sort of complicated arbitrary system which has limited links and priorities set for each type of shield. A more practical result is that the new shield link seemed to have faster charge transfer which acted as a stealth buff for Felon.

I began rewriting a lot of the shield link gadget. I suppose I had two design goals:

• When all the shields are in a clump the behaviour should collapse to the global case. This is what the xponen version fails to do.
• It should do "local stuff" (bottlenecking, network flow).

Another thing to keep in mind is that shield link is not some helpful unit AI. The mechanics should not need to be fought against but they will also not always implement smart or useful behaviour. It should be mechanically simple and leave it to players to figure out how to use it to their advantage.

I think my random neighbour transfer is close to achieving these goals. I have shown examples of the two shield case under both the global and random transfer systems.

The many Thugs + 1 Felon case is also theoretically equivalent with both systems. If you have a lot of Thugs then the average charge of the network will approximately 1250. So a Felon at 0 charge in a global link system would gain 12.5 charge per frame. With the random neighbour system each Thug has a 1/N chance of picking the Felon (N units in total) so approximately 1 Thug will link with the Felon and give the Felon 12.5 charge. The Felon will almost always link with a Thug and take 12.5 charge. This transfer happens every 2 frames so the systems have effectively equivalent behaviour.

One overlooked issue is that adding Thugs to a group of large shields that do not drop below Thug charge will hinder the transfer of charge between the large shields. This could be dealt with by not considering full units with less charge while looking for a partner to transfer with.

quote: The dynamic that any shield with charge > thug (max) charge does not benefit from thug regen is interesting, but not new iirc.

This has always been the case.

quote: On another note, the system as you explained means that if you have x thugs in one ball and an empty shield touching exactly one of the thugs, then charge rate to the empty shield goes down the higher x gets. I find that unintuitive at best and (mechanically) unreasonable at worst... Is that part of the design idea?

This behaviour sounds ok in terms of "local stuff". Local means that clumps of units will reinforce each other more strongly than tenuously connected ones. Large clumps could focus the reinforcement. Note however that the penalty for adding extra units will only go as low as 50% because the lone empty shield will still transfer charge with its neighbour. Also the charge transfer is likely to be more sustained as the neighbour has its charge refreshed to 100% by the large clump of shields.

quote: It seems the change has made sballing even more popular than it was. I'm getting tired of hearing "Vrooshhh Bushhhh" x100 from racketeer. I've noticed a markable increase in sballs lately.

Perhaps a constant is off somewhere and charge transfer is now much more rapid. Alternately the xponen behaviour could have broken shieldballs in an unexpected way.

The problem is that the proper solution - a full pressure-network simulation - is prohibitively expensive to compute. These things involve recursive calculations over O(n^2) relationships.

GoogleFrog
This is great info!
Can you please repost in a (quote)quote(/quote) the parts of your posts that describe only what the new version does?
I can't tell when you are are discussing the old version or the new version!

Are larger shields are still higher priority for charge transfer?

Is a line of shields that touch at the tip still bottlenecked by each shield's individual rate of charge transfer?

Are shield averages now seperated by the averages of a given shield size?

Yeah, it would be easily fixable as GF already noted.

AutoWar: The system is really simple now. Every shield finds a random neighboring shield and "normalizes" charge (transfers 1% of the difference). This happens a few times per frame.

Btw GF, your code only has a 1/N² chance (in a normal case with no disabled/dead shields) to make a shield exchange charge with itself.
The random part with "The +1 is here intentional [...] (otherID will be nil)" only results in an attempt+1, not an attempt=false. Since you have two attempts, you need to roll the right random number twice to not transfer.
I mean, unless every unit is included in its own neighbor list, in which case you have two different ways of making shield transfer fail (which I'm not sure if you actually intended), but I won't try to wrap my head around the AddDataThingToIterable, AddThingToIterable and double table business that's going on here...