View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0003835 | AI War 1 / Classic | Gameplay Issue | Sep 10, 2011 3:33 pm | Sep 12, 2011 6:42 pm | |
| Reporter | Cyborg | Assigned To | keith.lamothe | ||
| Status | resolved | Resolution | fixed | ||
| Product Version | 5.016 | ||||
| Summary | 0003835: deleting mining enclosure deletes the asteroid | ||||
| Description | Is this intended? I was trying to fix a bug with attaching mining enclosures, and it deleted my asteroids. Looks like it could prove to be a costly mistake of pressing the wrong key as well as a multiplayer griefing/hassle. | ||||
| Tags | No tags attached. | ||||
| Internal Weight | |||||
|
|
I'd have to ask Chris as he wrote all the spirecraft stuff but I believe this is intended. At least it's intended that if the AI blows up the enclosure it blows up the asteroid, and if scrapping didn't do it too then you could just scrap to save it from an attack. Or can/does the AI just shoot the bare rocks too? |
|
|
the AI cannot just shoot the rocks. Can you differentiate between the AI attacking it and scrapping it? |
|
|
I don't mind seeing the asteroid deleted if you scrap the enclosure. It is a limited resource, so it should be treated as such. |
|
|
I will agree with you Toll if you can give me one scenario where deleting it has any value aside from just being a mistaken keypress. |
|
|
Well, if you can delete the enclosure to prevent the destruction of the rock due to impending AI attack, that incentivizes a form of scrapping micro we prefer to avoid (hence why scrapping something that has AIP-on-death still triggers the AIP, etc). If the AI destroying the enclosure did not destroy the rock then it would be different, but it does (and that's by far the simpler approach both in balance and coding, it's unlikely that metamorphing the enclosure back into the rock would put it in _quite_ the same place, etc). Does scrapping the enclosure have a confirmation step? Would you prefer if it had a second confirmation step for "you're about to scrap something you cannot rebuild"? |
|
|
As for scenarios where there is value in deleting an enclosure... All enclosures take a fair bit of energy to keep going, aside from the resource drain. Thus, scrapping it frees up that energy, and removes the resource drain. As I said, they're limited resources; once you've placed an enclosure on the asteroid, you should be sure you want that spirecraft. Scrapping it and rebuilding another enclosure removes much of the limitations. |
|
|
A second confirmation step would be just fine. It is a severe consequence mistake. I just looked up the energy cost…is negligible. |
|
|
Yea, the energy cost isn't something we care about there. The "make sure you made the right choice" is more important. But in general we aren't big on stuff having different behavior based on exactly how it died; it does happen in a few cases though (warheads vs. interceptors, etc). |
|
|
That's fine. A confirmation would be good, as scrapping it would be permanently damaging, something you could never recover. You get nothing... Except for 3000 energy. |
|
|
Can the double check be extended for other "hard to" or can't rebuild stuff, like trader items, the initial home forcefield, and capturables? |
|
|
For 5.017: * Added a second confirm step when scrapping Spirecraft mining enclosures (since scrapping them does not give you back the asteroid from which they came) and the player home forcefield generator (since it cannot be rebuilt). I'd already done it for those two; I can add the flag elsewhere as needed. Specific ship type names and only those that are actually scrappable, please; I'm lazy ;) |
|
|
Q. is Does golems have this option? flag? |
|
|
Is it possible to scrap golems at all? I could look at the code but, as I said, I'm lazy ;) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| Sep 10, 2011 3:33 pm | Cyborg | New Issue | |
| Sep 10, 2011 3:35 pm | keith.lamothe | Note Added: 0013197 | |
| Sep 10, 2011 3:58 pm | Cyborg | Note Added: 0013198 | |
| Sep 10, 2011 4:04 pm | Toll | Note Added: 0013199 | |
| Sep 10, 2011 4:13 pm | Cyborg | Note Added: 0013200 | |
| Sep 10, 2011 4:47 pm | keith.lamothe | Note Added: 0013201 | |
| Sep 10, 2011 4:59 pm | Toll | Note Added: 0013202 | |
| Sep 10, 2011 5:02 pm | Cyborg | Note Added: 0013203 | |
| Sep 10, 2011 5:04 pm | Cyborg | Note Edited: 0013203 | |
| Sep 10, 2011 5:07 pm | keith.lamothe | Note Added: 0013204 | |
| Sep 10, 2011 5:09 pm | Cyborg | Note Added: 0013205 | |
| Sep 10, 2011 5:31 pm | TechSY730 | Note Added: 0013206 | |
| Sep 10, 2011 6:01 pm | keith.lamothe | Note Added: 0013208 | |
| Sep 10, 2011 6:01 pm | keith.lamothe | Status | new => resolved |
| Sep 10, 2011 6:01 pm | keith.lamothe | Resolution | open => fixed |
| Sep 10, 2011 6:01 pm | keith.lamothe | Assigned To | => keith.lamothe |
| Sep 12, 2011 6:40 pm | soMe_RandoM | Note Added: 0013222 | |
| Sep 12, 2011 6:42 pm | keith.lamothe | Note Added: 0013223 | |
| Apr 14, 2014 9:28 am | Chris_McElligottPark | Category | Gameplay - General Complaint => Gameplay Issue |
