Author Topic: C# Aurora v0.x Questions  (Read 36818 times)

0 Members and 1 Guest are viewing this topic.

Offline Jorgen_CAB

  • Rear Admiral
  • **********
  • J
  • Posts: 993
  • Thanked: 74 times
Re: C# Aurora v0.x Questions
« Reply #345 on: March 12, 2019, 03:42:15 AM »
I don't think it matter all that much in which order things are built... by the yard or by factories. If the yard builds it you still looses time you could do something else. It also would just be a one time thing. A yard that will stand there for a LONG time will generally be better with one slipway in several yards over time unless there are some sort of bonus for building ships in serial. Many yards makes it way easier to build more specialized ship classes and make smaller incremental changes and slight (and different) alterations to classes.

It depends on how expensive it is to add new slipways in contrast of building a new shipyard. Currently you build a yard for 2400 and it cost roughly 2000 minerals to expand it to a size of 10.000 tons and building a new slipway at 10.000t will cost you 2000 minerals. So I agree that if you build smaller ships then having a few slipways will be beneficial but as ships scale up in size the initial cost will sort of get lost and mean less and less and the flexibility of more yards are more important.

Perhaps the balance is good as it is... I don't know.
 

Offline TMaekler

  • Captain
  • **********
  • Posts: 461
  • Thanked: 60 times
Re: C# Aurora v0.x Questions
« Reply #346 on: March 12, 2019, 05:53:14 AM »
Maybe Steve can introduce a system where a repeat in slipway production increases the speed of production (to simulate experience). This extra speed then get's lost when you retool.

That would give you the choice of having multiple slipways for each class you build, but which might lay dorment for quite some time if you don't build there in series as well as the disadvantage of more workers needed in general, but give you the advantage of quicker construction if needed - vs. having fewer slipways you retool as you need, but have longer production times (and lesser need of slipway workers).
 

Offline misanthropope

  • Chief Petty Officer
  • ***
  • m
  • Posts: 42
  • Thanked: 14 times
Re: C# Aurora v0.x Questions
« Reply #347 on: March 12, 2019, 12:07:04 PM »
with an 8% inherent interest rate, construction 16 tech and a 30% governor bonus, the overhead cost of a project done via CF is .857 per BP.  that is to say, the overhead on a new 1000 ton naval shipyard is higher than the *total* cost of a 10,000 ton slip, during the phase of the game where errors actually matter.
 

Offline Darkminion

  • Petty Officer
  • **
  • D
  • Posts: 23
  • Thanked: 5 times
Re: C# Aurora v0.x Questions
« Reply #348 on: March 12, 2019, 01:52:10 PM »
Had a few questions pop into my head during lunch and figured I would ask.

1. Is there any possibility for DB access or APIs that would allow us to access game data? There are a few neat tools I have come across for VB6 that allowed you to dump data to create reports or create files that could be imported into Space Engine which helped add a ton of flavor to my games, providing you had access to the DB. Is this something that's an option or could be an option with C# sharp as well?

2. How much are you looking into AI Deployment/Combat when it comes to players devising ways to fool it? Can I crank out large missile drones with as large as possible active sensors to send them on wild goose chases across the known universe? Will the AI be able to discern between fleet contacts and missile contacts in this context? Could I do this endlessly or would it be possible to have them catch on at some point? I cannot remember in VB6 if active sensors on missiles give it away that it was a missile.
 

Offline Barkhorn

  • Captain
  • **********
  • B
  • Posts: 524
  • Thanked: 69 times
Re: C# Aurora v0.x Questions
« Reply #349 on: March 12, 2019, 02:40:29 PM »
In VB6 it does seem to give away that a contact is a missile.  I saw the AI spam about 1000 AMM's at a single sensor buoy.
 

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 7662
  • Thanked: 3579 times
    • http://www.starfireassistant.com
Re: C# Aurora v0.x Questions
« Reply #350 on: March 12, 2019, 04:46:06 PM »
Had a few questions pop into my head during lunch and figured I would ask.

1. Is there any possibility for DB access or APIs that would allow us to access game data? There are a few neat tools I have come across for VB6 that allowed you to dump data to create reports or create files that could be imported into Space Engine which helped add a ton of flavor to my games, providing you had access to the DB. Is this something that's an option or could be an option with C# sharp as well?

2. How much are you looking into AI Deployment/Combat when it comes to players devising ways to fool it? Can I crank out large missile drones with as large as possible active sensors to send them on wild goose chases across the known universe? Will the AI be able to discern between fleet contacts and missile contacts in this context? Could I do this endlessly or would it be possible to have them catch on at some point? I cannot remember in VB6 if active sensors on missiles give it away that it was a missile.

