Why not AC caches instead of Ore caches?

[Chthon]

Each of the 3 kinds of caches operate a little differently, which leads to some strange observations if you look at it as a whole:

Energy caches act as extra emergency energy storage.  They are only used if energy storage is at 0 and demand is higher than production.  Energy packets from the caches originate from the closest Command Module to the destination.

Ore caches act as immediate ore access.  They immediately fill all available space in the Command Module's storage.  They do not act as emergency storage, instead they remove any use from ore mines while they exist.  This results in an immediate abundance of AC, followed by next to no AC.

Aether caches will immediately deliver their contents to the closest forge.  Due to the nature of the forge, and not needing storage for Aether the reason it does so is obvious.

Here's a table with my points:

	Energy	Ore	Aether
Needs Storage	Yes	Yes	No
Used on Demand	Yes	No	N/A
Packets originate at CM	Yes	No	No
Needs "Refinement" before use	No	Yes	Yes
Prolonged Defense	Yes	Sometimes	No

If however we change Ore caches to Anti-creeper caches, we can make it operate identically to Energy.  It would provide extra emergency storage, could be used on demand when storage is drained, and packets could originate from the CM like with energy.  To leave it like it is, it'd be like if all of your collectors, CMs, and reactors shut down the second you got an energy cache until it was used.  It would also make it so defense of it could be a major issue as a counter balance to the benefits.  After all, if you don't use it immediately, you have to keep the creeper away from your cache.

[planetfall]

Yes, but then every score on a map with an ore pack will be invalid.

[teknotiss]

If however we change Ore caches to Anti-creeper caches, we can make it operate identically to Energy.  It would provide extra emergency storage, could be used on demand when storage is drained, and packets could originate from the CM like with energy.  To leave it like it is, it'd be like if all of your collectors, CMs, and reactors shut down the second you got an energy cache until it was used.  It would also make it so defense of it could be a major issue as a counter balance to the benefits.  After all, if you don't use it immediately, you have to keep the creeper away from your cache.

seconded

Yes, but then every score on a map with an ore pack will be invalid.

speaking as a huge AC fan who puts ore mines in most maps, so ??? this is a better system than the current one, i'm all for it!

[Godsbrother]

Yes, but then every score on a map with an ore pack will be invalid.

Yes, if current ore caches were switched it would invalidate times.  But, if instead AC caches were added as a fourth cache option for future maps it would just be another option for map makers.
Though I imagine Virgil has his hands full with Steam APIs and such atm, it would be an interesting change for the future.

[J]

You can disable siphons to stop ore being sent to a CN or an ore guppy.
Energy does need some kind of 'refinement', you can't use energy from energy packs without a CN.

[Chthon]

You can disable siphons to stop ore being sent to a CN or an ore guppy.
Energy does need some kind of 'refinement', you can't use energy from energy packs without a CN.

That's hardly the automatic solution that energy already has.
Energy doesn't really need refinement, it simply must originate from a CM or Guppy, and a Guppy must get it's energy from it's pad.  Same goes for Anti-Creeper.  Only Ore cannot originate from a CM

[planetfall]

You are confusing "energy" and "packets." As Virgil has said multiple times (none of which I can find at the moment), packets are physical objects made from energy at the CN.

[thepenguin]

Question: If ore becomes AC so it is like energy, why not just use either AC or energy?  If the purpose of changing them is so they have identical properties, I don't get the point.

[Chthon]

You are confusing "energy" and "packets." As Virgil has said multiple times (none of which I can find at the moment), packets are physical objects made from energy at the CN.

Packets and Energy may as well be the same thing.  There is no transparency to the fact that Energy is turned into Packets.  Instead for all intents and purposes to the player a packet is a unit of Energy.  That may be what happens behind the scenes, but unless a player is specifically told that, he is unlikely to ever figure that out on his own.  If the player could see the energy traveling from reators and collectors to the CMs and then packets coming out of the CMs then it would be transparent to the player.  However this was likely omitted due to processing constraints.  That and how chaotic it'd look.

Question: If ore becomes AC so it is like energy, why not just use either AC or energy?  If the purpose of changing them is so they have identical properties, I don't get the point.

The point is the two stored resources are treated quite differently when it comes to caches.  It further nerfs an already heavily nerfed resource without real reason for it.

[knucracker]

Ore and AC actually are basically the same thing.  The key game design decision is that 'ore' has to go to a Command Node before it can be dispatched as AC to units.  I could draw ore packets to look like AC, but they would still travel to a CN before going to a unit.  There are several reasons for this from game design considerations (player constraints) to run time performance issues.

