I just finished a Chronom map (November 12, 2010 (http://knucklecracker.com/creeperworld/viewscores.php?missionGroup=chronom&month=10&day=12&year1=2&year2=0&year3=1&year4=0)) 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.
(http://knucklecracker.com/forums/index.php?action=dlattach;topic=5010.0;attach=1571;image)
(http://knucklecracker.com/forums/index.php?action=dlattach;topic=5010.0;attach=1573;image)
(http://knucklecracker.com/forums/index.php?action=dlattach;topic=5010.0;attach=1575;image)
I can't seem to reproduce this
i get the right number of packets dispatched
You have to disable and enable the green packets during the flight of OC.
I did that, I disabled totem packets at the start of the level and re-enabled them during OC's flight
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:
Quote from: virgilw on August 18, 2010, 08:29:02 PM
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.
Quote from: UpperKEES on October 08, 2010, 04:35:27 PM
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:
Quote from: virgilw on August 18, 2010, 08:29:02 PM
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
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.
Quote from: UpperKEES on October 08, 2010, 04:35:27 PM
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).
(http://knucklecracker.com/forums/index.php?action=dlattach;topic=5010.0;attach=1577;image)
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.
(http://knucklecracker.com/forums/index.php?action=dlattach;topic=5010.0;attach=1579;image)
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.
(http://knucklecracker.com/forums/index.php?action=dlattach;topic=5010.0;attach=1581;image)
When I re-enabled them (see screenshot 4), 10 build packets got dispersed again.
(http://knucklecracker.com/forums/index.php?action=dlattach;topic=5010.0;attach=1583;image)
That's 5 too much as you can see below.
(http://knucklecracker.com/forums/index.php?action=dlattach;topic=5010.0;attach=1585;image)
Very cool Kees. Good eye.
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.
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.
Oh dear,
Quote from: UpperKEES on October 06, 2010, 11:27:47 AM
The fat lady sang.... (http://www.youtube.com/watch?v=dIVfbylUU-M) ;)
Quote from: Karsten75 on October 08, 2010, 07:20:59 PM
Oh dear,
Quote from: UpperKEES on October 06, 2010, 11:27:47 AM
The fat lady sang.... (http://www.youtube.com/watch?v=dIVfbylUU-M) ;)
Hahaha! That's exactly what I was thinking of.... :D
Quote from: mthw2vc on October 08, 2010, 06:46:22 PM
Try doing this with a weapon... ;)
Quote from: UpperKEES on October 08, 2010, 06:55:35 PM
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:(http://knucklecracker.com/forums/index.php?action=dlattach;topic=5010.0;attach=1588;image)
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.
Quote from: Fisherck on October 08, 2010, 08:51:00 PM
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.
Yeah, when I build my first two collectors of a map and one of them is connecting to an upgrade (which is very often the case because I fly OC there), I purposely start building the second collector when 2 packets for the first one have been sent, so I save one packet (corresponding to 1 second during the initial phase of the game).
"He that can not keep a penny shall never have many." Or as we say here:
"Who can't appreciate something small, isn't worth big things at all." ;)
Good catch....
This is one of those unintended consequences that pop up constantly with new feature additions. This is also a case where defensive programming prevents more serious problems. The structures don't freak out when they get packets that are beyond what was necessary.... this is "safe" because I coded up extra logic to handle cases that "weren't supposed to happen". :)
Now, the part about turning it on and off to force overdrive ammo packets to blasters.... you maybe should have kept that one to yourself. :) You might have been the only person to discover this and could have had an advantage on any "short" map where building a speed node was necessary and would make a difference in the score.
Quote from: virgilw on October 08, 2010, 11:36:50 PM
Good catch....
This is one of those unintended consequences that pop up constantly with new feature additions. This is also a case where defensive programming prevents more serious problems. The structures don't freak out when they get packets that are beyond what was necessary.... this is "safe" because I coded up extra logic to handle cases that "weren't supposed to happen". :)
Yeah, but the packets are still lost, so you really have to pay attention when re-enabling a certain packet type again.
Quote from: virgilw on October 08, 2010, 11:36:50 PM
Now, the part about turning it on and off to force overdrive ammo packets to blasters.... you maybe should have kept that one to yourself. :) You might have been the only person to discover this and could have had an advantage on any "short" map where building a speed node was necessary and would make a difference in the score.
Nah, I don't need another advantage; I already have my brain. ;) And when playing for a highscore I like everyone to have the same chances, so I can beat them fair and square. :)
I do like the term
overdriving for this new 'feature' though!
You can also use it to convert excess build packets into ammo.
Quote from: mthw2vc on October 09, 2010, 07:34:35 AM
You can also use it to convert excess build packets into ammo.
yes, that works very well, I can charge a blaster without ammo packets!
it must be that virgil's code sends packets in different types, but receives them all as just a general packet, and uses that for whatever it is trying to do
(you might be able to charge a totem with ammo packets or build packets :D)
Quote from: mthw2vc on October 09, 2010, 07:34:35 AM
You can also use it to convert excess build packets into ammo.
Great! That solves the initial delay after building a weapon.
Quote from: thepenguin on October 09, 2010, 09:01:06 AM
(you might be able to charge a totem with ammo packets or build packets :D)
Sure, you only have to build your own firing totems first.... :P
Quote from: UpperKEES on October 09, 2010, 09:48:14 AM
Sure, you only have to build your own firing totems first.... :P
Idea for an update? :D :P
I just noticed that an grey packet whent to an Blaster after i moved it ,
and it's only possible to move it after its finnished build =P
I did'nt notice if the grey packet worked as an red packet ,
but i dont think so .
And that was without turning off and on packets on the city !
Quote from: virgilw on October 08, 2010, 11:36:50 PMNow, the part about turning it on and off to force overdrive ammo packets to blasters.... you maybe should have kept that one to yourself. :) You might have been the only person to discover this and could have had an advantage on any "short" map where building a speed node was necessary and would make a difference in the score.
I knew about this... I just didn't say anything. (actually that's the truth) The reason why I never said anything is because I thought everyone knew o.O