Recent Posts

Pages: [1] 2 3 ... 10
1
C# Bug Reports / Re: v2.1.1 Bugs Thread
« Last post by verraka on Yesterday at 08:31:38 PM »
Quote from: Froggiest1982 link=topic=13078.    msg163470#msg163470 date=1672450365
For each increment, I have several of the following errors: Function #1954, Function #1943, Function #478

It happens when raiders appear.   

I have attached the Save.   

I have a similiar-ish issue to the quoted reply.    I only have star swarm and NPRs enabled however, no raiders.    When I attempt to advance time I get the same three function number errors as they do and it states "Object reference not set to an instance of an object. " after each function number.     Unlike, the above poster I am unable to progress past them as they continually reappear in a loop.     After I close one error message the next will pop up.     The errors pop back up again after I clear them, forcing me to force close aurora with the task manager.     I tried just spam clicking through the errors but if there is an end to them I can't reach it lol.   

This was a conventional start, with random stars, decimal separator is a period, year is only 2082.     I made backups, edited the DB to let me control the NPRs, and attempted to go through the NPRs to see if they were causing the issue.     I did see issues with fuel shortages and impossible civilian fleet pickups in the NPRs, so I deleted the offending fleets and civilian lines.     This seemed to allow me to progress for a few more days, but then the cycling errors returned.     

Earlier in this game I had gotten a singular error message with the same text about "Object reference not set to an instance of an object.    ", but was able to just click okay and continue the game.     This happened maybe 3-5 times spaced out by years before I hit this impassable wall of the three error messages cycling.     

I've attached the DB file.   

2
Thar’s a narrow-minded viewpoint- in that case, to avoid unintended consequences, why change anything ever?

Eh, if we're gonna go off the cusp here already and call others narrow minded, I think this is the more narrow minded viewpoint.

Every action has a consequence, and a lot of times these can be unforeseen, which cannot be avoided. It's part of the friction of making decisions and managing risk.

The answer to your question is, "when the possible risk is outweighed by the possible benefits of an action".

Although, I'm not really sure what this is in reference to or how this relates to the suggestion.
3
General Discussion / Re: Questions Not Worth Their Own Thread: C# Edition
« Last post by Snoman314 on Yesterday at 05:35:23 PM »
Do you have to use multistage? I know that is one way to use it, (i.e. a buoy with sensors and separation range calibrated for the carried missile to intercept without running out of fuel) but I thought that if you put a sensor in a strike missile launched by buoy or by ship, it will retarget a new hostile if the salvo was overkill. This is quite important for massed mines and offers a fire and forget approach to targeting fleets.

I am hoping to test this but in my current game the stack'o'swarm I was expecting after the loss of my scout arrived a little early so I am having to use the missiles I already have in the field which dont have sensors. Still I am sure the swarm will provide more targets once I get my act together. I will report what happens, assuming the empire survives that long!

Hmm, possibly I mis-read your earlier post. If you're talking about firing missiles at a waypoint near an intermittent contact, then I think it needs to be multi-stage. If you're talking about firing a big volley of missiles at one ship in a fleet and having them spread to other targets once the targeted ship is dead, that won't work, as they all hit simultaneously. Following saloves should re-target in that situation though.
4
Thar’s a narrow-minded viewpoint- in that case, to avoid unintended consequences, why change anything ever?

I like the idea behind this because it’s something that can be implemented for the AI simply as well as the player.

I feel that currently there is no purpose to AA units or air support in general. Getting ground attack craft to a hostile world and assigned to FFD is an unbearable micromanagement slog with little benefit as artillery and FFD support has next to no effect in combat. The AI doesn’t support the mechanic at all, and to do so would require more coding effort than this proposal.

It also allows players to fluff thei aerial support as they wish - from drone swarms to helicopters to bombers or anti-grav assault ships.
5
you cant avoid having *any* unintended consequences, but you can avoid *many* of them by eschewing sweeping solutions to narrow problems.
6
General Discussion / Re: Questions Not Worth Their Own Thread: C# Edition
« Last post by boolybooly on Yesterday at 02:23:02 PM »
As far as I know, you can do this, but you'd have to use multi-stage missiles. I'll be interested to hear how your testing goes, as I've never tried this myself.

