Should Sensors Get Tech Information?

[Paul M]

I have to admit that I can thank the precursers for active sensor 16, active sensor 21, and active sensor 28 which was years of time with my research rate.  They were 6K, 10K, 15K or so research points if memory serves me.  The time to collect each one with a dedicated scout ship was relatively short and with a travel time of a few months a huge boost to my technology.

I am not sure active scanning of a ship should reveal anything to be frank.  To be honest there is a very limited boost you can get from seeing something working, most of it would be the fact it confirms something is possible to do.  But to really get anywhere you need a copy of the technology itself.  I'd boost the return from wrecks and just outright remove "scanning" especially since neither search systems nor fire controls would be designed to return data of any use for technological research.  If you capture a population, a ship or a wreck should be the only way to get technology data beyond say a 10% value for seeing a system in operation and that should apply only to systems such as engines, active sensors and fire control and well little else.  Armour, interior armour, etc are not things that a hull mapping would reveal.  Most passives should give you is the performance ratings but nothing more.

Active targeting systems should be a hostile action but search sensors are just that and no one should be upset if you have them active, anymore then people are upset that currently airports have active radar, or the DEWline exists.

I suspect though that I am a lone wolf in this case.

[waresky]

No,we r 2 lonely wolf:)

Am loving Aurora for extreme hard "game" for "hardgamer".

when something become too easy ive a movement of noise..

[Hawkeye]

Make that three

[SteveAlt (OP)]

I have to admit that I can thank the precursers for active sensor 16, active sensor 21, and active sensor 28 which was years of time with my research rate.  They were 6K, 10K, 15K or so research points if memory serves me.  The time to collect each one with a dedicated scout ship was relatively short and with a travel time of a few months a huge boost to my technology.

I am not sure active scanning of a ship should reveal anything to be frank.  To be honest there is a very limited boost you can get from seeing something working, most of it would be the fact it confirms something is possible to do.  But to really get anywhere you need a copy of the technology itself.  I'd boost the return from wrecks and just outright remove "scanning" especially since neither search systems nor fire controls would be designed to return data of any use for technological research.  If you capture a population, a ship or a wreck should be the only way to get technology data beyond say a 10% value for seeing a system in operation and that should apply only to systems such as engines, active sensors and fire control and well little else.  Armour, interior armour, etc are not things that a hull mapping would reveal.  Most passives should give you is the performance ratings but nothing more.

This is a game vs reality situation. Being able to learn something about a higher tech enemy is fun within the context of the game. The reality is probably that it would be hard to learn a lot from active sensors, although knowing something can be done is often half the battle. In the modern world, nations spend a lot of time spying on each other's military assets, especially trying to learn information about their electronic systems so they can jam them. Perhaps something along those lines might be more appropriate.

Active targeting systems should be a hostile action but search sensors are just that and no one should be upset if you have them active, anymore then people are upset that currently airports have active radar, or the DEWline exists.

I agree that active sensors are not seen as hostile in the real world and the only reason they are seen as hostile in Aurora is their tech scanning ability. If that is removed or transferred to fire controls, then they wouldn't be seen as hostile. I think active fire control would be seen as hostile regardless of the tech scanning situation.

Steve

[Paul M]

I don't really see being able to scan tech data this easily as fun Steve, but that is just me.  I don't think it is necessary and certainly from the perspective of a multiplayer game it probably causes far more headaches then it adds to playing enjoyment.  With the existance of espionage rules, and being able to acquire tech from captured ships, wrecks and populations I would just recommend dropping it.

The spying that goes on today is to find out the capabilities of the systems rather than to find out details on the state of development of the basic science.  I'm pretty sure you don't get too much infromation on high power klystron development from detecting radar emmissions compared to getting your hands on a transmision station.  Even reading papers is rarely as useful as actually talking to the people who did the work.

Fire control would be a hostile action in my view as well.

Also if populations are vital to recovering tech data as opposed to just scanning the ships then it works in favor of not bombarding them into the stone age.

[SteveAlt (OP)]

