It's annoying to have to carefully protect some crystal energy to avoid this and it certainly seems to me like it's based on a false premise anyway.
I have never noticed lag from spending energy no matter how much I spend, even if it's over 100 energy. However, on my laptop I often noticed lag in major battles. The thing is I don't think the lag is coming from the energy packets, but rather the missiles. When there are a gazillion missiles flying around the game got slow, especially if they had to take twisty paths to take their targets. The same energy use from blasters didn't slow it, though.
Has the code actually been profiled to see for sure where the lag is coming from?
Yes, and it's been tweaked.... The code for missile pathing is just very CPU intensive. And that's as simple as it's going to get, sorry. It doesn't tend to cause crashes, so it's really just an unavoidable inconvenience at this point. The fact is, when you have 30 or 40 launchers all firing at once, there's a lot of pathing involved.
...no more pathing than when 100+ packets need to find their ways every second.
An interesting tidbit...
Path calculations for packets are done 'backwards'. As in from the target back to the ship. Path calculations for missiles are done 'forwards' (from the launcher to the target). The reason backwards path calculations happen for packets is that this is often the more efficient way to calculate the path. The destination is usually more 'contained' than the ship, so on average the path finding algorithm will have less empty space to search.
For missiles, calculations must be done from the launcher outwards. This is because a missile must never exceed the range of the launcher.
Lastly, missile path finding begins by first finding some Creeper to shoot at. This means finding the densest Creeper, in range, that there is a path to... no a cheap algorithm if you think about it. Packets on the other hand, just need to calculate a 'simple' path.
As for the 60 energy limit....
It has some performance considerations, but also some game play considerations. The 'bug' was actually that crystal energy let you exceed the limit... but I left it in since it offered another advanced strategy (save your crystal energy).
Funny, I remember you saying something a bit different about this during beta.
Quote from: virgilw on March 06, 2011, 01:13:38 PM
This ship can deliver 60pps max... but more specifically it can only deliver 2 packets per frame. So if you pause the game and then click to build a bunch of structures, they won't get the packets as fast as they want. For instance, pause, then build 20 things. 18 of them won't get packets dispatched on the first frame after you unpause.
Now.... This is the way things have been for some time and it predates the way crystal energy currently works..... So, I will take a look and see if I can special case this a bit so that the ship can delivery as many packets as needed so long as there is crystal energy.
One thing I see: The missile pathing calculations are being done twice. I also have seen them shoot beyond their range many, many times.
1) So long as the target is within the missile's displayed range the missile will fly to it even if it's longer than this. There is a limit but it's not what's shown.
2) I just watched a bunch of missile launchers firing through a rift. Given the terrain I hadn't brought my launchers to bear on one emitter, I went in with blasters alone. The launchers weren't too far away but the path was too far for them to fire. I built a rift and missiles started using a rift path to engage. However, when I moved the launchers closer to the rift they quit firing. I shorten the path and they don't shoot--obviously the issue was they were out of range by a direct path. That says to me the pathing is done once to decide what to shoot at (using a routine that doesn't know about rifts) and once to actually shoot (using one that does know.)
My inclination on missile pathing would be to do a breadth-first search out from the launcher building a missile path as you go. When you find a cell with more creeper than the current best you save the current path, once the search is over you have everything you need to fire the missile.
Personally I'm agitating for "full spread missile targeting," but I'll hold my breath for it to appear in a future version of the game. :)
Quote from: Grauniad on January 02, 2012, 08:01:09 PM
Personally I'm agitating for "full spread missile targeting," but I'll hold my breath for it to appear in a future version of the game. :)
What is that?
Quote from: Loren Pechtel on January 02, 2012, 07:03:59 PM
One thing I see: The missile pathing calculations are being done twice. I also have seen them shoot beyond their range many, many times.
1) So long as the target is within the missile's displayed range the missile will fly to it even if it's longer than this. There is a limit but it's not what's shown.
2) I just watched a bunch of missile launchers firing through a rift. Given the terrain I hadn't brought my launchers to bear on one emitter, I went in with blasters alone. The launchers weren't too far away but the path was too far for them to fire. I built a rift and missiles started using a rift path to engage. However, when I moved the launchers closer to the rift they quit firing. I shorten the path and they don't shoot--obviously the issue was they were out of range by a direct path. That says to me the pathing is done once to decide what to shoot at (using a routine that doesn't know about rifts) and once to actually shoot (using one that does know.)
My inclination on missile pathing would be to do a breadth-first search out from the launcher building a missile path as you go. When you find a cell with more creeper than the current best you save the current path, once the search is over you have everything you need to fire the missile.
Yes, that is correct. The reason is it does a very cheap check to see which blocks are in range.
Then (I am unsure the order, neither order seems particularly effecient) it finds the densest block, and checks for a path. If it cant path there, it will choose the next densest block, and so on. (requires recaclulation, unless all cells are loaded into a list, and read backwards here)
Or, It Calculates paths, and of all the reachable areas, it chooses the densest block.
Once it chooses the block, it creates a missile, and runs the generic pathfinding algorithm (ignore evil creeper damage) which, unexpectedly and serendipitously (http://knucklecracker.com/blog/index.php/2010/11/unintended-coolness/ (http://knucklecracker.com/blog/index.php/2010/11/unintended-coolness/)) Happens to take advantage of microrifts.
Quote from: Ranakastrasz on January 03, 2012, 04:14:52 PM
Quote from: Grauniad on January 02, 2012, 08:01:09 PM
Personally I'm agitating for "full spread missile targeting," but I'll hold my breath for it to appear in a future version of the game. :)
What is that?
Quote from: Loren Pechtel on January 02, 2012, 07:03:59 PM
One thing I see: The missile pathing calculations are being done twice. I also have seen them shoot beyond their range many, many times.
1) So long as the target is within the missile's displayed range the missile will fly to it even if it's longer than this. There is a limit but it's not what's shown.
2) I just watched a bunch of missile launchers firing through a rift. Given the terrain I hadn't brought my launchers to bear on one emitter, I went in with blasters alone. The launchers weren't too far away but the path was too far for them to fire. I built a rift and missiles started using a rift path to engage. However, when I moved the launchers closer to the rift they quit firing. I shorten the path and they don't shoot--obviously the issue was they were out of range by a direct path. That says to me the pathing is done once to decide what to shoot at (using a routine that doesn't know about rifts) and once to actually shoot (using one that does know.)
My inclination on missile pathing would be to do a breadth-first search out from the launcher building a missile path as you go. When you find a cell with more creeper than the current best you save the current path, once the search is over you have everything you need to fire the missile.
Yes, that is correct. The reason is it does a very cheap check to see which blocks are in range.
Then (I am unsure the order, neither order seems particularly effecient) it finds the densest block, and checks for a path. If it cant path there, it will choose the next densest block, and so on. (requires recaclulation, unless all cells are loaded into a list, and read backwards here)
Or, It Calculates paths, and of all the reachable areas, it chooses the densest block.
Once it chooses the block, it creates a missile, and runs the generic pathfinding algorithm (ignore evil creeper damage) which, unexpectedly and serendipitously (http://knucklecracker.com/blog/index.php/2010/11/unintended-coolness/ (http://knucklecracker.com/blog/index.php/2010/11/unintended-coolness/)) Happens to take advantage of microrifts.
It certainly seems to me that it would be cheaper to simply do a breadth-first search of nearby blocks following a legal missile path, retain the densest target found and fire on that. This would in effect reduce it to running the pathfinding algorithm once rather than once per block until a valid target is found.
Yes, well, I did not say I knew how it was coded, I just did one logical, and stated to be non-optimal method.
So yea, That one is more likely.