Author Topic: Core dump by new player (very long)  (Read 3575 times)

0 Members and 1 Guest are viewing this topic.

Offline Polaris (OP)

  • Leading Rate
  • *
  • P
  • Posts: 9
Core dump by new player (very long)
« on: May 28, 2011, 10:45:51 PM »
Below is a list of Aurora bugs, omissions, and oddities compiled during the course of play by a newbie.

I apologize in advance for the items that actually work as designed (WAD), reflect misunderstandings on the player's part, or have already been fully discussed on these fora.   I also apologize for the length!

However, I deliberately choose to include everything that seemed off to me, in order to give the game a new look by a fresh pair of eyes.   This opportunity only happens once for any given player; I have endeavored to make the most of it.

Posting here, as I understand it's the most suitable place for newbies to be.


============================================================


Game freeze:
Performing the following steps will reliably freeze Aurora on my system:
- request screenshot on the galactic map (rewrite)


Time steps:
- The Aurora turn processing system - in particular timing issues and slowness - is the most seriously flawed portion of the game, IMHO.

- At least some orders are only issued once per time step.   If you request a time step of 30 days, a survey ship will arrive at the next point to investigate, survey it, and then wait until the time step is over.   By way of comparison, my fairly low-tech, cheap survey craft can complete an asteroid survey in the inner Sol asteroid field and be at the next body in 1-2 days, if I ask for sufficiently short time steps.   If this also affects AI behavior. . .
- What's merely irksome in peacetime becomes deadly in battle.   Having easily won a battle against Precursors, I advanced my fleet towards the planet they were guarding, with no targets in sight, (very powerful) sensors active and shields up.   I clicked the 5 day time increment with no auto turns and 0 minimum increments.   Without time being stopped, and with no chance given for the player to react, a weaker Precursor force appeared, closed to their shooting range (far lower than mine), opened fire with missiles, received no counter fire from my 450 AAM launchers, and hit one of my ships.   All of this *is ridiculous*; had time been stopped at any point before impact, they wouldn't have had a hope in Hell of doing this (my fleet defences are way overkill).   The selection of time interval should *NEVER* have the effect of setting up gamey ambushes like this.   One likely cause of this is that auto Sub-pulses can easily be set too high to adequately handle battles.   All of this poses the player with the option of seeing his forces repeatedly abushed by the game design, or taking small, time-consuming steps even when things seem safe.
- The present system does have the advantage of reducing processing load.   However, there is nothing being done in Aurora battles that needs to take much CPU time each 5 seconds.   Running 720 pulses of 5 seconds each ought to be a quick exercise on a decent machine in small-to-medium scale battles.   A code profiler will detail why the game takes such an extraordinary amount of time to think during battles; one obvious low-lying fruit is the game's insisting on saving to file so often.
- Does the construction interval in game setup affect game housekeeping things like the triggering of leader events?  If so, then something need a rethink.
- There are various events and conditions that cause the game to stop processing automated time steps.   If options for this behavior were added to the existing Event Updates->Filter Events interface, that would be much appreciated.
- In sum, the current timing system imposes the Rules on the Gameplay in irksome, time-consuming, and occasionally absurd ways.   It's therefore well worth (re?)considering what going to pausable realtime would do for gameplay and processing efficiency.   Players would control the rapidity of processing, up to the limits of the software on their computer, and could set automatic interrupts.


Saving to file:
- The game saves to file every step, which takes a lot of time when done every day for a year.   Options to control this behavior and allow players to balance crash-recovery and time efficiency may be helpful.   My ideal option would be one of "save every X minutes", which I'd set to about 5.
   Is there static data that doesn't need to be in a file that is repeatedly saved?  Also, I notice that the file doesn't drop in size when I delete a test game, so the file grows ever-larger.


Error messages:
- Aurora is, for its scale and complexity, a remarkably stable game.   However, it does throw up a lot of error messages, each one of which has to be clicked through.   If these messages were instead saved to an error log of error type, sitation triggered, and essential debug info, then players would be able to copy and paste the error reports into posts.   This would be both more helpful to you, and less annoying for me.


Task groups interface:
- It is time-consuming to get task groups to navigate about the galaxy.   Consider having the first destination option, after more than one system is known, be called "Move to System".   When clicked, you see a list of all systems, with ETA to their side of the closest jump point, a Jump Gate indicator, and ideally a threat symbol (so the player is reminded that a particular path will take us into a known minefield!) and may choose one.   The ship will then take the shortest path to that jump gate.
- If a unit cannot perform its primary standing orders, but can execute its secondary, then the game should not throw up an error message, but simply inform the player which orders the TG is following (In othe words:  The game shows two messages in such cases.  The second message works great, but the first is unecessary).   
- A unit should not refuse to execute standing survey orders if the destination is more than 10 billion Km away, or any distance, but the player should be notified if the ship will take more than perhaps a month to get there.
- Conditional orders tend to be common to multiple TGs.   If the game allowed me to save them, I wouldn't have to make the same provision for refueling for each and every TG I field (or fiddle with subordinate HQs to work around this).



Division of production and mining by planet:
- While this game feature allows for great control, it also makes it more difficult for the player to get a sense of the empire as a whole.   For example, nowhere can you find out what amount of each mineral a production planet is actually getting per time period, if it receives anything from freighters or mass drivers.   Certainly the "Mass Driver +/-" column doesn't do this.   The problem can be greatly alleviated by, for each body sending minerals to a production world, tallying up the minimum of a.  the production of each planet attached, and b.  the transport capacity available (mass drivers are easy; freighters involve a calculation of time/round trip and carrying capacity) - and then adding the sum to the recent change column.
- In general, the interface should more clearly accomodate the Aurora resource/production system, in which multiple bodies supply a production center with resources.





Mining and Transport:
- One feature of the game is that a mine will produce, not a given amount of minerals per mine, but a given amount of minerals of each type per mine.   Same story with cost to buy from the civilian market, but not with any form of transport, by freighter or mass driver.   It would solve some problems if Aurora were to have a mining system in which each mine/mass driver produced/launched a set base amount, weighted towards those minerals with greatest accessability/largest stockpile on the mine world and lowest ratio of reserves to useage on the destination world (mass driver destination, or most recent freight run unload point).   Perhaps a base production for all minerals together per mine of 20 (double the current per-mineral value)?  Extra credit if players don't usually need to satify their OOD with tweaking mining operations, but have the option to prioritize particular minerals just in case.   Extra extra credit if the expected consumption need of each material was adjusted to something like 10,000 + next year's consumption at present factory settings.
- The resource situation in this game depends greatly - to me, excessively greatly - on the availability of worlds with high SUM(acces DURAN + access MERC + access CORUN), as you must have factories, mines, and labs to do anything else.   Going to a system similar to that suggested above would alleviate this.
- Duranium is almost always the bottleneck in production materials, one that affects everything about running an economy.   Corundium, Mercassium, or sometimes Neutronium, Sorium, or Gallium can run short, but Duranium doesn't have enough higher abundance to make up for the vastly greater consumption rate of the basic TN material.   I tend to consume almost as much Duranium as everything else combined.   In contrast, Corbomite, Boronide, Vendarite, and (probably) Uridium are in general overly adundant compared to need.   This, combined with the way mines work at present, is the root cause of various gameplay weaknesses, an example of which is that a mine world that doesn't have very accessible Duranium is seldom worth exploiting, thus consigning a lot of solar bodies that ought to be cool and interesting to the "ignore me" pile.



