ORIGINAL: Antmf
Hey guys, been watching youtube videos on this game. Trying to relearn
Anyways, the video I am watching shows the player using the move to command to go to new planets in his system when he first started for his explorers as opposed to explore. What is the difference and why would he use move as opposed to explore? and what is the best way to explore?
The sensors on exploration ships are initially extremely short-ranged. I think they cover not even a gas giant from one of its moon, unless, maybe, the moon is at an extremely close orbit. I guess the author of the video you were watching was trying to set some priorities in exploration. You typically do not want to know about the resources of each asteroid that early.
The primary difference to the 'explore' command is just that you are picking the explorer's path using 'move-to', while an automated 'explore' seems to pick the nearest unexplored object (within the context that is to be explored) next, when it decides the current object has been sufficiently explored.
There is, however, some crazy optimization potential when you are managing explorers with lots of queued 'move-to' orders: both, 'move-to' and 'explore' will waste lots of time actually moving to the object being explored. The exploration ship tends to linger far longer than necessary around the object it is scouting, actually continuing to move there after the resource data has been retrieved. Note, that an explorer under 'explore' doesn't seem to act any differently; it's exploration seems just to be composed of 'move-tos' under the hood.
Now, when you catch an explorer with queued 'move-to' commands near a target, you can simply issue a 'stop'. This just stops the first order in the queue (actually replaces the 'move-to' by a short-lived pause), making the ship immediately (well, almost) switch to the next one without wasting more time. The time gains can be significant.
ORIGINAL: Antmf
Do I go planet to planet or explore system or should I use move?
The selection of targets when using 'move-to' orders on explorers can be one of the trickiest problems in this game, depending on how thorough you want to be. Icemania's tips are on spot, my approach is similar:
* Pre-warp, when I am interested in my local system, I explore part of that with 'move-to' and, once this is done, let the initial explorers handle the rest with an 'explore'.
* When scouting the neighborhood, I switch to 'move-to' between systems, only. By that time I always have the second tier resource sensor tech (medium range) researched, so my explorers will, from near the star they're set to move to, cover the inner planets of each system. The goal in this stage is just to cover the basics of each system and to do this quickly: Are there habitable planets, independent civilizations, ruins, scenic or research locations, abandoned ships?
* When the explorers have just warp bubble drive, I typically command them to explore some more planets in interesting systems. For this it is good to have a feel for how long the reach of the medium tier resource sensors is.
* When there are ruins, I'll always divert the explorer which has just reached the system to explore these.
* When there are independents, I might check through a gas giant or two for a suitable fuel source.
* (edit:) Almost forgot about abandoned ships/bases; those (and ruins) are the reason you absolutely want to be faster than any AI in exploration. And they are the reason, micromanaging all this exploration is such an enormous pita. The problem is that, without long range sensor coverage, abandoned structures will be invisible to you, unless you have at least a ship in the system. So with all these explorers with queued up 'move-to' orders, you still have to catch them in each system between when they come out of warp and leave, if you do not want to miss potential abandoned ships. This is why queueing up 'move-tos' is dicey. It's convenient, but it would be safer to just move to one system. Then, the explorer might go idle, if you do not catch it before that, but you eliminate the potential to miss something.
The picture changes somewhat when the highest tier sensor tech (long range) is available. This covers most, but not quite all, orbits of a medium to large sized system. Simply by going from star to star you'll explore most of each system. Then I don't need to bother diverting explorers for anything but ancient ruins (and undamaged abandoned structures, of course). Otherwise they just go through 'move-to' commands between systems (queued-up or not, depending on how convenient vs. safe I want to have it).
To get the outer fringes of systems explored, I usually have a few explorers with 'explore sector' commands. This 'explore sector' can also be optimized, simply by renewing the command each time, immediately after such an explorer comes out of warp, btw. This way, even these explorers do not waste too much time actually moving to objects.
Because the long range sensor tech eases the handling of the explorer fleet and boosts its efficiency so much, it is pretty high on my research priorities. But there is so much other indispensable stuff in the Hi Tech area! For example, I never can decide whether to get it before or after Long Range Sensors, having half the research cost (iirc), but then you have to compare that to the power of explorers being able to make out non-cloaked abandoned ships and bases from some distance.
ORIGINAL: Antmf
P.S. is there a way to edit qued orders that show up when you dbl click on a ship?
You can remove the front order by issuing a 'stop', or you can clear the entire queue.
You can also replace the front order in the queue by any other order than 'stop'. For example, if you catch an explorer which has just found a system with ancient ruins before it has finished the 'move-to' to said system's star, you can issue an order to move to the planet bearing the ruins without disturbing the rest of the queue.
Actually, giving orders to ships which have other commands queued up, can lead to amazingly confusing, or at least unexpected, results.
ORIGINAL: Icemania
Yeah, but to an optimisation freak like me, anything other than "move to" is so pathetically slow ... I just can't handle it!!!
Indeed, but 'move-to' is also still slow, as outlined above.
