View Issue Details

IDProjectCategoryLast Update
0001156AI War 1 / ClassicSuggestion - Game MechanicsMar 7, 2011 4:57 pm
ReporterMalibu Stacey Assigned Tokeith.lamothe  
Status resolvedResolutionfixed 
Product Version4.028 
Summary0001156: Have auto-exploring scouts leave a scout per-system
DescriptionCurrently building some scouts & sending them off to auto-explore simply means "charge through as many systems as possible before you die" which makes it pretty much useless in my opinion. It would be far more useful if auto-exploring tried to leave a single scout alive in each explored system. Simply making one scout per system stop auto-exploring & then evade once a new system is entered would be enough.
TagsNo tags attached.
Internal Weight

Relationships

duplicate of 0002854 resolvedChris_McElligottPark "Establish Scout Network" to compliment scout "Auto Explore" 

Activities

keith.lamothe

Nov 6, 2010 12:21 pm

administrator   ~0002821

I don't find it useless at all, I find that it saves me a ton of clicks and time particularly in the early game where I just want to know what's on all of my bordering worlds (and further out, if possible) without having to give an order for each specific planet. I wouldn't want it to leave scouts behind in that case.

I would like a toggle that makes it do so, but the logic involved in a scout knowing whether a planet is already "taken care of" and doesn't need another scout is non-trivial. I'd like to do it at some point, though.

orzelek

Nov 6, 2010 12:23 pm

reporter   ~0002823

This maybe difficult since it would need to make sure that said scout kind of survived this leaving behind :D

keith.lamothe

Nov 6, 2010 12:23 pm

administrator   ~0002824

To clarify, auto-explore was never intended to replace manually giving the orders, and if it's actually getting in your way you should just forget it exists. It's just there to automate the extremely simple cases where you're not worried about focusing your scouts, you're not worried about them getting destroyed, and you're not worried about persistent intel. I run into those a lot, so I added the order.

Malibu Stacey

Nov 6, 2010 12:28 pm

reporter   ~0002826

I pretty much have stopped even thinking about it anymore & reverted back to micromanaging my scouts. I only suggest this in the interests of removing some of the early game micro.

orzelek it doesn't need to make sure a scout survives, it should just try. Simple logic would be to pick the scout with the highest HP of the group which is cloaking boosted as it's the most likely to live if it tries to evade.

Foogsert

Nov 6, 2010 12:55 pm

reporter   ~0002829

If this were to be added I'd rather it be a separate command, as more often then not I'm just trying to see as deep as possible.

keith.lamothe

Nov 6, 2010 12:59 pm

administrator   ~0002830

Right, it wouldn't touch the existing logic because, like you (and unlike the obviously misguided requestor ;) j/k ), many of us like it.

But I think it would be fairly easy to have an "auto-scout-picket" or something command that would take the scouts in the selection, and for each one find the nearest planet that you don't currently have scout intel on and hasn't already been chosen for this order, and send them there. The auto-evade behavior would take care of getting them out of the way. If they fail, ah well, should have given more specific commands ;)

Malibu Stacey, would that help?

Malibu Stacey

Nov 6, 2010 2:27 pm

reporter   ~0002831

Yeah sounds good keith =)

zebramatt

Nov 6, 2010 5:49 pm

reporter   ~0002844

I'm not sure I'm on board with this idea!

If all I need do to proliferate my scouts throughout the neighbouring systems is issue a single command, why need I do anything at all?

keith.lamothe

Nov 6, 2010 5:54 pm

administrator   ~0002846

It would only help you on planets that wouldn't terminate your scout, so you'd still almost certainly need to clear the tachyon guardians, etc, to make it "hospitable". The command would just be to save you the clicks and seconds spent on telling each individual socut which planet to go to, and save you the time of checking which nearby planets lack scout intel.

I'm generally only on board with this sort of stuff when it's clearly just an encapsulation of a simple process that's already trivially easy to perform manually. In this case:

*for each scout in my selection
**for each planet I do not own (sorted ascending by distance from current planet)
***if planet does not have scout intel right now, and has not already been picked during this process, send this scout there, and go to next scout in selection

It's not doing anything fancy like "is there a scout already enroute there from some other order" or "do I have a snowball's chance in the underworld of surviving", etc.

So it's actually less sophisticated than the existing auto-scout logic, which actually sets a mode on the scout (a fairly tenacious mode, we've found).

keith.lamothe

Mar 7, 2011 4:57 pm

administrator   ~0010947

For 5.003:

* Courtesy of the new 0000002 item on the mantis vote-tallies: Added "Auto-Scout-Picket" command to the context menu (there's also an key bind, unbound by default):
** Tell all cloaking scout units in the selection to try to station themselves on a planet where you do not currently have scout intel. Basically it:
*** 1) Makes a list of all scouts with cloaking in your selection.
*** 2) Makes a list of all planets you do not have current (less than 5 seconds ago) scout intel.
*** 3) Sorts that list of planets by distance (ascending) to the planet with your selection.
*** 4) Tells the first scout in the first list to go to the first planet in the second list, and so on. If it runs out of planets it loops back to the beginning of the planet list and thus it will double up, etc. When it runs out of scouts it stops.
** Please remember that this order (and auto-explore) are only intended to automate simple scouting situations and thus save you time giving otherwise trivial orders. If your scouts all die before accomplishing anything that means that it's not a simple scouting situation and you'll need to take manual control to get good results.

Issue History

Date Modified Username Field Change
Nov 6, 2010 12:11 pm Malibu Stacey New Issue
Nov 6, 2010 12:21 pm keith.lamothe Note Added: 0002821
Nov 6, 2010 12:21 pm keith.lamothe Assigned To => keith.lamothe
Nov 6, 2010 12:21 pm keith.lamothe Status new => considering
Nov 6, 2010 12:23 pm orzelek Note Added: 0002823
Nov 6, 2010 12:23 pm keith.lamothe Note Added: 0002824
Nov 6, 2010 12:28 pm Malibu Stacey Note Added: 0002826
Nov 6, 2010 12:55 pm Foogsert Note Added: 0002829
Nov 6, 2010 12:59 pm keith.lamothe Note Added: 0002830
Nov 6, 2010 2:27 pm Malibu Stacey Note Added: 0002831
Nov 6, 2010 5:49 pm zebramatt Note Added: 0002844
Nov 6, 2010 5:54 pm keith.lamothe Note Added: 0002846
Feb 17, 2011 9:18 pm Malibu Stacey Relationship added duplicate of 0002854
Mar 7, 2011 4:57 pm keith.lamothe Note Added: 0010947
Mar 7, 2011 4:57 pm keith.lamothe Status considering => resolved
Mar 7, 2011 4:57 pm keith.lamothe Resolution open => fixed