Aha!  Now I understand what you're saying.  I think there's a different way to get around the micromanagement - don't require a fire control lock in order to fire missiles.  If I look at the way Harpoon, Tomahawk, AMRAAM (IIRC) etc. work, they all can navigate by waypoint to a point near the target, at which point terminal search/guidance kicks in.  In other words, there's no indicator to the target that a missile launch has occured (unless the target detects the actual missiles) until very late in the missile's flight.  The fire control is only used at the very end.  This is actually similar to what goes on now in Aurora - if one target is destroyed the fire control (and associated missiles) simply switches to another, which is the moral equivalent of navigating the associated missiles to the neighborhood of the second target using waypoints, then doing terminal guidance with the fire control radar.

The yukky part that I see here is some sort of minimum time requirement that the target be illuminated - otherwise you could just light it up at the very end and the target would never know what hit it.  OTOH, that's essentially what happens right now (without detection of fire control) - just being detected by an active search radar doesn't indicate whether you're targetted by missiles which are in flight, and a target only has to be illuminated by fire control for 5 seconds in order to be hit with redirected missiles.  So the minimal change would be to allow fire control to be used in intel mode (which would be detectable by the target and last for long periods of time), or to automatically switch on and be detected during terminal guidance.

I don't think the problem changes. The issue is not that the target only has the same time to react as it does now (because fire control isn't currently detectable). The issue is that if fire control becomes detectable by the target only, rather than generally, then there is an advantage in micromanaging the attack so you don't illuminate your target until the last second, because if you use fire controls as normal the target knows it is the only possible target and gets a warning that it doesn't get now. That advantage gained through micromanagement doesn't exist under the current game mechanics and it wouldn't exist if fire control were generally detectable because just like now with active sensors no one would know who you were shooting at, if at all. The micromanagement advantage only exists if fire control is detectable solely by the target.

Steve

[SteveAlt (OP)]

I don't really see being able to scan tech data this easily as fun Steve, but that is just me.  I don't think it is necessary and certainly from the perspective of a multiplayer game it probably causes far more headaches then it adds to playing enjoyment.  With the existance of espionage rules, and being able to acquire tech from captured ships, wrecks and populations I would just recommend dropping it.

The spying that goes on today is to find out the capabilities of the systems rather than to find out details on the state of development of the basic science.  I'm pretty sure you don't get too much infromation on high power klystron development from detecting radar emmissions compared to getting your hands on a transmision station.  Even reading papers is rarely as useful as actually talking to the people who did the work.

Fire control would be a hostile action in my view as well.

Also if populations are vital to recovering tech data as opposed to just scanning the ships then it works in favor of not bombarding them into the stone age.

I can see both points of view on this and to be honest I would be quite happy with either in the game. I think there is general agreement that active sensors should not be able to scan for tech data and we seem to be down to two options as to the way forward.

1) Fire controls are used to scan for tech data and those fire controls emissions would be detectable. The mechanics would be generally the same as with active sensors at the moment.

2) There is no way to 'scan' for tech data. It can only be gained through espionage, salvaging wrecks, examining captured ships through the process of scrapping them - which in this case means taking them apart to see how they work, or capturing populations. I would probably change the way tech data is gained from populations so that the number of intact installations of particular types reflected the chance of gaining tech data in a related area (chance of construction rate tech based on surviving construction factories for example) with research labs having a chance of yielding any background techs possessed by the Empire originally in control of the population. This would allow data to be gained from mining colonies and sensor outposts with no actual population but would mean a planet with a large pop and minimal industry would yield little. This would fit in well with the suggestion above that bombarding would be a bad idea if you wanted tech data.

Option 2) is the easiest for me in terms of implementation and in terms of performance. It is also more realistic. Option 1) makes it easier to overcome enemies with greater technology and over time will allow lower tech races to catch up more quickly.

I would be interested to hear opinions on a straight choice between the two.

I am also considering adding an additional way to gain tech in either v4.1 or v4.2, which I'll call Osmosis. If a planet has more than one population and the smaller pop is at least 10m, the technology of the higher-tech Empire will gradually filter to the lower tech Empire. I would probably handle this by checking every time an Empire gets a new background tech. If the other Empires on the planet don't have the technology two levels below the newly researched one, they will get it through osmosis. So if the United States developed Ion Engines, then any Earth-based power without nuclear thermal engines would receive them at that point. If the USA developed 25cm lasers, then 15cm lasers would become generally available on Earth. This reflects modern life. For example, India has a relatively modern military but almost all of the background technology required for that military was invented elsewhere. The other world powers didn't explicitly hand over that technology, it just became generally available. They aren't in the same class as the USA in technology terms because the very latest US tech is kept very secret. Older US technology that is a couple of generations out of date has spread around the globe.

