What does the Narrow Band tech do??
I currently have a game (my AAR) with all research 5k, with active sensor tech 2 levels higher, and I need a size 6 Sensor to find enemy missiles at roughly 300k, while my Anti-Missiles have a million range.
Suffice to say, this makes it impossible for me to Anti-Missile Sensors on my Anti-Missile Escorts, so I need a dedicated sensor ship for it.
Btw, I've never ever had an NPR, precursors, or anythign else really fire missiles or >size 6 at me.
I now need a size 50 Fleet Scout Sensor for good sensor coverage instead of the size 30, so "slightly worse" is a drastic understatement, while I still need a fightersensor of nearly the same size to have any chance to detect them at a good distance; Dectection kinda just became harder across the board. R100 is just a retarded resolution, who builds ships of 5000 tons? I've yet to see any.
But as said, I like the changes. More challenging to get good recon now. On the other hand, Cloaking is likely less efficient, but I've yet to test that.
So, does that mean that Aurora will eventually be rewritten? Or will it just die in favor of something new?The most likely outcome is that it will continue to be developed in VB6 and I will eventually create a different type of game in C#.
As for the resolutions, what is it with R100?Anti-missile sensors are actually slightly better with the changes, especially against missiles larger than size 6. Longer range sensors above resolution 100 are slightly worse but that is working as intended.
I mean, I hardly EVER see a ship of that size, every reasonable precursor is at least 120, and I find resolutions below 150 for sensors to be a waste of range.
All the recent change did for me is that my sensor Ships now need an additional 10 HS of sensor, because the long range sensor is way less long ranged, and missiles now require me to have a 10 HS R1 sensor to detect at reasonable ranges, where before a 4 HS R0 would do.
Which obviously means I can't pack Anti-Missile Sensors on my Anti-Missile Escorts anymore.
I use SQL 2000, 2005 and recently 2008 for work, 2005 is definitely better than 2000 but I haven't had a chance to do anything new in 2008 yet.
In saying that, you'd need a licence to package SQL Server methinks?
Yes, you are probably right. Many years ago I was a commercial C++ programmer (in Windows 3.1 !!) so C# is probably going back to my roots. I'll download the Express version and take a look.
Steve
That's fine with me - rest is good :-) Like I said, sorry I didn't realize all this before you coded it up - I'm mainly trying to plant the seed right now....
On VB2010, Joel On Software (a collection of blogs from a very insightful guy) characterizes the various .NET languages as being different syntactic sugar (my name) on top of the same underlying language. This is accurate - what they've done is added language extensions to the various languages to essentially let you write C# (which is a truly excellent language) in those languages. If you go to a .NET language, you might be better off simply biting the bullet and learning C# - after all, didn't SA start out as your toy to learn VB? :-)
I think this is something I going to have to study when I am less tired and then get back to you. I have been playing with Visual Basic 2010 today and it has been both enlightening and frustrating. There is definitely no way to upgrade Aurora without effectively rewriting it. They are barely the same language. Its also surprising that several useful features in VB6 are not even in VB2010. On the other hand, if I start a new project I will write it in VB2010 because it is far more OO-friendly and obviously will be supported for a lot longer. I have also been looking at SQL Server 2008 but I think it is over-complicated for what I need.
Steve
Yep - you understood the figures correctly :-) I hadn't realized that was your goal - what you describe is (almost) what the current formula does, as far as I can tell. The "almost" is because the penalty, at fixed sensor size, for detecting small objects as the resolution increases has actually gotten worse - it used to be a linear penalty; now it's a sqrt worse (i.e. 3/2 exponent rather than 1 exponent).
If you wanted to go back to the original penalty (max range vs. resolution, for fixed target and sensor size, goes like 1/Resolution), then I think the thing to do is to keep the sqrt(Resolution) in the max range, but change the drop-off to a 3/2 power as well. This formula would be:Code: [Select]Range = sqrt(Resolution)*Strength*EM*10Kkm*min(1, (Size/Resolution)^(3/2)).This flattens the drop-off curve, but in such a way as to compensate for the overall reduced range for large targets. With this formula, doubling the resolution cuts the range for small targets by a factor of 2, and increases the range for large targets by a factor of sqrt(2) - the current formula cuts the range for small targets by 2*sqrt(2) and increases the range for large targets by sqrt(2) (the same). The original formula cut the small-target range by 2 and increased the large target range by 2 as well.
I would prefer the latest formula proposal, but at the end of the day it's your game (and work) so your decision :-)
. I have been playing with Visual Basic 2010 today and it has been both enlightening and frustrating. There is definitely no way to upgrade Aurora without effectively rewriting it. They are barely the same language. Its also surprising that several useful features in VB6 are not even in VB2010. On the other hand, if I start a new project I will write it in VB2010 because it is far more OO-friendly and obviously will be supported for a lot longer. I have also been looking at SQL Server 2008 but I think it is over-complicated for what I need.My intention for the change was to increase the overall range of low resolution sensors and decrease the max range of very high resolution sensors (with resolution 100 remaining the same) while retaining the drop off for detecting objects smaller than your resolution. I wasn't trying to decrease the penalty for detecting small objects for higher resolution sensors, which I think is what your proposal would do if I understand the figures (which isn't necessarily a givenYep - you understood the figures correctly :-) I hadn't realized that was your goal - what you describe is (almost) what the current formula does, as far as I can tell. The "almost" is because the penalty, at fixed sensor size, for detecting small objects as the resolution increases has actually gotten worse - it used to be a linear penalty; now it's a sqrt worse (i.e. 3/2 exponent rather than 1 exponent).. I was trying to allow the creation of sensors that could detect smaller objects at a greater range than the same size (and tech) sensor in the previous version while still requiring ship designers to think carefully about their sensor resolution. I think I have achieved that objective, or at least it feels like it within my own campaign.
Steve
Range = sqrt(Resolution)*Strength*EM*10Kkm*min(1, (Size/Resolution)^(3/2)).
This flattens the drop-off curve, but in such a way as to compensate for the overall reduced range for large targets. With this formula, doubling the resolution cuts the range for small targets by a factor of 2, and increases the range for large targets by a factor of sqrt(2) - the current formula cuts the range for small targets by 2*sqrt(2) and increases the range for large targets by sqrt(2) (the same). The original formula cut the small-target range by 2 and increased the large target range by 2 as well.. I was trying to allow the creation of sensors that could detect smaller objects at a greater range than the same size (and tech) sensor in the previous version while still requiring ship designers to think carefully about their sensor resolution. I think I have achieved that objective, or at least it feels like it within my own campaign. 