Nerf to Sensors

They completely changed they system on how it works.  I don't think you can change it back.

Given the capacity of ship hulls if your not putting other things on there..... reducing sensors less drastically was never going to achieve the desired result.

They would have been better off not even trying.... or simply putting a limit on the number of modules allowed on the ship.

Perhaps they will throw in a sensor booster module that requires Thalium and only 1 allowed per ship?

I have not looked at the current opt-in. However, based on the patch notes, it sounds as though sensor components now provide a 'scan power' which represents a number of tiles revealed. Is that correct? If so, it should be possible to add a 'scan power' multiplier to the sensor components which would produce at least a similar range gain per additional sensor component as was present under the old system, unless for whatever reason the developers decided not to support both flat and multiplicative 'scan power' bonuses.

This change is great for the game balance. 

ignore the haters. If they want the old system back they can mod it in.

I love that if you want to increase your sensor range, you need to actually research techs in the sensor tree now, rather than just stacking 10 low tech sensors on a cargo ship at turn 1.

Awesome change.

Hurray!!!    Hurray!!!  Hurray!!!

Diminishing Returns are here!!!

I've always wanted this change.  I've argued for it since Beta.  It was Impossible to mod into the game and had to come from Stardock's end.

Absolutely thrilled here.  It took a year, but was worth the wait.

Great job Stardock!

While it was not possible to mod in a constant area per component or per capacity spent model, it was possible to get something similar simply by adding a per-component capacity scaling factor to the sensor components, which results in both the number of tiles revealed by a ship with and the capacity required for N sensor components being quadratic in N.

Beyond that, I fail to see why anyone should want a constant area per component system. Area is not a useful metric of sensor coverage, especially when you consider that the game rounds the sensor range to an integer and so ships whose sensors reveal different nominal areas can have the same effective sensor range. Area revealed does not readily tell the player the minimum warning time they'll have of the approach of a vessel of a given speed (which is most directly sensor range / target speed, with some complications because the game uses a discrete-time sequential-action model), nor does it readily tell the player the maximum exploration rate of the ship (which is most directly one plus twice the sensor range tiles per action). Constant area per component also fails to clearly communicate to the player how much of a benefit you get out of adding another component, i.e. it wastes the player's time, because the player either has to place the component(s) to experimentally determine the benefit gained or the player has to compute the necessary number of components to add to get to the next range breakpoint; how much of a change in sensor range do you think you'd get by adding a component which reveals 12 tiles to a vessel which already has a sensor range of 10?

Yes, great job trading a transparent system which had correctable flaws for an opaque system which is little different in effect from what could have been implemented in the transparent system. After all, why wouldn't you want to waste time adding half a dozen sensor components when you could instead have added only a single component that has the same cost has those half a dozen components and achieved the same effect? Why wouldn't you want to have to experimentally or analytically determine the actual effect of adding one or more sensor components when the game could instead just tell you the actual benefit of adding the component directly? +1 sensor component = +r sensor range, where r is an integer determined by the type of sensor component is just too simple, isn't it? No, we'd all much prefer that we get +1 sensor component = +t nominal tiles revealed, which translates to an increase in effective sensor range of round(A^-1(t + T)) - round(A^-1(T)), and since that's still too clear let's further obfuscate things by making it so that each sensor component gives +p sensor power instead of +t tiles revealed so that the player also needs to know what t(p) is in order to analytically determine what the actual benefit of adding the next sensor component is, or so that a player designing a sensor ship needs to waste their time experimentally determining the number of sensor components and thus capacity required for a given sensor range and then do it again for another sensor range to compare trade-offs. But then, it's not like anyone would ever want to design a ship to maximize exploration rate (which typically is maximized with a balance of sensor and drive components rather than full-sensors) rather than total area observed; that would just be silly.

It was entirely possible to add a per-component scaling factor to the sensor component capacities and manufacturing costs. It is entirely possible to make such a system work in a manner similar to the model introduced in the current opt-in, except that instead of having to add multiple components to increase sensor range you'd only add a single component, and instead of reporting the benefit of a sensor component in terms of some obscure derived-attribute of area observed, which isn't actually linearly related to the actual area observed because of rounding, you'd have the benefit of a sensor component reported in the actual range gained by adding that sensor component.