Also, if option 2) was the way forward, there would be still be an element of option 1) in the future because analysing enemy active sensors would become a vital part of electronic warfare when I revise that area.

Steve

[Brian Neumann]

Option 2 is more realistic, but I personally prefer option 1.  It also helps to level the field over time when you run into a more advanced race.  If you can hold on then you will start to get info back that could help.

Brian

[sloanjh]

I don't think the problem changes. The issue is not that the target only has the same time to react as it does now (because fire control isn't currently detectable). The issue is that if fire control becomes detectable by the target only, rather than generally, then there is an advantage in micromanaging the attack so you don't illuminate your target until the last second, because if you use fire controls as normal the target knows it is the only possible target and gets a warning that it doesn't get now. That advantage gained through micromanagement doesn't exist under the current game mechanics and it wouldn't exist if fire control were generally detectable because just like now with active sensors no one would know who you were shooting at, if at all. The micromanagement advantage only exists if fire control is detectable solely by the target.

I'm actually trying to say something else - sorry if I'm not being clear.  My observation is that if you made fire control illumination (as opposed to specifying a target) detectable, it would be consistent, given the current target switching abilities, to only have the fire control actually illuminate the target for the last 5 seconds (let me put off the realism of this 'til a later paragraph). This is based on the fact that I can aim my missiles at one ship and then switch targets at the last instant; this is mechanically the same as (the ship's fire control suite, by which I include onboard computers, datalink, active tracking etc.) guiding them to waypoints through datalink right up until the last 5 seconds, and only then illuminating the target.  In other words, no micromanagement would be needed, because it can be assumed that the ship's fire control suite will always be doing the micromanagement, and the result is that targets are only ever illuminated for the last 5 seconds (unless they're manually illuminated for another reason such as intel gathering or as a pointed message).

Now for realism: I suspect you'll object (and I agree with the objection) that only requiring illumination for the last 5 seconds is a bit unrealistic  IIRC, the reason for Aurora fire control radar is that an active contact actually has an "uncertainty blob"; it's location isn't actually well enough determined to guide a missile properly.  It seems like this blob should be proportional to the distance to the target, so that e.g. you have to start illuminating the target when the missile is 90% of the way there, because that's the point where it becomes too late to correct for the uncertainty.  I've come up with two ways to manage this based on whether a short or long period of illumination is required.

Short illumination:  Have a "terminal guidance time" tech that tells how long (e.g. 30 seconds) a target needs to be illuminated before a missile can hit.  The problem with this one comes up for AMM - the entire flight time of the attacking missiles through the detection envelope might be shorter than this time.  In addition, from a practical point of view there's not a lot of additional benefit to knowing that missiles are coming in 30 seconds before they hit, i.e. it's not worth screwing around with coding up illumination detection.

Long illumination:  Have the requirement for illumination be a percentage of the total flight time/distance, i.e. illumination turns on when missiles are 90% of the way there.  The problem with this one is figuring out what "90% of the way there" means, since this will change depending on whether the target is coming towards you or away.  Another problem is that target switching would be way too slow - you shouldn't need to illuminate for an additional 1/2 hour in order to correct a missile from one ship to another ship in the same fleet - and trying to solve this problem opens one up to micromanagement exploits.  I've got a mechanism that I think has a chance of working - let me know if you want me to post it.

To phrase things a different way, I think there's two things going on:

1)  From a realism point of view, targets shouldn't have to be illuminated for the entire time of flight of a missile - it's only at the end that precise location information is required.

2)  Trying to make the terminal guidance phase (when illumination is required) long enough for the target to take significant action (i.e. longer than a minute or two) is a yukky problem, and can lead to the sorts of micromanagement exploits that you're worried about.  

John

[sloanjh]

I think the ideas in option 2 are great, and should be done (at some point) whether or not you do option 1.