Do you have to use multistage? I know that is one way to use it, (i.e. a buoy with sensors and separation range calibrated for the carried missile to intercept without running out of fuel) but I thought that if you put a sensor in a strike missile launched by buoy or by ship, it will retarget a new hostile if the salvo was overkill. This is quite important for massed mines and offers a fire and forget approach to targeting fleets.

I am hoping to test this but in my current game the stack'o'swarm I was expecting after the loss of my scout arrived a little early so I am having to use the missiles I already have in the field which dont have sensors. Still I am sure the swarm will provide more targets once I get my act together. I will report what happens, assuming the empire survives that long!
7
It has frequently been opined that flying units are missing from Aurora ground combat, and that assigning space-based fighters to ground combat through FFD doesn't really scratch that itch.
The typical suggestion is that to remedy this, a 'flyer' unit type should be added alongside the existing vehicles.

I want to propose an alternative: Make 'aerospace' a capability similar to 'Boarding Combat'

This capability could be connected to any vehicle type and would do the following:
  • Provide superior evasion; either a simple HitMod*0.1, or (Hitmod^2)*0.1 - flyers are fast/high and hard to hit; AA weapons should inherently ignore this modifier and revert to HitMod
  • Reduce armor (and perhaps hitpoints) by a factor of 0.25 - the main problem with flying platforms is they need lift at the cost of armor, and these structures render them fragile.
  • Increase GSP Resupply Cost by a factor of ~2.5  maybe depending on technology - Flyers eat fuel.
  • They cannot benefit from Fortification - a flyer may sit in an underground hangar, but if it is then it's not fighting

This achieves 2.5 things:
  • It continues Steve's design philosophy that labels are roleplay-agnostic.
    Use a Light Vehicle to imagine an ornithopter or an unmanned drone; Super-Heavy can be anything from steampunk attack-blimps to flying Gundams; whatever you can imagine.
  • You (Steve) would barely need to mess around with unit types or weapon types!
    • Fit your 'aerospace heavy vehicle' with bombardment weapons if you want it to be a durable, RE-stationed bomber
    • Fit your 'aerospace light vehicle' with Light AA if you want a front-line interceptor designed to take on other flyers.
  • As an extension of [2] you fix the 'AA Horizon' problem that all AA units on the planet can fire at any aircraft: AA units are now only engaging hostile forces that their formation is in combat with, and their combat doesn't need a separate mechanic

Of course flyers that are hard to hit could potentially bring a host of balancing issues, but that's eminently tweakable by (for instance) altering AA cost/effectiveness or flyer resource requirements.
The point is to add interesting options and expand our roleplaying potential at a manageable development cost!
8
C# Bug Reports / Re: v2.1.1 Bugs Thread
« Last post by Alphard on Yesterday at 01:34:40 PM »
https://i.    imgur.    com/TICq8yN.   png

"2. 1. 1 Function #917: Value was either too large or too small for an Int32. "

Occurred when setting a civilian contract to move automines to C/2017 K2, which is quite a far distance away from Earth actually.     This appears thousands of times and renders the game unplayable, forcing deletion of the game.     Actually, since the default behavior is to load your most recent game, I had to reinstall the entire game.     I couldn't stomach going through 4,000 message box prompts to see if there was a way to fix this.   

I think it is probably some type of check that is failing due to overflow because of the huge distance involved.   
9
C# Suggestions / Re: Ground combat - morale, organization and training level
« Last post by TurielD on Yesterday at 01:25:36 PM »
despite the elegance of the suggestion, it seems to me that many unintended consequences would be avoided at a small cost in effort if the more prosaic approach of simply defining one or a few "aerospace" unit types were taken instead.

Everything has unintended consequences, that's the nature of Aurora.

Anyways, I think its worth making its own thread, so I'll do that to stop derailing this one quite so badly. My apologies to Garfunkel
10
definitely would need to reduce hit points in addition to armor.  many quality designs rely on a combination of evasion and hit points for survival as armor is expensive and those things are free.  cap or hcap light vehicles are already quite strong among attacking options, and multiplying their survival by a factor of nearly ten for a cost increase of (presumably) 100% would revolutionize ground combat.

despite the elegance of the suggestion, it seems to me that many unintended consequences would be avoided at a small cost in effort if the more prosaic approach of simply defining one or a few "aerospace" unit types were taken instead.
Pages: [1] 2 3 ... 10
SMF spam blocked by CleanTalk