Post by: SteveAlt on May 02, 2009, 12:35:50 PM
Something to bear in mind as well is that because of this tech detection ability, using active sensors is regarded as a very hostile act. Removing this ability would make active sensors much more prevalent in safe systems with multiple races, such as in a multi-nation start on Earth, although there would still be the downside of giving yourself away to potentially hostile forces in less safe areas. This would probably make things easier in terms of monitoring traffic in inhabited systems but actually increase the number of sensor checks carried out, which might have a performance impact of its own.
The options I can think of at the moment are:
1) Leave things as they are now
2) Change the way it works slightly by checking the chance of tech gain before examining the target ship. Currently the ship details are accessed and then a check is made against each background tech connected with each component, which means you can learn more than one tech at once. A change to this option would mean a check up front to determine if anything was going to be learned and then accessing the database to pick the background tech for a random component. This is less detailed but faster.
3) Remove the entire tech detection idea
4) As 3) but also change wreck salvage and scrapping of captured ships to have a good chance of tech point gains similar to current tech scans, rather than the existing system of learning to build a specific system. Essentially, a good chance of tech from salvage/scrapping would replace a low chance of tech from scanning. This option retains the ability to gain tech, removes the possibly too-powerful tech-scanning ability of active sensors, improves performances and allows more active sensor use without a casus belli. A downside is that if you are outclassed, you may not get to salvage any wrecks. Conversely, you would have more chance of getting data from the occasional precursor wrecks scattered through the galaxy.
5) Remove the ability for normal active sensors to detect tech data and instead add some new type of dedicated, expensive and relatively short-ranged scanner system with this ability
I am sure there are other ideas I haven't thought of yet so all suggestions and comments welcome.
Steve
Post by: Erik L on May 02, 2009, 12:57:17 PM
Post by: SteveAlt on May 02, 2009, 01:13:38 PM
Quote from: "Erik Luken"
Make it so that you do not get active sensor data unless the ship has been targetted via the F8 screen.Interesting idea! Effectively this would mean that fire controls could scan tech rather than active sensors, which could be explained by their much tighter focus. Of course, this would probably mean that ships should know when they were being illuminated by fire control, which has other implications. The main one being that there would be a tendency to shoot all missiles at waypoints close to the target to avoid warning the target and then lock it up at the last second, which would lead to a lot more micromanagement. Firing at waypoints does give flexibility but it causes some design headaches too
An option to solve that might be that fire controls are detected like active sensors, rather than just by the targeted ship. While not as realistic it would avoid the micromanagment aspect as firing at a waypoint is no longer a way to remain undetected. Of course, it could just be left as it is now where ships don't know when they are being targetedand fire controls are undetectable. Its not as bad as it sounds because a fire control can only scan one ship at once, not every ship in range like an active sensor, so the tech scanning ship would remain secret but limited to its number of fire controls. The latter would likely not change the current casus belli situation though as active sensors would still be required to find scan targets for fire controls so the active sensor itself would likely still be seen as hostile.
Steve
Post by: Erik L on May 02, 2009, 04:06:27 PM
Think of popular fiction and movies, especially military air warfare movies. The "missile lock" is seen as a sign of aggression, whereas radar (an active scanner) is not. That's what I am suggesting.
And definitely make fire lock be detectable. Or possibly, allow fire control suites to be brought online/offline separately from active scanners. Active scanners pose no direct threat; they cannot guide weapons. Fire control suites, however are a direct threat since they directly control weapons. And like you say, make the "tighter focus" aspect of the fire control suites gain tech data.
One thing I'd like to see is the ability to load tech data into a drone and fire it off. Similar to CD in Starfire, SLAM drones in Weber's Fury books, etc. Sucks to have a long fight that you KNOW you are going to lose, and gain a crapload of tech data, but not be able to make anything of it since the ships get blown to debris. Of course, make this a limited resource on a ship. Maybe 1 per 1000 tons or so. And if you fire off the drone, then get further updates, that drone will not have the additional information. Possibly also make memory capacity limited on the drones. Maybe 5000 rp capacity. Ideally they'd be JP capable too.
Post by: SteveAlt on May 02, 2009, 05:25:42 PM
Quote from: "Erik Luken"
Not necessarily would active scanners be hostile. It's the act of locking a target with fire control that is usually seen as hostile.I agree that fire control being the hostile act in reality is true and I agree that in the context of the game, allowing fire control to be the tech scanner makes a lot of sense. It is also better than the current system in terms of performance.
Think of popular fiction and movies, especially military air warfare movies. The "missile lock" is seen as a sign of aggression, whereas radar (an active scanner) is not. That's what I am suggesting.
And definitely make fire lock be detectable. Or possibly, allow fire control suites to be brought online/offline separately from active scanners. Active scanners pose no direct threat; they cannot guide weapons. Fire control suites, however are a direct threat since they directly control weapons. And like you say, make the "tighter focus" aspect of the fire control suites gain tech data.
I also agree that being able to detect fire control makes sense. The only problem I can see is that if the lock is only detectable by the target, the aforementioned micromanagement of shooting all missiles at waypoints to avoid warning the target would become prevalent. So if we go down this route, I think perhaps the use of active fire control would be generally detectable, probably by EM sensors in the same way as they detect active sensors (although that would then add more checks to the sensor phase
).Steve
Post by: Erik L on May 02, 2009, 05:40:59 PM
Post by: ShadoCat on May 02, 2009, 07:26:20 PM
One way to remove the waypoint issue is that unless the missile has on board sensors, it can't fire without a lock (even if it will be routed to a waypoint). Though that has issues with non weapon missiles. Maybe, for weapon missiles, they have to be programmed while in the launch tube (higher data rates). So the target must be lit at the time it is programmed. Then all the firing ship has to do is send updates.
Another option would be a tech scanner about the size of a fire control system (with range vs tech points gained and modified by scanner size).
Post by: sloanjh on May 02, 2009, 10:09:06 PM
Quote from: "SteveAlt"
I also agree that being able to detect fire control makes sense. The only problem I can see is that if the lock is only detectable by the target, the aforementioned micromanagement of shooting all missiles at waypoints to avoid warning the target would become prevalent. So if we go down this route, I think perhaps the use of active fire control would be generally detectable, probably by EM sensors in the same way as they detect active sensors (although that would then add more checks to the sensor phase :-) (Although the fact that they're as smart as they are is impressive.) A few observations on their behavior:
A) They keep their active sensors going all the time, which makes them easy to spot, track, and avoid. A simple sprint/drift strategy, where they move to a new location, light up the actives for a few seconds, then move to another location would make Precursor systems MUCH less safe to play in.
B) When they lose contact with something they're chasing, they either stop or reverse course and head back to what they're guarding, even if they have a speed advantage. This is how I've been playing tag with them - I have an active sensor that can pick them up at ~300Mkm (their active detection range for me is about 90Mkm and thermal is probably about 150), so I turn it on, let them chase me while I scan them, turn it off when they get too close, they stop, and I build the range back up and repeat. This is a LOT of micromanagement and a bit of gaming the system - OTOH my range advantage is big and their speed advantage is small, so it can also be viewed as substituting for a much more intense cat-and-mouse with much smarter precursors. If they didn't stop, but instead continued going to the contact point they'd be tougher to evade without a speed advantage.
C) They all lump together. What would be really nasty would be if e.g. 5 precursors chasing a contact spread out when they lost contact, in order to cover a range of possible evasion courses the contact might be taking (again, assuming a speed advantage for the precursors).
D) They use a direct pursuit course, rather than lead pursuit. This means they don't close the range as rapidly as they might.
4) If Precursors (and presumably NPR) were more clever, then presumably it would be harder to keep them under active observation for long periods of time. This would argue for making the rate of acquisition higher.
5) I was frustrated that I couldn't get any information on sensor tech from Precursor listening posts. I tried active scanning them and, as far as I could tell, got nothing (they didn't show up as active contacts, even though I had them on thermal - hmmm - how does one target them for missile strikes?). When I invaded and captured them station with ground troops, they instantly popped down in tech to one of my standard tracking stations. Note that this is just an observation - I understand the coding difficulties of having different tech installations; I'm just saying it would be nice to be able to get tech information (e.g. factory, mining, wealth(?)...) from captured enemy bases which were of higher tech e.g. with a Xeno team. Maybe the thing to do is to place a ruins when an enemy population is captured, or put a "tech available" flag on populations that would be true both for ruins and for captured populations. If you went down this road it would probably actually have to be a list of "available tech" for the population, so one couldn't get Precursor or highly advanced tech from an NPR that was only slightly ahead of you.
6) When my spy ships came home to Sol, sometimes they dump to Earth, sometimes to Mars. This is awkward from a game perspective, and didn't make much sense. I'd much rather have the tech data go to every planet (at least in the system). This leads to the idea of a "load tech data" command for ships that would allow research points acquired on one world to be transported to other worlds. It probably wouldn't be used a lot, but every now and then I decide I'd really rather be working on an already-started project in another system.
So I think what I'd like to see for tech acquisition is the following:Smarter Precursors that are harder to dodge and preclude active observation for extended periods of time (unless the intel ship has both a range and speed advantage).
Faster acquisition of data when spying - this is so that spying can be a strategy, rather than just an occasional bonus. Perhaps the thing to do is to restrict the amount of data that can be acquired through spying to e.g. the first 75%, for example any points beyond 1500 for a 2000 point tech would be lost (useless). This is essentially the way it works now, except with a "100%" limit, i.e. you can't start getting data on the next TL until you've dumped the current TL data to a world and advanced your TL. The advantage of a 75% limit is that it counteracts the unrealistic phenomenon that I saw when I was getting active sensor tech through passive means - I went up about 5 levels in the space of a year. From a realism point of view, this represents the effort needed to grok the data that was acquired. In game mechanics, a 75% limit would make research 4x as easy, which translates to roughly a 2 TL boost (since cost tends to double with TL). If you wanted a 3 TL boost then you would make the limit 87.5%.
If I do have a range and speed advantage, the ability to give a "spy" order to an intel ship that would keep it greater than X and less than Y distance away from the nearest bad guy. I realize this might be hard to code up.
More ability to gain tech from populations (e.g. listening posts), either through scanning or capturing. Capturing a populated populationshould allow you to gain productivity tech as well.
[/list]
I bolded the 75% limit stuff because I think it has a lot of potential to fix the things that are subtly off with the current system. If acquisition is too fast (as for active sensors observed by passive) then you can advance too quickly in TL. If it's too slow (as it appears to be with active scanning from my experience with the precursors), then it turns into a random "act of god" event in short encounters like combat (which spying isn't a strategy, it's just luck) and requires too much micromanagement for long encounters, because the encounters are so long. The 75% trick solves the "too fast" problem by requiring research investment to use the data, and solves the "too slow" problem by allowing acquisition to be made much faster.
I'm not sure (but lean against) whether the same should apply to ruins, wrecks, and/or captured populations - it seems like the data from these is different in that you've got physical artifacts to examine. In addition, these can be made slow, since they don't require micromanagement (because you've got control of the thing being examined). So from a game play point of view, the same problems don't show up that would require the 75% trick - the investment (from a game play sense) is in making the Xeno teams.
John
Post by: welchbloke on May 03, 2009, 01:06:45 PM
Post by: Manekaalecto on May 03, 2009, 02:04:33 PM
a) gathering tech points
b) be detectable
c) considered to be very impolite (casus belli level of offense)
should work fine and be a lot of fun.
Post by: sloanjh on May 03, 2009, 03:26:11 PM
Quote from: "welchbloke"
I also would like to put a vote in for fire control detectable and providing tech data. Fire control is certainly detectable in th real world and I can't see any reason why it couldn't be read across to Aurora.
BTW, I would vote against having a lock-on be detectable by anything other than the target. Since fire control is purportedly tight-beam, the other ships wouldn't be getting hit by the beam (unless they're supposedly seeing backscatter). The other advantage of "target-only" detection is that it's one less O(N) detection check to do during the detection phase
John
Post by: SteveAlt on May 03, 2009, 05:31:56 PM
Quote from: "sloanjh"
1) I don't understand why making active sensor detection a non-hostile act would make people more likely to play the "waypoint" trick. I haven't tried this, but I had assumed that I could (in 4.0b) fire my missiles at a distant waypoint and only "light up" the target once the missiles arrive. If not, I think this should be a valid tactic from a realism point of view - I'm pretty sure that e.g. Tomahawk, AMRAAM, Harpoon, Phoenix etc. all work this way IRL. Actually, now that I think of it, most if not all of these have onboard active terminal guidance so it's not quite the same, but the same principle should apply for semi-active homing. In other words, I think this should already be possible, so it shouldn't be a negative on the idea of making lock-on the hostile act.Its not making active sensor detection a non-hostile act that would make people more likely to play the "waypoint" trick, it's making fire control lock-on detectable only by the target
Quote
2) My answer to the original question is "yes". Most of the fun in my current game is from playing tag with the precursors, trying to get tech info from them. I'm torn as to the rate of acquisition - when I was just passively listening to the active sensors, I was getting info pretty rapidly (i.e. a couple of weeks to get enough tech for the next level). Now that I'm letting them chase me around while I ping them, which I've been doing non-stop for a couple of game-years now, the tech info is flowing in MUCH more slowly - I haven't gotten 1 full level of information in any system. This might argue for making the acquisition rate a bit faster, since the only reason I'm able to keep them under active observation for years at a time is that Precursors aren't that smart (and I'm doing a lot of micromanagement - see below).Even if we switched to fire control instead of active sensors for tech scanning, you could still play tag with the precursors in much the same way.
Quote
A) They keep their active sensors going all the time, which makes them easy to spot, track, and avoid. A simple sprint/drift strategy, where they move to a new location, light up the actives for a few seconds, then move to another location would make Precursor systems MUCH less safe to play in.Precursors and NPRs will turn their sensors off sometimes. At the moment though, once they detect you on passives they will switch on actives. I agree there could be a little more intelligence in this area and perhaps they shouldn't switch on actives until within range of the thermal contact. However, for the initial version of the AI I though it would be better to engage actives in case anything else was closer that passive hadn't spotted. Once the current version is done, I will revisit the AI for the next version.
Quote
When they lose contact with something they're chasing, they either stop or reverse course and head back to what they're guarding, even if they have a speed advantage. This is how I've been playing tag with them - I have an active sensor that can pick them up at ~300Mkm (their active detection range for me is about 90Mkm and thermal is probably about 150), so I turn it on, let them chase me while I scan them, turn it off when they get too close, they stop, and I build the range back up and repeat. This is a LOT of micromanagement and a bit of gaming the system - OTOH my range advantage is big and their speed advantage is small, so it can also be viewed as substituting for a much more intense cat-and-mouse with much smarter precursors. If they didn't stop, but instead continued going to the contact point they'd be tougher to evade without a speed advantage.When I get back into the AI code, I will add some more intelligence and some randomizing to Precursor behaviour.
C) They all lump together. What would be really nasty would be if e.g. 5 precursors chasing a contact spread out when they lost contact, in order to cover a range of possible evasion courses the contact might be taking (again, assuming a speed advantage for the precursors).
D) They use a direct pursuit course, rather than lead pursuit. This means they don't close the range as rapidly as they might.
4) If Precursors (and presumably NPR) were more clever, then presumably it would be harder to keep them under active observation for long periods of time. This would argue for making the rate of acquisition higher.
Quote
5) I was frustrated that I couldn't get any information on sensor tech from Precursor listening posts. I tried active scanning them and, as far as I could tell, got nothing (they didn't show up as active contacts, even though I had them on thermal - hmmm - how does one target them for missile strikes?). When I invaded and captured them station with ground troops, they instantly popped down in tech to one of my standard tracking stations. Note that this is just an observation - I understand the coding difficulties of having different tech installations; I'm just saying it would be nice to be able to get tech information (e.g. factory, mining, wealth(?)...) from captured enemy bases which were of higher tech e.g. with a Xeno team. Maybe the thing to do is to place a ruins when an enemy population is captured, or put a "tech available" flag on populations that would be true both for ruins and for captured populations. If you went down this road it would probably actually have to be a list of "available tech" for the population, so one couldn't get Precursor or highly advanced tech from an NPR that was only slightly ahead of you.Although you can't get direct tech data by scanning a population, when you capture a population you have the chance of gaining data on that population's technology. Larger populations will yield a greater chance.
Quote
6) When my spy ships came home to Sol, sometimes they dump to Earth, sometimes to Mars. This is awkward from a game perspective, and didn't make much sense. I'd much rather have the tech data go to every planet (at least in the system). This leads to the idea of a "load tech data" command for ships that would allow research points acquired on one world to be transported to other worlds. It probably wouldn't be used a lot, but every now and then I decide I'd really rather be working on an already-started project in another system.Those two requests are unfortunately contradictory. If the ship with the tech data unloaded to both Earth and Mars, you could then load the points on Earth on to a ship and moves them to Mars, doubling the original points total ;-) should allow you to gain productivity tech as well.[/quote]
You can already get a huge amount of data when you capture a population but that is based on population size.
Quote
I bolded the 75% limit stuff because I think it has a lot of potential to fix the things that are subtly off with the current system. If acquisition is too fast (as for active sensors observed by passive) then you can advance too quickly in TL. If it's too slow (as it appears to be with active scanning from my experience with the precursors), then it turns into a random "act of god" event in short encounters like combat (which spying isn't a strategy, it's just luck) and requires too much micromanagement for long encounters, because the encounters are so long. The 75% trick solves the "too fast" problem by requiring research investment to use the data, and solves the "too slow" problem by allowing acquisition to be made much faster.
It does have quite a few complications though in terms of how the data is held and when it can be used.
Quote
I'm not sure (but lean against) whether the same should apply to ruins, wrecks, and/or captured populations - it seems like the data from these is different in that you've got physical artifacts to examine. In addition, these can be made slow, since they don't require micromanagement (because you've got control of the thing being examined). So from a game play point of view, the same problems don't show up that would require the 75% trick - the investment (from a game play sense) is in making the Xeno teams.
Steve
Post by: SteveAlt on May 03, 2009, 05:37:19 PM
Quote from: "sloanjh"
I agree that it would be more realistic that only the target would detect the fire control. Unfortunately, in game-terms it leads to a micromanagement nightmare. If you are launching missiles against an enemy ship and only that ship can detect your lock, then to avoid giving yourself away the obvious thing becomes to launch the missiles at a waypoint instead of directly at the ship. You may have to retarget the missiles several times at different waypoints if the enemy fleet is changing course. Finally, you retarget the missiles again just before they arrive. You would have to do this for every ship firing missiles.Quote from: "welchbloke"I also would like to put a vote in for fire control detectable and providing tech data. Fire control is certainly detectable in th real world and I can't see any reason why it couldn't be read across to Aurora.
BTW, I would vote against having a lock-on be detectable by anything other than the target. Since fire control is purportedly tight-beam, the other ships wouldn't be getting hit by the beam (unless they're supposedly seeing backscatter). The other advantage of "target-only" detection is that it's one less O(N) detection check to do during the detection phase
If fire controls are generally detactable, then there is no disadvantage in targeting a ship directly because even targeting a waypoint will result in detection, which means there is no need for any micromanagement.
Steve
Post by: sloanjh on May 03, 2009, 06:30:58 PM
Quote from: "SteveAlt"
Quote from: "sloanjh"I agree that it would be more realistic that only the target would detect the fire control. Unfortunately, in game-terms it leads to a micromanagement nightmare. If you are launching missiles against an enemy ship and only that ship can detect your lock, then to avoid giving yourself away the obvious thing becomes to launch the missiles at a waypoint instead of directly at the ship. You may have to retarget the missiles several times at different waypoints if the enemy fleet is changing course. Finally, you retarget the missiles again just before they arrive. You would have to do this for every ship firing missiles.Quote from: "welchbloke"I also would like to put a vote in for fire control detectable and providing tech data. Fire control is certainly detectable in th real world and I can't see any reason why it couldn't be read across to Aurora.
BTW, I would vote against having a lock-on be detectable by anything other than the target. Since fire control is purportedly tight-beam, the other ships wouldn't be getting hit by the beam (unless they're supposedly seeing backscatter). The other advantage of "target-only" detection is that it's one less O(N) detection check to do during the detection phase
If fire controls are generally detactable, then there is no disadvantage in targeting a ship directly because even targeting a waypoint will result in detection, which means there is no need for any micromanagement.
Steve
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.
John
Post by: sloanjh on May 03, 2009, 07:24:39 PM
Quote from: "SteveAlt"
Its not making active sensor detection a non-hostile act that would make people more likely to play the "waypoint" trick, it's making fire control lock-on detectable only by the targetSee preceding post.
Quote
Agreed. My observation was that playing tag for years at a time leads to a lot of micromanagement (that would be handled by the commander on the scene, but the AI isn't up to it), which in turn is a drag on the quick progress of the game. So the argument is that the useful episodes of tag should be much shorter (weeks or months of game time, rather than years), so that "tag" runs on roughly (i.e. within an order of magnitude or so) of the time-scale of a battle, i.e. it's a game within the game (just like battles are). So the trick is "how do I make the micro-managed part of spying be on timescales of weeks or months while keeping the tech level advances at timescales of months or years" - that's what the 75% trick addresses.Quote2) My answer to the original question is "yes". Most of the fun in my current game is from playing tag with the precursors, trying to get tech info from them. I'm torn as to the rate of acquisition - when I was just passively listening to the active sensors, I was getting info pretty rapidly (i.e. a couple of weeks to get enough tech for the next level). Now that I'm letting them chase me around while I ping them, which I've been doing non-stop for a couple of game-years now, the tech info is flowing in MUCH more slowly - I haven't gotten 1 full level of information in any system. This might argue for making the acquisition rate a bit faster, since the only reason I'm able to keep them under active observation for years at a time is that Precursors aren't that smart (and I'm doing a lot of micromanagement - see below).Even if we switched to fire control instead of active sensors for tech scanning, you could still play tag with the precursors in much the same way.
Quote
Sorry - I didn't mean for my comments to be a slam on existing Precursor behavior - I think they both rock and am all in favor of your initial implementation. The intent was to give you info for the next round of AI improvement. My experience is that I've seen individual precursors turn off their actives, but since they don't move while the actives are off they're still pretty easy to avoid.QuoteA) They keep their active sensors going all the time, which makes them easy to spot, track, and avoid. A simple sprint/drift strategy, where they move to a new location, light up the actives for a few seconds, then move to another location would make Precursor systems MUCH less safe to play in.Precursors and NPRs will turn their sensors off sometimes. At the moment though, once they detect you on passives they will switch on actives. I agree there could be a little more intelligence in this area and perhaps they shouldn't switch on actives until within range of the thermal contact. However, for the initial version of the AI I though it would be better to engage actives in case anything else was closer that passive hadn't spotted. Once the current version is done, I will revisit the AI for the next version.
Quote
Quote5) I was frustrated that I couldn't get any information on sensor tech from Precursor listening posts. I tried active scanning them and, as far as I could tell, got nothing (they didn't show up as active contacts, even though I had them on thermal - hmmm - how does one target them for missile strikes?). When I invaded and captured them station with ground troops, they instantly popped down in tech to one of my standard tracking stations. Note that this is just an observation - I understand the coding difficulties of having different tech installations; I'm just saying it would be nice to be able to get tech information (e.g. factory, mining, wealth(?)...) from captured enemy bases which were of higher tech e.g. with a Xeno team. Maybe the thing to do is to place a ruins when an enemy population is captured, or put a "tech available" flag on populations that would be true both for ruins and for captured populations. If you went down this road it would probably actually have to be a list of "available tech" for the population, so one couldn't get Precursor or highly advanced tech from an NPR that was only slightly ahead of you.Although you can't get direct tech data by scanning a population, when you capture a population you have the chance of gaining data on that population's technology. Larger populations will yield a greater chance.
Oops - my bad. I've only captured Precursor outposts, and didn't have any artifacts to examine.
Quote
Quote6) When my spy ships came home to Sol, sometimes they dump to Earth, sometimes to Mars. This is awkward from a game perspective, and didn't make much sense. I'd much rather have the tech data go to every planet (at least in the system). This leads to the idea of a "load tech data" command for ships that would allow research points acquired on one world to be transported to other worlds. It probably wouldn't be used a lot, but every now and then I decide I'd really rather be working on an already-started project in another system.Those two requests are unfortunately contradictory. If the ship with the tech data unloaded to both Earth and Mars, you could then load the points on Earth on to a ship and moves them to Mars, doubling the original points total :-)
The real benefit, however, comes after a few TL. Lets say you've been diligently spying on the precursors, and you're up to strength 16 (caveat - I'm making these levels/costs up), which costs 32,000 points, that strength 24 costs 64,000 points, and that your best research planet can do 8000 points/year on sensors. As it stands today, you can spend a few weeks listening to precursors broadcast active sensors, pick up all 64,000 points, and advance a TL in the space of a few months (most of which is spent in travel time to the precursor system) - this is what happened in my current game. With the 75% idea, even if you had only spend a few days (or even hours) listening, it would still have taken a full year of your best research planet's time to gain strength 16, and will take two years to gain strength 24. This is why I'm proposing that acquisition be a lot faster (to cut down on micromanagement during games of tag) - it's not harmful to balance because once you've gained a couple of levels quickly, it becomes impractical to advance any further until you've upped your research base. The big investment would be in resources would be building the spy ships, and in game time would be doing the last 25% of research, rather than in the act of spying.QuoteQuoteMore ability to gain tech from populations (e.g. listening posts), either through scanning or capturing. Capturing a populated population :-)
John
Post by: Paul M on May 04, 2009, 07:15:22 AM
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.
Post by: waresky on May 04, 2009, 12:59:02 PM
Am loving Aurora for extreme hard "game" for "hardgamer".
when something become too easy ive a movement of noise..
Post by: Hawkeye on May 04, 2009, 02:16:09 PM
Post by: SteveAlt on May 05, 2009, 12:52:23 PM
Quote from: "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.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.
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.
Quote
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
Post by: Paul M on May 06, 2009, 02:15:55 AM
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.
Post by: SteveAlt on May 06, 2009, 12:15:51 PM
Quote from: "sloanjh"
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.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.
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.
Steve
Post by: SteveAlt on May 06, 2009, 01:45:06 PM
Quote from: "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.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.
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.
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
Post by: Brian Neumann on May 06, 2009, 01:54:21 PM
Brian
Post by: sloanjh on May 06, 2009, 02:06:13 PM
Quote from: "SteveAlt"
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
Post by: sloanjh on May 06, 2009, 02:18:16 PM
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
Post by: SteveAlt on May 06, 2009, 04:32:54 PM
Quote from: "sloanjh"
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.Quote from: "SteveAlt"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).
Quote
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 unrealisticPossibly, although as you mentioned earlier the target being unaware of the attack is no different than it is now.
Quote
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.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.
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.
Steve
Post by: SteveAlt on May 06, 2009, 04:38:13 PM
Quote from: "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.
Quote
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
Post by: sloanjh on May 06, 2009, 05:50:38 PM
Quote from: "SteveAlt"
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.Quote from: "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.
Quote
QuoteI 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
Post by: sloanjh on May 06, 2009, 08:29:02 PM
Quote from: "SteveAlt"
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.
Quote
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
Post by: Erik L on May 06, 2009, 09:25:16 PM
Quote from: "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....
...
John
Only in the fact I commited some updates to the board at the same time you clicked submit
Post by: sloanjh on May 07, 2009, 12:38:58 AM
Quote from: "Erik Luken"
Quote from: "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....
...
John
Only in the fact I commited some updates to the board at the same time you clicked submit :-)
John
Post by: Sotak246 on May 07, 2009, 06:29:50 PM
Mark
Post by: Erik L on May 07, 2009, 11:34:40 PM
Quote from: "sloanjh"
Quote from: "Erik Luken"Quote from: "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....
...
John
Only in the fact I commited some updates to the board at the same time you clicked submit :-)
John
Odd, the updates I did didn't take me more than 30 minutes at the outside.
Post by: sloanjh on May 08, 2009, 08:01:31 AM
Quote from: "Erik Luken"
Quote from: "sloanjh"Quote from: "Erik Luken"Only in the fact I commited some updates to the board at the same time you clicked submit :-)
John
Odd, the updates I did didn't take me more than 30 minutes at the outside.
It's possible that I tried a few times over the space of 1/2 hour, then went away and didn't come back for a few hours, hence the perception of it being down for a few hours.
John
Post by: SteveAlt on May 08, 2009, 09:10:10 AM
Quote from: "Sotak246"
Just my quick two cents..I like the like option 1, perferably using firecontrol sensors, not active. I do like your option 2 but the osmosis gives me pause. In some cases like your example it would be great, but in others it would conflict with some of the setups I have been using. In some cases I want the lesser power to stay where it is or advance on my schedule. Maybe a toggle on the loading screen such as the one for jumpgates at all jumppoints.If I do add osmosis at some point, I will make it an option
Steve
Post by: SteveAlt on May 08, 2009, 09:58:33 AM
Quote from: "sloanjh"
Now that I think of it, two thoughts on osmosis:My immediate reaction is that the jump from pre-TNT to post-TNT shouldn't be that easy. I can think of two game mechanics options to slow osmosis down a little. The first is a percentage chance each increment to gain any eligible technology by osmosis, rather than making it automatic, and that jumping to TNT should be a very small percentage. The second is that an Empire can only gain a one new tech through osmosis for a given period - say 3 months - because it takes time to absorb the tech. In this latter case, the 'time to next osmosis' for a pre-TNT could be set to maybe 2 years so they would only gain TNT after that time.
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?
Quote
2) Should trade between Empires cause osmosis of tech?I have been considering this myself. I think it would be possible, although a lot less likely than for pops on the same planet. Perhaps the military status would also have to be friendly for it to happen.
Steve
Post by: SteveAlt on May 08, 2009, 10:14:17 AM
Quote from: "sloanjh"
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.When I do the EW review, most likely for v4.2, I am probably going to introduce thermal fire-control so you can lock up a passive thermal contact and guide missiles into the attack. The disadvantage being that without active sensors, you won't actually know what you are firing at :).
Quote
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.I would prefer not to get involved in that level of complexity. If the contact jumped around a central point, a player could work out the central point with some effort. If the contact was off by a certain distance and direction that scaled with range to target, they could also work it out, although both would require micromanagement. As with real life, most search radars (active sensor) can locate a target fairly accurately but don't have the ability to simumltaneously illuminate several targets for missiles, although there are exceptions.
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.
Steve
Post by: Drusus on May 08, 2009, 12:11:07 PM
1. I keep finding the fact that I need to turn on active sensors to find out even “Who” is out there a little disturbing. EM and Thermal signatures should be different enough to at least get the racial profile.
2. I would agree that if active sensors can provide information it would have to be FC. A search radar simply does not generally have the resolution to really give you any information other than “object, X big”.
3. The idea of getting some passive targeting will be nice.
4. Knowing a FC system has locked on should be detectable by at least the Task Group. If an Owl Screech lights somebody up you normally get enough scatter/leakage to know it. Admittedly Aurora ships are further apart, but they systems should be that much more sensitive too.
I will admit that my service experience and historical/fiction readings have always made me a large proponent of operating under a strict EMCON guideline and picketing systems ala Weber’s “Bugs”. I can remember many times that if we did not have a bird up we were ID’g the opposing forces purely off of their emissions. Radar might have a contact but if you wanted to know what it was then you would rely on the EW to tell you it had a Surface X, Conical Scan Y, and Raster Z. Correspondingly that would get you down to 1 or 2 classes of ship and you could then use intel to pin down the exact ship. As a matter of fact many radar emission signatures vary enough ship to ship that you can literally tell “Hull X” from pure passives if you have the base intel.
The fact that Aurora makes me go active to get any decent data has made it so that I have considered a throwaway penetration ship so that I can make the detection and then blow the ship up (if needed) so that I can conceal true bearing to fleets or WPs. Unfortunately I have not had enough time to get deep in a game to possibly need it.
Post by: Drusus on May 08, 2009, 12:16:06 PM
Quote
SteveAlt wrote:
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.
I would prefer not to get involved in that level of complexity. If the contact jumped around a central point, a player could work out the central point with some effort. If the contact was off by a certain distance and direction that scaled with range to target, they could also work it out, although both would require micromanagement. As with real life, most search radars (active sensor) can locate a target fairly accurately but don't have the ability to simumltaneously illuminate several targets for missiles, although there are exceptions.
I can see firing at a waypoint being messy.
However the big exception that I see to that is something like the SPY-X systems. Where the missles recieve initial and mid-Course corrections from the search radar and the FC only lights up the target for terminal guidance when you need the absolute resolution.
That would probably be a bear to model though.
Post by: Steve Walmsley on May 08, 2009, 01:11:19 PM
Quote from: "Drusus"
I can see firing at a waypoint being messy.You can do this in v4.0. Use the fire control to target a waypoint and fire at that. Issue mid-course corrections if necessary by creating new waypoints and re-assigning the fire control. Finally, illuminate the target when the misiles are getting close.
However the big exception that I see to that is something like the SPY-X systems. Where the missles recieve initial and mid-Course corrections from the search radar and the FC only lights up the target for terminal guidance when you need the absolute resolution.
That would probably be a bear to model though.
Its not modelling this in the game that concerns me, as it is already done, but I didn't want this to become a standard way to do things because it involves a lot of micromanagement, which is something i want to avoid outside of specific situations.
Steve
Post by: Steve Walmsley on May 08, 2009, 03:44:16 PM
Quote from: "Drusus"
Since I am weighing in late on this I will just keep my comments to a summary rather than responding to the upthread posts:I know that in the real world you can learn a huge amount from passive sensors. In Aurora you can tell the race of a population from their emissions so I guess it wouldn't be too much of a leap to identify the specific race from their engine emissions, or their active sensor emissions. However, on the other hand I do like the uncertainty that this brings to the game and the fact that you never really know what that thermal/EM contact is unless you use active sensors. It also avoids a potential programming can of worms where players may want to simulate the engine or sensor emissions of other races. So in Aurora, much of what you would get from real world passive sensors is actually part of what you get from Aurora active sensors.
1. I keep finding the fact that I need to turn on active sensors to find out even “Who” is out there a little disturbing. EM and Thermal signatures should be different enough to at least get the racial profile.
Quote
2. I would agree that if active sensors can provide information it would have to be FC. A search radar simply does not generally have the resolution to really give you any information other than “object, X big”.I think there is general consensus that if tech scanning remains, it will be from fire controls rather than active sensors.
Quote
3. The idea of getting some passive targeting will be nice.I will add this at some point, although as I mentioned the identity of the target will remain unknown without actives.
Quote
4. Knowing a FC system has locked on should be detectable by at least the Task Group. If an Owl Screech lights somebody up you normally get enough scatter/leakage to know it. Admittedly Aurora ships are further apart, but they systems should be that much more sensitive too.I think for simplicity my preference is for fire control to be generally detectable, although I might make it a simple flag for active fire control on a unit, rather than showing the range.
Quote
I will admit that my service experience and historical/fiction readings have always made me a large proponent of operating under a strict EMCON guideline and picketing systems ala Weber’s “Bugs”. I can remember many times that if we did not have a bird up we were ID’g the opposing forces purely off of their emissions. Radar might have a contact but if you wanted to know what it was then you would rely on the EW to tell you it had a Surface X, Conical Scan Y, and Raster Z. Correspondingly that would get you down to 1 or 2 classes of ship and you could then use intel to pin down the exact ship. As a matter of fact many radar emission signatures vary enough ship to ship that you can literally tell “Hull X” from pure passives if you have the base intel.As I mentioned above, I accept that in reality passives can give you a lot more information that in Aurora. Its really a game design choice rather than a misapprehension on my part regarding passives vs actives.
The fact that Aurora makes me go active to get any decent data has made it so that I have considered a throwaway penetration ship so that I can make the detection and then blow the ship up (if needed) so that I can conceal true bearing to fleets or WPs. Unfortunately I have not had enough time to get deep in a game to possibly need it.
Steve
Post by: Doug Olchefske on May 08, 2009, 04:29:50 PM
Quote from: "SteveAlt"
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
I vote for option 2. Gaining tech from scans always seemed too easy to me. As for osmosis, you may just want to gift research points instead of granting tech outright.
Post by: rmcrowe on May 08, 2009, 04:52:44 PM
robert
Post by: Paul M on May 09, 2009, 04:22:08 AM
1. Fire control should be detected by the unit targeted if that unit has EM sensors, regardless of the range of the sensors you can't miss you're being painted. At the same time any other ship in the task group would be informed, "hey boys someone just hull mapped us and we have high resolution scanning, setting condition orange."
2. Given the ranges of missiles and the speed of ships, no missile could hit anything not actively painted for the whole missile flight time. Unless you have active (not passive as they would be useless to a missile) systems on the missile itself the missiles CEP would be huge just because frankly in a few seconds the ships move well in excess of a 1000 km. Active sensors on the missiles would allow for way points and last moment targeting (less for detection of where but of determination by the missile of which target to hit). I have missiles with flight times of 130 minutes against even a merchant moving at 700 km/s the sphere the ship could inhabit is huge.
3. No modern navy leaves ships un-engaged, infact no navy has ever done that. There are exceptions if your strike package is too small you prioritize but basicaly no one does the standard tactic in games of firing on one target till it pops and then switching. The reason is that the crews of ships not engaged are much more effective (they are in a far less stressful situation). You could add that the crew bonus of any unengaged ship goes up by +25% (as in add 25% to it not multiply by 1.25). By the way that is conservative.
4. Passive sensors in space don't yield anywhere near the detail they do on the surface. This is due to range and the fact that in the flight time of the signal the ship moves. So if you are a few million Kms from the target when you pick up its engines the ship could be up to a hundred thousand km away from that position. You are always looking at the past. This does not matter on earth since if the target is a micrometer or so away from where you think it is well its not an issue. Once you have him you start to build a plot but you are always seeing the past. This means for targeting purposes unless the ship never deviates from its exact course and speed you probably don't know exactly where it is. There are exceptions (objects in orbit) but for the most part knowing where something was is not as useful as knowing where it is. Plus without triangulation you would only really know the maximum distance it could be, distance to target requires at least a couple of measurements at different positions. But localization for targetting purposes is just about impossible.
For purposes of the game requiring active sensors on the missile (for active terminal guidance) to use way point targetting makes the most sense. Otherwise missile ambushes are just too easy. If your missile doesn't have active sensors then you have to illuminate the target with your fire control the whole way. I know you want to avoid the issues with target position from light speed sensor systems but I think you have to make a break from what is currently the use of an exploit of this. Basically the current way point tactic exploits the game mechanics, so I think you need to add in game mechanics to keep things balanced. Illuminating the target for the last 5 s or so would be pointless in reality, it would also be hard to do since you would not know exactly where your missiles where, nor exactly where the target was so timing it would be harsh.
I hope this makes sense.
Post by: sloanjh on May 09, 2009, 11:02:39 AM
Quote from: "Paul M"
2. Given the ranges of missiles and the speed of ships, no missile could hit anything not actively painted for the whole missile flight time. Unless you have active (not passive as they would be useless to a missile) systems on the missile itself the missiles CEP would be huge just because frankly in a few seconds the ships move well in excess of a 1000 km. Active sensors on the missiles would allow for way points and last moment targeting (less for detection of where but of determination by the missile of which target to hit). I have missiles with flight times of 130 minutes against even a merchant moving at 700 km/s the sphere the ship could inhabit is huge.
I think there's an aspect of Aurora-physics/technobabble you're not aware of - superluminal communication. So both active sensors and datalink are instantaneous. If you add this as a postulate, then mid-course corrections and datalinked guidance (without a sensor head on the missile) are both possible.
Note that this is a simplification assumption that Steve put into the game so that one wouldn't have to hurt one's brain with time-delayed contacts (in contrast to long range contacts in submarine warfare today, where such issues do arise).
John
Post by: Randy on May 12, 2009, 02:24:39 PM
Treat it sort of as a detectable "fire control" - but it can't control weapons - it can only acquire tech info. maybe call it a "scanner". This then opens up a tech branch to allow for optimization in terms of size, range, and efficiency.
And it lets you leave fire control as is (and ignore the question of detect/no detect of tracking), remove tech scanning from the other sensors, and isolate the tech code in a specific system...
It would also make it somewhat easier to control how effective it is
Randy