System and resource layout:
- The game does not make it easy to mine multiple bodies each with few resources.   Unless an interface is devised that allows mining ships to automatically seek out resources, perhaps all bodies ought to have either no resources, or a meaningful amount.   Bodies with few resources are mere interface clutter now.
- Jump points are invariably clusters around the central star in a system.   It occasionally happens that a secondary star exists at a great distance from the primary (right now I'm looking at a system with a distance of more than 90 billion km between the two).   It seems a pity that whatever bodies orbit such secondary stars have no chance to be anywhere close to a jump gate.
- In cases where bodies are extremely isolated from jump gates (huge orbits, no LG points, long travel time from any gate), it would be cool if resource availability were upped, perhaps to reflect the Precursors having never found such places, or thought then economic to mine.


Division of tech by planet:
- Tech is researched in particular labs, on particular planets.   This feature and the interface combine to make research increasingly troublesome when more than one world is involved.   It would simplify empire management greatly, and cost little in realism, if the tech screen combined all labs on all planets, but tech research and the scientist leading it had some chance of being lost if labs were destroyed or captured by hostile action or disaster.   This example, so I argue at least, points out the difference between complexity that brings out the coolness, and complexity productive only of more complexity.


Window management:
- Window settings are not completely saved when closing a game.   Every time I restart Aurora, I must manually activate and move the many screens in frequent use so as to make maximal usage of my tiny screen (only 1920x1080 . . . ).   System and galactic view windows settings should be saved.   Message window table positions should be saved.   Galactic view display position and settings should be saved.

- Various windows become active and are brought to the front as time passes.   This causes annoying "flashing", especially when you're running automated turns, hiding the window you might personally want up and front (like a map of the current arena of conflict).   Supressing messages doesn't appear to affect this behavior.
- If a window is active but hidden by other windows, and you request it to be displayed by clicking a menu option or icon, it is not brought to the top so you can actually see it again.
- There are a number of instances where windows should refresh, but don't - too many to list in a general suggestions post.   If you want players to help provide a list of such instances, just ask.

Window management, reconsidered:
Ambitious thought - Consider whether it would be advantageous to re-think Aurora window management from scratch.
   Imagine a main screen that normally toggles between system and galaxy view that displays instead of the current menu when starting a game.   Make that screen into a "cockpit control panel" (as seen in several 4x space games) by including buttons or hotspots for all the screens necessary for the player to access all options and information.   The present display options shown on the galaxy view and system view are normally hidden and can be shown if you roll your mouse over a labeled hotspot.
   On the left or bottom of the screen goes a serious of hotspots; when you roll your mouse over one, after a small delay the interface for a particular game component (like Population and Economy or Class Design) replaces all of the main screen except for some equivalent to a hotspot marked by a "go back" arrow, or the list of all available interfaces.   The player can now rapidly shift screens as needed, without even the need to click.
   At the bottom or on the right of the screen are displayed recent messages.
   On the right of the screen are displayed lists, those for task groups, colonies, or minerals available in your homeworld being three of many tasty options.   The player can minimize these lists to free up screen space.   Clicking on items brings up to the appropriate interface with that entity displayed.   A highly effective method of doing all this is showcased in the Paradox Interactive game HO3.



Game interface and empire size:
     If there is a original sin of 4x space empire games, it is large empire bog-down.   Micromanagement due to lack of automation, interface incapacity to handle the sheer amount of Stuff, and software instability plague every non-trivial effort in the genre.   Aurora (as stated before) deals more than credibly with the third, but has some important issues with the first two; I will report here only on those that I noticed first.

1.   All of the lists in Aurora - those for leaders, task groups, ship designs, component selection, colonies, research possible and active, and so forth - are limited in space.   The more things or options, the greater the burden on the player to find the one thing he wants.   What is fun and approachable in the early game steadily becomes less so as empire size increases.

1a.   Seriously consider limiting total number of entities of various types for all empires.   Or at least giving players the option of setting up entity-limited campaigns.
1b.   Find ways to give lists more space on the screen.   Probably due to the interface libraries in use for Aurora development, the current interfaces waste a tremendous amount of space on margins; the two shipyard interfaces, the leadership interface, and the research interface are cases in point.   The list of active techs wants more space.   The drop down lists in various places ought to extend to the bottom of the parent window when necessary.   The longer the game is able to keep the player from having to scroll through lists every time he wants to do the most common tasks, the better!
1c.   Label lists where appropriate.   The drop-down lists of ship designs and task groups would benefit from a layout that looks like:
Survey
   (ship design 1)
   (ship design 2)
   (ship design 3)
Cargo
   (ship design 4)
Missile
   (ship design 5)
   (ship design 6)
1d.   Make it easier for the player to pick out the items of interest.   With a fairly small empire, I am already reaching for the time-consuming "Add title" to help keep track of leaders I'm grooming for future needs, especially persons good at commanding naval task forces, and adding 2-3 character class labels to all ship designs and task groups, just to reduce the time spent hunting stuff down in lists.
1e.   Allow tables to resort when you click on the header of any column.   If I want to sort ground forces by effective strength, or sort available tech by research cost, this should be a matter of double-clicking that column header.

1e.   Game inferfaces can and should scale up with empire size better.   Take the leadership interface as an example.   Information relevant to decisions requires many mouse clicks to obtain.   New officers must be individually processed; I delete 2 out of 3 new officers just to keep the interface from chewing up too much of my time, or as my naval leaders exceed 500, my computer's processing power.   Recommendations:
   1e. 1:  Devote as much of the Leaders interface as possible to a great big table of leaders.   It wants to show at least 40 leaders at a time, more if the Leaders interface can at all accomodate it.   Allow it to toggle between showing all ranks and ranks above or below a given value.   Each leader gets a row.   Name and title, rank and senority ("Rear Admiral (1)"), most recent assignment and date, location, and each ability or attribute, gets a (jusually narrow, with a abbreviated or vertical title) column.   The list resorts A-Z then Z-A when you click on any column heading.   If you shift-click on a column heading, then that column will act as a secondary sort (similar to the existing "Search by Ability or Location", "Ability B" option).   Any information that doesn't conveniently fit in the table is shown in a suitably attractive but condensed format, perhaps below the table.
   1e. 2:  Players may set up minimal abilities in all type for a incoming leader to be accepted as Active (and start taking up player and interface time and attention).   If a new leader doesn't meet any of the minimums, or is manually retired, he/she goes in the "Inactive Reserve" list, which players may draw upon by clicking a special button.   Officers in Reserve appear on no lists anywhere else, cost nothing to retain, and stay available for activation for 4 years before being deleted.
   1e. 3:  Active (possibly just employed, or else players will fiddle with active and reserve status to save money) leaders cost a small amount of wealth to retain (on the order of 0. 33 (~0. 50 if actual employment is required) wealth/year/rank, modified by racial wealth % and government type).   Leaders are not auto-culled if not recently assigned, if they have ever been assigned to anything.   If auto-culled, leaders move to the reserves and stay available for re-activation for 4 years.
   1e. 4:  The officer ship and ground unit assignments interface scales very poorly.   Information helpful to making decisions and assignment buttons are scattered all over the window.   Ships and ground units displayed as options for assignment are crudely sorted, lack sufficient ways to be culled to a manageable size, and jump to the beginning of the list with every assignment.   This is fine and dandy when empire size is small, but gets increasingly tedious when you're growing.
   I recommend implementing one or more hierachical unit displays: 
1.   Ships by type and model, using a list that behaves like the existing planetary Ground Units interface.
2.   Ship by task force and task group - same list behavior
3.   Or, ships by broad category (as is done now, but with user-definable options, or simply enough of them to keep list size manageable.


2.   Queuing orders is of obvious remedial value and is already employed.   In part.
   I do not know how to queue up ship builds.   Every single ship my empires fields have had to be ordered individually.   Consider if it would be helpful to combine the two shipyard interfaces into one, reduce the space for the Complex Activity and Create Task sections drastically to free up enough space for the list of built items.   Extra credit if the interface shows yards and builds at all planets, but with option to show only the currently selected world.
   The queue for science builds is cumbersome.   It's really easy to use the wrong scientist, in part because the scientist is cleared when changing tech field, in part because the research queue is really small and doesn't show scientist specialization, and in part because the size of columns in tables snap back to default values on a screen refresh, and certainly aren't saved to file.   The only way to swap current and queued tech (like when you want to immediately research the nifty new engine you just designed) is to cancel the first, which clears the second.   The list of possible tech doesn't update when an item is added to active research or the queue, so running Mines 14 right after Mines 12 takes a bit of fiddling.   One way to reduce errors in choosing tech and scientists is to highlight scientists and techs that match in green and make the text bold, so the player has confirmation that he hasn't accidentally had the wrong scientist selected when choosing a tech.
   The Task Groups order queue allows only the last or all actions to be removed.   It does not allow me to remove an action in the middle by double-clicking on it, or to resort actions.
   I cannot queue ground unit builds.

3.   Among the more noticeable problems this game develops with increasing empire size is message spam.   The options to supress messages of particular types is much appreciated, but the player's choices (suppression, background and text colors) should be allowed to be explicitly saved and loaded, the list of displayed messages needs more sorting and classification options (such as "show non-combat", "show combat", "show idled/no orders" (displays all messages indicating idle research centers and task groups, and units that cancelled their orders due to some problem), and cancellation of automatic time steps should always pay attention to message supression settings where they don't already.



Miscellaneous:
- When a ship is constructed, it joins an existing task force.   In the frequent case of your wanting to make a new task force of that ship type, there is no option in the to Manage Shipyards interface to "Create/Join new taskforce".   All ships of the same type, if completed at the same time, with this option selected, join a single new task group automatically created for them.

- It is possible for a leader to be retired for not being assigned to anything in the past X years in the case that you haven't assigned him recently because you like the job he's doing just fine.   I've taken to re-assigning all of my leaders every 3-4 years to make sure the game doesn't take away good leaders with the bad.

- The "unassign all" button is both unecessary (we have "unassign type") and dangerous, as a mis-click here wipes out all scientist assignments, but not the research projects themselves, making for total research chaos.



(leaders)
- If leader history were ordered most recent first, or the window started at the most recent item, then it would be easier to tell the most recent assignment (important if you want to keep an officer around for future needs).




Galactic map:
- Attempting to take a screenshot reliably freezes the game on my system.
- When Task Groups->"center map on fleet" is active, the galactic map should not move about, if the star is currently fully visible, and the map all fits on the screen (rectangle containing all stars is less than current screen size). 


- Mass drivers on mine worlds should not launch 0 tons.


Civilians:
- I don't know what it takes to get the civilians to start setting up mining colonies.   It took more than 20 years for them after first geological exploration to do so in my most recent game, despite my subsidizing the shipping line and building a commerical spaceport early on.
- The first world my civilians choose to send colonists to was a mining operation roasting at 1271 degrees C.   Lacking other means to control the civilians - I really wanted to delete all their colony ships and forbid them from making more, since they obviously didn't know how to use them - I immediately set my homeworld to a population destination and built an extra colony ship to rescue stranded souls.

- Population and Production, Industry:  When clicking on one of the items in the build list, the resource requirement should be displayed, just as it is when clicking on one of the Construction Options.


- Ground units built using cadres created from trained units (higher morale) have no extra training (morale of 100).   Because cadres "represent the best officers and men of the old unit", they logically wouldn't do much if anything to reduce build cost, but would certainly improve unit quality.
- It is surprisingly expensive to build ground unit training facilities, it takes a suprisingly long time to train units, but the build cost of ground units is curiously low.   Adjusting these values so ground units build pace is more like that of small ships would make good sense.
- Also, one vote for the first 10-20 points of ground force training to happen more quickly, and for training level to be capped at some level (perhaps +50%; +34% is good for ships, though).
- Consider removing the requirement to have a Ground Force Training Facility for ground unit construction.   Raising a militia takes little industrial power, and more advanced unit cost can be increased to compensate.   Certainly it should not take so much for a planet to raise its own militia.   This will also cut down on the micro-management required to raise and distribute ground forces (not a part of the game that most players are especially interested in focusing effort on).
- Ground unit training should work more like ship training does:  Leaders commanding the unit, the brigade, and the division should each contribute all or a fraction of their training bonus to training the unit.   At present, only HQ leaders have an effect; training bonuses on inividual unit leaders is wasted.   Ground combat bonus should work similarly; at present, only the individual unit's leader has an effect - at least as shown in the ground units interface - which is neither logical or consistant. \
- It is hard that my very well-trained units, with morale values well above 100, suddenly lose years of preparation if their HQ changes.   Even if this itself is WAD, it's hard that it takes so long for morale to recover.
- It is strange, but also a very good thing, that they don't lose any morale if I clear their HQ and than re-assign them.


- When a sector grows in size, a message should be given.

- Consider not dropping fuel efficiency linearly with tech.   While the effects of many tech advances act as roughly consistant multipliers on the previous level, increases in fuel efficiency with each new tech rise rapidly:  a 10% reduction for the first advance (100% -> 90%), but a 50% reduction for the final advance (20% -> 10%).

- When attempting to use a Lagrange point, I cannot get the game to recognize the order request.   Double-clicking on a destination (one of the other Lagrange points) does nothing.   Solved:  found out that you have to explicitly click "add move" in this case - and all cases that involve a third order selection step.

- If a ship is built, and the task group to which it is assigned does not exist, the ship vanishes with no warning given.   The new-built ship does not appear on any list.   I noticed this when for reasons unknown my shipyard TG went missing; lost 6 ships before I figured out that this was a bug.

- Should development cost be linear with size of components?  Consider upping the cost for size 1 components of various types by x2 to x5, and then using the square root of the size as a cost multiplier.

- When designing active sensors, I notice that sensors with a resolution of 100 claim to have much better range against ships of 1000 size than do sensors of 1000 resolution.   However, the game rules state that sensors allow a ship to detect other ships "equal to or above it's [sic] stated resolution size within it's stated range".

- This oddity aside, more information on sensor effectiveness in the design interface would be helpful.   Ideally, a graph of target size/signature versus range could be provided for active, EM, and thermal sensors.   Failing this, I'd like a table of ranges for EM and thermal sensors, and an expanded table for active sensors, consisting of 5000 tons, max smallcraft, max fighter, large missile, and small missile to be provided.

- The effect of mesons on internal armour is not clear.   Is internal armour degraded on a survived hit (like external armour is)?

- Thermal detection of ships yields less valuable data than detection by active sensors, but ranges are generally lower than those of active sensors at the same size and tech, especially for low-tech engines.   Should thermal signature be linear with engine rating?  Perhaps a lesser increase, and a higher base value?

- Consider removing the planetary sensor tech and instead use thermal tech (or some mix of the three ordinary sensor techs).

- It should be made clearer what the EM signature of an active sensor is.   I can't find this info anywhere.

- Members of a diplomatic team that do nothing (no assignment, no actions) gain skill over time.   WAD?

- I get Loading Problem-type messages from civilian TGs that attempt to load an item that isn't available.   I don't need to know this, really.

- TGs that have a loading problem may cancel their orders, even if more of the item they want is being built.   They also may spam messages (I /think/ this is a second, distinct issue, deriving from another glitch; perhaps occuring when TGs are full).   If simply waiting will get a TG what it wants, without further player intervention, then that's what they should do.   If it is full, and later orders will allow it to empty itself, then it should skip the current load order.

- Financial centres seem underpowered for their cost.   Also, should they use manufacturing sector workers?

- I accidentally changed a cargo ship design to PDC.   Every single existing ship of that type lost its engines and cargo space.   My entire shipping capacity was wiped out at a blow.   Rethink how ship designs interact with existing ships and current builds, please, because the Lock feature isn't enough protection.
- The ease of changing active ships by fidding with their designs allows for wild abuse as well.   I had both official and civilian colony ships of a particular type, but no shipyard tooled to build them.   Some new engine tech, a little unlock and redesign and suddenly all the ships were moving 50% faster!

- Retool costs seem very high.   When I'm swapping out just then engines on a cargo ship, I should not be paying more than it would take to build a new vessel.

- Follow-up bugreport:  When fleet speed is above maximum speed, speed should be set to maximum.

- When one TG joins another, the current speed of the combined group should be that of the existing TG (unless this is higher than max).   The task group screen should not generate an error message of the form "no longer exists".

- Destroying jump gates should be possible, if it is not already.


- The shipyard operations techs could stand to be made fewer, and more costly, with larger reductions in cost per tech gained.   Perhaps -10, -20, -35, -50?  Maximum effect of highest tech looks good.

- In various displays, change engine "Efficiency: 0. 6" to "Consumption: 0. 6", and "E10" to "FC10", or something similar.


- Maintenance is a chore, and I personally feel the game imposes too much of it on me (unless I chose the no breakdowns option, but that's the opposite extreme).   Maintenance facilities should be much easier to build up to the usual sizes of ships.   Overhauls should be needed less often, and take less time; you know balance is screwy when it may easily take longer to overhaul a ship than it did to build it.   Breakdowns should not become so common when a ship is old; a slower rate of increase in breakdowns (square root instead of linear, perhaps) and a lower maximum rate, please.   Maintenance supplies may also be overpriced.
- If breakdowns and maintenance are lightened up, consider cancelling the commercial immunity, setting commercial breakdowns to 10% of military, and applying this on the component level, not the ship level.   So one can run ships with very reliable engines, but finicky weapons, say.

- Should ships cost money to maintain, as ground troops do?  Certainly, turning on the no breakdown option shouldn't mean that ships cost nothing to maintain - it should just mean that they cost money or resources instead of supplies to maintain.

- Should the tech Boat Bay be in Missiles and Kinetic Weapons as it is currently, or in Construction, or in Logistics?

- When designing a magazine, armour type has no visually obvious effect.

- If you build a ship with prefabbed components, and then cancel the build, the components are not returned.

- When a scrap order is given, the ship being scrapped should be removed from the list of ships of that type available to scrap.

- The filter message system should distinguish between health events that eliminate officers and those that don't.

- In Sol Starts, the bodies of the Sol system have generic images; given that worlds in other systems may have appropriate images, this is odd.

- Hyper drives should turn on and off automatically.    Unless there's any drawback to their being on in hyperspace, in which case the player should be able to set guidelines.   I'd much rather be focusing on more interesting parts of the game instead of fiddling with engine settings on transports, and my having to do so militates against using hyper drives.

- Commander messages assume all commanders are male.

- Ganymede's gravity should be either 0. 14 or 0. 15 Earth's
- Callisto's gravity should be 0. 13 Earth's
- Titan's gravity should be 0. 14 Earth's
- Probably various other changes. . .

- Consider relaxing the rules about habitation of lower gravity worlds.   It's likely to be at least as easy for humans to live on the Moon (. 165 g) than on a world with 1. 5 gs of gavity.

ALREADY REPORTED - The techs Genome sequence:  Temperature Range +5, +6, and +8 degrees all unlock when Genome sequence:  Temperature Range +4 is researched.

- The player should be able to specify power plant size down to the nearest 0. 1 HS.   Same comment applies to various other tech designs.

- Missiles:  The power of extra armour (always) and ECM (unless much better than their ECCM) doesn't seem to warrant the price in speed, size, and cost on single-warhead missiles (MIRVs may be different). 
- This goes double because, if I forgo armor and sensors, I can reduce launcher size, which doesn't just reduce component size, but also increases reload speed.   A 0. 75 size/x2 modded size 2 launcher has the same firing rate as a size 4 launcher, but you can squeeze 8 of 'em into the space taken up by 3 of the larger launchers.   Armor or ECM will find it difficult to make up for the fact that doubling missile size thus divides throw weight by 2. 67.
- This feature also decreases the value of drones and MIRVs.
- Consider allowing players to specify drone engine size.

- Calculations on a spreedsheet indicate that engine tech is HUGELY important to missile potency, as it boosts effective range, hit chance, surviveability, and first-strike potential.   Consider toning down this tech's effects a bit to give the other techs more air time.   (and/or) Consider bumpng up the rate of improvement in agility tech, currently of secondary importance due to the lower % of space devoted to agility on most anti-ship and even anti-missile designs. 

- Consider allowing players to specify military and commercial engine size to the nearest HS.   I want to be able to field ships the size of fighters but with more fuel-efficient engines, "drone smallcraft" that sneak in to missile range, launch their payloads off, and head back to their mothership.

- Population and Production, Missiles:  Obsoleting missile types doesn't clear the missile design lists.  This makes for clutter over time.

- In the Geological Survey Report interface, may we have an option to search within one of the active sectors only?  Or within a certain time-distance of an existing planet with factories?  The idea here is to more easily determine how long it will take to get minerals back from a potential mine world to the factories it will feed.

- I know of no way to recover minerals or components from PDCs being taken out of service.

- There should be some way for shipping lines to upgrade their fleets.   I want them to get away from using their slow, fuel-gulping old ships, and switch progressively to the faster, more fuel-efficient models they now have blueprints for.

- Population and Production, list of worlds:  There should be some easy way for players to get more information on the world; perhaps a double-click takes you directly to the System Generation and Display interface, with that world selected?

- Messages:  A double-click on any message related to a task group should bring up the Task Groups interface, with that TG selected.

- Should troop transport bays have such a high HTK?  Perhaps more crew per cargo handling system?

- The building of civilian ships causes official unit numbering to skip values.

- Is missile ablative armour consumed on a survived hit?  In other words, if I put 3 points of ablative armor on a missile, does kill change remain at 25% (1/(1+3)) per point of damage sustained, or it go 25%, 33%, 50%, 100%?

- I am able to build missiles that move far more quickly than my best CIWS models or any reasonable turret design can match.   What is the penalty to hit if a CIWS system or turret cannot track as quickly as a target flies?

- It should be clearer what the power production and consumption of a ship is, and perhaps a warning should be given in Design Errors if there's not sufficient power.

- When I double-click on a new-built ship in the TG interface, and the Individual Unit Details interface appears, the ship doesn't show, because the window hasn't been refreshed.

- Task Groups:  When a TG copies orders to subordinate TGs, Cycle Moves should be changed to match.

- Having ships be set as subordinate TGs of the Tugs that last towed them is wrecking havor with my attempts to use the "copy orders command" to make moving about multiple tugs at once more practicable.

- Every so often a few of my civilian ships rebel and go pirate.   The problem is that 1) they do so right under the guns of my main battlefleet in my well-defended home system instead of in an underdefended region, and 2) they have the same nationality ID as the Precursors.
- It is possible that this happens when I mis-click the Transfer Fleet to Alien Empire button in Task Groups, but I thought I said NO when confirmation was requested.

- PDC, by default, are designed with x1 fuel tank (bug 1).   The tank doesn't get filled (bug 2), and generates error messages.   Similar comments apply to any ship or base with no engines; what should happen is that the fuel tank is filled regardless.   After all, it may be a fuel storage depot or have shields.   Extra credit if a warning indicator is given for ships with no engines or shield and useless fuel.

- TG interface:  When issuing orders to load or unload ground units, the ground units are displayed in a single list, with no indication of commanding HQ, fighting ability, morale, or strength.   As units are chosen, the list of available ground units is not updated (this last is a common problem with Aurora interfaces). 
- When units are chosen for transport that are commanded by an HQ, but not the HQ itself, the HQ continues to think that it commands units after they're gone, and therefore refuses to accept new units.   More generally, there are several ways to get an HQ to think it has subordinate units when it doesn't; the code involved needs to properly update in all cases where it doesn't yet.

- Messages:  I'm occasionally told that a TG has completed its order a great many times (10 or 20 repetitions of the same message).   This has happened with tankers, troop transports, TGs with cycling orders (but also those without)

- There should be a way (other than in Spacemaster) to scrap installations.

- When a geologic team is placed on an asteroid, they should not take too very long to find what's to be found and report completion.   At present, they take half of forever.

- It should be possible to not use any components when building a ship, to save them for other ships.

- The method for assigning TGs to TFs is extremely non-inuitive (it's also undocumented, as far as I can tell).

- I'd like to be able to rename civilian shipping lines.   Yeah, I know I don't control them, but they're part of my empire and I like their names to suit my theme.

- The level of armor tech should not have such an important impact on the cost of bulky ships.   This is especially noticable with orbital habitats; at Laminate Composite Armour tech level, no-frill stations with five orbital habitats and minimum armour spend more on the armour than they do on the habitats.   
- Let's cruch some numbers.   I want to run 60 mines on a planet hostile enough that buiding infrastructure is impracticable.   I have abundant people.   With LC Armor tech, and turbocharged civilian engines capable of putting out 312. 5 power each, my current or near-future build infrastructure allows me the option of building 500,000-person orbital habitats that can be towed at ~500 km/s by tugs sporting 85 of my max engines.   Cost of a habitat:  3650 PB.   Cost of a tug:  7,100 PB.   Habitat requirement to run 60 mines:  Approximately 8, for ~4 million people.   Total build cost of 60 mines, 1 tug, 8 habitats:  43,500 BP.   Total time to move all eight habitats for each one billion km distance from construction site to mine world: ~200 days (You can drop this to 100 days/1E9 km by raising total cost to 50,600 BP).
- Total cost of 60 automated mines and 6 25,000 cargo @ 4000 km/s freighters, at the same engine tech level:  20,700 BP  Total time for the ships to transport the mines, for each one billion km distance:  ~13-14 days.   Other advantages include reduced duranium and mercassium consumption, no population requirements, fewer soft targets, and decreased micromangement.   A disadvantage is increased corundium consumption.

- It should not be the case that a laser that draws 6 power per shot with a capacitor capable of restoring 5 fires once every 10 seconds.   This leads to designing weapons around the rules rather than their purpose.   The best way to fix this is to have much shorter combat pulses, a change requring the rethink of the present timing system (and some interface alterations).   A more modest fix is to simply allow capacitors to store a bit more energy, so such a weapon will only have to pause an extra 5 seconds to recharge 1 time in 5.

- Missile/Buoy Design:  I cannot get any MIRV design to release submunitions at a distance other than 150,000 km.   Whenever I specify a different Separation Range, it's reset to the default value after confirmation of design.   Closing the design window, reopening it, and looking at Previous Design shows the default separation value in all cases.   All of my designed MIRVS, intended to release submunitions at ranges varying from 5m to 21m km, in fact do so at 150k km.

- Task Groups:  When a order is given to load an HQ with sub-units attached, please confirm in the resulting orders list if only the divisional HQ is being loaded, or whether HQ+sub units is being loaded.
- Task Groups:  There should be an "unload all ship components order or option to the existing unload ship components order.


Combat:
- When a target is destroyed, all systems having that target should either switch targets (if orders call for this and a suitable target is available), or clear the target (otherwise).   Certainly, I should not be getting spammed with "unable to locate target" messages.

- Because the pace of the game picks up with tech, there should be a research path allowing faster ground unit builds.

- When a colony is abandoned, its governer has a blank assignment.   He should be unassigned instead.

- There is no way to reduce the size or number of slipways of a shipyard; would it be worth adding a Scrap Slipway command?

- Should the Boat Bay and Hanger techs be moved to the Construction category?

- Should there be ways to destroy jump gates?

- Should Gauss Cannon tech be under Missiles or Energy Weapons?

- Planetary bombardment may be too effective.   1 strike for 166 points of damage destroyed ~24,500 build points worth of installations, wrecked a brigade, and reduced the combat power of 2 divisions (42 units) by about 25%.   The readiness loss taken in seconds took more than a year to recover.

- Manage Shipyards:  The repair command should not have healthy ships (repair cost 0) as options.

- When building ground units, numbering should increment for each unit of that type, not each ground unit of any type.

- When missiles are swapped in launchers, there should be an extra delay imposed (you've got to switch sources and re-establish the loading routine, not just reload the launchers)

- In battle, contacts on the system map window often flicker off and on.   They should only visually disappear if contact is actually lost.

- Naval officers gain naval attributes over time; ground officers appear not to gain land attributes over time.

- Because of an NPC battle, turn increments went to 5-10 seconds for a while, then went to 60 seconds - and there it remained until my patience ran out, four real-world hours on a fast computer later.   In SM view, I get a message each turn increment saying that "Increment length adjusted because a ship is within firing range. "  Yes, I could ask for the DB password and try to fix the problem by deleting the offending ships, but the Aurora turn processing system is broken, this problem could recur at any moment, and there's only so much "working around" I'm prepared to do when not being paid.

Aurora has greatness - I haven't enjoyed a 4x space game so much in a long time - but the fun's at an end, for me, for a while.
 

Offline Thiosk

  • Commodore
  • **********
  • Posts: 784
  • Thanked: 1 times
Re: Core dump by new player (very long)
« Reply #1 on: May 29, 2011, 02:45:28 AM »
Whoosh, thats a text.

Quote
- Should there be ways to destroy jump gates?

I have decided that no, you should not.  I now consider the jumpgate as a stabilized wormhole-- jump gate ship flies up, stabilizes the wormhole, files on.  Nothing to blow up.

Is that canon?  No idea, but it sure explained to me why I would find stable jumpgates in uninhabited systems-- those wormholes are either naturally stable or previously stabilized by the nearby ruins.
 

Offline Steve Walmsley

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11658
  • Thanked: 20379 times
Re: Core dump by new player (very long)
« Reply #2 on: May 29, 2011, 05:02:19 AM »
Whoosh, thats a text.

I have decided that no, you should not.  I now consider the jumpgate as a stabilized wormhole-- jump gate ship flies up, stabilizes the wormhole, files on.  Nothing to blow up.

Is that canon?  No idea, but it sure explained to me why I would find stable jumpgates in uninhabited systems-- those wormholes are either naturally stable or previously stabilized by the nearby ruins.

Although I haven't stated it anywhere, the stablised jump point, rather than an actual physical jump gate, is how I tend to view it as well. Maybe I should make that canon. I'll give it some thought.

Steve
 

Offline Thiosk

  • Commodore
  • **********
  • Posts: 784
  • Thanked: 1 times
Re: Core dump by new player (very long)
« Reply #3 on: May 29, 2011, 01:39:29 PM »
As for the rest of the comments, theres some good stuff in there--

I think the majority of the most major things are what is typically discussed in the Aurora 2 thread.
 

Offline Polaris (OP)

  • Leading Rate
  • *
  • P
  • Posts: 9
Hyper Drives
« Reply #4 on: July 05, 2011, 10:29:16 PM »
Some interesting tidbits learnt when playing an empire that began on a planet orbiting a distant secondary star, 90 billion km from any jump point.


The Hyper Drive:  New Frontier of game abuse
- The check to prevent hyper drives being used near stars is only made if the order will both take the TG through a hyper limit line and complete within a non-hyper zone.   This misses some relevant situations.   A ship that starts in a non-hyper zone can immediately engage hyper drive (both by order and manually), and can complete any order at x10 speed within that same non-hyper zone or outside all non-hyper zones, just not in a different non-hyper zone.   A ship passing through a non-hyper space can continue to engage hyper drive, however often it crosses a hyper limit line, as long as the order destination is outside a hyper limit.   This means that a hyper-capable fleet can (almost) always be at x10 speed, anywhere.   Even the automatic turning off of hyper drive when transiting a jump gate can be overcome by turning on hyper drives at the far side of the jump gate (manual method required if within a hyper limit).
- Fuel consumption when in hyper drive is 1/9th normal, per unit time.   Per unit distance, it is 1/90th normal.   (this apparently varies, perhaps with efficiency tech; more advanced engines had 2/21th the consumption per unit time)  This does seem a bit generous.
- Oddly, however, a hyper-capable ship is not allowed go into hyperspeed, by order or manually, if hauling another ship at the time the order was input, even if that other ship has no engines or has them turned off.   It will, however, stay in hyperspace when tractoring another ship.   It will also understand and execute  queued orders to first tractor another ship, than enter hyperspace.   These last two rules are much appreciated, because otherwise using hyper-capable tugs  would be impracticable.
- Ironically, the opposite is also true.   I moved an entire non-hyper-capable battlefleet with hyper-capable tugs.   When released and recombined, the fleet had hyper drive engaged and was moving at a rate of speed that rendered it almost invincible in battle.
- A second, related issue:  I figured out that Aurora allows a fleet to haul as many ships as it has tractor-equipped ships (much appreciated), but then discovered that, when the tugs were in hyper drive, the game was still allowing the towed fleet to contribute its non hyper-capable engines to boost overall speed.   Consider not just disallowing this obvious no-no, but having the engines of towed ships contribute nothing to overall propulsion.
- The current requirement to explicitly engage hyper drive, combined with the lack of automatic visual aids when plotting a course through multiple systems makes setting up long-range routes (moving asteroid mining bases, collecting minerals, etc. ) very tedious.   There is a much-appreciated automatic route finder (Task Groups->Task Group Orders->Show All Pops checkbox), but it doesn't understand hyper drives.   I suspect this means that the AI doesn't either.
- Civilians also do not understand hyper drives.    This is probably because they plot directly from world to world.   If an important world is in far space, this can easily lock up the entire trading system.
- The Task Group window's Time and Distance display does not take hyper drive into account.

Proposed hyper drive rules:
1.   A TG or attached subgroup that can move faster in hyper drive will automatically engage hyper drive when possible, and turn it off when not.   The player is given a checkbox that provides the option to turn this behavior off.
2.   Hyper drive cannot be engaged or sustained in non-hyper space.   If practicable, non-hyper space should include a zone around all bodies with masses 10% of earth's or greater.
3.   Hyper drive uses either 1. 5x the fuel per unit time, or the same multiplier as tech engine size.
4.   Ships in hyper drive cannot fire any weapon, energy, physical, or missile.   Perhaps they should also be harder to hit with missiles.
5.   Hyper drive takes a small but non-zero amount of time (perhaps 1 hour) to engage (and perhaps also disengage).

 

Offline Polaris (OP)

  • Leading Rate
  • *
  • P
  • Posts: 9
And to close.
« Reply #5 on: July 05, 2011, 10:30:41 PM »
. . .  And some parting, mostly minor, thoughts.


- The System Map shows the first Deep Space Tracking Station on a body as having 1/2 the range of an equivalent shipboard sensor.   Population and Production -> Summary shows DSTS strength as being linear with #DSTS * tech multiplier, but the System Map claims that if any DSTSs exist, then detect range in km = (20*exp(0. 223*#DSTS)) * target emission * 10000.   Tech has no visual effect whatsoever.   Get enough DSTSs in the same place, and the game will generate an overflow message then you request to see Passive Sensor Ranges on the System Map.
- What really happens?  The System Map is wrong and the Summary right.   Detect range in km = #DSTS * tech multiplier * target emission.

- Missiles do not know how to intercept a moving target except by heading towards its current location.   A ship in hyper drive may easily be uncatchable, even it doesn't manoeuver.

- Missile transfer ought to take time.   My PDCs and orbiting fleets need only small magazines because I can instantly (in game time, not mine!) reload them from population stockpiles.

- It would be neat if a ship or base could be designated a location for the purposes of TG orders (perhaps only if stopped, perhaps even if moving).   Fuel, munitions, ores, even infrastructure could be stored and redistributed.   Would help with managing supply routes that cross hyper limits as well.

- May we be able to rename waypoints, please?

- System View, Display 2 tab:  The option "Asteroids with colonies only" hides asteroids with fleets orbiting them, even if they are in colonized (case of mining colonies with asteroid miners orbiting them).

- It's a pity that civilian admin terraforming bonuses don't apply to ship-borne modules.

- Geological team surveys of chunks and asteroids take an inordinate amount of time.   Surveys of chucks should take less time, and as at present yield fewer resources, than surveys of terrestrial worlds, and asteroids and comets should take and offer even less.

- Somewhere in the economy window ought to be a planetary type indicator.   It should be easier to avoid choosing a world asteroid miners can't work on.   Related comment for the Geological Survey Report:  selecting Asteroids should also show comets.
- The list of colonies in that window needs sorting tools, because it rapidly gets difficult to find places in this essential interface.   At a minimum, the list of worlds without mines or population should be sorted by star, and it would also help if worlds without mines but with orbiting asteroid mining modules were placed together.

- Virtually all - 99. 5% or more - of all asteroids aren't worth mining.   Consider having fewer asteroids, fewer asteroids with minerals, but more asteroids with quantities large enough to be worth the bother of mining.   Having standing orders for a TG to Mine out Ore, then Go to Next Body would be helpful, if combined with a less time-consuming method of gathering in ore from scattered sources.   Perhaps all asteroid miners with cargo bays should fill those bays with mined ore, then leave the rest on the planet's surface.

- When a colony is abandoned, minerals on the surface (actually anything not obviously requiring maintainance) should not vanish.

- HQs ought to be trainable.   At a minumum, there should be some way for them to become less likely to be destroyed.   Also, does it benefit  game play make them so time-consuming to build?  In Aurora, training high morale ground units is a work of decades, which seems awfuly long.   Better to impose expense in extra leadership and/or resources.

- When issuing an automatic route order using the Show All Pops checkbox, the list of bodies, JPs, etc.  is not updated when the order is issued.

- Balance issue:  The cost to develop and build jump engines seems quite high compared to the cost of building jump gates.   Either the first should be less costly, or jump gates need a nerf (Can be destroyed, perhaps?).

- Why are geological sensors civilian, but gravitational sensors military?

- It should take no minerals to assemble a PDC.   Quite apart from the oddity of requiring more matter to build the same thing, it obligates players to transport a variety of goods for no particularly good reason.

- It can happen that damage to an engine (example:  maintainance failure) doesn't reduce current TG speed.   Maximum drops, but not necessarily current.

- Active sensors could stand a little range nerfing.

- Consider rethinking mineral accessibility in terrestrial-sized worlds.   It's easiest to achieve balance between production and consumption of a resource if it takes about as much effort to obtain one unit of each.   At present, one mine feeds about one factory, given high accessibility and a decent mix of TN elements including enough Duranium.   Most mineral-bearing worlds don't meet one or the other of these requirements.   If the mine is an Automated Mine, the usual case on worlds that aren't asteroids or comets, it costs twice what a factory does.   Shipyards, ordinance, fighters, and ground units also consume minerals.   So we're already seeing an imbalance. 
- Now throw in accessibilities of 0. 1 or 0. 2 into the mix, then combine the current mining rules with low mineral diversity, and you've got some balance issues.   We're talking five or ten times the investment in mines to feed a given amount of resource-consuming activities.
- Similar comments about wealth generation and expenditure.

- If you click Task Groups ->  Special Orders / Organization -> Transfer Fleet to Alien Empire by accident, then the fleet will be transferred whether you confirm or cancel.
- There's no reason for a non-SM player to be able to assign fleets to a hostile empire.   I don't need that pistol to shoot myself in the foot, thanks.

- I designed a fighter engine with x1. 4 size hyper drive.   The size remained 50 tons and the cost didn't budge.   Here, as elsewhere, the game should calculate to the nearest 5 tons at least.

- I attempted my first boarding action.   Six marine companies, in as many dropships moving at 31K km/s, against a large civilian freighter (one of those I accidentally transferred) moving at about 3000 km/s and with a crew of 2000.   This was an operation that deserved to succeed, in my opinion, but didn't even come close.   The massacre of the marines was so quick and complete that I'm not sure that ten times as many could have taken the objective.   Given that there are no weapons that can preferentially target drives, and drives are the most durable components on most civilian ships, I humbly suggest a rebalance.
 

Offline Steve Walmsley

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11658
  • Thanked: 20379 times
Re: Core dump by new player (very long)
« Reply #6 on: July 16, 2011, 05:17:14 AM »
I will go through all of the above points and reply at some point. Just haven't had the necessary time lately.

Steve
 

Offline Polaris (OP)

  • Leading Rate
  • *
  • P
  • Posts: 9
Re: Core dump by new player (very long)
« Reply #7 on: July 20, 2011, 04:37:37 PM »
Quote from: Steve Walmsley link=topic=3630. msg37045#msg37045 date=1310811434
I will go through all of the above points and reply at some point.  Just haven't had the necessary time lately.

Steve
I have to again apologize for the length.   I personally need responses to nothing - if anything seems off, just ignore it.   :)
 

Offline ardem

  • Rear Admiral
  • **********
  • a
  • Posts: 814
  • Thanked: 44 times
Re: Core dump by new player (very long)
« Reply #8 on: July 21, 2011, 03:15:09 AM »
- Balance issue:  The cost to develop and build jump engines seems quite high compared to the cost of building jump gates.   Either the first should be less costly, or jump gates need a nerf (Can be destroyed, perhaps?).

I disagree with this one, since Jump Gates cannot be destroyed they are open portals to your enemies as well, it is very risky just to build jump gates everywhere what points you are gaining on jump ships you losing on defences and sensors for those jump gates, especially when you find some very nasty enemies.

- It should take no minerals to assemble a PDC.   Quite apart from the oddity of requiring more matter to build the same thing, it obligates players to transport a variety of goods for no particularly good reason.

Thats like saying it should not take any more materials to put together a prefab house, but problem is it does, materials used for construction, materials used for safety and a whole range of materials used for various things. I personally like to think Prefab is not 100% complete just 90% there with the rest done when onsite.
« Last Edit: July 21, 2011, 03:21:18 AM by ardem »
 

Offline voknaar

  • Lt. Commander
  • ********
  • Posts: 201
Re: Core dump by new player (very long)
« Reply #9 on: July 21, 2011, 03:28:00 AM »
Someones gotta dig the secret giant underground bunker that doesn't exist in official reports :)
 

Offline Soralin

  • Petty Officer
  • **
  • S
  • Posts: 19
Re: Core dump by new player (very long)
« Reply #10 on: July 21, 2011, 04:05:10 AM »
- It should take no minerals to assemble a PDC.   Quite apart from the oddity of requiring more matter to build the same thing, it obligates players to transport a variety of goods for no particularly good reason.

Thats like saying it should not take any more materials to put together a prefab house, but problem is it does, materials used for construction, materials used for safety and a whole range of materials used for various things. I personally like to think Prefab is not 100% complete just 90% there with the rest done when onsite.
You could always put that on the end building the thing though, make building pre-fab stuff take more resources, and take the increased size into account in how many modules it takes, etc.  It could be nothing more than the equivalent of packing a bunch of extra minerals or assembly equipment or such in to use at the far end in building it.  It's pretty much exactly the same thing, but it would make things a bit easier on micromanagement to do it that way rather than having to figure out how many minerals of each type you need, and load them on to the transport separately.  Plus it would mean they can be made to fit nicely and evenly into a transport.
 

Offline Thiosk

  • Commodore
  • **********
  • Posts: 784
  • Thanked: 1 times
Re: Core dump by new player (very long)
« Reply #11 on: July 21, 2011, 06:13:12 AM »
I think thats a better idea.  Tasking the ship to deliver minerals is trivial, which is exactly why its annoying.  Even ikea sends you an allen wrench.  One already has to babysit #of sections and engineering brigade transport to move them around.
 

Offline Polaris (OP)

  • Leading Rate
  • *
  • P
  • Posts: 9
Re: Core dump by new player (very long)
« Reply #12 on: October 24, 2011, 04:47:06 PM »
A missile design spreadsheet was made available earlier at
www. megaupload. com/?d=CJNSP716

It continues the good work so kindly made available at:
https://spreadsheets0. google. com/spreadsheet/ccc?authkey=CImjy-8G&hl=en&key=tsW-t_hfarNRG2kO91LK_VQ&hl=en&authkey=CImjy-8G#gid=2

Changes:
- Distinct handling of anti-ship and anti-missile designs.   The first optimizes survivability and hitting power, the second optimizes hit chance.
- Various new knobs to fiddle in order to model a particular challenge and find the perfect counter.
- Fine-tuning of various equations to better fit Aurora's internal calculations.


Please feel free to share all further developments.
 

Offline Person012345

  • Captain
  • **********
  • Posts: 539
  • Thanked: 29 times
Re: Core dump by new player (very long)
« Reply #13 on: October 24, 2011, 06:07:15 PM »
Just a point.  Civilians are SUPPOSED to be uncontrollable.  A company thinks it's a good idea to set up a colony on a methane-filled, 1000 degree heat planet? Fine, ignore them and take the taxes/buy their resources.

Although, the ability to manipulate civilian property more under certain types of government might be interesting.
 

Offline Din182

  • Sub-Lieutenant
  • ******
  • D
  • Posts: 145
Re: Core dump by new player (very long)
« Reply #14 on: October 24, 2011, 06:30:50 PM »
A missile design spreadsheet was made available earlier at
www. megaupload. com/?d=CJNSP716
This spreadsheet is really glitchy. The one at https://spreadsheets0.google.com/spreadsheet/ccc?authkey=CImjy-8G&hl=en&key=tsW-t_hfarNRG2kO91LK_VQ&hl=en&authkey=CImjy-8G#gid=2 is far better. It only makes anti-missile missiles, but if you want anti ship missiles, just decrease the agility while improving other things until you get the to-hit you want.
Invader Fleet #13090 has notified Fleet Command that it intendeds to Unload Trade Goods at Earth!