Number of totem packets not calculated correctly (BUG)

[UpperKEES]

I just finished a Chronom map (November 12, 2010) and experienced something very strange:

When I flew Odin City to the last totem I disabled the totem packets (green) temporarily to prevent loss when losing connections during flight. When I landed OC into the Creeper the packets kept being dispersed to the two bottom totems while enough packets had been sent already, see screenshots 1 & 2 below. Even when the rift opened the packets kept going, see screenshot 3. Without this loss I would have been able to charge the last totem quicker.

When I tried a second time I was able to reproduce this behaviour exactly.

[thepenguin]

I can't seem to reproduce this

i get the right number of packets dispatched

[UpperKEES]

You have to disable and enable the green packets during the flight of OC.

[thepenguin]

I did that, I disabled totem packets at the start of the level and re-enabled them during OC's flight

[UpperKEES]

I disable them at the start as well, but when all collectors are finished I start flying OC to the last totem. During that flight I enable the green packets, but at the moment a connection with a collector is going to be lost, I disable the green packets again. When the last collector has been reached (top right), I enable them again. Normally I should benefit from that; because the packets to the bottom totems have to travel further I wanted to release them a bit earlier, so the last one would arrive at its destination at the same moment the top totem is fully charged.

Edit: I'm sure it has to do something with this:

I'll also have to decide how to handle the requested packets that aren't being delivered.  Right now, they show up in deficit since they have been requested and aren't being fulfilled.  They also dispatch at 32 per second once a checkbox is re-enabled.  So if you have a ton of energy stored up, and you turn back on construction... a gazillion packets come streaming out machine gun style and build everything.  If you don't have bunch of energy stored up then you get a little burst and your energy is drained.

I guess I could do something better... but it's a computational pain to go selectively remove individual packet types from every structure's personal queue... I'll have to experiment and see what works...

Probably the packets that were still on their way when I turned off that type of packets were not taken into account. This might also be the case for ammo and build packets. As a result of this it could very well be that disabling and re-enabling a certain type of packets causes the packets still on their way to be forgotten. This isn't bad for ammo packets for a weapon that is firing, but it is for totem packets, build packets and ammo packets for weapons that are disarmed or deactivated, because these packets will be lost. I'll try to test this for other packet types.

[thepenguin]

I disable them at the start as well, but when all collectors are finished I start flying OC to the last totem. During that flight I enable the green packets, but at the moment a connection with a collector is going to be lost, I disable the green packets again. When the last collector has been reached (top right), I enable them again. Normally I should benefit from that; because the packets to the bottom totems have to travel further I wanted to release them a bit earlier, so the last one would arrive at its destination at the same moment the top totem is fully charged.

Edit: I'm sure it has to do something with this:

I'll also have to decide how to handle the requested packets that aren't being delivered.  Right now, they show up in deficit since they have been requested and aren't being fulfilled.  They also dispatch at 32 per second once a checkbox is re-enabled.  So if you have a ton of energy stored up, and you turn back on construction... a gazillion packets come streaming out machine gun style and build everything.  If you don't have bunch of energy stored up then you get a little burst and your energy is drained.

I guess I could do something better... but it's a computational pain to go selectively remove individual packet types from every structure's personal queue... I'll have to experiment and see what works...

no, that just involves packets being counted as deficit, virgil fixed it up, so unless you are experiencing deficit (which you are not), that is unrelated

EDIT: it also involves packets streaming out "machine gun style" which virgil fixed too

[UpperKEES]

When a certain type of packets is being disabled these packets are removed from the queue of that item (in this case a totem). This is indeed to display the deficit correctly, but apparently it forgets about the packets on their way when the packets are being enabled again, so it is absolutely related. And by the way: I do have a deficit on my first screen as you can see.

[UpperKEES]

Probably the packets that were still on their way when I turned off that type of packets were not taken into account. This might also be the case for ammo and build packets. As a result of this it could very well be that disabling and re-enabling a certain type of packets causes the packets still on their way to be forgotten. This isn't bad for ammo packets for a weapon that is firing, but it is for totem packets, build packets and ammo packets for weapons that are disarmed or deactivated, because these packets will be lost. I'll try to test this for other packet types.

I have has tested it some more, this time with build packets and the results are exactly as expected:

After releasing some build packets during OC's flight I disabled the packets until I reached my destination. On screenshot 1 you can see three packets on their way (one got lost due to a lost connection, hence the gap between packet 2 and 3).



When OC landed I enabled the build packets again. Odin City dispersed 10 of them, while only 7 are needed. On screenshot 2 you can see the three redundant packets on their way to the already finished collector.



Of course this has nothing to do with flying OC; it will happen any time you disable a certain type of packets and re-enable while packets of this type are still on their way. On screenshot 3 you can see I built a collector with OC on the ground. I released 5 build packets and disabled them for a brief period of time.



When I re-enabled them (see screenshot 4), 10 build packets got dispersed again.



That's 5 too much as you can see below.

[Pyxis_GeeK]

Very cool Kees. Good eye.

[mthw2vc]

Try doing this with a weapon...  ;)

[UpperKEES]

I guess it will work the same way, but when the weapon is consuming packets (firing) fast enough, they might not get lost as it can store the redundant packets.

By the way: when you wait with re-enabling the packets until all previous packets have arrived at their destination unit, you won't encounter this problem, so it only concerns packets on their way while re-enabling.

[Karsten75]

Oh dear,

The fat lady sang.... ;)

[UpperKEES]

Oh dear,

The fat lady sang.... ;)

Hahaha! That's exactly what I was thinking of.... :D

[UpperKEES]

Try doing this with a weapon...  ;)

I guess it will work the same way, but when the weapon is consuming packets (firing) fast enough, they might not get lost as it can store the redundant packets.

Tested it and it works as expected. I found a very nice side effect however! When you keep disabling and re-enabling the ammo packets every few seconds they keep being sent, thus not waiting for the weapon to request them. Assuming your amount of energy isn't a problem this will prevent your weapons (especially blasters) from starving when the lines of supply are rather long. When you keep doing this you won't need speed nodes at all!!! ;D Hmmm, maybe I should replay some maps right now....

Continuous fire without speed nodes:

[Fisherck]

Very interesting. You sure have a good eye. The only time I can say I have seen something like this is when you get the 10% less build upgrade. You enable it when building a building like a collector, but too slow for the city to register it, and the collector is built before the last packet has been sent out, but the city still sends a packet out for it.