Post reply

Warning - while you were reading 67 new replies have been posted. You may wish to review your post.

Note: this post will not display until it's been approved by a moderator.

Name:
Email:
Subject:
Message icon:

shortcuts: hit alt+s to submit/post or alt+p to preview

Please read the rules before you post!


Topic Summary

Posted by: Kyle
« on: Yesterday at 07:13:57 PM »

- Hid the research projects for Missile tracking time bonus.  As in Aurora 7.1, this bonus doesn't do anything, so there's no point in it being researchable.  May revisit later, but for now I'm moving on to save time.

Didn't you mention earlier that this "bug" was fixed? If so the research should have intended effects?

I assume you're referring to this?

Progress update 2020-02-11
...
As previously reported in this thread, tracking penalties don't seem to always apply when beams shoot missiles in A4X.  I've made sure to include the tracking penalty, and I route every single situation where a beam weapon fires through a single routine so calculations are guaranteed to be identical no matter the scenario. 
I actually misread the thread I linked to.  The bug I worked on was one where tracking penalty was not being applied in all situations, which I fixed by making sure every beam fired is routed though a single routine.  That is what I was referring to as having fixed.  I have not done any work on the Missile tracking time bonus.  I will eventually come back to it and most likely put it on a tweaks menu along with a few other things, that can be enabled/disabled by the SM.
Posted by: procdrone
« on: Yesterday at 05:49:18 PM »

- Hid the research projects for Missile tracking time bonus.  As in Aurora 7.1, this bonus doesn't do anything, so there's no point in it being researchable.  May revisit later, but for now I'm moving on to save time.

Didn't you mention earlier that this "bug" was fixed? If so the research should have intended effects?
Posted by: Kyle
« on: Yesterday at 10:18:03 AM »

Progress update 2020-02-18:

Version 88 is up.  Some things included are:

- CIWS
- ECM on ships
- ECM on missiles
- ECM degrades beam fire control chance to hit
- ECM degrades missile fire control maximum range
- ECCM on beam fire controls, missile fire controls, and CIWS
- Laser warheads
- Fixes to all the bugs reported in the bug thread

Here's a list of the design choices that are in the game as it stands right now:

- Missiles cannot bypass detection by existing less than 5 seconds.  Will be optional later on.
- Geo survey default orders limit range to 10b km.  I originally omitted the limit because it's arbitrary and inflexible, but valid concerns of excessive fuel usage were raised.  I'd like to rework things to make this smarter some day, perhaps by checking low-fuel conditional orders even while fleets are still in flight for an existing order, but to save time and match A4X, it's a flat 10b km for now.
- Hid the research projects for Missile tracking time bonus.  As in Aurora 7.1, this bonus doesn't do anything, so there's no point in it being researchable.  May revisit later, but for now I'm moving on to save time.
- In-flight retargeting (when original target is lost) (automatic, NOT manual) is still allowed  (Might make it optional later on)
- As in Aurora 7.1, laser warheads use missile damage code.  It sort of naturally emerged that it's just faster to code it this way and less of a performance hit.  I may revisit later on and add an option to use beam mechanics.
- I now treat fuel as a floating point number rather than integer.  This is to prevent the "exploit" in A4X where you can travel across the galaxy using 0 fuel if you use small enough sub-pulse times, an effect you often can't avoid even if you want to.  Fuel is now rounded to integers for UI display only.

With a few exceptions, my general philosophy is when in doubt, match Aurora4x and revisit later, for better or worse.  There's still a whole lot more to add rather than spend any more time in this area.   Speaking of which, next up, in no particular order, is secondary stages, shooting things on the ground, shooting things *from* the ground, dust and atmospheric effects on beam weapons, and radiation warheads!


Posted by: joansam
« on: February 17, 2020, 08:27:38 PM »

Yeah, in general Aurora isn't a game made with a balanced meta in mind. I'd prefer allowing in-flight retargeting since it makes more sense, gives more RP potential and means you don't have to micro individual salvos as much for fear of waste. Abusing it for mega-strikes will just be one more entry in the already large list of house rules for fair play.
Posted by: Tuna-Fish
« on: February 16, 2020, 11:50:51 AM »

Quote from: Steve Walmsley link=topic=10149. msg118865#msg118865 date=1581688322
you can create situations where a ship can combine multiple salvos for simultaneous attack.

As far as I know this tactic is used by players sometimes anyway, it requires missiles with several different speeds in cargo, some calculations, good timing of shots and ideally zero or predictable target movement.

It's actually a lot easier than that. Just make a 2-stage missile where the second stage is a normal-ish missile with a long range and matching separation range, and the first stage has a speed exactly equal to your fleet speed. So long as your engagement is strictly linear, if you are flying towards them as you launch, all your missiles will travel alongside you as you approach the enemy. When you hit separation range, all your missiles will instantly pop and go zooming towards the enemy as one cloud of death and destruction.

(Honestly I mostly just use box launchers these days anyway.)

Posted by: Garfunkel
« on: February 14, 2020, 12:08:43 PM »