This has been a flaming hot topic since beta. I hate the way it is now. However I simply went into the game xml under shipcomponentdefs and modded sensor power from .25 to 30 and now the stacked sensors work liike the did initiall on my initial survey ships. i did not bother with the other tiers. 

I agree with Joeball. The system we had was far better but whatever. I'll adapt and just mod it back. 

@joeball123:  Excellent post.  As with most changes to Gal Civ 3, this may have been overdone.

An argument for sensor stacking a year ago offered the stacked antenna arrays NASA and observatories used as an example.  I retorted by explaining how the inverse square relationship between distance and the intensity of light waves made their argument moot.  A 120 antenna array does not give you 120 times the resolution.

The suggested remedy was somewhat less stringent than an inverse square relationship.

If what Stardock has implemented does not work out well, they will surely adjust it until it does.  May take another year, but they will.

I had a conversation with several GCIII and II friends. One thing we all agree on is that sensors on a starbases should be FAR more powerful than those on a mobile ship. I would love to stack sensors on a starbase and string a line of them along a frontier. 

Also I do think we should boost starbase hitpoints up by 1000. I am serious. I think a fully upgraded (all available modules) on a military starbase should have 2000 hit points. This would give it just enough time to launch maybe one or two volleys on a dreadnaught before being destroyed. 

I can stack 1000 missile attack and 800 doom ray attack on a huge end game hull along with 200 def each and still have 750 hit points. A fully upgraded mil starbase which took 20-40 constructors to build has 200-300 hit points maybe 60 defs and maybe 60 atta on all fronts. For a massive stationary place <WHICH IS FORTIFIED> it is simply no challenge to a single end game huge hull. 

Boost the hit points to 2 or even 3k and now I have  reason to string mil bases around the galaxy  which I would do! 

I'm loving the sensor change!

The straightforward linear increase with additional sensors was ridiculous. Now you have to actually build sensor ships into fleets, and put thought into positioning them around your borders. Space is big after all.

I'll have to remember this so I can mod it for my own game.

I doubt that it helps the situation any, but I have to observe that the pattern of reaction is remarkably similar to that for the introduction of the coercion system as a solution to the planetary production wheel.  

The old system was highly exploitable.  I know because I exploited it mercilessly.  I will find other things to exploit instead.  The new system looks to be somewhat challenging to work with.  I hope I am not the only one who finds that to be the best feature of the change.

While I don't hate the new system, I will say, I find it less transparent, and that is an issue.

I also find it annoying. I think sensor systems should be "one per ship" and generally just better. Note, it should be "one sensor module per ship" regardless of upgrade level. And the high levels being quite good.

Starbases should then have intensely better sensors.... what with their nigh infinite size/space issues.

I agree gauntlet - while I love the spirit of the changes, they are not very transparent to the player. Would love to see some tweaks that keep the objecrive but improve transparency.

It would be good to see the introduction of a sensor starbase, or at the very least a beefing up of military starbase sensor modules

A system where linier sensor range equaled the square root of sensor power rounded up might have been easier to grasp than counting in sixes like a Sumerian.

I actually had this in my GSM mod. I just took it out, at request of some users lol.

It result is similar to inverse of range, but we'll work to make it more transparent. 

Not griping.  However novel your solution it works.

My first impression upon hearing about this nerf was being unhappy about it. Now, after having some 300+ odd turns into my current game with the latest beta version, I'm thinking it's not as bad as I was initially worrying about. What sucked was having to redo my ships but it actually got me off my butt to do a little house cleaning at the same time so it wasn't all bad. So far I'm really liking this version with the shipyard changes, minor diplo tweaks, and various other balancing and tweaking that has been done. Slowly but surely we're getting there and what a fun ride it has been!

So the pattern of the change.

We begin with an easily exploitable system that requires balancing - in both cases, something is excessive, so sensor ranges stack too high and planetary output is 3 or 4 times higher than the pricing model.

Then, rather than making a small and obvious change that corrects the balance (diminishing returns on sensors or decreasing output on buildings), SD dispose of the existing system and introduce a new, over-engineered solution to achieve the same thing, but which is ultimately imbalanced in new, exciting ways, and also much harder to keep track of.