I only think you should bother with option 1 if the acquisition rate is comparable to osmosis (i.e. neither significantly faster nor very much slower).  One way to do this would be to make the acquisition rate similar to that for active sensor data (from passive detection) and put in the 75% limit (which corresponds to the two TL of osmosis).  If the acquisition rate is so slow that it takes years to advance a TL, then gaining tech points becomes a random event that just complicates the game without having a significant impact on the progress of an empire.

John

[SteveAlt (OP)]

I don't think the problem changes. The issue is not that the target only has the same time to react as it does now (because fire control isn't currently detectable). The issue is that if fire control becomes detectable by the target only, rather than generally, then there is an advantage in micromanaging the attack so you don't illuminate your target until the last second, because if you use fire controls as normal the target knows it is the only possible target and gets a warning that it doesn't get now. That advantage gained through micromanagement doesn't exist under the current game mechanics and it wouldn't exist if fire control were generally detectable because just like now with active sensors no one would know who you were shooting at, if at all. The micromanagement advantage only exists if fire control is detectable solely by the target.

I'm actually trying to say something else - sorry if I'm not being clear.  My observation is that if you made fire control illumination (as opposed to specifying a target) detectable, it would be consistent, given the current target switching abilities, to only have the fire control actually illuminate the target for the last 5 seconds (let me put off the realism of this 'til a later paragraph). This is based on the fact that I can aim my missiles at one ship and then switch targets at the last instant; this is mechanically the same as (the ship's fire control suite, by which I include onboard computers, datalink, active tracking etc.) guiding them to waypoints through datalink right up until the last 5 seconds, and only then illuminating the target.  In other words, no micromanagement would be needed, because it can be assumed that the ship's fire control suite will always be doing the micromanagement, and the result is that targets are only ever illuminated for the last 5 seconds (unless they're manually illuminated for another reason such as intel gathering or as a pointed message).

Aha! Now I understand. You are saying that assuming you don't want to scan for tech, the fire control would automatically guide the missiles near to the target but only actually illuminate it at the last second and all that would be part of the normal function of the fire control. No micromanagement would be needed because the only real difference to the existing situation is that target would be able to detect a fire control in the last seconds before the missiles hit. I presume that for tech scanning, the fire control would illuminate the target and the target would be aware of that illumination.

Now for realism: I suspect you'll object (and I agree with the objection) that only requiring illumination for the last 5 seconds is a bit unrealistic

Possibly, although as you mentioned earlier the target being unaware of the attack is no different than it is now.

IIRC, the reason for Aurora fire control radar is that an active contact actually has an "uncertainty blob"; it's location isn't actually well enough determined to guide a missile properly.  It seems like this blob should be proportional to the distance to the target, so that e.g. you have to start illuminating the target when the missile is 90% of the way there, because that's the point where it becomes too late to correct for the uncertainty.  I've come up with two ways to manage this based on whether a short or long period of illumination is required.

Short illumination:  Have a "terminal guidance time" tech that tells how long (e.g. 30 seconds) a target needs to be illuminated before a missile can hit.  The problem with this one comes up for AMM - the entire flight time of the attacking missiles through the detection envelope might be shorter than this time.  In addition, from a practical point of view there's not a lot of additional benefit to knowing that missiles are coming in 30 seconds before they hit, i.e. it's not worth screwing around with coding up illumination detection.

Long illumination:  Have the requirement for illumination be a percentage of the total flight time/distance, i.e. illumination turns on when missiles are 90% of the way there.  The problem with this one is figuring out what "90% of the way there" means, since this will change depending on whether the target is coming towards you or away.  Another problem is that target switching would be way too slow - you shouldn't need to illuminate for an additional 1/2 hour in order to correct a missile from one ship to another ship in the same fleet - and trying to solve this problem opens one up to micromanagement exploits.  I've got a mechanism that I think has a chance of working - let me know if you want me to post it.

To phrase things a different way, I think there's two things going on:

1)  From a realism point of view, targets shouldn't have to be illuminated for the entire time of flight of a missile - it's only at the end that precise location information is required.

2)  Trying to make the terminal guidance phase (when illumination is required) long enough for the target to take significant action (i.e. longer than a minute or two) is a yukky problem, and can lead to the sorts of micromanagement exploits that you're worried about.  