The 10 billion km restriction on default survey orders is needed because the TG does not check for fuel remaining except between orders. So if you have the typical survey TG with default order of "survey next body" and the conditional order of "refuel at 50%", it is very much possible to run into a situation where the ship, with 60% of fuel remaining, issues itself an order to survey a comet that is 12 billion km away. Not only will the ship take a month to go that far but it'll be billions of km away from everything else when it runs out of fuel. And that's an easy example. What about binary & trinary systems, where the companion star is 20+ billion km away without any Lagrange points? Even if your survey ship does not run out of fuel, it'll take several months or even years to complete its mission.

So I would encourage you to include the 10 billion km restriction on the default survey order.

As for the missile re-targeting, it will change the meta-game because it'll affect how far your missile sensors need to see but that's a minor thing as long as manual re-targeting is not allowed. Which it shouldn't be because it was changed in Aurora for a good reason - stacking salvos at a way point and then "dumping" them all in one go at your target was impossible to defend against and it was easy to perform. If players now want to do the same thing, they need multiple types of missiles and calculate the time-on-target themselves, which is a lot of work both in-game and outside the game.
Posted by: EvadingHostileFleets
« on: February 14, 2020, 10:02:05 AM »

Quote from: Steve Walmsley link=topic=10149. msg118865#msg118865 date=1581688322
you can create situations where a ship can combine multiple salvos for simultaneous attack.

As far as I know this tactic is used by players sometimes anyway, it requires missiles with several different speeds in cargo, some calculations, good timing of shots and ideally zero or predictable target movement.
Looks too much of a hassle though, I am going for ton of 0. 25 launchers when saturation is required and generally have no problem achieving needed numer of salvos and missiles on target at once.  Time of reload is. . .  manageable, considering distances involved.
Posted by: Steve Walmsley
« on: February 14, 2020, 07:52:02 AM »

Given that most missiles today can retarget in flight, Aurora’s limitations never made much sense to me. Good tweak, from both a gameplay and realism perspective.

Missiles in Aurora used to be able to re-target in flight, but that was removed for game-play reasons many years ago. With re-targeting, you can create situations where a ship can combine multiple salvos for simultaneous attack.
Posted by: joansam
« on: February 14, 2020, 07:31:35 AM »

Given that most missiles today can retarget in flight, Aurora’s limitations never made much sense to me. Good tweak, from both a gameplay and realism perspective.
Posted by: Sunmannus
« on: February 14, 2020, 04:21:16 AM »

Quote from: Kyle link=topic=10149. msg118854#msg118854 date=1581664975


Quote from: Sunmannus link=topic=10149. msg118851#msg118851 date=1581650900
Hi Kyle, is there a technical reason why you can't create a 32-bit version of quasar?
I used to play Aurora on a laptop with a 32-bit OS, so if possible, I would appreciate it if you could create a win32-compatible version (for the final versions I mean, not during development .  .  .  )

Regards. 
Nope, no reason.   I can certainly do that later on, for now I'm just saving time by only building for a couple of platforms.

Good to know, thanks.
Posted by: Kyle
« on: February 14, 2020, 01:22:55 AM »

In Progress update 2020-02-06 I see what seems to be missiles changing target mid-course if original one is destroyed.  I may be wrong for I am newbie, but does Aurora behave like that? I observe so far that missiles come to the wreck and only then search for new target, provided that they have sensors.
As far as I know that is the case in Aurora
You're right, but it was no extra work on my part to just allow retargeting before they reach the wreck, and I feel it makes more sense this way.  And in some situations, less tedious to manage. 


Hi Kyle, is there a technical reason why you can't create a 32-bit version of quasar?
I used to play Aurora on a laptop with a 32-bit OS, so if possible, I would appreciate it if you could create a win32-compatible version (for the final versions I mean, not during development . . . )

Regards.
Nope, no reason.  I can certainly do that later on, for now I'm just saving time by only building for a couple of platforms.
Posted by: obsidian_green
« on: February 13, 2020, 10:26:31 PM »

This is amazing. I love the current version of Aurora 4x, but I was never going to buy a supercomputer to play it, which meant death by slowdown that eventually became even worse than the combination of pathing and exponential dirty clothes that overwhelmed my DF experience. This will be a speedy 7.1 with bug fixes? Terrific!

I'd love to play Aurora again and this looks like it will make it possible.  :)
Posted by: Sunmannus
« on: February 13, 2020, 09:28:20 PM »

Hi Kyle, is there a technical reason why you can't create a 32-bit version of quasar?
I used to play Aurora on a laptop with a 32-bit OS, so if possible, I would appreciate it if you could create a win32-compatible version (for the final versions I mean, not during development . . . )

Regards.
Posted by: Gabethebaldandbold
« on: February 12, 2020, 03:05:51 PM »

In Progress update 2020-02-06 I see what seems to be missiles changing target mid-course if original one is destroyed.  I may be wrong for I am newbie, but does Aurora behave like that? I observe so far that missiles come to the wreck and only then search for new target, provided that they have sensors.
As far as I know that is the case in Aurora
Posted by: EvadingHostileFleets
« on: February 12, 2020, 03:52:18 AM »

In Progress update 2020-02-06 I see what seems to be missiles changing target mid-course if original one is destroyed.  I may be wrong for I am newbie, but does Aurora behave like that? I observe so far that missiles come to the wreck and only then search for new target, provided that they have sensors.
Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55