GalCiv3 Forums
2 Navigational Sensors provide a
Range: 4
Mass: 20
Cost: 18
Maint: 0
1 Sensor Array provides:
Range: 4
Mass: 20
Cost: 65
Maintenance: .3
As it stands, the sensor array is 100% useless. Perhaps this was intended with some of decaying return effect that has been discussed, but without that, there is 0 benefit.
I agree. I also noted the same issue with the life support upgrades:
https://forums.galciv3.com/466770/page/1/
Which makes auto designed ships even worse, since their manufacturing costs spiral out of control without any particular benefit.
So sensors are technically balanced, but only for AI and players that don't design their own ships. Informed players can still skirt the rules. 
In my opinion there are two reasonable solutions to end this (unfortunately both require code changes and not just an XML change):
1) Diminishing returns +(Sensor radius) bonuses are now +(Sensor rating).
Equation: (sensor radius) = b + c * (sensor rating) ^ p
Sample constants: b = 1, c = 1, p = 0.5
2) Module limits A ship can now equip a maximum of n sensor-type modules. (n=2 would be reasonable)
I wish they would hire a mathematician or statistician. That would eliminate so much of the guesswork on balancing things like sensors.
I know programmers deal with math, but a true mathemarician would easily avoid these arbitrary "corrections" and simply be able to show them how to do this instead of just guessing and seeing what works.
Maybe. But it seems like they just didn't think to see how it stacks up against other sensors.
Hence why it's on an opt-in patch, and not been put straight into a live one... Good catch guys.
This is what you call a brain fart... 
Just use the sensors as they were and add a small negative percentage to each one and be done with it. Now you can't stack them up to infinity and still get a decent amount of range without being OP in the process.
Well, to be fair, i don't know what all those hype around sensors was about. Sure, it was an overkill against normal AI or lower (but to be fair yet again, that AI is seriously easy anyway). AI about normal see all map anyway - the fact he doesn't always take all planets means nothing, it's all about weights, scripts and priorities. So AI see all galaxy, higher AI, even ignore FoW, i dunno why we can't do the same, especially if we need adequate techs, a lot of manufacturing to do so, and it's limited anyway on big maps. Sensors ships, radars and such is normal. IMO, we must know about type of each star in galaxy from first turn, it's not hard even with today technology.
On the other way, nerfing support systems is one of the ways to hinder AI colonization Jihad.
No... the AI don't see all the map and certainly follow fog of war rules. The developers have refuted that several times.
The AI will get some bonuses by seeing some distance on some higher difficulties but they never loose FOW as far as I know. The developers have explained that the AI will randomly be able to see into FOW to some extent at certain points... but this is only to reflect the benefit that players have of guessing where an opponent moved to when moving into the FOW, that is otherwise a rather unfair advantage to a human opponent.
Not knowing the stars is simply a game mechanic choice which has nothing to do with reality. In reality this information and most likely the number and size of planets as well should be shown. We are already starting to map the number of planets that orbits stars.
So you never saw pirates follow your ships like a hound?
It really contradict with the fact AI sends constructors half a galaxy away for a cluster of resources. It mostly stops to do so now, but it's not because it don't see them anymore, they just lowered priorities of such actions. And "randomly" is very comfortable term. 99 from 100 is "random" too, because you know it's random and totally could happens. And AI doesn't need to know everything, just where good planets are and there you main fleet is... After they colonize good planets , they could get knowledge about where "medium" planets are... Randomly, you know...
Not knowing the stars is simply a game mechanic choice which has nothing to do with reality. In reality this information and most likely the number and size of planets as well should be shown. We are already starting to map the number of planets that orbits stars.I just like how you can guess the possibility of gaining a decent planed based on Star type, like in MoO2.
The AI gets no fog of war for already revealed space at gifted and a fully revealed galaxy at genious.
Source: https://forums.galciv3.com/466398 reply #2
Well, judging from a Dev Post in that thread difficulty spreadsheet is legit. The only things is that it doesn't hint about how AI is "blessed" with random knowledge of yet unexplored locations.
And Why, just why they add 20% range bonus to AI on gifted? It's like a lot! AI is already expanding like crazy, why give him even more bonuses for it. That's why there is so much difference between normal and gifted...
I think there's a pretty simple fix to the sensor ship issue: make sensors increase vision area instead of vision radius.
They probably wouldn't even need to hire one. Fans just LOVE telling developers how the things "should" be done.
The rest is a matter of putting a question before the public and applying a bit of common sense to select to the most reasonable and well founded answer.
Beats me why no one does that, but hey, I'm not a developer I'm not supposed to know all the factors and all the reasons.
In what good way could that be considered simple?
The game doesn't track movement directions, nor has it any other mechanics in place that would allow it to reasonably handle variable "shapes" of vision. Not to mention the inconvenience that would mean for players...
A circle (or rather a hex) is all it (and we) can comfortably handle, and that is defined by none other than radius.
No, it makes sense and can remain a hex. r = sqrt(A/pi). Then round up, that's good enough. Might need to tweak sensor upgrade scales because it is appropriate gameplay-wise to have a large sensor radius in the mid-late game.
I would say "confirmation bias" mostly at work here. Yes they will follow you to some extent and it depends on how close you are to them... or rather how far into the FOW you move. As I said, the AI will to some extent know where you are when you move out of their FOW, this is to compensate for a humans ability to do the same by taking an educated guess where the opponent went.
That is why you feel they "hound" you... you as a human could be the exact same thing.
No, it makes sense and can remain a hex. r = sqrt(A/pi). Then round up, that's good enough. Might need to tweak sensor upgrade scales because it is appropriate gameplay-wise to have a large sensor radius in the mid-late game.
Yes... this is a simple way to handle it. Unfortunately most people would not fully understand it... math is not as universally understood in the world as we like to believe...
The good news is that they don't have to, they just need to understand "more sensors => further sight".
I bet over half the playerbase doesn't understand how exactly Duritanium refineries impact your manufacturing, but they know it helps, and they're having fun anyway.
Well, for starters, your formula doesn't work on the hex grid, at least not under the rules we have. The area revealed by a sensor of range R is A = 3R^2 + 3R (+1 if you include the tile upon which the sensor sits), and so (ignoring the tile in which the sensor sits) you really ought to have R = -0.5 + sqrt(9 + 12A)/6 for the sensor range.
Beyond that, without breaking out a calculator, tell me how much range you'll get with a sensor area of 10, 100, 500, 1000, 2000, or any other arbitrary number. You don't know, do you? That is a major reason why you should not provide sensor effectiveness in terms of area revealed. Especially since sensors have two primary roles - early warning and surveillance - and only one of those cares at all about area revealed. The amount of warning time you get is a bit less than linear with sensor range (since we're dealing with discrete time rather than continuous time, there's a floor(X) function involved; any amount of warning less than a full turn, or which doesn't bring the warning time to the next higher integer number of turns, doesn't really do anything for you), and surveillance targets are at best roughly linear with area. Exploration rate, meanwhile, is linear with sensor range under the assumption of constant speed (and can in fact be reduced by increasing sensor range), except potentially on the first turn you rushed a sensor ship out (and therefore probably had a lot of unexplored tiles close enough to the point where the sensor ship emerged to suddenly gain a revealed-area-dependent amount of information). Why exactly is area a good way of providing the player with information on the quality of their sensors?
Problem is, if sensor components reveal a set amount of area per sensor, more sensors does not necessarily imply greater sensor range. There is no constant area such that adding another sensor component guarantees that the sensor range will actually increase since we're dealing with discrete ranges. There is, in fact, a great deal of potential dead space, where adding several sensor components will in fact not accomplish anything at all.
Moreover, tiles revealed is a very poor metric of the quality of the sensors. What do you care most about with sensors? How much time you have to respond to an oncoming hostile target? That amount of time is dependent upon sensor range (specifically, advanced warning time is greater than or equal to max(0, floor((R - M + 1)/M), where R is the effective sensor range at a specific point and M is the number of moves per turn the hostile target can make). Where does area come into this? Nowhere directly. Exploration? Well, the turn your ship is created you could perhaps reveal up to 3R^2 + 3R + (2R + 1)*M tiles, but after that it's no more than (2R + 1)*M tiles per turn, where M is the number of moves per turn of the exploration vessel. Where does the area revealed by the sensors come into play here? Once again, nowhere directly, except possibly on the turn your ship is created. Surveillance? Now here's something that is, to a degree, dependent upon area; the maximum number of targets which can be observed should be roughly linear with area on a map with a more or less uniform distribution of surveillance targets. On the other hand, the safety of the observer is dependent upon its ability to observe from further away than the observed can strike, and its secrecy is dependent upon the ability of the observer to watch from beyond where the observed can see. Beyond that, just how much is area actually worth for surveillance? Of those several hundred to several thousand tiles my ship can observe, how many do I actually care about?
So, of early warning, exploration, and surveillance, the three primary functions of a sensor ship, we have two which predominantly range-dependent and one which is somewhere between range-dependent and area-dependent. Why, exactly, is area a good metric for indicating how much I'll get out of a sensor component?
I regard your proposed solution as being worse than the problem which it is supposed to remedy. -N*X% sensor range with N sensors, without the penalty even ignoring the first component? Reduced mass efficiency, maybe, but not reduced sensor range per sensor. Yes, for certain types of detectors, you can make a realism-based argument for it; for others you cannot, however, and it's not like Galactic Civilizations sensors behave like anything currently in existence anyways.
Besides which, you already cannot stack sensors up to infinity. You're being excessively hyperbolic, don't you think?
Well, for starters, your formula doesn't work on the hex grid, at least not under the rules we have. The area revealed by a sensor of range R is A = 3R^2 + 3R (+1 if you include the tile upon which the sensor sits), and so (ignoring the tile in which the sensor sits) you really ought to have R = -0.5 + sqrt(9 + 12A)/6 for the sensor range.
Beyond that, without breaking out a calculator, tell me how much range you'll get with a sensor area of 10, 100, 500, 1000, 2000, or any other arbitrary number. You don't know, do you? That is a major reason why you should not provide sensor effectiveness in terms of area revealed. Especially since sensors have two primary roles - early warning and surveillance - and only one of those cares at all about area revealed. The amount of warning time you get is a bit less than linear with sensor range (since we're dealing with discrete time rather than continuous time, there's a floor(X) function involved; any amount of warning less than a full turn, or which doesn't bring the warning time to the next higher integer number of turns, doesn't really do anything for you), and surveillance targets are at best roughly linear with area. Exploration rate, meanwhile, is linear with sensor range under the assumption of constant speed (and can in fact be reduced by increasing sensor range), except potentially on the first turn you rushed a sensor ship out (and therefore probably had a lot of unexplored tiles close enough to the point where the sensor ship emerged to suddenly gain a revealed-area-dependent amount of information). Why exactly is area a good way of providing the player with information on the quality of their sensors?
I sense a little misdirected hostility here. I have not, in this post or any other post, given an opinion on the merits of linear or diminishing returns on sensor range. I'll leave that up to the developers who have the difficult task of balancing this game.
Without breaking out the calculator, no I could not tell how much range you'll get given a specific sensor area. But I never suggested you needed to tell the user what the area is, I just think it is a logical way of implementing diminishing returns, something the developers have been considering. You could still show the user the range, you just need to calculate it, just as you would with any diminishing returns implementation.
Speaking of calculating it, a circle DOES work. It's not perfect hex math, but it is just as good as any other arbitrary formula for implementing diminishing returns, short of hex math. Furthermore, if you really want hex math, I'm not opposed to that. The primary point is that area is an effective way of implementing diminishing returns, and circle math is a simple, close approximation:
A=10, r=ceil(sqrt(A/pi)) = 2, with your hex formula, hexr=1.39, round up to 2
A=100, r=7, hexr=5.29, round up to 6
A=500, r=13, hexr=12.42, round up to 13
A=1000, r=18, hexr=17.76, round up to 18
A=2000, r=25, hexr=25.3, round up to 26
BAM, Mr. Smarty Pants!
Using a ceiling function, the circular approximation of the radius is wrong ~26.5% of the time for numbers of tiles ranging from 1 to 720 (which should correspond to sensor ranges of 1 to 15).
For a number of tiles which should correspond to a sensor range of R, the circular approximation is wrong for
Note that this does not consistently decrease; the circular approximation is wrong for ~36% of the numbers of tiles which should give a sensor range of 38, for example.
This is a nontrivial error rate.
I did not express an opinion on the merits of linear or diminishing returns, either. I said that giving a sensor component's bonus in terms of area revealed is unclear and fails to provide useful information to the player.
It's not just the sensor array. It looks like all of them are now scaled to the same range-per-mass, so navigational sensors will provide the same benefit as any of the others without imposing the increased construction and maintenance costs. The "Immune to Nebulas" trait of the subspace sensor does potentially make it worthwhile to add one of those if you research that far down the sensor line, but even then, only one. You might also come up against a situation where you have enough space left to add one interstellar sensor but not two navigational sensors, although that's probably corner-case for everything other than a sensor buoy.
Since this setup makes no sense in itself, I can only assume that it's a precursor to some other change to the way sensor range is calculated, whether it's some form of diminishing returns, or best-one-only, or whatever else.
Using a ceiling function, the circular approximation of the radius is wrong ~26.5% of the time for numbers of tiles ranging from 1 to 720 (which should correspond to sensor ranges of 1 to 15).
For a number of tiles which should correspond to a sensor range of R, the circular approximation is wrong for
...
Note that this does not consistently decrease; the circular approximation is wrong for ~36% of the numbers of tiles which should give a sensor range of 38, for example.
This is a nontrivial error rate.
I did not express an opinion on the merits of linear or diminishing returns, either. I said that giving a sensor component's bonus in terms of area revealed is unclear and fails to provide useful information to the player.
You're not getting away with this one. I may not be able to spout out complex functions, but I am pretty decent at spotting misuse of statistics. First, you have to use ceil, floor, or round somewhere for any and all functions, including yours, becease, as you said yourself, we're talking about discreet units. So don't blame the ceil function, it was chosen to give a little extra range to players for gameplay reasons.
Second, the range using the circle formula is at worst off by one, at least in the numbers I calculated. So while it is indeed wrong, it is STILL a close enough approximation for gameplay reasons.
Third, missing tile count is irrelevant. It is effectively a measure of area and you said it yourself in the second paragraph of reply #20 (paraphrased) that area is not a good measure of effectiveness.
I'm not stuck on circle math, nor do I consider it superior in any way. But both numerically and logically it's really not as bad as you are trying to convince others. I agree with you that area does not give players much useful info. But again I never said players need to know about area, I'm just saying area is a reasonable method for implementing diminishing returns.
Should also be noticed that they have already made changes to the Sensor Range and mass in 1.03, so my original concerns have been addressed.
So far I am liking it. The initial sensor ship I could make is "nice", but not hokey. I've been debating on certain maps whether to build it right off the bat, which is what I was hoping to see.
Welcome Guest! Please take the time to register with us.