Now I understand what you meant, I agree with 1) and I don't think 2) is a real issue because even knowing an attack will begin in 5 seconds is 5 seconds longer than at the moment (assuming you can't detect the missiles). However, I think we are back to a different but familiar problem. At the moment active sensors are seen as hostile because you can scan tech and it is also necessary for an attack. If fire controls were generally detectable and necessary for tech scanning, then active sensors would no longer be seen as hostile because the fire control would be the sign of an attack. However, if fire controls could only be detected in the last seconds before an attack, then they would provide no warning of an attack. In that case, the only warning would be the active sensors that would be necessary for the fire controls to lock on, which means active sensors would have to be regarded as hostile (as the only visible sign of an imminent attack) and we are back to square one.

Steve

[SteveAlt (OP)]

I think the ideas in option 2 are great, and should be done (at some point) whether or not you do option 1.

Most of 2) is already in v4.0. You can already get tech from espionage, salvaging wrecks, scrapping captured ships and capturing populations. The only difference is that for capturing populations I would make the tech gain based on industry rather than total population.

I only think you should bother with option 1 if the acquisition rate is comparable to osmosis (i.e. neither significantly faster nor very much slower).  One way to do this would be to make the acquisition rate similar to that for active sensor data (from passive detection) and put in the 75% limit (which corresponds to the two TL of osmosis).  If the acquisition rate is so slow that it takes years to advance a TL, then gaining tech points becomes a random event that just complicates the game without having a significant impact on the progress of an empire.

Osmosis would depend very much on the situation. Its only really applicable to a game with multiple starting races on the same planet or where different Empires establish colonies on the same planets. In some games, it wouldn't ever happen because the different races inhabit different planets.

Steve

[sloanjh]

I think the ideas in option 2 are great, and should be done (at some point) whether or not you do option 1.

Most of 2) is already in v4.0. You can already get tech from espionage, salvaging wrecks, scrapping captured ships and capturing populations. The only difference is that for capturing populations I would make the tech gain based on industry rather than total population.

Yep - it's some form of the "based on industry" bit that I really like.   Hmmmm I guess that means that capturing shipyards (military tech), research labs (other tech), and sensor outposts (passive scanner tech) becomes much more militarily important, while capturing industrial populations (factories, mines etc) become important for productivity.

I only think you should bother with option 1 if the acquisition rate is comparable to osmosis (i.e. neither significantly faster nor very much slower).  One way to do this would be to make the acquisition rate similar to that for active sensor data (from passive detection) and put in the 75% limit (which corresponds to the two TL of osmosis).  If the acquisition rate is so slow that it takes years to advance a TL, then gaining tech points becomes a random event that just complicates the game without having a significant impact on the progress of an empire.

Osmosis would depend very much on the situation. Its only really applicable to a game with multiple starting races on the same planet or where different Empires establish colonies on the same planets. In some games, it wouldn't ever happen because the different races inhabit different planets.

I think I phrased things poorly.  What I'm trying to say is that getting 100 or 200 points here or there from tech scanning doesn't add the possibility of using scanning as a significant strategy, since it can't be used to appreciably change your tech level, and that osmosis sounds like a such a significant strategy (plant a colony through diplomacy and see the benefits).  The only way I think it's worth putting tech scanning into the game is to give it the potential to add tech levels at a rate similar to those at which a new tech level can be research within your civilization, i.e. a year or so.  At the same time, stone-age primitives shouldn't be able to jump to the tech level of a civilization that's had TNT for a century in the space of 10 years, so there has to be something to put the brakes on (the 75% idea, which essentially cuts off useful tech acquisition 2-4 tech levels above the natural set point of the civilization, as determined by its research capacity).  I view this as a game design issue; mechanisms shouldn't be put in that don't present the opportunity for a strategic choice, or somehow are needed for balance.  From trying to go down the tech scanning road in my current game, I'm finding that it's much too quick to advance to high levels of active scanning (go find a precursor and listen to him for a few weeks) and too slow to advance other technologies.  So what I'm trying to say is that I'm neutral on this one; I think the active scanning strategy makes for a good balancing mechanism in a "mouse within the walls" pre-TNT start (where you only encounter civilizations which are far ahead of you in tech level, due to the 20 years spent getting off the planet), but that the current acquisition rate has too much micromanagement.  If the micromanagement can be reduced I would say keep it; if not then rip it out.