I haven't decided yet whether to secure the DB for C# Aurora, but I will probably go for something similar to VB6.

AI should be smarter regarding target selection and will be able to tell the difference between missiles and ships, although I haven't finished coding it yet. I will have to get moving on that though because my latest test game just generated precursors during system generation (about 10 minutes ago) for the first time.
 
The following users thanked this post: JakeLoustone, Darkminion, chrislocke2000, Garfunkel, JacenHan, King-Salomon, Lornalt

Offline Rastaman

  • Sub-Lieutenant
  • ******
  • R
  • Posts: 123
Re: C# Aurora v0.x Questions
« Reply #351 on: March 20, 2019, 11:55:53 AM »
Steve, in one of your posts a while ago you hinted at a new feature you called "active electronic warfare". Do you mean offensive electronic countermeasures (OECM), as employed for example by the USN with their Prowler/Growler aircraft? What are your plans and thoughts on this?

For those new to the idea, this would open up a whole other form of fascinating gameplay:

- OECM can affect an area or better a direction/angle, which would make necessary the proper positioning of ECM craft.
- A new support type of spacecraft.
- The capability of low observable spacecraft, supported by OECM forces, would be enhanced.
- The current form of Aurora ECM would be properly called DECM and its capabilities would have to be more limited/nerfed in contrast to OECM.
- OECM and DECM can be detected and analyzed by ELINT modules, so that stealth spacecraft better do not activate DECM.
- Active sensors, like modern AESA sensors in real life (AN/APG-81, AN/APG-82 etc.), could double as OECM.
- Possibly frequency bands?
« Last Edit: March 20, 2019, 12:00:52 PM by Rastaman »
 

Offline Lornalt

  • Able Ordinary Rate
  • L
  • Posts: 4
  • Thanked: 1 times
Re: C# Aurora v0.x Questions
« Reply #352 on: April 11, 2019, 11:57:49 PM »
So Just asking  ;D can we still give titles to the Officers? for Role Play purpose of course. . .  Hail to the Emperor!
 

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 7662
  • Thanked: 3579 times
    • http://www.starfireassistant.com
Re: C# Aurora v0.x Questions
« Reply #353 on: April 12, 2019, 02:31:34 AM »
So Just asking  ;D can we still give titles to the Officers? for Role Play purpose of course. . .  Hail to the Emperor!

Not coded at the moment, but will be easy to add.
 
The following users thanked this post: Lornalt

Offline Jorgen_CAB

  • Rear Admiral
  • **********
  • J
  • Posts: 993
  • Thanked: 74 times
Re: C# Aurora v0.x Questions
« Reply #354 on: April 17, 2019, 09:00:54 AM »
Just wanted to ask if you have any intention of looking into the fire-control versus salvo issue for Aurora C# at some time?

I mean there are some mechanical issues in how salvos and fire-controls can often be abused mechanically that makes relatively little sense. So.. expanding on the fire-control and how many guns or missiles they can control or incoming targets they can track or some such?

In general I try not to abuse this mechanic but it is often very hard to walk the line since it is a very grey one.
 
The following users thanked this post: alex_brunius, serger

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 7662
  • Thanked: 3579 times
    • http://www.starfireassistant.com
Re: C# Aurora v0.x Questions
« Reply #355 on: April 17, 2019, 10:16:12 AM »
Just wanted to ask if you have any intention of looking into the fire-control versus salvo issue for Aurora C# at some time?

I mean there are some mechanical issues in how salvos and fire-controls can often be abused mechanically that makes relatively little sense. So.. expanding on the fire-control and how many guns or missiles they can control or incoming targets they can track or some such?

In general I try not to abuse this mechanic but it is often very hard to walk the line since it is a very grey one.

Are you talking about creating many small salvos to confuse point defence?
 

Offline Jorgen_CAB

  • Rear Admiral
  • **********
  • J
  • Posts: 993
  • Thanked: 74 times
Re: C# Aurora v0.x Questions
« Reply #356 on: April 17, 2019, 03:39:19 PM »
Are you talking about creating many small salvos to confuse point defence?

Yes, that is one of the artefacts of the current mechanic.

You can get this artefact in a few ways... one is making PD very expensive through use of the often cheaper missile fire-controls or by loading different missiles and fire them from the same fire control and thus creating several salvos from the same fire-control.

I do think there could be some balance between needing FC to control and target missiles based on tech level rather than having fixed salvo sizes. This might also "solve" the extreme Box launcher salvos that also often can make PD very weak in the other direction, especially when these two are combined to make the PD very expensive to maintain.

There is also some issues (in my opinion) with the bonus you get to fighter beam fire controls. They are so much cheaper that it is more efficient to create small turreted Gauss or rail gun fighters. A Gauss turret with an 85% reduced Gauss turret can often be up to 50% faster in tracking than on a ship and still cheaper to operate by stuffing it in a hangar.