In both cases, we had a system where the fundamentals were fine but the balance sucked, and SD's solution has been to change the fundamentals and ignore the balance. It's always good to see tangible evidence of SD reacting to player feedback, and this is definitely such a case, but I do sometimes wonder why the devs refuse to take the path of least resistance. The engine change was this done right - a small addition to the engine output calculation that limited the overpowered returns. This is it done wrong - ripping out the old calculation and sticking in a new, much less intuitive calculation.

Stacked sensors were ridiculously OP. I've no sympathy for requests for a return for mega-range sensor ships that could reveal a whole Insane map in one turn, and I agree with Gauntlet that a Starbase-based long-range sensor network with ships having theater-or-less sensor capability is a preferable option to sensor ships... but a simple 10% diminishing return on ship sensors was easy to add into the old system, just as reducing output was easily doable without coercion and Wheelgate.

These big ground-up redesigns of mechanics where fine-tuning is required are frankly just bizarre; they tend to piss of sections of the playerbase, break other connected systems (as this appears to do to sensor bonuses, at least according to another thread) and they either don't deal with the original problem or introduce new issues that leave it just as imbalanced. 

^^^ This would be the optimum case. We have the ability to make 'one per ship' modules' which is what we can and should do here. I would be happy with a good/moderate sensor module that ratchets up along the tech line as one per ship and allow star bases to have <greater range> than a ship. This again would make me want to build said starbases to use as an early warning system along the border. 

The sensors should SCALE to map size. If you are in 'medium' a sensor sees 4 or 5 hexes out while the same sensor on an insane map should perhaps see 10 or 15 hexes out. This would all be test to find the optimum scale 'per map size'. 

Many things in game really should be scaled to map size but that is another thread: {Engines, Life Support, Sensors, trade route value} all should scale up or down as calculated at start of game based on map size and # of planets/hab planets....

FWIW, one can mod in the old system of how Sensors worked as "SensorRange" does still work as an Effect Type. I tested this by putting in the old ShipComponentDefs.xml into my mod directory and loaded up an old tech tree that still had techs that modified by SensorRange instead of SensorPower.  Game loads and runs as it used to.

So a replace mod should work where one puts back in Sensor Range everywhere and takes out Sensor Power (making sure to take out the new values for Sensor Power and put in the old values for Sensor Range)

*PAUSE*

NOT IT!!!

*PAUSE*

Now that I've gotten that out of the way, it wouldn't be that hard.  Make a back up of the data and DLC folders before updating to 1.7 and then check the files that have SensorPower and switch them back to SensorRange.  Shouldn't be that many of them. ;p

I don't understand why people want things to scale with map size. Doesn't that just remove the point in having a bigger map? If things take too long or the map seems to big for what you have, then surely you should just play on a smaller map, as clearly you aren't a fan of the big ones with the added challenges?

It's been explained more than once.  But to try once again in a slightly different way, there's a sweet spot to scaling and sizing.  One can want to explore and play on a large large map while not having it be excruciatingly slow. Different experience doesn't have to mean an excruciating one.  One can want to have lots of things to do on a very large map while not wanting to inch like a turtle.

To put it yet another way: pace pace pace.  It's not the size of the map that might matter, but the pace of play.  Even on an Insane Map, pace of play can be set so it will take a looooooong time to complete yet still feel like one is accomplishing a lot every few turns.

Really, I think it's the pace of play argument that isn't getting enough look at here.  The folks who want fast ships and large sensor ranges want a faster pace of play for the game AND a larger map to play on. I fail to see why this is a hard concept to grasp.

 EDIT::: 

And before the arguement about "large maps should take long" gets trotted out... I AGREE.  But I said "pace" not "length" for a reason.  A fast paced game can still be a very long one on an Insane map depending on the settings.  Pace and Length are two separate, if often related, concepts.  I want to play a long game, but I don't necessarily want to play a slow one.  

On smaller maps, games are going to be short(er), even if they are slow paced.  Thus those who are arguing here don't want to play on smaller maps as they do want longer games with the more options that the larger maps give.  They just don't want a slow paced long game.