View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0001156 | AI War 1 / Classic | Suggestion - Game Mechanics | Nov 6, 2010 12:11 pm | Mar 7, 2011 4:57 pm | |
| Reporter | Malibu Stacey | Assigned To | keith.lamothe | ||
| Severity | feature | ||||
| Status | resolved | Resolution | fixed | ||
| Product Version | 4.028 | ||||
| Summary | 0001156: Have auto-exploring scouts leave a scout per-system | ||||
| Description | Currently 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. | ||||
| Tags | No tags attached. | ||||
| Internal Weight | |||||
| duplicate of | 0002854 | resolved | Chris_McElligottPark | "Establish Scout Network" to compliment scout "Auto Explore" |
|
|
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. |
|
|
This maybe difficult since it would need to make sure that said scout kind of survived this leaving behind :D |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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? |
|
|
Yeah sounds good keith =) |
|
|
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? |
|
|
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). |
|
|
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. |
| 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 |