I would not mind an overview of how FC works at some point. Like engines now scaling I would like FC to work the same on all platforms and that abusing the mechanic less of an issue because sometimes it is hard to avoid even when you try to avoid it.

For example a smaller FC you would put on a fighter (or a ship with one or a few cannon turrets) are able to track or control fewer missiles in flight, thus being smaller and fit on a fighter. That fighter are going to fire a small volley of missiles anyway etc... This would also solve some other issues with fire huge volumes of really small missiles, this would be expensive since it would need allot of FC or very advanced ones etc.. so this would also indirectly help the small versus large missile debate as well.
« Last Edit: April 17, 2019, 05:47:10 PM by Jorgen_CAB »
 

Offline Scandinavian

  • Warrant Officer, Class 1
  • *****
  • S
  • Posts: 80
  • Thanked: 20 times
Re: C# Aurora v0.x Questions
« Reply #357 on: April 17, 2019, 06:09:45 PM »
Given the greatly increased performance of the C# version, I'd propose doing away with the salvo concept entirely (or, mechanically, assign each missile to its own salvo).

This will slightly increase the propensity of AMMs to overkill when launching multiple AMMs per ASM, but it would remove the arbitrary distinction between 5 missiles fired by the same fire control in the same increment, and the same 5 missiles fired by 5 different FCs.

This would necessitate reworking the interaction between beam PD and missiles. My proposal would be to consolidate all missiles that are valid targets for beam PD during the increment, and resolve firing as if they had been one large salvo. The defender would need to be able to set how the PD should prioritize the missiles (which can be basically three attributes): Thermal signature, target cross-section (size), and speed, and whether they should be targeted in random order, lowest to highest, or highest to lowest.

If implemented in isolation, it would mean that no vessel ever required more than 1 FC for final defensive fire. However, to counter that, we could limit the number of weapons a single FC could control (with a single turret counting as one weapon, giving an additional advantage to turreting your PD weapons).

To balance this restriction, missile fire controls should be similarly restricted on the number of missiles they can have in space at any given time.

To begin with, I'd suggest letting an FC control 5 missiles or beam weapons, with a tech line for growing control capacity. Reducing this number during the component design phase should have an effect on size and cost (so FCs that only need to control one missile or weapon at short range get to claw their way down to fighter size without invoking special rules for fighters.).
 

Offline MarcAFK

  • Vice Admiral
  • **********
  • Posts: 1874
  • Thanked: 84 times
  • ...it's so simple an idiot could have devised it..
Re: C# Aurora v0.x Questions
« Reply #358 on: April 17, 2019, 09:44:50 PM »
I like those ideas, but I would offer a counter suggestion which also involves ECM.
Firstly, don't give fire controls arbitary hard limits to the amount of missiles or salvos they can control, but instead add mechanics where controlling multiple salvos causes a malus to accuracy and ECM/ECCM.
In an environment where theres little ecm or risk of your salvos being shot down you should be able to commit massive alpha strikes, but in a more restrictive environment you may wish to make less but better controlled salvos.
In addition, allow individual fire controls to split salvos up if desired, add a drop down or something so it can be split in 2/3/4/5 etc.
And as a counterpoint allow remaining pd after destroying a salvo to retarget other salvos hitting in teh same increment, but at a malus based on the firecontrol tech.
These 2 alone should do away with the exploit. However the AI will need to know how to deal with these mechanics, though already AI can be cheesed with the current salvo mechanics.
" Why is this godforsaken hellhole worth dying for? "
". . .  We know nothing about them, their language, their history or what they look like.  But we can assume this.  They stand for everything we don't stand for.  Also they told me you guys look like dorks. "
"Stop exploding, you cowards.  "
 
The following users thanked this post: Scandinavian

Offline chokuto

  • Petty Officer
  • **
  • c
  • Posts: 20
  • Thanked: 6 times
Re: C# Aurora v0.x Questions
« Reply #359 on: April 17, 2019, 10:38:25 PM »
I would be in favour of doing away with the salvo concept entirely as I think it adds unnecessary complexity and exposes an exploit.

With this approach I do think that something would have to be done about only need one fire control for final defensive fire.

Quote
And as a counterpoint allow remaining pd after destroying a salvo to retarget other salvos hitting in teh same increment, but at a malus based on the firecontrol tech.

Maybe a railgun or guass cannon should have a to hit penalty for each subsequent missile it is targeting. Potentially a tech line to reduce this, but not sure whether this would be on the fire control or the weapon. Also would think this should apply to turreted weapons but not sure how
 

 

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