So, Ore Resource Packs are going to send their contents to a CN first.  Whether it is AC or Ore doesn't really matter.  Energy and packets work the same way.  Energy gets sent from collectors and reactors to the CNs, then packets originate from the CN.  One difference, though, is that energy travels instantly from a collector to a CN whereas the resource from an ore mine (which is ore, but it could be drawn to look like AC) takes time to travel to the CN.

Ore Resource Packs currently don't delay.  When you build a siphon on one, it starts sending the ore the the CNs.  Now yes it is possible they will fill up the AC storage on all of the CNs.  When this happens, all ore production shuts down (from mines and from ore resource packs).  There is no place to store any ore/ac, so production shuts down.  Note that production from ore mines does not shut down just because a resource pack is sending ore to a CN.  Ore mines only shutdown when AC storage is full.

If you don't want a siphon to send the ore to the CNs, then you can either not build the siphon or disable it.  You could also choose (map permitting) to increase the size of your AC storage via the forge.  For instance, imagine you had unlimited AC storage on the CNs.  Would you ever want to not send the contents from an Ore Resource pack to the CNs?  Most likely not (excepting for multiple CNs and odd arrangements in their locations and totally different issues than are being discussed here).

Now I could add an option on ore resource pack siphons that says "Only dispatch ore to CN's when less than half full".  That would make an ore siphon toggle on and off based on the stored AC that you have.  It would preserve ore resource packs until you run low on stored AC.  Note that doesn't change anything about ore, ac, where it moves to, etc.  It would just make an ore siphon only activate when you run low on AC.  Similarly, an energy resource pack already works this way.  The reason this isn't the default behavior for ore resource packs is because of the time it takes to send ore to a CN (you might want to avoid that delay and already have the AC ready to go), because you can move AC around by moving a CN, because you can rain AC from orbit, and much of the time it doesn't hurt a thing to have full storage of AC at a CN.

[Chthon]

A better way to do it might be have it only send ore when

ore remaining/ore income (total time left on ore depletion) < connection distance from siphon to nearest CM * packet speed (total length of time a siphon would need to send ore to the CM)

Each siphon can store it's own value for the right side of the equation, and it only needs to update if the network it's connected to has a change in it.  The left side can be set to be compared with all siphons only if your ore income is negative, and there is not enough ore on the network incoming the CMs to fill them completely.  Individual siphons would activate at different points based on how long it would take for their product to arrive in time.

The connection distance would likely be calculated the same way it already is with any packet sent.  I assume that relay distances are considered half the value of any other connection due to their increased speed.  Since you are already doing this for every packet, one check per siphon for every network update more isn't going to adversely affect performance unless there is an inordinate amount of siphons on the map.  Same disclaimer for map makers as for guppy users I guess :)

The only thing I can see affecting performance is 1 check to see if ore income is negative every frame, 1 division every frame ore income is negative, and #OreSiphons comparisons when ore income is negative.  The added pathing checks for the ore packets every frame are already done at this point.  This being said a single math operation per siphon plus 1-2 per frame is likely far less intensive than running the pathing algorithm for each packet.  The algorithm more than likely includes dozens to hundreds of comparisons per packet.  As a result I don't think there will be a performance issue.

All in all this system should allow ore siphons to be toggled into a mode where they only send ore when you are about to deplete your reserves, and any ore that is sent will arrive just in time at the max speed of the siphon.  Due to the non-instant transfer of ore compared to energy, there will be differences inherent as a result; Ore may be sent when consumption of ore stops just short of hitting bottom, extremely distant ore siphons may trigger all the time, and if the distance between your command modules is large, ore packets may not arrive at the command module that is most convenient to send anti-creeper.  However if this is a toggle you add in, where you can have normal siphon operation or just in time operation, a player can choose to switch it right before a massive need, or simply drain really far siphons as fast as possible to avoid issues like described.

Let me know what you think Virgil, and if you have any questions about what I mean.  I do make some assumptions on your programming, like that you use an A* algorithm for packet pathing.  However you might have come up with a more specialized algorithm that works better for your system.  Still I don't see how that could be that much less processor intensive, even if you use a system like routing over the internet.  E.g. for return trips each node remembers the link for the shortest route home to each of the 3 destination CMs.  Packets would still have to check which way to go at each node on the trip.  Doing that with outgoing packets from the CMs would be a bit trickier however, though I suppose you could have a similar system to a routing table, where if it fills up, only then must it sends a new check.  The larger you make said table though, the more comparisons per node you would need and eventually you would defeat the purpose with too small or too large a table.  There would be a sweet spot but it could be hard to find.

[hbarudi]

why not have both anticreeper and ore caches and packet and energy caches and
when aether caches release aether, they seem to do it slowly, so if that rate can be modifiable