Suggestions

[Admiral]

Could you have an option to display the health and reload bars when ships are shown in icon view please?

Yeah, that's another good one.  It might adversely affect performance to a small-to-moderate degree depending on your hardware and just how far you are zoomed out (if there are thousands of ships in battle onscreen at once), but I doubt it will be anything too terrible and if you have the hardware to handle that, then great.  Added to my list.

Excited to see this one, thanks for liking the idea.

You could also have a slider (akin to the "show icons at this zoom level" slider) that says "show health bars out to this zoom level." Alternatively, you could show health bars on only selected ships (if there are "too many" on screen, but how you define that is up to you) or draw them only on ships closest to the center of the screen, or whatever.

Another thing I'd like vis-a-vis health bars is seeing them on enemy ships as well. I only really care about the shields and big enemy ships (which is why I always got the desync problem you recently fixed, as I watched the shield health in the tooltip like a hawk).

Go on vacation! (Iceland is nice...)

Cheers!

[Admiral]

Could you do any of these things with newly reclaimed ships please?

a) Add them to the combat group (1-9) of the parasite that claimed them?
b) Add them to a special combat group of "reclaimed ships?"
c) Have them inherit the mode of the reclaiming ship (free-roaming defender, etc.?)
d) Have them inherit the command queue of the reclaiming ship?
e) Specify a "all reclaimed ships should go here" point on each planet?

Cheers!

My instinct is to do A, C, and D as new behaviors (no settings required).  Would that work for you?

Any of them work for me. The other two are useful so you can tell them to immediately go to a place where they can be healed.

[x4000]

Excited to see this one, thanks for liking the idea.

Well, it was a good idea!

You could also have a slider (akin to the "show icons at this zoom level" slider) that says "show health bars out to this zoom level." Alternatively, you could show health bars on only selected ships (if there are "too many" on screen, but how you define that is up to you) or draw them only on ships closest to the center of the screen, or whatever.

Yeah, any one of those could work well if it starts chugging too much.  I'll code it out so it shows all of them at first, and we'll see how it does, and if it's getting too laggy in big battles with that on, then I can add in the performance improvements as secondary options.  This isn't going to be a default-on feature, so I don't feel too bad about doing it that way.  No sense in restricting functionality for the sake of performance if performance isn't first proven to be an issue.

Another thing I'd like vis-a-vis health bars is seeing them on enemy ships as well. I only really care about the shields and big enemy ships (which is why I always got the desync problem you recently fixed, as I watched the shield health in the tooltip like a hawk).

Ah, gotcha.  Well, the default implementation will have it for all ships, so that should work for you!

Go on vacation! (Iceland is nice...)Cheers!

Yep, I was really tempted to start working on some of the features like the planet renaming right immediately, but there's enough of them that I'll suddenly look up and it will be 12 AM local.  So those will get saved for later, and I'm outta here except for anything that's more serious...

[darke]

Yep, I was really tempted to start working on some of the features like the planet renaming right immediately, but there's enough of them that I'll suddenly look up and it will be 12 AM local.  So those will get saved for later, and I'm outta here except for anything that's more serious...

Always the problem with holidays when what you're doing at work is fun. You'll often find your relaxing holiday ends up being relaxing-whilst-doing-work.

[Admiral]

My instinct is to do A, C, and D as new behaviors (no settings required).  Would that work for you?

Any of them work for me. The other two are useful so you can tell them to immediately go to a place where they can be healed.

I was thinking about this again this morning as I lay, wishing I were still asleep but being jet-lagged awake.

I think these behaviors should be optional, either individually and/or in aggregate. Why? Reclaimed ships often have a very low health. My strategy has been, so far, to move my huge mass of ships (with only reclaimer starships, no parasites) through an enemy's position, and then rubberband select all the relcaimed ones, move them back to where a repair station or engineer waits and fix them up before sending them back in. I especially do this when I'm getting IV or C ships reclaimed.