Now that I think of it, two thoughts on osmosis:

1)  Let's say I plant a 10million pop colony on a planet with 2billion NPR primatives (no tech, no pre-TNT industry) or even pre-TNT industrial primatives.  Do you really want them to jump straight up to 2 TL below my TL?  In other words, is the proposed osmosis mechanism too fast?

2)  Should trade between Empires cause osmosis of tech?

John

[sloanjh]

Drat!  My first response to this got eaten by a "this board is unavailable screen" (which was very weird), and of course I had forgotten to save the text before hitting "submit".  Trying to reproduce....

Aha! Now I understand. You are saying that assuming you don't want to scan for tech, the fire control would automatically guide the missiles near to the target but only actually illuminate it at the last second and all that would be part of the normal function of the fire control. No micromanagement would be needed because the only real difference to the existing situation is that target would be able to detect a fire control in the last seconds before the missiles hit. I presume that for tech scanning, the fire control would illuminate the target and the target would be aware of that illumination.

Yep.  I think I had another comment here, but I've forgotten it - oh well.

Now I understand what you meant, I agree with 1) and I don't think 2) is a real issue because even knowing an attack will begin in 5 seconds is 5 seconds longer than at the moment (assuming you can't detect the missiles). However, I think we are back to a different but familiar problem. At the moment active sensors are seen as hostile because you can scan tech and it is also necessary for an attack. If fire controls were generally detectable and necessary for tech scanning, then active sensors would no longer be seen as hostile because the fire control would be the sign of an attack. However, if fire controls could only be detected in the last seconds before an attack, then they would provide no warning of an attack. In that case, the only warning would be the active sensors that would be necessary for the fire controls to lock on, which means active sensors would have to be regarded as hostile (as the only visible sign of an imminent attack) and we are back to square one.

Two things (condensed from lost post):

1)  This assumes that the only way to attack someone at long range is with an missile that's actively guided.  What about heat seekers?  Presumably I could put a passive (e.g. thermal) or even active head on a missile, and use that for terminal guidance after navigating the missile to the vicinity of a passive contact - this is essentially the way that submarines attack targets now with torpedoes (with wire-guided torpedoes getting real-time course correction from the sub's passive suite).  In fact, if we carry the sub analogy further, active sensors are usually used defensively (by the escorts) in order to create a sanitized region around high value targets errr I mean assets.  As someone posted, having an air traffic control radar turned on is not a hostile act, it's a way of ensure you know everything that's going on in your airspace.

2)  How about this for a twist: it seems like the underlying problem here is that the location of  a passive contact is much less well known than that of an active contact, which in turn are much less well know than a target being illuminated by fire control, but that Aurora is displaying the exact location of the contact to the player in all three cases.  This leads to the exploit of plopping a waypoint down right next to the target, then only "lighting it up" for the final approach.  So why not solve the problem by introducing uncertainty  into the position being reported to the player?  Basically, each sensor type (passive/active/fire control) would have an uncertainty level, expressed as a percent of the distance to the target.  For example passive uncertainties might be ~10%, active might be ~0.1%, and fire control might be zero.  When the location of the contact is reported to the player, it's shifted by a random vector somewhere within the uncertainty circle.  For simplicity, the direction and fraction of the distance from the center of the circle could be calculated once when the contact is first acquired, then just rescaled by the best (uncertainty level)*distance of all the sensors that "see" the contact at the end of a particular timestep.

The way fire control would work (assuming that you're not micromanaging with a waypoint) would be that Aurora would know the (uncertainty level)*distance for a particular target, and automatically illuminate it when the missiles got to that distance (or the player could choose an illumination distance or illuminate by hand for the whole flight).  If there's a seeker head on the missile, then it could just be fired at a waypoint with instructions to turn on the seeker when it gets there.

What do you think?

John

[Erik L]

Drat!  My first response to this got eaten by a "this board is unavailable screen" (which was very weird), and of course I had forgotten to save the text before hitting "submit".  Trying to reproduce....
...
John

Only in the fact I commited some updates to the board at the same time you clicked submit