I still think the most helpful choices are the ones that are harder to implement, to realize this strategy (building up a fleet of ships you wouldn't otherwise have, like getting a fleet of Core cruisers which I had yesterday).

Cheers!

[Admiral]

I just finished my first game (2 player, 40 planets, lv 3, 4 easier random AIs) in 16.5 hours of game time last night, over the course of 5-6 evenings in the span since the initial release of 1.005. I have a few more ideas to share with the community...

• Shield ships. These should be ships that move at a reasonable pace (slower than the fastest ones, but fast enough to keep up with the rest) and don't go any faster than the fastest other ships they're grouped with. They should have no offense and only a small rechargeable shield bubble. It should only recharge at a slow rate, though how that is implemented I leave as an exercise (recharge Y% every X seconds, or only after a delay after taking damage - like repair, etc.). They should probably be limited to a handful per level (30?). Alternatively, make them more powerful but a starship, limited to 7 or so.
• Target following. I should be able to have one ship (or group) target another ship (or group) and have it do the smart thing, while following as closely as possible during the interim. Attack ships would take the targets from the followed group. Repair ships/engineers would repair ships in that group or of that type (preferentially). Shield ships would attempt to bubble each of the ships in the group or of that type.
• Cloak ship. As shield ship, but provides a small cloaking bubble.
• Cloner ship. A special ship with no offense and little defense that when assigned to a friendly target, will clone it (turn into it) after a while. Obviously it should be expensive to build in the first place, and then probably use the same amount of resources (metal, crystal) as building the cloned ship would have done. It should probably respect any limits on ship counts as well. This would be a nice (albeit very slow) way to build up a little fleet of Core ships or ships you don't have tech access to.
• Repair nanites. This is a ship addition, like the exo-harvester shield is an addition to harvesters. Once attached to a ship, it is permanently there, and that ship gets a self-repair ability on the order of (whatever power you wish, no better than an engineer and probably half or a third as good). You can only have so many of these in play. (The shield/cloak ships could also be implemented in this manner, as an add-on.) This is useful for those ships you most highly value, although presumably they could be attached to any other logical thing (mines are not logical).
• Retreat at low health. Yes, the problem is "what does it mean to retreat?" In any event, it would be nice to tell ships that at a certain health level, they should fall back in some way (perhaps just move out of range of any attacking enemy notwithstanding unlimited distance enemies), so they have a chance of being preserved. This might not be useful given the AI (target one until dead) except if given a relatively high threshold, and a fast ship or a high-health starship. Still, would be nice to maintain certain strategic assets.
• Health histogram. Somewhat as an alternative to the above, but also as an enhancement, modify the list of ships (hover in the lower left corner) to include a histogram of ships in various states of repair. This could be a simple addition of two or three more columns: the first in red color, with a number of ships below 25% health. Then, a column in yellow, with a number of ships below 50% health. (You could also do other # of columns or thresholds.) These columns should be individually clickable and that would select all ships of that type with that amount of health (or less). This would allow me to tell at a glance if my two Zlinth starships, which are at 60%, is really one at 20% and the other at 100%, or both at 60%, etc. Also useful for keeping your Core ships alive.
• Reload bar suppression. I don't really care about the reload bars, I realized. I don't really know if they're important, so maybe that is a tactical error on my part, but I'd just as soon have an option to suppress them (and a key to show them temporarily while pressed?).
• Health bar coloring. It would be nice to have the health bars change color at certain thresholds, such as green at 100%, yellow at 50% and red at 25%. If you really want to get fancy, you could interpolate between colors between the thresholds.
• Selection of low health ships. A key which when held would modify whatever the selection you're doing is for low (<25%) or mid (<50%) health ships. We're rapidly running out of modifier keys in my world...
• Post-winning options. Several things: How about letting us save a won game and also continue a won game (although you should probably auto-pause the game when the win occurs). My friend was very disappointed that he didn't get to complete his attack on a heavily fortified planet as I wiped off the second AI's home command center last night, and I can certainly understand that.
• Auto-save rotation. Have the auto-save keep the last N most recent auto-saves. Alternatively, have it auto-save to a subdirectory and timestamp each auto-save.
• Auto-save naming. Have the game name the autosave using the name of the last loaded (or saved) game as a suffix. Have a lobby option to set the "save game name" for new games, or provide a reasonable default (e.g., names of players & starting date/time). Helpful for when you have (as I do) multiple games going simultaneously on the same laptop (tutorial, solo game, several multiplayer games).
• Ungrouped selection. A modifier key to be able to select ships that are not in a group. Useful when you have groups massing at a wormhole, get a batch of reinforcements, and want to add them to another group (also at the wormhole) but you can't select them easily.
• Idea suppressor. Some subliminal visual that allows you to play the game without coming up with any other whacky ideas.

I welcome thoughts.

Cheers!

[x4000]

Always the problem with holidays when what you're doing at work is fun. You'll often find your relaxing holiday ends up being relaxing-whilst-doing-work.

Yeah, no kidding.  I'm going to be out of the house starting in a few hours, though, so no chance of that until tomorrow after that point.

And in a few weeks, I'll be out of the state for a week, so then I'll really be a bit separate for that time.  Looking forward to that, it's been a long (but great) year so far.

[x4000]

My instinct is to do A, C, and D as new behaviors (no settings required).  Would that work for you?

Any of them work for me. The other two are useful so you can tell them to immediately go to a place where they can be healed.

I was thinking about this again this morning as I lay, wishing I were still asleep but being jet-lagged awake.

I think these behaviors should be optional, either individually and/or in aggregate. Why? Reclaimed ships often have a very low health. My strategy has been, so far, to move my huge mass of ships (with only reclaimer starships, no parasites) through an enemy's position, and then rubberband select all the relcaimed ones, move them back to where a repair station or engineer waits and fix them up before sending them back in. I especially do this when I'm getting IV or C ships reclaimed.

I still think the most helpful choices are the ones that are harder to implement, to realize this strategy (building up a fleet of ships you wouldn't otherwise have, like getting a fleet of Core cruisers which I had yesterday).

Cheers!

This is a good point, I will make those optional on second thought.  As to the harder-to-implemet behaviors, those are something that will actually be possible for you to do by using an upcoming "space tug" ship in conjunction with the Mobile Repair Station.  You'll have to unlock that for knowledge and bring it along, but it's a great combo that would allow you to do what you are looking for.

[x4000]

• Shield ships. These should be ships that move at a reasonable pace (slower than the fastest ones, but fast enough to keep up with the rest) and don't go any faster than the fastest other ships they're grouped with. They should have no offense and only a small rechargeable shield bubble. It should only recharge at a slow rate, though how that is implemented I leave as an exercise (recharge Y% every X seconds, or only after a delay after taking damage - like repair, etc.). They should probably be limited to a handful per level (30?). Alternatively, make them more powerful but a starship, limited to 7 or so.

Actually, the Mark III Force Fields are mobile, and basically let you do this sort of thing.  The force fields don't heal, but rather just take damage until they eventually die.  It can be quite powerful, but costs a lot of knowledge to get there.

• Target following. I should be able to have one ship (or group) target another ship (or group) and have it do the smart thing, while following as closely as possible during the interim. Attack ships would take the targets from the followed group. Repair ships/engineers would repair ships in that group or of that type (preferentially). Shield ships would attempt to bubble each of the ships in the group or of that type.

The group-move is most likely the closest I'm going to come to that.  Ships will continue to fire while moving, but engineers won't repair while moving unless they are just following after the group.

• Cloak ship. As shield ship, but provides a small cloaking bubble.

I love it.  Added to my list for future DLC.

• Cloner ship. A special ship with no offense and little defense that when assigned to a friendly target, will clone it (turn into it) after a while. Obviously it should be expensive to build in the first place, and then probably use the same amount of resources (metal, crystal) as building the cloned ship would have done. It should probably respect any limits on ship counts as well. This would be a nice (albeit very slow) way to build up a little fleet of Core ships or ships you don't have tech access to.

Very interesting... added to my list for the expansions (since I'm not doing new bonus-style ship classes except in those).  I think that's a really cool idea.

• Repair nanites. This is a ship addition, like the exo-harvester shield is an addition to harvesters. Once attached to a ship, it is permanently there, and that ship gets a self-repair ability on the order of (whatever power you wish, no better than an engineer and probably half or a third as good). You can only have so many of these in play. (The shield/cloak ships could also be implemented in this manner, as an add-on.) This is useful for those ships you most highly value, although presumably they could be attached to any other logical thing (mines are not logical).

Another very cool one.  Added to my list for future DLC, or perhaps the expansion (we'll see when it comes up).

• Retreat at low health. Yes, the problem is "what does it mean to retreat?" In any event, it would be nice to tell ships that at a certain health level, they should fall back in some way (perhaps just move out of range of any attacking enemy notwithstanding unlimited distance enemies), so they have a chance of being preserved. This might not be useful given the AI (target one until dead) except if given a relatively high threshold, and a fast ship or a high-health starship. Still, would be nice to maintain certain strategic assets.

This has come up before, and it's a great idea.  It's on my list to have "space tugs" which can be built from the mobile repair stations.  They will go out and forcibly drag your ships that are below a certain health back to the repair station.  This one should be around sooner than later.

• Health histogram. Somewhat as an alternative to the above, but also as an enhancement, modify the list of ships (hover in the lower left corner) to include a histogram of ships in various states of repair. This could be a simple addition of two or three more columns: the first in red color, with a number of ships below 25% health. Then, a column in yellow, with a number of ships below 50% health. (You could also do other # of columns or thresholds.) These columns should be individually clickable and that would select all ships of that type with that amount of health (or less). This would allow me to tell at a glance if my two Zlinth starships, which are at 60%, is really one at 20% and the other at 100%, or both at 60%, etc. Also useful for keeping your Core ships alive.

Intriguing... there is some complexity with the clicking of the secondary columns, etc, but I like this idea overall.  It's added to my list, but most likely will be a part of DLC after a longer while, just because of the complexity of this one.

• Reload bar suppression. I don't really care about the reload bars, I realized. I don't really know if they're important, so maybe that is a tactical error on my part, but I'd just as soon have an option to suppress them (and a key to show them temporarily while pressed?).

Another great idea.  Yes, I think that is a great thing to suppress.  The only reason for showing it is to know if the ships are firing or not (and, in some cases when you are watching your ships anxiously for the next volley, it is also helpful).  But with the I key, and Fast & Dangerous mode, it is not useful as much of the time anymore.  Added to my list!

• Health bar coloring. It would be nice to have the health bars change color at certain thresholds, such as green at 100%, yellow at 50% and red at 25%. If you really want to get fancy, you could interpolate between colors between the thresholds.

I like it.  Added as an option to the list (will be a settings option when it comes out).

• Selection of low health ships. A key which when held would modify whatever the selection you're doing is for low (<25%) or mid (<50%) health ships. We're rapidly running out of modifier keys in my world...

Ha, that's another good one, and seems worth the use of the keys.

• Post-winning options. Several things: How about letting us save a won game and also continue a won game (although you should probably auto-pause the game when the win occurs). My friend was very disappointed that he didn't get to complete his attack on a heavily fortified planet as I wiped off the second AI's home command center last night, and I can certainly understand that.

This is an interesting point, I like it.  Added to my list.

• Auto-save rotation. Have the auto-save keep the last N most recent auto-saves. Alternatively, have it auto-save to a subdirectory and timestamp each auto-save.

Good point.  On the list (not the subdirectory).

• Auto-save naming. Have the game name the autosave using the name of the last loaded (or saved) game as a suffix. Have a lobby option to set the "save game name" for new games, or provide a reasonable default (e.g., names of players & starting date/time). Helpful for when you have (as I do) multiple games going simultaneously on the same laptop (tutorial, solo game, several multiplayer games).

Hmm, if I do this, then it's going to be really hard to figure out which games are actually autosaves.  Autosaves are really meant to be temporary saves that prevent undue loss if your game ends unexpectedly (loss of power, crash, whatever), not a permanent archival system.  When stopping play, it's important to save your game for real, as is the case in pretty much all other games I can think of.  Our autosave functionality is pretty much identical to all shooters on the PC and PS3, and most RTS games don't have multiplayer save of late so I can't compare there (and I can't remember what they do with single-player).  I'm wary of getting too overcomplicated with this.

• Ungrouped selection. A modifier key to be able to select ships that are not in a group. Useful when you have groups massing at a wormhole, get a batch of reinforcements, and want to add them to another group (also at the wormhole) but you can't select them easily.

Added to the list.

• Idea suppressor. Some subliminal visual that allows you to play the game without coming up with any other whacky ideas.

Haha...

Thanks for all the great suggestions!

[Admiral]

• Auto-save naming. Have the game name the autosave using the name of the last loaded (or saved) game as a suffix. Have a lobby option to set the "save game name" for new games, or provide a reasonable default (e.g., names of players & starting date/time). Helpful for when you have (as I do) multiple games going simultaneously on the same laptop (tutorial, solo game, several multiplayer games).

Hmm, if I do this, then it's going to be really hard to figure out which games are actually autosaves.  Autosaves are really meant to be temporary saves that prevent undue loss if your game ends unexpectedly (loss of power, crash, whatever), not a permanent archival system.  When stopping play, it's important to save your game for real, as is the case in pretty much all other games I can think of.  Our autosave functionality is pretty much identical to all shooters on the PC and PS3, and most RTS games don't have multiplayer save of late so I can't compare there (and I can't remember what they do with single-player).  I'm wary of getting too overcomplicated with this.

I think I was unclear, sorry. All I am suggesting here is that each different "game" have a different autosave name. Right now, if I play game A (solo) a while, then play game B (multiplayer) a while, my game A autosaves are overwritten as they are all called the same thing. All I'm suggesting is that the autosave name be different on a per-game basis, e.g.,

Autosave - A.sav
Autosave - B.sav

You could even use an internal game UUID or something as the A and B; I had simply suggested instead using the last saved/loaded game name (or a reasonable default). I mostly use the autosaves as "oh shoot I really shouldn't have done that" undo points, in addition to the aforementioned "damn, the game crashed" saves (which has happened only once so far, well done).

Also, could you explain a bit more about the "engineers not healing while moving, except when following along" bit please? Does that (whatever that is, since I didn't understand) also apply to mobile repair stations?

Finally, the mobile shield ships I was thinking would only have 25,000-150,000 health in their shield (something in the range of a typical Tech Level I through C ship's health), not be a super badass 56,000,000 like the Force Field IIIs.

Glad you liked most of the other ideas. (Sorry, just had to try this "glow" thing.)

Cheers!

[x4000]

I think I was unclear, sorry. All I am suggesting here is that each different "game" have a different autosave name. Right now, if I play game A (solo) a while, then play game B (multiplayer) a while, my game A autosaves are overwritten as they are all called the same thing. All I'm suggesting is that the autosave name be different on a per-game basis, e.g.,

Autosave - A.sav
Autosave - B.sav

I understood what you meant -- the main thing is that this is going to require an internal dictionary of past autosaves, plus some changes to how the games themselves are set up (with a permanent name instead of just saving as whatever you want).  I haven't seen this with any other games, and I don't have a good mental model for this, hence my reluctance.

For instance:
- Where is the permanent name of the game entered in the UI?
- What happens when you load up an Autosave version -- does it retain the permanent name from the other one, etc?
- You could run into naming conflicts if a save file is called Autosave - A already, although of course this could happen now with the Autosave, so this is probably a bad argument.

Writing them out, they don't seem that serious, and it seems like there were some other things I was concerned about with that, too (well, in my case I would not want this option, I have around 60 games saved at any given time and one autosave is just fine), but this would be the sort of thing I'd add as an option, anyway.

My background is primarily in databases, so it always just makes me really nervous to use user-editable strings like this as keys.  And, I guess that's really the issue here, when I look at the arguments I come up with against this.  It's one of those "unclean" things to do for a database, but in a filesystem of course that's really a different animal.  So, anyway, this is now added to my list (it will be a settings option to turn this on), despite those earlier reservations.  It's important not to let the prejudices of one programming environment (which are quite valid in that context, for many reasons) unduly affect work in another, I think.

You could even use an internal game UUID or something as the A and B; I had simply suggested instead using the last saved/loaded game name (or a reasonable default). I mostly use the autosaves as "oh shoot I really shouldn't have done that" undo points, in addition to the aforementioned "damn, the game crashed" saves (which has happened only once so far, well done).

Right, I know what you mean about using it as a "go back" point.

Also, could you explain a bit more about the "engineers not healing while moving, except when following along" bit please? Does that (whatever that is, since I didn't understand) also apply to mobile repair stations?

When you give an engineer a move order, it won't do anything else except move until it reaches its destination.  This is by design, because in the past engineers were incredibly "disobedient" and would just do their own thing regardless of what the players told them -- a problem in heavy fire, etc.  Repairs often imply movement for engineers (they have to move into repair range), so hence the conflict.  In attack-move or free-roaming mode, they don't work that way, but they'll try to repair stuff anywhere on the current planet.  For mobile repair stations, they NEVER move to repair other ships, they just repair everything that is in a certain radius.  So, for them, moving or not makes no difference.

Finally, the mobile shield ships I was thinking would only have 25,000-150,000 health in their shield (something in the range of a typical Tech Level I through C ship's health), not be a super badass 56,000,000 like the Force Field IIIs.

Good point.  Added to my list.  I think this would make an interesting new bonus ship class for one of the expansions, actually.  I think it would be a very popular new option like parasites, anti-armor, and munitions boosters tend to be now.

Glad you liked most of the other ideas. (Sorry, just had to try this "glow" thing.)

Cheers!

You bet!

[PhilRoi]

Hey maybe as a compromise,  just split up the auto saves based on number of human players?   get a 1 player auto save and a 2 player auto save. etc.  This inherently limits the number of auto saves and keeps it simple to track.   And gives the functionality to keep single player saves from overwriting multiplayer saves...   limit it even more to a single player auto and an auto for when there are 2 or more humans playing....     just a thought.  I've never needed to use the auto save anyhow.  but I think this would give a rudimentary form of the functionality he was looking for above.

on a different note,  I was thinking about the AI data centers and my research vessels.  I wish my research vessels could data mine the data centers for knowledge since i am sure there is a ton of data in there...    then the programmer in me stepped in and said that would be a pain to code.  Just re-use(or modify) the graphics and create a new unit and call it an "Archival Library" and make it a capture-able immobile station.  and give say 500-1000 knowledge on capture.  Then the strategy game designer in me stepped in and said...   no freebies!   Have to give it a penalty to make it intresting.  Say the same penalties as a "captive human colony"?  Capture it get a small 1 time bonus to knowledge  but the AI gets a small kick in its aggression and tries hard to get it back.  these are already behaviors that have been coded before so it should be simple.  This presents a few strategical considerations for the player to consider before snacking on one of these.  IS the AI boot worth it?  is the system defendable?   sometimes (especially on smaller maps) your just a little short of the knowledge you need to unlock something and this gives you an option to get that extra K.  If it isn't worth it, then like the human colonies it gives you something to dance around and avoid like human colonies, increasing the complexity of "terrain".

[x4000]

Hey maybe as a compromise,  just split up the auto saves based on number of human players?   get a 1 player auto save and a 2 player auto save. etc.  This inherently limits the number of auto saves and keeps it simple to track.   And gives the functionality to keep single player saves from overwriting multiplayer saves...   limit it even more to a single player auto and an auto for when there are 2 or more humans playing....     just a thought.  I've never needed to use the auto save anyhow.  but I think this would give a rudimentary form of the functionality he was looking for above.

Very good points, thanks!

on a different note,  I was thinking about the AI data centers and my research vessels.  I wish my research vessels could data mine the data centers for knowledge since i am sure there is a ton of data in there...    then the programmer in me stepped in and said that would be a pain to code.  Just re-use(or modify) the graphics and create a new unit and call it an "Archival Library" and make it a capture-able immobile station.  and give say 500-1000 knowledge on capture.  Then the strategy game designer in me stepped in and said...   no freebies!   Have to give it a penalty to make it intresting.  Say the same penalties as a "captive human colony"?  Capture it get a small 1 time bonus to knowledge  but the AI gets a small kick in its aggression and tries hard to get it back.  these are already behaviors that have been coded before so it should be simple.  This presents a few strategical considerations for the player to consider before snacking on one of these.  IS the AI boot worth it?  is the system defendable?   sometimes (especially on smaller maps) your just a little short of the knowledge you need to unlock something and this gives you an option to get that extra K.  If it isn't worth it, then like the human colonies it gives you something to dance around and avoid like human colonies, increasing the complexity of "terrain".

You know, it's funny you bring this up -- when I originally coded the data centers, I had logic in there so that you could always capture them for a knowledge increase, or you could destroy them like now in order to decrease the AI progress.  I kind of like that back-and-forth, since in many ways having the AI Progress higher is one of the best tradeoffs for having more knowledge.  Your suggestion is making me think it would be a good idea to give scouts a new ability, like "infiltrate" or something, that would let you assign them to a data center to basically capture knowledge from it instead of downing the AI Progress.  Like you mentioned, something in me likes the symmetry with the Data Centers, since presumably they are full of knowledge.  This particular change doesn't increase the complexity of the terrain, but it does increase the complexity of the interesting decisions the players have to make.   Then data centers are not just rotely destroyed, and there is the chance of players having much higher AI Progress values, but also more knowledge.  Added to my list!

[PhilRoi]

trick for capturing K from data centers will be making it so that a scout can't capture knowledge and then the player assaults the data center for the reduced ai level as well.  instead of giving the ability to the Scout give it to Armored research vessel.   Then the  player has to escort the research vessel (which has the necessary computers, scanners, and equipment) into the AI planet and over to the Data center.  Then he has to guard it while the Data Center is mined by the Research vessel.   It also gives the player another reason to invest in the more expensive  research vessels.

[x4000]

trick for capturing K from data centers will be making it so that a scout can't capture knowledge and then the player assaults the data center for the reduced ai level as well.  instead of giving the ability to the Scout give it to Armored research vessel.   Then the  player has to escort the research vessel (which has the necessary computers, scanners, and equipment) into the AI planet and over to the Data center.  Then he has to guard it while the Data Center is mined by the Research vessel.   It also gives the player another reason to invest in the more expensive  research vessels.

Yeah, that's true the science labs would probably make more sense for this sort of function -- good point!  When the knowledge is "stolen" from the data center, I think that would basically destroy the data center in a way that does not increase the AI Progress.  So it would definitely be an either/or sort of situation.