Aurora 4x

VB6 Aurora => Aurora Suggestions => Topic started by: Kurt on November 24, 2008, 01:00:01 PM

Title: Suggestions for 3.3
Post by: Kurt on November 24, 2008, 01:00:01 PM
Steve-  

I was transferring fuel around in one of my expploration squadrons when I encountered this annoying little feature.  One the "Individual Units Details" screen, on the "miscellaneous" tab, while transferring fuel, I noticed that every time I hit the "transfer to" or "transfer from" button the target of the transfer reset to the first ship on the list.  As a result of this I kept transferring fuel from the wrong ship every time I forgot that this reset.  It would be nice if the target of the transfer remained the same until I rest it.  

Kurt
Title: Re: Suggestions for 3.3
Post by: Steve Walmsley on November 26, 2008, 07:03:13 AM
Quote from: "Kurt"
Steve-  

I was transferring fuel around in one of my expploration squadrons when I encountered this annoying little feature.  One the "Individual Units Details" screen, on the "miscellaneous" tab, while transferring fuel, I noticed that every time I hit the "transfer to" or "transfer from" button the target of the transfer reset to the first ship on the list.  As a result of this I kept transferring fuel from the wrong ship every time I forgot that this reset.  It would be nice if the target of the transfer remained the same until I rest it.  
Fixed for v3.3

Steve
Title: Re: Suggestions for 3.3
Post by: Kurt on November 28, 2008, 11:42:48 AM
Steve -

Recent events in my campaign have had me considering the repair situation in Aurora.  Now, I admit that maybe I'm doing something wrong, but it seems to me that repairs are problematic.  After all, damaged ships have to sit at the planet with the shipyards, waiting for a slipway at a shipyard of the proper size to clear before it can be repaired.  This may take years if it is a larger ship, as pausing construction on a new ship just stops construction, it doesn't make that slipway available for use for repairs or anything else.  That means that your only choice is to cancel construction or wait for the new ship to be launched.  

That got me to thinking about possible alternatives, and several come to mind.  First off, how about specialized slipways just for repair.  They would have the same capacity limitations as regular slipways, but wouldn't be specialized for a single class, and would only be able to do repairs (or maybe refits as well).  They would be much cheaper than regular slipways, because they are less useful.  A government might not have any of these during peace, but during war they would be very useful to have, as damaged ships wouldn't be clogging up the yards.  

Another possibility is a repair module, that would use maintenance supplies to repair battle damage.  

Or, you could change things so that pausing a new construction order would free up that slipway to do something else, so that repairs could be initiated immediately without having to cancel the new construction or wait for the ship to be launched.  

I'm sure there are other possibilities, I am just looking for a way around the bottleneck.  

Kurt
Title: Re: Suggestions for 3.3
Post by: waresky on November 30, 2008, 04:44:49 PM
Steve,ur "game" are far from "simplicistic" right?...so..
whynot setup an "hard realistic" option: FOG real map..

i mean: when u enter in another system u dont know anything,u not know every planet position..and final u NOT know HOW many planet are in a system.
In a "fog" situation u MUST setup a real survey mission,visual distance for "spotting" a planet or have a right "sensor for "ping" on a map,with a "?" dot on map..

hope u have understand whatever am mean..
Are more "thrilling" enter in a system REAL unknow.
Do u remember Megatraveller yeah? an Squadroon need to Gas Giant or H2O for refuel..BUT..r sure u found in a system?and EXIST a planet or gas giant?
For me this "fog" are more exiting than enemy encounter...

Hope have an "options" same in a 3.3
Title: Re: Suggestions for 3.3
Post by: kdstubbs on November 30, 2008, 08:56:02 PM
Essentially the concept of a repair dock works.  The US Navy for example has a mobile dry dock, which is capable of handling up to an 80,000 ton ship.  We used it to move the USS Stark from the Middle East back to the ship yard for repairs.  The idea of a dry dock would allow you to have any ship come into the way, conduct repairs and then refloat or relaunch the ship back into space.  It does not build ship, it simply allows you to make fast repairs to damaged ships.  

In Starfire, I usually build a fast mobile shipyard or machine shop into a large hull, so I can conduct repairs forward.  Under Aurora I would image a space dock would allow you to place the equivalent of a dry dock in space.  The facility would only allow for a ship to dock inside, provide shirtsleeve environment for repair, and then pump out all the air, and relaunch the ship.  This would allow you to repair armor damage or do major overhauls that do not require a full shipyard.  

Just a follow up on Kurt's idea
Title: Re: Suggestions for 3.3
Post by: backstab on November 30, 2008, 09:56:55 PM
Steve-

Will it be possable to split your ground foces into groups and have them attack different empires/nations on the same planet and maybe hold some back as reserves ????
Title: Re: Suggestions for 3.3
Post by: schroeam on December 01, 2008, 12:13:15 AM
Since we've determined that the ship's don't actually stay in orbit unless you put them there, maybe just allow the maintenance facilities to take care of all repairs and overhauls unless damage is too great.  Say, for example, the majority of the ship is gone, yet somehow it didn't blow up, it would require an actual shipyard to repair, or rebuild as it would be, but if it came home under it's own power then the maintenance facility could handle it.  The U.S. Navy tries to do as much repairs outside of drydocks as possible... too much $$$ involved.  It may come down to allowing the MF to handle the repairs, and allowing the shipyard to do the repairs, and letting the player decide what level of damage a shipyard is required.

Adam.
Title: Re: Suggestions for 3.3
Post by: Kurt on December 02, 2008, 01:13:27 AM
Quote from: "backstab"
Steve-

Will it be possable to split your ground foces into groups and have them attack different empires/nations on the same planet and maybe hold some back as reserves ????

Okay, this is my third attempt to post this message.  This morning I think I took too long and it timed out when I tried to post it, and just now I started writing this, then decided I needed to do some research, so I copied what I had written, did my research, then came back and the texted that I had copied was gone.  The third time is either going to be a charm, or I give up.   :D

Backstab's post above got me thinking about ground combat, something I have been pondering on and off for some time, especially given the likely importance that it may have in my campaign.  The suggestion above crystalized some ideas that have been bouncing around in my head for a while.  The changes I'm thinking of are taken from some of the strategic level games I've played in the past, and I think that they will give ground combat in Aurora more of an interesting dimension.  

Working from Backstab's suggestion and the strategic games I mentioned, I suggest the creation of "assignment areas".  A nation would have a "Strategic Reserve", and a "Border Area" for each nation on the planet.  If there are no other nations, then there is only the Strategic Reserve.  If there are five other nations, then there is the reserve and five border areas, one for each other nation.  Ground troops have to be assigned either to the reserve, a PDC (like the reserve but sheltered from orbital bombardment), or a border area.  A ground unit has to be given an order to move from one area to another, and ground units cannot move from one border area to another.  They have to go to the reserve first, then to which ever border area they are needed.  This setup simulates actual physical locations, but at a strategic level without having to worry about maps and actual locations.  A system like this also gives the player a lot of options for strategy, as real decisions need to be made between forward deployment and reserves.  Also, instead of having one large mass of troops available for defense against any enemy, a nation with multiple opponents will have to decide how to allocate its troops depending on the threat level of each nation.  Of course, units can only attack the nation "adjacent" to the border area they are assigned.  

A nation attacking another nation would only have to face the ground units actually assigned to its "border area".  Of course, both nations will be able to move units from the reserve to their threatened border, but if one surprises the other it could possibly destroy most of the defending units in the border area and do some damage to the defending nation before it can move units into the threatened area.  

Along these same lines I'd like to suggest adding the ability to give units different orders.  Implicit in the suggestion above are movement orders, but I'd like to see different combat orders as well.   The type of orders a unit can use would be dependent on the type of unit.  The following are the ones I can come up with off of the top of my head:

1.  Entrenched defense (Infantry only, adds to defense strength)
2.  Anti-partisan (garrison and infantry, adds to police value, reduces attack value)
3.  All out assault (all except garrison, requires morale of +80, adds to offensive strength, reduces defense strength)
4.  Penetration Assault (Armor only, requires morale of +80, reduces morale rendering a unit incapable of attacking)

All units with no orders are considered to be "Defending" with no stat adjustments.  There more commands, I know, but that is all I can think of for now.  

An ambitious change, I know, but something along these lines would add a lot.  

Kurt
Title: Re: Suggestions for 3.3
Post by: welchbloke on December 02, 2008, 07:01:28 AM
I like this suggestion but I guess the coding changes would be significant.  If this change did go through, can I suggest that there should be some kind of intelligence to suggest if additional units move into an adjacent border area?  I would have thought that the movement of large bodies of troops would attract some attention and might concern the nation that suddenly has several corps of troops arrive on its border  :D

Welchbloke
Title: Re: Suggestions for 3.3
Post by: Shinanygnz on December 02, 2008, 04:48:56 PM
What about installations?  Are they going in the strategic reserve area, randomly to different areas or assumed equally spread?  Just one area for an wholly owned planet is going to make an assault very hard.  Why should these areas go away when there's noone to occupy them then reappear if someone invades?

However, I do like the concept a lot and I think Steve should expand on it and go ahead and add ground locations to planets based on size.  Start with 1 on a comet/asteroid then more based on surface area.  Pick the number carefully (or make it user configurable) so you can have the multi-race to a planet start, with each owning x bits of y total.  Ground units are then in a set place, with a movement speed.  Installations could even be randomly set in a location and you might be able to pick off an enemy's shipyard or main mining site.
No need to mess around with terrain types IMO though.

You could add "drop infantry" (or armour, we're talking TNE after all) to allow you to attack an area from troop ships in orbit, i.e. without having to land them with ships and those then being put at risk.

Would certainly make ground assaults more interesting and fun, e.g. you hit an area and the defenders move their reserve over to attack it, then you drop your real attack the other side of the planet, only to find a hidden PDC or two full of more defenders you were previously unaware of.
Seeing as we have individual ship armour block records, I don't see a sensibly sized planetary "map" as a massive administrative or record keeping burden and it's not something we'll need to use all the time.

Btw Steve, can we have an upgrade or scrap task for Low Tech units please?

Stephen
Title: Re: Suggestions for 3.3
Post by: James Patten on December 03, 2008, 06:32:46 AM
Quote from: "Shinanygnz"
Btw Steve, can we have an upgrade or scrap task for Low Tech units please?

I agree to the upgrade (we can already scrap them).  I hate that I cannot upgrade the 101st Airborne or 10th Mountain Divisions.
Title: Re: Suggestions for 3.3
Post by: IanD on December 04, 2008, 07:54:05 AM
adradjool wrote
Quote from: "adradjool"
The U.S. Navy tries to do as much repairs outside of drydocks as possible... too much $$$ involved. It may come down to allowing the MF to handle the repairs, and allowing the shipyard to do the repairs, and letting the player decide what level of damage a shipyard is required

Should there be a Fleet base installation?

A Fleet Base could produce some maintenance supplies, perhaps equivalent to 5-10 maintenance facilities, but could also allow overhauls and minor refits (e.g. those for which a shipyard does not have to retool for, but perhaps take a little longer than a shipyard). A Fleet Base could repair some damage, say up to a third of the ship, or only internal systems and up to half the engines, and again possibly take longer than a shipyard. It would only be transportable as prefabricated modules and once constructed would not be moveable. It would require an indigenous population. But it would allow the creation of a network of distant fleet bases, without having to construct shipyards in those distant systems, which some political systems might like. It would also emulate the naval bases the British Empire scattered across the globe and it would look good to see your network of bases on the Galactic display.

Regards
IanD
Title: Re: Suggestions for 3.3
Post by: Steve Walmsley on December 04, 2008, 11:00:51 AM
Quote from: "Kurt"
Steve -

Recent events in my campaign have had me considering the repair situation in Aurora.  Now, I admit that maybe I'm doing something wrong, but it seems to me that repairs are problematic.  After all, damaged ships have to sit at the planet with the shipyards, waiting for a slipway at a shipyard of the proper size to clear before it can be repaired.  This may take years if it is a larger ship, as pausing construction on a new ship just stops construction, it doesn't make that slipway available for use for repairs or anything else.  That means that your only choice is to cancel construction or wait for the new ship to be launched.  
Don't forget that ships can repair themselves with access to sufficient maintenance supplies. Set up your damage control queue and when you (frequently) run out of supplies, load some more from the planet below. This is obviously a lot easier at a planet with maintenance supplies or else you wil run out very quickly.

Quote
That got me to thinking about possible alternatives, and several come to mind.  First off, how about specialized slipways just for repair.  They would have the same capacity limitations as regular slipways, but wouldn't be specialized for a single class, and would only be able to do repairs (or maybe refits as well).  They would be much cheaper than regular slipways, because they are less useful.  A government might not have any of these during peace, but during war they would be very useful to have, as damaged ships wouldn't be clogging up the yards.  Another possibility is a repair module, that would use maintenance supplies to repair battle damage.  
I do intend to create a repair module at some point, or maybe just allow one ship to use its damage control to repair another ship. A ship with a high damage control rating and a lot of maintenance supplies will do the job very quickly (probably too quickly :))

Steve
Title: Re: Suggestions for 3.3
Post by: Steve Walmsley on December 04, 2008, 11:09:20 AM
Quote from: "waresky"
Steve,ur "game" are far from "simplicistic" right?...so..
whynot setup an "hard realistic" option: FOG real map..

i mean: when u enter in another system u dont know anything,u not know every planet position..and final u NOT know HOW many planet are in a system.
In a "fog" situation u MUST setup a real survey mission,visual distance for "spotting" a planet or have a right "sensor for "ping" on a map,with a "?" dot on map..

hope u have understand whatever am mean..
Are more "thrilling" enter in a system REAL unknow.
Do u remember Megatraveller yeah? an Squadroon need to Gas Giant or H2O for refuel..BUT..r sure u found in a system?and EXIST a planet or gas giant?
For me this "fog" are more exiting than enemy encounter...

Hope have an "options" same in a 3.3
I have considered this in the past. The main problem is performance, because I would have to create a list of all systems bodies known by each race and check that every time a list of system bodies was accessed (such as system map, galactic map, fleet window, system view window, etc). This would even add some performance lag if you were using it because for each system body I would have to check whether I needed to check :) or duplicate the code with the checks in. Duplicate code always leads to errors later. A secondary issue is that the events log would be filled with "planet discovered" events and my final concern is that while this would be fun at first it would eventually get tedious, especially if you have to keep sending geosurvey ships back to check out new planets. However, that doesn't mean I won't add it at some point as an optional rule. I think it would add an extra dimension for those players who wanted that level of detail.

Steve
Title: Re: Suggestions for 3.3
Post by: Brian Neumann on December 04, 2008, 05:56:46 PM
Quote from: "Steve Walmsley"
I do intend to create a repair module at some point, or maybe just allow one ship to use its damage control to repair another ship. A ship with a high damage control rating and a lot of maintenance supplies will do the job very quickly (probably too quickly :))

Steve

How about averaging the damage control of the repair ship with the damaged ship.  This would keep it from reparing things to fast.  Also have it use twice the maintenance (one for each ship) to simulate the expense involved.

Brian
Title: Re: Suggestions for 3.3
Post by: Brian Neumann on December 13, 2008, 04:44:46 AM
How about the ability to make a waypoint that moves.  Designate the waypoint as a set distance and direction from a target.  Basically the same idea as escort ships use now, only in reverse.  This would allow for a missile attack where the missiles loiter near the target, but as the target moves they keep up with it.

Brian
Title: Re: Suggestions for 3.3
Post by: Cassaralla on December 16, 2008, 10:58:44 AM
How about the ability to designate old outdated ships as target hulls for gunnery practice?

Doing so would take the crew off the ship and it could then be towed into empty space and used for testing weaponry on.  Of course it wouldn't have any active defences but it would at least give folks a chance to test their weapons in live fire exercises, to see how crews perform or how effective current missiles and beam weapons are against armour etc.
Title: Re: Suggestions for 3.3
Post by: Father Tim on December 17, 2008, 02:17:54 PM
Quote from: "Cassaralla"
How about the ability to designate old outdated ships as target hulls for gunnery practice?

Doing so would take the crew off the ship and it could then be towed into empty space and used for testing weaponry on.  Of course it wouldn't have any active defences but it would at least give folks a chance to test their weapons in live fire exercises, to see how crews perform or how effective current missiles and beam weapons are against armour etc.

Create a race with 0 pop, call them 'Target Practice', and transfer your ship to them.  Your crew will be removed and a crew of the appropriate grade will placed aboard (consider them the 'rules' your military's umpires are using to score the live-fire exercise).  Now blow them away at your convenience.
Title: Re: Suggestions for 3.3
Post by: Cassaralla on December 18, 2008, 02:25:20 PM
I guess I can do it that way then.  I just like the idea of designating an old flagship as the testing target for the next generation of ships and weapons.
Title: Re: Suggestions for 3.3
Post by: Erik L on December 18, 2008, 05:58:49 PM
I'd like to see a combined "resupply" conditional order. Refuels and resupplies.
Title: Re: Suggestions for 3.3
Post by: Erik L on December 19, 2008, 02:18:20 PM
As an option, have an officer reassigned on promotion.
Title: Re: Suggestions for 3.3
Post by: James Patten on December 26, 2008, 06:28:28 AM
It would be nice to have a way to review racial tech items once created.  Items such as missiles (what kind of sensor and armor do I have), engines (75% or 50% Thermal Signature Reduction), or energy weapons.  Maybe a view-only version of the tech creation window with that item in it?
Title: Re: Suggestions for 3.3
Post by: Hawkeye on December 26, 2008, 06:56:15 AM
This is on the Tech Review Screen (CTRL+F7)
Title: Re: Suggestions for 3.3
Post by: Kurt on December 28, 2008, 08:30:00 PM
Steve -

Just a little suggestion based on the 6 Powers Campaign.  I was having a problem that I was convinced was a bug.  Ships were getting "stuck", not arriving when they were supposed to, using up their supplies, and so on.  The first couple of times I figured I screwed something up, and then I realized that this was happening more than once.  Then I realized that it was happening in the same system over and over again.  I figured that Aurora was glitched and that this system was the Bermuda Triangle of space.  

I started documenting the problem, and when it cropped up the second time after documenting it in the same system I figured I had enough to declare a problem and I was set to ask you if I could send you the database so you could diagnose the problem.  Then I did a little more checking by opening the system map, and lo and behold, it was a nebula system!  Right there on the map was the notation that ships could only travel at a certain speed depending on their armor.  Doh!  That was the explanation!  

Now, I knew that nebulas limited speed, and I knew that this system had a nebula, but I didn't put the two together, because on the Task Group screen the group still was apparently maintaining its maximum speed and its ETA was based on this fictional, unobtainable speed.  It would be nice if the group's real maximum speed was reflected on the Task Group screen, along with its real ETA.  

Kurt
Title: Re: Suggestions for 3.3
Post by: SteveAlt on December 29, 2008, 06:34:44 AM
Quote from: "Erik Luken"
As an option, have an officer reassigned on promotion.
I was wondering if rather than using the current reassignment method where every officer runs on his own individual tour length and can only take assignments that are free at that point, I should reassign every officer at the same time, say Jan 1st every two years (or whetever tour length is set by the player), so that officers are distributed to assignments more accurately.

Steve
Title: Re: Suggestions for 3.3
Post by: SteveAlt on December 29, 2008, 06:39:28 AM
Quote from: "Kurt"
Steve -

Just a little suggestion based on the 6 Powers Campaign.  I was having a problem that I was convinced was a bug.  Ships were getting "stuck", not arriving when they were supposed to, using up their supplies, and so on.  The first couple of times I figured I screwed something up, and then I realized that this was happening more than once.  Then I realized that it was happening in the same system over and over again.  I figured that Aurora was glitched and that this system was the Bermuda Triangle of space.  

I started documenting the problem, and when it cropped up the second time after documenting it in the same system I figured I had enough to declare a problem and I was set to ask you if I could send you the database so you could diagnose the problem.  Then I did a little more checking by opening the system map, and lo and behold, it was a nebula system!  Right there on the map was the notation that ships could only travel at a certain speed depending on their armor.  Doh!  That was the explanation!  

Now, I knew that nebulas limited speed, and I knew that this system had a nebula, but I didn't put the two together, because on the Task Group screen the group still was apparently maintaining its maximum speed and its ETA was based on this fictional, unobtainable speed.  It would be nice if the group's real maximum speed was reflected on the Task Group screen, along with its real ETA.  
I added the correct speed on the system map for v3.2. I'll add the correct speed and ETA to the task group window for v3.3

Steve
Title: Re: Suggestions for 3.3
Post by: Kurt on December 29, 2008, 06:44:55 AM
Quote from: "SteveAlt"
Quote from: "Kurt"
Steve -

Just a little suggestion based on the 6 Powers Campaign.  I was having a problem that I was convinced was a bug.  Ships were getting "stuck", not arriving when they were supposed to, using up their supplies, and so on.  The first couple of times I figured I screwed something up, and then I realized that this was happening more than once.  Then I realized that it was happening in the same system over and over again.  I figured that Aurora was glitched and that this system was the Bermuda Triangle of space.  

I started documenting the problem, and when it cropped up the second time after documenting it in the same system I figured I had enough to declare a problem and I was set to ask you if I could send you the database so you could diagnose the problem.  Then I did a little more checking by opening the system map, and lo and behold, it was a nebula system!  Right there on the map was the notation that ships could only travel at a certain speed depending on their armor.  Doh!  That was the explanation!  

Now, I knew that nebulas limited speed, and I knew that this system had a nebula, but I didn't put the two together, because on the Task Group screen the group still was apparently maintaining its maximum speed and its ETA was based on this fictional, unobtainable speed.  It would be nice if the group's real maximum speed was reflected on the Task Group screen, along with its real ETA.  
I added the correct speed on the system map for v3.2. I'll add the correct speed and ETA to the task group window for v3.3

Steve

Thank you!  Gradually, you are limiting my ability to do stupid things  :D

Kurt
Title: Re: Suggestions for 3.3
Post by: ZimRathbone on December 29, 2008, 07:21:17 AM
Quote from: "SteveAlt"
Quote from: "Erik Luken"
As an option, have an officer reassigned on promotion.
I was wondering if rather than using the current reassignment method where every officer runs on his own individual tour length and can only take assignments that are free at that point, I should reassign every officer at the same time, say Jan 1st every two years (or whetever tour length is set by the player), so that officers are distributed to assignments more accurately.

Steve

That is sort of the way it works in the ADF, and is known as MIMO (March In, March Out).   The vast majority of moves happen at roughly the same time (within a month or so) , every 3rd year has a bit of a spike as more personnel change posting (about 60% more than the other two years).  

I would suggest setting the code to ensure that all tours end before assigning any new officers, as it makes it less likely that the same officer gets reassigned to the same post again, and again and yet again (my current max is the same officer assigned to the same ship for 6 two year tours in sucession).
Title: Re: Suggestions for 3.3
Post by: SteveAlt on December 29, 2008, 08:24:04 AM
Quote from: "ZimRathbone"
Quote from: "SteveAlt"
Quote from: "Erik Luken"
As an option, have an officer reassigned on promotion.
I was wondering if rather than using the current reassignment method where every officer runs on his own individual tour length and can only take assignments that are free at that point, I should reassign every officer at the same time, say Jan 1st every two years (or whetever tour length is set by the player), so that officers are distributed to assignments more accurately.
That is sort of the way it works in the ADF, and is known as MIMO (March In, March Out).   The vast majority of moves happen at roughly the same time (within a month or so) , every 3rd year has a bit of a spike as more personnel change posting (about 60% more than the other two years).  

I would suggest setting the code to ensure that all tours end before assigning any new officers, as it makes it less likely that the same officer gets reassigned to the same post again, and again and yet again (my current max is the same officer assigned to the same ship for 6 two year tours in sucession).
ADF = Australian Defence Force?

It turned out to be a relatively simple change so I have made it. When a race is created, the time is noted. If automated assignments are switched on then after a period equal to the tour length, every officer that is commanding a ship or a ground unit or is a staff officer and does not have the "Do Not Remove" flag set will be removed from their post. Then the program will carry out a reassignment of all available posts for that race in those areas. This should ensure the best officers go to the best ships and that any newly arrived officers get into suitable commands fairly quickly. When this mass assignment takes place, a note is made of the time and when the tour length has passed the whole process happens again.

I think the next step is to make sure that fleet admirals don't end up commanding destroyers. Several people have suggested having a max rank so how about 2 ranks above the minimum. So if you set Commander as the min rank, then the max rank will be Commodore. Min rank Captain then max rank Rear Admiral, etc.. Is two ranks appropriate or should it just be one rank?

Steve
Title: Re: Suggestions for 3.3
Post by: Erik L on December 29, 2008, 03:12:01 PM
Quote from: "SteveAlt"
I think the next step is to make sure that fleet admirals don't end up commanding destroyers. Several people have suggested having a max rank so how about 2 ranks above the minimum. So if you set Commander as the min rank, then the max rank will be Commodore. Min rank Captain then max rank Rear Admiral, etc.. Is two ranks appropriate or should it just be one rank?

Steve

Two works for me.
Title: Re: Suggestions for 3.3
Post by: schroeam on December 29, 2008, 08:57:36 PM
Quote from: "Erik Luken"
Quote from: "SteveAlt"
I think the next step is to make sure that fleet admirals don't end up commanding destroyers. Several people have suggested having a max rank so how about 2 ranks above the minimum. So if you set Commander as the min rank, then the max rank will be Commodore. Min rank Captain then max rank Rear Admiral, etc.. Is two ranks appropriate or should it just be one rank?

Steve

Two works for me.

Two's good, except for governorships, headquarters, and capital ships.  Maybe three for those, if possible.
Title: Re: Suggestions for 3.3
Post by: Erik L on December 29, 2008, 09:41:20 PM
Quote from: "adradjool"
Quote from: "Erik Luken"
Quote from: "SteveAlt"
I think the next step is to make sure that fleet admirals don't end up commanding destroyers. Several people have suggested having a max rank so how about 2 ranks above the minimum. So if you set Commander as the min rank, then the max rank will be Commodore. Min rank Captain then max rank Rear Admiral, etc.. Is two ranks appropriate or should it just be one rank?

Steve

Two works for me.

Two's good, except for governorships, headquarters, and capital ships.  Maybe three for those, if possible.

I don't believe governors and task group commanders are subject to rotation rules.
Title: Re: Suggestions for 3.3
Post by: schroeam on December 30, 2008, 12:22:27 PM
Quote from: "Erik Luken"
I don't believe governors and task group commanders are subject to rotation rules.

I wasn't sure if the restriction would be global or just on the automated assignments.
Title: Re: Suggestions for 3.3
Post by: ZimRathbone on December 31, 2008, 08:48:44 AM
Quote from: "SteveAlt"
ADF = Australian Defence Force?

 Aye
Quote from: "SteveAlt"
It turned out to be a relatively simple change so I have made it. When a race is created, the time is noted. If automated assignments are switched on then after a period equal to the tour length, every officer that is commanding a ship or a ground unit or is a staff officer and does not have the "Do Not Remove" flag set will be removed from their post. Then the program will carry out a reassignment of all available posts for that race in those areas. This should ensure the best officers go to the best ships and that any newly arrived officers get into suitable commands fairly quickly. When this mass assignment takes place, a note is made of the time and when the tour length has passed the whole process happens again.

I think the next step is to make sure that fleet admirals don't end up commanding destroyers. Several people have suggested having a max rank so how about 2 ranks above the minimum. So if you set Commander as the min rank, then the max rank will be Commodore. Min rank Captain then max rank Rear Admiral, etc.. Is two ranks appropriate or should it just be one rank?

Steve

Two ranks is good I think.
Title: Re: Suggestions for 3.3
Post by: Steve Walmsley on December 31, 2008, 08:55:31 AM
I have changed the automated assignment to include the two rank restriction for all ships and all ground forces except HQs. I have left staff officers alone as they are based on a max rather than min rank anyway. Planetary and sector governors and task force commanders are not covered by automated assignments. The two rank restriction will only apply to automated assignments so you will be able to override it for manual assignments.

Steve
Title: Re: Suggestions for 3.3
Post by: Erik L on December 31, 2008, 05:15:34 PM
I think this has been mentioned before... A way to upgrade LTA/LTI units.

Also. Not sure where it disappeared to, but when you buy civilian ships, a popup to select the task group they go into.
Title: Re: Suggestions for 3.3
Post by: Brian Neumann on December 31, 2008, 08:02:10 PM
Have missiles survive for 1 second in a nebula.  This will prevent planets from being almost impossible to conquor.  A planet with 1 or more atmosphere pressure and in a nebula can only be engaged with meson's.  But Meson's don't seem to affect ground units.  This would also give missile ships a little bit of combat power, but it will be terribly short ranged for whatever tech is being used.  Almost any beam weapon will be able to out range it.  A good example is most ion engine missiles have speeds between 25-30000 km/s.  Any visable light laser has at least a matching range.  By the time that the lasers are at the same tech level they will have 3-5 times the range, and be firing much faster.

Brian
Title: Re: Suggestions for 3.3
Post by: jfelten on January 07, 2009, 05:25:17 AM
Quote from: "Brian"
Have missiles survive for 1 second in a nebula.  This will prevent planets from being almost impossible to conquor.  A planet with 1 or more atmosphere pressure and in a nebula can only be engaged with meson's.  But Meson's don't seem to affect ground units.  This would also give missile ships a little bit of combat power, but it will be terribly short ranged for whatever tech is being used.  Almost any beam weapon will be able to out range it.  A good example is most ion engine missiles have speeds between 25-30000 km/s.  Any visable light laser has at least a matching range.  By the time that the lasers are at the same tech level they will have 3-5 times the range, and be firing much faster.

Brian

Or maybe allow missiles in a nebula but reduce their speed to the maximum ship speed in a nebula?
Title: Re: Suggestions for 3.3
Post by: jfelten on January 07, 2009, 05:56:16 AM
I apologize for not having all the correct terms here, but I don't have a copy of Aurora to reference as I write this.  I would like an option that when a divided TF is given the assemble order, that child TF's that are not co-located with the mother TF have an order added to join the mother TF.  

What I've been doing is sending a fleet of non-jump grav survey ships along with one jump capable "mothership" in to a system to survey for warp points.  The divide option (or whatever it is called, the one that automatically splits a TF in to single ship TF's, one of which becomes the parent TF and all the rest child TF's) is super useful here as it copies the survey orders from the parent TF to the children TF's.  And although I've not timed it, it seems that splitting the grav survey ships up results in surveying a system much faster (someone please correct me if I'm wrong about this!).  But when done I want to recombine those all back in to the original parent TF.  There is an assemble button for that but it only works for child TF's that are co-located with the parent TF.  So I have to go to every child TF (single ship TF) and give each of them orders to join the parent TF once they finish their JP surveys.  That is a lot of clicking.  It is still a heck of a lot better than doing it all manually, but by adding this one additional feature it would be nearly totally automated.  

Note that I would like the join order added to the child TF's existing orders, not just replace their existing orders, since they may have a few JP's left to survey at that point.
Title: Re: Suggestions for 3.3
Post by: schroeam on January 07, 2009, 09:10:53 AM
Quote from: "jfelten"
I apologize for not having all the correct terms here, but I don't have a copy of Aurora to reference as I write this.  I would like an option that when a divided TF is given the assemble order, that child TF's that are not co-located with the mother TF have an order added to join the mother TF.  

What I've been doing is sending a fleet of non-jump grav survey ships along with one jump capable "mothership" in to a system to survey for warp points.  The divide option (or whatever it is called, the one that automatically splits a TF in to single ship TF's, one of which becomes the parent TF and all the rest child TF's) is super useful here as it copies the survey orders from the parent TF to the children TF's.  And although I've not timed it, it seems that splitting the grav survey ships up results in surveying a system much faster (someone please correct me if I'm wrong about this!).  But when done I want to recombine those all back in to the original parent TF.  There is an assemble button for that but it only works for child TF's that are co-located with the parent TF.  So I have to go to every child TF (single ship TF) and give each of them orders to join the parent TF once they finish their JP surveys.  That is a lot of clicking.  It is still a heck of a lot better than doing it all manually, but by adding this one additional feature it would be nearly totally automated.  

Note that I would like the join order added to the child TF's existing orders, not just replace their existing orders, since they may have a few JP's left to survey at that point.

There are a couple different ways to do this.  You can either have the subfleets try to find the parent fleet and merge with them using conditional orders.
       Condition: Parent fleet in system
       Order: Join Parent Fleet in System
This option has a disadvantage of using valuable fuel if the fleets are 180 degrees apart in a very large system and they chase each other around.  Another option is to arrange for a rendezvous point and have the parent fleet absorb the sub fleets.  This uses the secondary default order and one set of conditional orders.
       Primary Default Order:  Survey nearest survey location (or next three)
       Secondary Default Order:  Move to Entry Jump Point
       Conditional Order for Parent Fleet:
            Condition:  Sub fleets in same location
            Order:  Incorporate sub-fleets in same location
I've generally used the second option.  This seems to work best since the jump ship will usually explore the newly discovered jump points once the survey is complete, and the sub-fleets will concentrate in one, "safe" area.  

Hope this helps.

Adam.
Title: Re: Suggestions for 3.3
Post by: Erik L on January 07, 2009, 09:11:49 AM
Quote from: "jfelten"
I apologize for not having all the correct terms here, but I don't have a copy of Aurora to reference as I write this.  I would like an option that when a divided TF is given the assemble order, that child TF's that are not co-located with the mother TF have an order added to join the mother TF.  

What I've been doing is sending a fleet of non-jump grav survey ships along with one jump capable "mothership" in to a system to survey for warp points.  The divide option (or whatever it is called, the one that automatically splits a TF in to single ship TF's, one of which becomes the parent TF and all the rest child TF's) is super useful here as it copies the survey orders from the parent TF to the children TF's.  And although I've not timed it, it seems that splitting the grav survey ships up results in surveying a system much faster (someone please correct me if I'm wrong about this!).  But when done I want to recombine those all back in to the original parent TF.  There is an assemble button for that but it only works for child TF's that are co-located with the parent TF.  So I have to go to every child TF (single ship TF) and give each of them orders to join the parent TF once they finish their JP surveys.  That is a lot of clicking.  It is still a heck of a lot better than doing it all manually, but by adding this one additional feature it would be nearly totally automated.  

Note that I would like the join order added to the child TF's existing orders, not just replace their existing orders, since they may have a few JP's left to survey at that point.

Set a conditional order to rejoin parent fleet in system.
Title: Re: Suggestions for 3.3
Post by: Randy on January 07, 2009, 02:21:28 PM
Just a suggestion-

  You might want to make it so that you actually have to own a ship before you can scrap it...  :lol:
Title: Re: Suggestions for 3.3
Post by: sloanjh on January 07, 2009, 11:39:13 PM
Quote from: "jfelten"
I apologize for not having all the correct terms here, but I don't have a copy of Aurora to reference as I write this.  I would like an option that when a divided TF is given the assemble order, that child TF's that are not co-located with the mother TF have an order added to join the mother TF.  

What I've been doing is sending a fleet of non-jump grav survey ships along with one jump capable "mothership" in to a system to survey for warp points.  The divide option (or whatever it is called, the one that automatically splits a TF in to single ship TF's, one of which becomes the parent TF and all the rest child TF's) is super useful here as it copies the survey orders from the parent TF to the children TF's.  And although I've not timed it, it seems that splitting the grav survey ships up results in surveying a system much faster (someone please correct me if I'm wrong about this!).  But when done I want to recombine those all back in to the original parent TF.  There is an assemble button for that but it only works for child TF's that are co-located with the parent TF.  So I have to go to every child TF (single ship TF) and give each of them orders to join the parent TF once they finish their JP surveys.  That is a lot of clicking.  It is still a heck of a lot better than doing it all manually, but by adding this one additional feature it would be nearly totally automated.  

Note that I would like the join order added to the child TF's existing orders, not just replace their existing orders, since they may have a few JP's left to survey at that point.

First, yes, splitting the survey ships up results in faster surveys.  This is because the total survey time is the sum of the time it takes to survey a location ("parked survey") plus the time it takes to get to that location ("transit").  The total parked survey time over the entire system depends only the number of ships (actually survey modules) doing the surveying, since it's a fixed number of survey points.  The total transit time, however, varies depending on the path of each ship; the worst transit time is obtained by having every ship visit every survey location.

Second, I never had much luck with the "join" order for re-assembling fleets (it didn't seem to do what I wanted it to do), so I basically don't use it.  For situations like you describe, I tend to use my jump ships in "bridge mode" - I park them at the JP and let them escort other units through as the other units arrive.  Part of this is role-playing - once my civ has discovered aliens exist, it always has a powered-down (i.e. stealthy) jump ship at the JP in "overwatch mode" - if the survey ships get eaten by BEMs (as happened in Steve's current campaign), the overwatch ship will know about it and transit back to warn the civ.

In other words, my survey ships tend to trickle into a system rather than arriving all at once.  All that being said, your suggestion sounds like a good idea - I think I remember being in a similar situation and all that clicking being a pain.

John
Title: Re: Suggestions for 3.3
Post by: jfelten on January 08, 2009, 05:41:27 AM
I'll try the conditional order.  I was already using both conditional orders but can give one of them up.  

Issuing the Join orders manually seemed to work perfectly for me.  It was just extra clicks.  

I understand about having a jump ship at the WP to escape with word of an emergency.  I guess I could just put zero survey instruments on the jump ship and then it would just sit at the WP while the non-jump survey ships went to work.  But I'm personally more interested in having the process as automated as possible so I can focus on other aspects of the game.  I guess at this point I'm pretending there is some system such as Starfire courier drones in use that can get word out if a giant space goat is encountered and eats the fleet.  

My real suggestion for 3.3 would be an order to give a fleet to go survey a system and it would then do so on its own in the most efficient manner without further input from me.  I assume this would also be of value to the game system for when fully automated NPR's are introduced.
Title: Re: Suggestions for 3.3
Post by: sloanjh on January 09, 2009, 12:54:50 AM
Quote from: "jfelten"
I understand about having a jump ship at the WP to escape with word of an emergency.  I guess I could just put zero survey instruments on the jump ship and then it would just sit at the WP while the non-jump survey ships went to work.  But I'm personally more interested in having the process as automated as possible so I can focus on other aspects of the game.  I guess at this point I'm pretending there is some system such as Starfire courier drones in use that can get word out if a giant space goat is encountered and eats the fleet.  
LOL - I guess goats will eat anything!

I like your technobabble idea for courier drones if one doesn't want to deal with the communications tail.  I probably won't use it, though - I actually like role-playing the paranoid-explorer-thing (at least after I've discovered my first ruins).  My grav survey ships are warp-capable, and it's usually not efficient to have more than 2-3 in a system at once - they end up spending a lot of distance leap-frogging each other.  (In fact, one could probably prove that the most efficient time/ships ratio can't involve more than 3 ships in the system, since the 3rd ship wouldn't be able to avoid leap-frogging one of the others.)  So what I actually do is creep into the system, keep a ship right on the JP until habitable worlds are probed and the system looks safe (and until any non-jump-capable geo-survey ships have arrived), then make sure that I always have at least two ships doing the survey, so that if one gets ambushed the other(s) has a good chance of escaping.

Quote
My real suggestion for 3.3 would be an order to give a fleet to go survey a system and it would then do so on its own in the most efficient manner without further input from me.  I assume this would also be of value to the game system for when fully automated NPR's are introduced.

I think this was Steve's original vision for the "join" order.  I've found that survey fleets are too resource-intensive and cumbersome (from an efficiency point of view), and so my survey units tend to operate independently.

One interesting aspect of this survey doctrine is that it's not very paranoid, i.e. the ships are going to be tooling around with a large signature in a system that might have aliens.  This might give a cool role-playing opportunity, i.e. representing a peaceful civilization that's trusting in the kindness of the universe. :twisted:

John
Title: Re: Suggestions for 3.3
Post by: jfelten on January 09, 2009, 04:15:21 AM
Quote from: "Erik Luken"
Set a conditional order to rejoin parent fleet in system.

At the risk of hijacking the suggestions thread, I tried this last night and it didn't work for me.  Maybe I did something wrong but the conditional order took precedence over that default orders (or whatever they are called) to survey, so my survey ships would immediately abort their survey to go rejoin the mother TG.
Title: Re: Suggestions for 3.3
Post by: jfelten on January 09, 2009, 05:01:26 AM
Back to actual suggestions.

1.  Could the Task Group window show the full location in the location field?  Right now it only seems to show the system, not the planet/JP/etc.  

2.  Now that I've found some of the useful mouse-overs, could the Production Window / Mining/Maintenance, "Mouse Over" show what each mineral is primarily used for?  I know a lot of things take small amounts of several minerals so it isn't clear cut, but each mineral seems to be primarily used for a handful of things.  I made a reference list from a posting I found here, but it would be convenient to have it right there where most needed.

3.  Another mouse-over request.  Have the Production Window / Research RP "Mouse Over" show the Research Points per annum calculation, as you already do for industrial production etc.

4.  Have the "New Thermal Contact" event list which sensor platform made the contact, or at least the first one.  

5.  Allow "banning" a planet/moon that has population (to keep civilian ships from adding more).  See the bug report I'm about to post on why I ran in to this.  

6.  Whenever a specific ship (unit) is referenced in the event log, please list which TG it is in.  

7.  It would be handy if the function keys worked no matter which Aurora window had focus.  

8.  On the System Map, if I select the option to highlight alien population centers, it only seems to function when I have one under actual observation but "forgets" once it is no longer under sensor coverage.  I can imagine this could get complicated since an alien population center could be destroyed or removed or conquered between observations, but it would be handy to be able to see "known" alien population centers on the System Map even when not under direct observation, even if that information might be stale.

9.  It would streamline the game if I could tell TG's to go do something several systems away without having to enter each WP transit manually.  This gets in to areas such as path finding which can become complicated to code.  I'm sure it has been considered and I'm not suggesting anything new, especially since this would be necessary for AI NPR's, but I thought I would list it.  For example, I would like to be able to tell a TG to go pick up a team on a moon several systems away and return them to the home world with just a couple clicks.  That also saves me from having to go to the Galacitc Map and figuring out the route myself should I not have it memorized.  I kind of miss the old Starfire IFN here where I could assume they would hitch a (slow) ride back on a freighter as long as it was connected to the IFN.

10.  When a research project is completed, report in the event log which new techs if any are thereby opened for research.

11.  Allow an entire system to be flagged off limits to civilian ships.
Title: Re: Suggestions for 3.3
Post by: Erik L on January 09, 2009, 12:13:36 PM
Quote from: "jfelten"
Quote from: "Erik Luken"
Set a conditional order to rejoin parent fleet in system.

At the risk of hijacking the suggestions thread, I tried this last night and it didn't work for me.  Maybe I did something wrong but the conditional order took precedence over that default orders (or whatever they are called) to survey, so my survey ships would immediately abort their survey to go rejoin the mother TG.

I know I have done that before, but not recently.
Title: Re: Suggestions for 3.3
Post by: ZimRathbone on January 10, 2009, 06:02:37 AM
Quote from: "adradjool"
Quote from: "jfelten"
I apologize for not having all the correct terms here, but I don't have a copy of Aurora to reference as I write this.  I would like an option that when a divided TF is given the assemble order, that child TF's that are not co-located with the mother TF have an order added to join the mother TF.  


There are a couple different ways to do this.  You can either have the subfleets try to find the parent fleet and merge with them using conditional orders.
       Condition: Parent fleet in system
       Order: Join Parent Fleet in System
This option has a disadvantage of using valuable fuel if the fleets are 180 degrees apart in a very large system and they chase each other around.  Another option is to arrange for a rendezvous point and have the parent fleet absorb the sub fleets.  This uses the secondary default order and one set of conditional orders.
       Primary Default Order:  Survey nearest survey location (or next three)
       Secondary Default Order:  Move to Entry Jump Point
       Conditional Order for Parent Fleet:
            Condition:  Sub fleets in same location
            Order:  Incorporate sub-fleets in same location
I've generally used the second option.  This seems to work best since the jump ship will usually explore the newly discovered jump points once the survey is complete, and the sub-fleets will concentrate in one, "safe" area.  

Hope this helps.

Adam.

I use option 2 as well - only niggle I have encountered is that the 2ndry Default tends to evaporate, and needs to be refreshed for each new system (no biggie)

Mike
Title: Re: Suggestions for 3.3
Post by: jfelten on January 12, 2009, 06:21:02 AM
Have the keyboard arrow keys "pan" in the System Map (in addition to the arrow buttons).
Title: Re: Suggestions for 3.3
Post by: jfelten on January 12, 2009, 06:22:42 AM
I could not find a way to change the time/distance scale on the System Map.  Currently it is set to 5,000 Km/s.  If there is no place to change it, my suggestion is to add a way to edit that parameter.
Title: Re: Suggestions for 3.3
Post by: IanD on January 12, 2009, 07:33:55 AM
A simple addition to raise the paranoia of player races, (at least I assume it would be simple).

Have some random fluff for ruins that is given with the first result of the xenologists investigations. E.g.  “These installations appear to have malfunctioned and simply been abandoned” or “this settlement was destroyed by nuclear bombardment”. This may give a player race a reason to increase their military R&D and construction.

If the result could be tied to the condition of the ruin all the better.  E.g. Destroyed Outpost – 70% chance result of some sort of military action, ruined outpost - 50% chance of “bombardment +/- indications of ground combat” etc. You could even solicit the group for suitable fluff.

If you want to be more ambitious, then the type of fluff could affect the security requirements of populations in adjoining systems. But I fear this could be a lot of work for little return.

Regards
Ian
Title: Re: Suggestions for 3.3
Post by: welchbloke on January 12, 2009, 12:50:57 PM
Quote from: "IanD"
A simple addition to raise the paranoia of player races, (at least I assume it would be simple).

Have some random fluff for ruins that is given with the first result of the xenologists investigations. E.g.  “These installations appear to have malfunctioned and simply been abandoned” or “this settlement was destroyed by nuclear bombardment”. This may give a player race a reason to increase their military R&D and construction.

If the result could be tied to the condition of the ruin all the better.  E.g. Destroyed Outpost – 70% chance result of some sort of military action, ruined outpost - 50% chance of “bombardment +/- indications of ground combat” etc. You could even solicit the group for suitable fluff.

If you want to be more ambitious, then the type of fluff could affect the security requirements of populations in adjoining systems. But I fear this could be a lot of work for little return.

Regards
Ian
I like the idea of adding the fluff to the reports on ruins, this could allow for lots of role-playing directions that I may not have otherwise followed.  As was mentioned by Kurt I think  in a post recently, it is easy to fall into a routine of doing the same thing everytime and races becoming carbon copies of each other.  I know if I started to find ruins with reports like 'destoryed as a result of bombardment/space weather event etc' then the race I was controlling would pursue tech to defend againt whatever natural/un-natural distater was reported.  I don't think that the changing the security requirements of adjacent systems is worth it.  I'm sure there's lots of cool things that Steve wants to add that could use the coding time  :D
Title: Re: Suggestions for 3.3
Post by: jfelten on January 13, 2009, 07:38:57 AM
I would be helpful if there was an order to transfer fuel between co-located TG's that does not include dedicated tankers/oilers.  I've been doing it manually between ships in co-located TG's via the Ships window, but that is tedious especially when you have several ships in each TG.  The equalize fuel button in the TG window helps, but it is still a lot of mouse clicks just to transfer fuel.  I assume it is easier with dedicated tankers but sometimes tankers are not available.
Title: Re: Suggestions for 3.3
Post by: jfelten on January 14, 2009, 09:22:17 AM
Could designed but not yet researched missiles be added to the technology report?  I designed several missiles then didn't get back to the game for several days and then didn't remember which was which and could find no way to view the designs since I hadn't researched them yet.
Title: Re: Suggestions for 3.3
Post by: Hawkeye on January 14, 2009, 10:40:21 AM
Hm, you could use the colony - tech screen and switch back and forth between avilable and researched projects on the ship component tab to find out which ones are allready finished, but I agree, it is a bit cumbersome
Title: Re: Suggestions for 3.3
Post by: sloanjh on January 14, 2009, 09:55:58 PM
Quote from: "jfelten"
Could designed but not yet researched missiles be added to the technology report?  I designed several missiles then didn't get back to the game for several days and then didn't remember which was which and could find no way to view the designs since I hadn't researched them yet.
The "instant" tech button (in SM mode) is convenient in these sorts of situations.  Temporarily give your civ the tech, then take it away after you've looked.

John
Title: Re: Suggestions for 3.3
Post by: jfelten on January 15, 2009, 04:06:04 AM
Quote from: "sloanjh"
Quote from: "jfelten"
Could designed but not yet researched missiles be added to the technology report?  I designed several missiles then didn't get back to the game for several days and then didn't remember which was which and could find no way to view the designs since I hadn't researched them yet.
The "instant" tech button (in SM mode) is convenient in these sorts of situations.  Temporarily give your civ the tech, then take it away after you've looked.

John

Good idea.  Thanks.  I'll still leave the suggestion to add a check box to the tech report to show designed but not researched items (it wouldn't hurt to have a way to delete them as well), but this sounds like a good work around in the mean time.  I didn't realize you could unresearch techs.
Title: Re: Suggestions for 3.3
Post by: Father Tim on January 15, 2009, 09:50:54 AM
Quote from: "jfelten"
(it wouldn't hurt to have a way to delete them as well), but this sounds like a good work around in the mean time.  I didn't realize you could unresearch techs.

The 'Delete' button works to get rid of unresearched techs.  If you've already researched them, then you have to 'Remove' the tech frist, then delete it.
Title: Re: Suggestions for 3.3
Post by: Steve Walmsley on January 15, 2009, 12:18:12 PM
Quote from: "Randy"
Just a suggestion-

  You might want to make it so that you actually have to own a ship before you can scrap it...  :lol:
Fixed for v3.3 (or probably v4.0)

Steve
Title: Re: Suggestions for 3.3
Post by: Steve Walmsley on January 15, 2009, 12:20:06 PM
Quote from: "jfelten"
Have the keyboard arrow keys "pan" in the System Map (in addition to the arrow buttons).
The keyboard keypad will pan the system map and the keypad +/- will zoom it,

Steve
Title: Re: Suggestions for 3.3
Post by: Steve Walmsley on January 15, 2009, 12:22:58 PM
Quote from: "jfelten"
5.  Allow "banning" a planet/moon that has population (to keep civilian ships from adding more).  See the bug report I'm about to post on why I ran in to this.  
There is a Ban Body button on the F9 System View window that will do this.

Steve
Title: Re: Suggestions for 3.3
Post by: jfelten on January 16, 2009, 08:50:39 AM
Quote from: "Steve Walmsley"
Quote from: "jfelten"
Have the keyboard arrow keys "pan" in the System Map (in addition to the arrow buttons).
The keyboard keypad will pan the system map and the keypad +/- will zoom it,

Steve

O.K.  I'm using a laptop without a keypad so I missed that and tried using the arrow keys which didn't work.  The laptop does have the "Fn" pseudo-keypad but those are miserable to try to use for much.
Title: Re: Suggestions for 3.3
Post by: jfelten on January 16, 2009, 08:51:39 AM
Quote from: "Steve Walmsley"
Quote from: "jfelten"
5.  Allow "banning" a planet/moon that has population (to keep civilian ships from adding more).  See the bug report I'm about to post on why I ran in to this.  
There is a Ban Body button on the F9 System View window that will do this.

Steve

I did try that.  Unfortunately it doesn't work for zero pop "colonies" and throws an error dialog instead.
Title: Re: Suggestions for 3.3
Post by: Father Tim on January 16, 2009, 10:02:41 AM
Quote from: "jfelten"
Quote from: "Steve Walmsley"
Quote from: "jfelten"
5.  Allow "banning" a planet/moon that has population (to keep civilian ships from adding more).  See the bug report I'm about to post on why I ran in to this.  
There is a Ban Body button on the F9 System View window that will do this.

Steve

I did try that.  Unfortunately it doesn't work for zero pop "colonies" and throws an error dialog instead.

Banning a planet with an existing colony throws an error, as it should.  The short version is you can't declare a colony off-limits to civilians only.  That's the point of civilian shipping - it goes where it wants to, not where you want it to.  Any colony with less than 10m population and less than its Infrastructure can support is a valid delivery location.  The probem arises from putting colonies on Col Cost:N/A worlds (such as automated mining sites), which the current version of Aurora interprets as being the same as Col Cost: 0.0.   When the underlying bug is fixed (which it has been for 4.0) the problem will disappear.   In the mean time, you will have to manually remove the excess population in SM Mode (or just live with the problem).
Title: Re: Suggestions for 3.3
Post by: jfelten on January 16, 2009, 10:22:04 AM
Quote from: "Father Tim"
Banning a planet with an existing colony throws an error, as it should.  The short version is you can't declare a colony off-limits to civilians only.  That's the point of civilian shipping - it goes where it wants to, not where you want it to.  Any colony with less than 10m population and less than its Infrastructure can support is a valid delivery location.  The problem arises from putting colonies on Col Cost:N/A worlds (such as automated mining sites), which the current version of Aurora interprets as being the same as Col Cost: 0.0.   When the underlying bug is fixed (which it has been for 4.0) the problem will disappear.   In the mean time, you will have to manually remove the excess population in SM Mode (or just live with the problem).

I can't imagine why the government/military shouldn't be able to tell the civilian ships "This colony/system/area is off limits to you".  Especially when you consider that some government types are dictatorships or monarchies.
Title: Re: Suggestions for 3.3
Post by: schroeam on January 16, 2009, 06:25:17 PM
Quote from: "jfelten"
Quote from: "Father Tim"
Banning a planet with an existing colony throws an error, as it should.  The short version is you can't declare a colony off-limits to civilians only.  That's the point of civilian shipping - it goes where it wants to, not where you want it to.  Any colony with less than 10m population and less than its Infrastructure can support is a valid delivery location.  The problem arises from putting colonies on Col Cost:N/A worlds (such as automated mining sites), which the current version of Aurora interprets as being the same as Col Cost: 0.0.   When the underlying bug is fixed (which it has been for 4.0) the problem will disappear.   In the mean time, you will have to manually remove the excess population in SM Mode (or just live with the problem).

I can't imagine why the government/military shouldn't be able to tell the civilian ships "This colony/system/area is off limits to you".  Especially when you consider that some government types are dictatorships or monarchies.
I agree that at some point, regardless of the government type, there will be areas that the government wants off limits to civilian ships due to quarantine, rebellion, secret research, etc.  There are plenty of examples of this throughout history, and even present today.

Adam.
Title: Re: Suggestions for 3.3
Post by: schroeam on January 16, 2009, 06:28:49 PM
How about an addition to the espionage code that allows espionage teams to sneak into alien empires using civilian ships?  Just assign the target empire and the team makes it's own way, if possible, to the destination.  If there is not a way, then maybe a message stating that the target empire was unreachable through clandestine means.

Adam.
Title: Re: Suggestions for 3.3
Post by: Erik L on January 16, 2009, 07:04:38 PM
Quote from: "adradjool"
How about an addition to the espionage code that allows espionage teams to sneak into alien empires using civilian ships?  Just assign the target empire and the team makes it's own way, if possible, to the destination.  If there is not a way, then maybe a message stating that the target empire was unreachable through clandestine means.

Adam.

This idea I like.

Steve, with the additional automation, what you going to do with trade routes? Will the trade ships become legitimate contacts and targets?
Title: Re: Suggestions for 3.3
Post by: alanwebber on January 21, 2009, 08:35:58 AM
When building fighters, could we have a warning if a default fleet isn't selected? I've just built 12 fighters which disappeared into the ether. They are still present on the squadrons screen but not on the individual units one.
Title: Re: Suggestions for 3.3
Post by: Bellerophon06 on January 21, 2009, 12:56:34 PM
I don't know how difficult this would be to code, but I would be interested in seeing the option to build military or commercial engines.  Much like the Starfire system where commercial ships whose engines can run all out at all times with little maintenance penalty and warships that can go much faster than the commercial ships, but can only do so for limited periods.  This could also require warships to have a "cruising speed" after which maintenance penalties would begin to apply.  The military engine could have a speed increase of 50% from the normal "maximum" speed but have a 75% failure increase over time, for instance.  The consequences would be interesting if one of your warships had a major failure while they were running from the enemy at flank speed.
Title: Re: Suggestions for 3.3
Post by: Brian Neumann on January 21, 2009, 03:22:02 PM
Quote from: "Bellerophon06"
I don't know how difficult this would be to code, but I would be interested in seeing the option to build military or commercial engines.  Much like the Starfire system where commercial ships whose engines can run all out at all times with little maintenance penalty and warships that can go much faster than the commercial ships, but can only do so for limited periods.  This could also require warships to have a "cruising speed" after which maintenance penalties would begin to apply.  The military engine could have a speed increase of 50% from the normal "maximum" speed but have a 75% failure increase over time, for instance.  The consequences would be interesting if one of your warships had a major failure while they were running from the enemy at flank speed.

In a way there is already part of this in place.  The commercial engine has several levels of improved efficiency added to it.  As thier is a 2-1 ratio of fuel efficiency vs engine power change this results in slower ships (a 20% reduction in fuel use is also a 10% reduction in engine power)  The reduction in power and the fuel use is cumulative so even a few levels of each can make a big difference on how much fuel you use.  The reverse is also true.  A "military" engine uses a more powerfull engine but one that is much less fuel effecient.  (a 10% boost to power is also a 20% increase in fuel use.  all together that is about a 13% increase in fuel use)

Brian
Title: Re: Suggestions for 3.3
Post by: jfelten on January 22, 2009, 05:23:05 AM
I was also thinking about commercial engines like the old Ic.  It does seem a bit silly that freighters are essentially the same speed as warships.  And I don't think that fuel efficiency should be the main point to differentiate on.  I would like commercial engines to also be substantially cheaper (50%?) and to require substantially less maintenance and/or have a lower failure rate so they would be a worthwhile option, but maybe be about 75% as powerful as military engines.  You would have to balance it against simply putting fewer regular engines in the design so there was an advantage to the civilian engines.  It could be a fairly low tech modifier to be researched and apply to regular engines similar to the efficiency modifier.  

I'm not too keen on the idea of running military engines at full power resulting in things falling apart.  You are going to end up with what is essentially a random event costing someone a major battle.  Even if that is "realistic" it doesn't make for a good game unless you are going for historical recreation accuracy (which obviously isn't the case with Aurora).
Title: Re: Suggestions for 3.3
Post by: Charlie Beeler on January 22, 2009, 08:14:43 AM
I agree with Brian.  Research different power and fuel efficencies then design the engines and powerplants accordingly.
Title: Re: Suggestions for 3.3
Post by: schroeam on January 22, 2009, 08:15:43 AM
I'm not sure that a knew line of tech for a commercial engine is the right answer.  They would still have the ability to run faster than a warship as long as there are not restrictions in the number of engines used.  Maybe the right answer is an additional tech in the mode of some sort of booster.  I guess it would work the same as afterburners for today's fighters.  They would provide a short term boost of speed to quickly close the range with an enemy, but at the same time increase the possibility of engine damage exponentially with regard to time in service and the consumption of fuel goes up by a factor of maybe four or more.  I'm not exactly sure where this would correlate in SF, but I think the closest was detuning engines.  Maybe the engine booster tech line would allow for longer periods of use before catastrophic effects took place as well as slightly smaller percentage (1-2%) of fuel consumption with each tech level.  As with everything, a smaller version could be created for gunboats and fighters.  

Adam.
Title: Re: Suggestions for 3.3
Post by: Erik L on January 22, 2009, 11:35:15 AM
Think of it this way...

Here are two designs, built with 250k rp given via SM mode.

Code: [Select]
Power Output: 120     Explosion Chance: 1     Efficiency: 0.125    Thermal Signature: 120
Engine Size: 5    Engine HTK: 2     Internal Armour: 0
Cost: 60    Crew: 25
Materials Required: 15x Duranium  0x Neutronium  45x Gallicite

Development Cost for Project: 600RP
Code: [Select]
Power Output: 160     Explosion Chance: 5     Efficiency: 0.25    Thermal Signature: 160
Engine Size: 5    Engine HTK: 2     Internal Armour: 0
Cost: 80    Crew: 25
Materials Required: 20x Duranium  0x Neutronium  60x Gallicite

Development Cost for Project: 800RP
The first is using a power vs. efficiency of 50%, and as you can see, would require more engines to output the same as the "stock vanilla" engine (#2). For those wanting to live on the edge, there is this alternative too.
Code: [Select]
Power Output: 240     Explosion Chance: 35     Efficiency: 0.5    Thermal Signature: 240
Engine Size: 5    Engine HTK: 2     Internal Armour: 0
Cost: 120    Crew: 25
Materials Required: 30x Duranium  0x Neutronium  90x Gallicite

Development Cost for Project: 1200RP

As you can see, it has twice the power of the first "commercial" engine. It also is subject to instability in combat from damage. In all honesty, if I were to use such a design, I'd throw some internal armor on it also.
This is how I'd use the third engine.
Code: [Select]
Power Output: 240     Explosion Chance: 35     Efficiency: 0.5    Thermal Signature: 14.4
Engine Size: 10    Engine HTK: 2     Internal Armour: 6
Cost: 465    Crew: 25
Armour Type: Crystalline Composite Armour
Materials Required: 176.25x Duranium  45x Neutronium  348.75x Gallicite

Development Cost for Project: 4650RP

Couple designs based on the above engines.
Code: [Select]
Fletcher class Freighter    6000 tons     234 Crew     949.4 BP      TCS 120  TH 600  EM 0
5000 km/s     Armour 1-29     Shields 0-0     Sensors 32/32/0/0     Damage Control Rating 1     PPV 0
Annual Failure Rate: 288%    IFR: 4%    Maintenance Capacity 99 MSP    Max Repair 100 MSP
Cargo 40000    Cargo Handling Multiplier 120    

Commercial Engine (5)    Power 120    Efficiency 0.13    Signature 120    Armour 0    Exp 1%
Fuel Capacity 130,000 Litres    Range 312.0 billion km   (722 days at full power)

Thermal Sensor TH1-32/15 (1)     Sensitivity 32     Detect Sig Strength 1000:  32m km
EM Detection Sensor EM1-32/15 (1)     Sensitivity 32     Detect Sig Strength 1000:  32m km

This design is classed as a freighter for maintenance purposes
Top speed in 5000km/s with 5 engines.
Code: [Select]
Coontz class Cruiser    9800 tons     827 Crew     15259.9 BP      TCS 196  TH 72  EM 900
6122 km/s     Armour 1-40     Shields 30-300     Sensors 32/32/0/0     Damage Control Rating 35     PPV 54
Annual Failure Rate: 153%    IFR: 2.1%    Maintenance Capacity 4866 MSP    Max Repair 3960 MSP

Military Engine (5)    Power 240    Efficiency 0.50    Signature 14.4    Armour 6    Exp 35%
Fuel Capacity 260,000 Litres    Range 95.5 billion km   (180 days at full power)
Omicron R300/15 Shields (5)   Total Fuel Cost  75 Litres per day

Quad 12cm C4 Far X-Ray Laser Turret (1x4)    Range 320,000km     TS: 32000 km/s     Power 16-16     RM 8    ROF 5        4 4 4 4 4 4 4 4 3 3
Quad Gauss Cannon R5-100 Turret (1x20)    Range 50,000km     TS: 32000 km/s     Power 0-0     RM 5    ROF 5        1 1 1 1 1 0 0 0 0 0
Fire Control S16 300-32000 H15 (2)    Max Range: 600,000 km   TS: 32000 km/s     98 97 95 93 92 90 88 87 85 83
Solid-core Anti-matter Power Plant Technology PB-1 AR-6 (1)     Total Power Output 80    Armour 6    Exp 5%

Active Search Sensor S300-R40/15 (1)     GPS 12000     Range 120.0m km    Resolution 40
PD Radar (1)     GPS 900     Range 9.0m km    Resolution 1
Thermal Sensor TH1-32/15 (1)     Sensitivity 32     Detect Sig Strength 1000:  32m km
EM Detection Sensor EM1-32/15 (1)     Sensitivity 32     Detect Sig Strength 1000:  32m km

Compact ECCM-5 (1)         ECM 50

Top speed is 6122km/s. As you can see, the Coontz is nearly twice the size, same number of engines, and still has 1100km/s on the freighter design. Both of these designs were off-the cuff designs created while writing this post. I cannot vouch for the effectiveness of the Coontz in battle. Also note the operation length as determined by fuel. The freighter has 722 days, while the cruiser has 180 days (plus shields) on twice the fuel capacity. Of course, some of that is based on the size of the ships too.

For comparison, here is a similar tonnage ship to the freighter.
Code: [Select]
North Carolina class Cruiser    6000 tons     517 Crew     8751.6 BP      TCS 120  TH 72  EM 540
10000 km/s     Armour 4-29     Shields 18-300     Sensors 32/32/0/0     Damage Control Rating 35     PPV 12
Annual Failure Rate: 57%    IFR: 0.8%    Maintenance Capacity 4558 MSP    Max Repair 3960 MSP

Military Engine (5)    Power 240    Efficiency 0.50    Signature 14.4    Armour 6    Exp 35%
Fuel Capacity 120,000 Litres    Range 72.0 billion km   (83 days at full power)
Omicron R300/15 Shields (3)   Total Fuel Cost  45 Litres per day

40cm C10 Far X-Ray Laser (1)    Range 600,000km     TS: 10000 km/s     Power 40-10     RM 8    ROF 20        40 40 40 40 40 40 40 40 35 32
Fire Control S16 300-32000 H15 (1)    Max Range: 600,000 km   TS: 32000 km/s     98 97 95 93 92 90 88 87 85 83
Solid-core Anti-matter Power Plant Technology PB-1 AR-6 (1)     Total Power Output 80    Armour 6    Exp 5%

Active Search Sensor S300-R40/15 (1)     GPS 12000     Range 120.0m km    Resolution 40
Thermal Sensor TH1-32/15 (1)     Sensitivity 32     Detect Sig Strength 1000:  32m km
EM Detection Sensor EM1-32/15 (1)     Sensitivity 32     Detect Sig Strength 1000:  32m km

Compact ECCM-5 (1)         ECM 50
Note the range envelope differences. 10,000 less litres on the North Carolina, and just over 10% of the endurance. But twice the speed.
Title: Re: Suggestions for 3.3
Post by: Bellerophon06 on January 22, 2009, 01:07:43 PM
These are all very valid points.  I suppose that I should start playing around with engine design a little more to get exactly what I want out of it.  I also haven't paid enough attention to the amount of maintenance points placed onboard the warships versus the freighters.  The warships have to carry a lot more spare parts to lower their intermittent failure rate to a level below that of the freighter.  More in game experience will probably help both of those.  :)
Title: Re: Suggestions for 3.3
Post by: Erik L on January 22, 2009, 02:39:32 PM
Quote from: "Bellerophon06"
These are all very valid points.  I suppose that I should start playing around with engine design a little more to get exactly what I want out of it.  I also haven't paid enough attention to the amount of maintenance points placed onboard the warships versus the freighters.  The warships have to carry a lot more spare parts to lower their intermittent failure rate to a level below that of the freighter.  More in game experience will probably help both of those.  :)

Just remember, the freighters in my example could easily mount the "military" engines and still be classed as freighters. I think the only restrictions are weapons, defenses and scanners. There is a post somewhere detailing what a freighter can have and still be a freighter.
Title: Re: Suggestions for 3.3
Post by: cjblack on January 22, 2009, 06:16:12 PM
Quote from: "Erik Luken"
Code: [Select]
Power Output: 240     Explosion Chance: 35     Efficiency: 0.5    Thermal Signature: 240
Engine Size: 5    Engine HTK: 2     Internal Armour: 0
Cost: 120    Crew: 25
Materials Required: 30x Duranium  0x Neutronium  90x Gallicite

Development Cost for Project: 1200RP

Code: [Select]
Power Output: 240     Explosion Chance: 35     Efficiency: 0.5    Thermal Signature: 14.4
Engine Size: 10    Engine HTK: 2     Internal Armour: 6
Cost: 465    Crew: 25
Armour Type: Crystalline Composite Armour
Materials Required: 176.25x Duranium  45x Neutronium  348.75x Gallicite

Development Cost for Project: 4650RP
That's quite a Thermal Signature reduction for the armoring.
Title: Re: Suggestions for 3.3
Post by: Erik L on January 22, 2009, 07:00:13 PM
Quote from: "cjblack"
Quote from: "Erik Luken"
Code: [Select]
Power Output: 240     Explosion Chance: 35     Efficiency: 0.5    Thermal Signature: 240
Engine Size: 5    Engine HTK: 2     Internal Armour: 0
Cost: 120    Crew: 25
Materials Required: 30x Duranium  0x Neutronium  90x Gallicite

Development Cost for Project: 1200RP

Code: [Select]
Power Output: 240     Explosion Chance: 35     Efficiency: 0.5    Thermal Signature: 14.4
Engine Size: 10    Engine HTK: 2     Internal Armour: 6
Cost: 465    Crew: 25
Armour Type: Crystalline Composite Armour
Materials Required: 176.25x Duranium  45x Neutronium  348.75x Gallicite

Development Cost for Project: 4650RP
That's quite a Thermal Signature reduction for the armoring.

The second one I added Thermal Reduction to, in addition to the armor. Armor alone won't do that.

I was thinking a government, or military would not want its civilians to be stealthy. ;)
Title: Re: Suggestions for 3.3
Post by: jfelten on January 23, 2009, 05:12:57 AM
Just looking at this, the armored engine is twice as powerful than the "commercial" engine but is also twice as large AND costs more than 10x as much to build.  Why wouldn't I just put twice as many "commercial" engines on my warship?  They would take the same amount of space yet generate the same total "thrust".  The armored engines are certainly tougher, but that is out balanced by them being much more expensive, much less fuel efficient, plus they still have the chance of blowing up.  Or am I missing something?  I'm not really sure how engine armor works in combat.
Title: Re: Suggestions for 3.3
Post by: Charlie Beeler on January 23, 2009, 07:53:55 AM
Quote from: "jfelten"
Just looking at this, the armored engine is twice as powerful than the "commercial" engine but is also twice as large AND costs more than 10x as much to build.  Why wouldn't I just put twice as many "commercial" engines on my warship?  They would take the same amount of space yet generate the same total "thrust".  The armored engines are certainly tougher, but that is out balanced by them being much more expensive, much less fuel efficient, plus they still have the chance of blowing up.  Or am I missing something?  I'm not really sure how engine armor works in combat.

If you look at the non-armored power 240 engine you'll see that it is the same size as the "commercial" power 120 engine.  Armor takes mass/hull space.  While you can equal the up-powered/armored engine your also segnificantly more vulnerable to combat damage disabling you.  It's a matter of choice.
Title: Re: Suggestions for 3.3
Post by: jfelten on January 23, 2009, 08:27:42 AM
Quote from: "Charlie Beeler"
Quote from: "jfelten"
Just looking at this, the armored engine is twice as powerful than the "commercial" engine but is also twice as large AND costs more than 10x as much to build.  Why wouldn't I just put twice as many "commercial" engines on my warship?  They would take the same amount of space yet generate the same total "thrust".  The armored engines are certainly tougher, but that is out balanced by them being much more expensive, much less fuel efficient, plus they still have the chance of blowing up.  Or am I missing something?  I'm not really sure how engine armor works in combat.

If you look at the non-armored power 240 engine you'll see that it is the same size as the "commercial" power 120 engine.  Armor takes mass/hull space.  While you can equal the up-powered/armored engine your also segnificantly more vulnerable to combat damage disabling you.  It's a matter of choice.

I understand that but some amount of armor is necessary IMO if you crank up the explosion chance.  I wouldn't really consider a regular engine "commercial" if the "military" version had a 35 times greater chance of exploding when it takes damage.  Military systems should be better suited to taking damage than commercial systems, not worse.  If anything it should be the other way around with the commercial engine not being as robust with regard to damage.  There would be some good military potential uses for fragile/dangerous engines "running hot" but not on mainline warships.  At least not for most empires.  It might be an interesting option for some races to go for maximum speed regardless of risk.  I could also see them used on fighters, but not the carriers.
Title: Re: Suggestions for 3.3
Post by: Erik L on January 23, 2009, 09:12:23 AM
The explosion chance only comes into effect if the engine takes damage, not during regular operations. With the 6 points of armor, you'll need to do at least 7 points of damage for a 35% chance to cause an explosion.
Title: Re: Suggestions for 3.3
Post by: jfelten on January 23, 2009, 09:40:40 AM
Quote from: "Erik Luken"
The explosion chance only comes into effect if the engine takes damage, not during regular operations. With the 6 points of armor, you'll need to do at least 7 points of damage for a 35% chance to cause an explosion.

Exactly.  A warship is much more likely to take damage than a freighter.
Title: Re: Suggestions for 3.3
Post by: Steve Walmsley on January 23, 2009, 11:42:47 AM
Quote from: "Erik Luken"
Steve, with the additional automation, what you going to do with trade routes? Will the trade ships become legitimate contacts and targets?
I think trade ships can already be detected and destroyed.

Steve
Title: Re: Suggestions for 3.3
Post by: Steve Walmsley on January 23, 2009, 11:48:25 AM
Quote from: "adradjool"
I'm not sure that a knew line of tech for a commercial engine is the right answer.  They would still have the ability to run faster than a warship as long as there are not restrictions in the number of engines used.  Maybe the right answer is an additional tech in the mode of some sort of booster.  I guess it would work the same as afterburners for today's fighters.  They would provide a short term boost of speed to quickly close the range with an enemy, but at the same time increase the possibility of engine damage exponentially with regard to time in service and the consumption of fuel goes up by a factor of maybe four or more.  I'm not exactly sure where this would correlate in SF, but I think the closest was detuning engines.  Maybe the engine booster tech line would allow for longer periods of use before catastrophic effects took place as well as slightly smaller percentage (1-2%) of fuel consumption with each tech level.  As with everything, a smaller version could be created for gunboats and fighters.  
This is something I have been considering. Either a seperate booster or more likely some type of boost mode for engines that would substantially increase fuel consumption and add a failure chance to an engine. The only thing that had stopped me so far is that there are a lot of places in the code where speed is checked and I would have to go through all of them to ensure they took 'boost mode' into consideration. If I did add a boost mode it would be a seperate tech line and would be part of the engine design, making the engine more expensive but probably not any larger.

Steve
Title: Re: Suggestions for 3.3
Post by: Charlie Beeler on January 23, 2009, 11:54:44 AM
Quote from: "Steve Walmsley"
Quote from: "adradjool"
I'm not sure that a knew line of tech for a commercial engine is the right answer.  They would still have the ability to run faster than a warship as long as there are not restrictions in the number of engines used.  Maybe the right answer is an additional tech in the mode of some sort of booster.  I guess it would work the same as afterburners for today's fighters.  They would provide a short term boost of speed to quickly close the range with an enemy, but at the same time increase the possibility of engine damage exponentially with regard to time in service and the consumption of fuel goes up by a factor of maybe four or more.  I'm not exactly sure where this would correlate in SF, but I think the closest was detuning engines.  Maybe the engine booster tech line would allow for longer periods of use before catastrophic effects took place as well as slightly smaller percentage (1-2%) of fuel consumption with each tech level.  As with everything, a smaller version could be created for gunboats and fighters.  
This is something I have been considering. Either a seperate booster or more likely some type of boost mode for engines that would substantially increase fuel consumption and add a failure chance to an engine. The only thing that had stopped me so far is that there are a lot of places in the code where speed is checked and I would have to go through all of them to ensure they took 'boost mode' into consideration. If I did add a boost mode it would be a seperate tech line and would be part of the engine design, making the engine more expensive but probably not any larger.

Steve

Thre is already the power boost tech.  Perhaps a change in the way it is used.  Something like a standard mode for base output and a military mode for boosted output?
Title: Re: Suggestions for 3.3
Post by: Steve Walmsley on January 23, 2009, 12:06:28 PM
Quote from: "Charlie Beeler"
Quote from: "Steve Walmsley"
Quote from: "adradjool"
I'm not sure that a knew line of tech for a commercial engine is the right answer.  They would still have the ability to run faster than a warship as long as there are not restrictions in the number of engines used.  Maybe the right answer is an additional tech in the mode of some sort of booster.  I guess it would work the same as afterburners for today's fighters.  They would provide a short term boost of speed to quickly close the range with an enemy, but at the same time increase the possibility of engine damage exponentially with regard to time in service and the consumption of fuel goes up by a factor of maybe four or more.  I'm not exactly sure where this would correlate in SF, but I think the closest was detuning engines.  Maybe the engine booster tech line would allow for longer periods of use before catastrophic effects took place as well as slightly smaller percentage (1-2%) of fuel consumption with each tech level.  As with everything, a smaller version could be created for gunboats and fighters.  
This is something I have been considering. Either a seperate booster or more likely some type of boost mode for engines that would substantially increase fuel consumption and add a failure chance to an engine. The only thing that had stopped me so far is that there are a lot of places in the code where speed is checked and I would have to go through all of them to ensure they took 'boost mode' into consideration. If I did add a boost mode it would be a seperate tech line and would be part of the engine design, making the engine more expensive but probably not any larger.
Thre is already the power boost tech.  Perhaps a change in the way it is used.  Something like a standard mode for base output and a military mode for boosted output?
Yes, that a good idea. Modifying the use of the existing tech would be more sensible than a seperate new tech.

Steve
Title: Re: Suggestions for 3.3
Post by: backstab on January 23, 2009, 07:20:23 PM
Any Chance of Orbital colonies and marine boarding parties ?
Title: Re: Suggestions for 3.3
Post by: schroeam on January 23, 2009, 09:03:26 PM
Quote from: "backstab"
Any Chance of Orbital colonies and marine boarding parties ?
I like the idea of boarding parties, although assault shuttles would also need to be included.  Maybe a ship component of "Marine Detachment" or "Security Station" where the strength of the marines on board was based on the ground troop strength tech and number of detachments or stations included.  Another way to avoid assault shuttles would be for a ship to be able to dock with another.  To go along with this, an order for ship capture, or board to search for contraband, could be given to ship X with ship Y as the target.  The order would be carried out as long as Ship X was able to catch Ship Y and maintain the same position.  As ship X gained on ship Y the captain attempted to get ship Y to stop using what diplomacy skill he has.  Obviously not having any diplomacy skill will more than likely result in hostile action, but should said captain succeed, he could possibly gain a diplomacy bonus, or raise an existing one.

Adam.
Title: Re: Suggestions for 3.3
Post by: sloanjh on January 23, 2009, 09:33:47 PM
Quote from: "adradjool"
Quote from: "backstab"
Any Chance of Orbital colonies and marine boarding parties ?
I like the idea of boarding parties, although assault shuttles would also need to be included.  Maybe a ship component of "Marine Detachment" or "Security Station" where the strength of the marines on board was based on the ground troop strength tech and number of detachments or stations included.  Another way to avoid assault shuttles would be for a ship to be able to dock with another.  To go along with this, an order for ship capture, or board to search for contraband, could be given to ship X with ship Y as the target.  The order would be carried out as long as Ship X was able to catch Ship Y and maintain the same position.  As ship X gained on ship Y the captain attempted to get ship Y to stop using what diplomacy skill he has.  Obviously not having any diplomacy skill will more than likely result in hostile action, but should said captain succeed, he could possibly gain a diplomacy bonus, or raise an existing one.

Adam.

This also fits in with the "pirates" thread somewhere else.  I would expect anti-piracy designs to be heavy on boarding and shuttle capability.  One campaign I would be interested in playing is one where an isolated empire that had a pure piracy-suppression navy encountered a warlike NPR.

John
Title: Re: Suggestions for 3.3
Post by: waresky on January 24, 2009, 11:47:10 AM
Steve,u remember Subsector ICONS on Megatravl,around the Stellar System? Presence or not of Gas Giant (ex:Sorium on GG) presence or not of Water (same purpouse FLEET movement planning) and so on..
CAN u make same option for Galactical Map and so we have a fastest fuel strategical situation,for bettter planning on Fleet movement or war planning,blockade strategical resypply Systems and so on..?

best regarde.

P:S!!

OBVIOUSLY this "icons" for Sorium presence are available ONLY after the Survey (geo) are complete at 100%...

Giorgio
Italy
Title: Re: Suggestions for 3.3
Post by: Erik L on January 24, 2009, 12:30:15 PM
Quote from: "waresky"
Steve,u remember Subsector ICONS on Megatravl,around the Stellar System? Presence or not of Gas Giant (ex:Sorium on GG) presence or not of Water (same purpouse FLEET movement planning) and so on..
CAN u make same option for Galactical Map and so we have a fastest fuel strategical situation,for bettter planning on Fleet movement or war planning,blockade strategical resypply Systems and so on..?

best regarde.

P:S!!

OBVIOUSLY this "icons" for Sorium presence are available ONLY after the Survey (geo) are complete at 100%...

Giorgio
Italy

You can show planets that have a suitable habitability cost (0-2), (2-4), etc. This would do the "water" thing. But that is usually only for your species.
Title: Re: Suggestions for 3.3
Post by: waresky on January 26, 2009, 10:49:22 AM
NO Erik:)),am mean a completely another thing..

Sorium are vital,crucial,for Fleet Operations in War time,first fact.
WE need an option in "galactic map": "WHERE are this damned SORIUM surveyed?"
Hope u understand what am mean:)

Am need an USEFUL icon for represent this resource to show in galactic map,WHEN we have surveyed a GAS GIANT (if Sorium present) AND above the planets,IF presents.

for waht need this info? simple.

Steve remember MEGATRAVELLER Fleet Operation on Gas Giant refuel..need Fuel Harvester on fleet?send one before and parking around a Gas surveyed?ENEMY WHERE can refuel easy before us?

ICON to Sorium Representation on Galmap are VERY useful.
Title: Re: Suggestions for 3.3
Post by: James Patten on January 26, 2009, 11:07:33 AM
I note where sorium is in gas giants by putting a label on my map (usually "Fuel" because that's pretty short).  Of course you cannot attach the label to a star, so when I move stars around the label is left behind and I forget where it was to begin with.

Waresky's suggestion of an icon showing where sorium-laden gas giants are is spot-on.  Very helpful.
Title: Re: Suggestions for 3.3
Post by: Erik L on January 26, 2009, 01:04:23 PM
Quote from: "waresky"
NO Erik:)),am mean a completely another thing..

Sorium are vital,crucial,for Fleet Operations in War time,first fact.
WE need an option in "galactic map": "WHERE are this damned SORIUM surveyed?"
Hope u understand what am mean:)

Am need an USEFUL icon for represent this resource to show in galactic map,WHEN we have surveyed a GAS GIANT (if Sorium present) AND above the planets,IF presents.

for waht need this info? simple.

Steve remember MEGATRAVELLER Fleet Operation on Gas Giant refuel..need Fuel Harvester on fleet?send one before and parking around a Gas surveyed?ENEMY WHERE can refuel easy before us?

ICON to Sorium Representation on Galmap are VERY useful.

I was referring to the water suggestion, not the sorium one. Showing gas giants as a symbol on the galactic map is useful. But I tend to build a refueling operation in a nodal system as it is. So I have that listed.

For what it is worth, I don't think I've ever depleted the sorium in a gas giant. Ever.
Title: Re: Suggestions for 3.3
Post by: waresky on January 27, 2009, 10:34:18 AM
u right Erik,but we loose the core interesting of "gas Giant with Sorium ICONS" on galactic layer..

isnt the problem the gas giant depleting ornot:)..are a another matter.

with dozens of thousands of possible star systems,the Fleet operations become more deep and deep on space,agree?
Ok..before u build up an entire FLEET (NOT a simple Task group,part of them BUT an FLEET) an Admiral NEED a some crucial logistical strategical information.
before u going on void,hostile space with a Trillions Credit Squadroon,and arent only a money trouble,but TIME,resourcesmok? ok..before u going into space U NEED know where,when and how much u can RESUPPLY ur damned Fleets:)

open Strategical Galactic map and..FIND this damned SORIUM resource where at..not only with a label..BUT with a IMMEDIATE icon reknow around.
So..i can prepare better my Fleet,Cruiser Scquadroon,Assault Squadroon,Carrier Squadroon,Logistical,support,Electronics and Countermeasure Squadroon and so on..

BUT I need to know where r damned SORIUM for refuel my invaluable Fleet:)
Simple.or where we can setup an Siege around Gas giant in a strategical (for us and for enemy) Star System.
Understand?:)))
Title: Fleet or Squadroon ICON
Post by: waresky on January 27, 2009, 02:01:26 PM
hi STEVE.
u have play at Spinwarrd March Campaign (Megatrav's Imperium Vs Zhodani boardgame?)
Am afascinating to Fleet and Squadroon scheets...

possible have on Galactic map an same situation? sort of icon's Fleet or Squadroon?

AH another stupid enhancement: CHANGE the Orrorific terms: TASK GROUP and TASK FORCE..pls..:)..FLEET and SQUADROONS are very MORE role playing ambientation:)))))

Ty very much:)..
Title: Re: Suggestions for 3.3
Post by: Steve Walmsley on January 28, 2009, 05:24:35 AM
Quote from: "backstab"
Any Chance of Orbital colonies and marine boarding parties ?
Not in the short term but both may be possible in future versions.

Steve
Title: Re: Suggestions for 3.3
Post by: Steve Walmsley on January 28, 2009, 05:28:25 AM
Quote from: "waresky"
Steve,u remember Subsector ICONS on Megatravl,around the Stellar System? Presence or not of Gas Giant (ex:Sorium on GG) presence or not of Water (same purpouse FLEET movement planning) and so on..
CAN u make same option for Galactical Map and so we have a fastest fuel strategical situation,for bettter planning on Fleet movement or war planning,blockade strategical resypply Systems and so on..?

best regarde.

P:S!!

OBVIOUSLY this "icons" for Sorium presence are available ONLY after the Survey (geo) are complete at 100%...
I could put icons on the system map for any gas giants with Sorium but I am not sure how useful it would be. Many gas giants have Sorium but not at high accessibility and you can't access it anyway unless you have fuel harvesters. You can quickly locate suitable gas giants on the Mineral Survey Report window (sixth button from the right on the system map - the icon is a chart in front of a planet). Perhaps a better option might be showing operating fuel harvesters on the galactic map?

Steve
Title: Debris - Re: Suggestions for 3.3
Post by: jfelten on January 28, 2009, 10:39:39 AM
Suggestion:  When a ship etc. is destroyed in deep space, in addition to life pods, create some debris.  Perhaps they evaporate (disperse) over time.  It could just float there or be given a small constant velocity, or even slowly be pulled towards the sun.  Maybe allow a freighter or mining ship to recover some mineral content if they intercept debris.  I guess you could just put some floating minerals there to represent the debris to simplify things.  It would be interesting to come across evidence of ancient battles (assuming you don't go with debris evaporating).  If there was a major battle there might be enough debris for reinforcements to rush there to try to recover the debris first.
Title: Re: Debris - Re: Suggestions for 3.3
Post by: Erik L on January 28, 2009, 10:42:42 AM
Quote from: "jfelten"
Suggestion:  When a ship etc. is destroyed in deep space, in addition to life pods, create some debris.  Perhaps they evaporate (disperse) over time.  It could just float there or be given a small constant velocity, or even slowly be pulled towards the sun.  Maybe allow a freighter or mining ship to recover some mineral content if they intercept debris.  I guess you could just put some floating minerals there to represent the debris to simplify things.  It would be interesting to come across evidence of ancient battles (assuming you don't go with debris evaporating).  If there was a major battle there might be enough debris for reinforcements to rush there to try to recover the debris first.

Wrecks should be created when a ship is destroyed. Those can be reclaimed with a ship with a salvage module.
Title: Strip mines Re: Suggestions for 3.3
Post by: jfelten on January 29, 2009, 07:12:04 AM
Suggestion:  Strip mine installation.  Same cost to build but double the output of a regular mine or automated mine but consumes 4x the mineral potential (I.e. half is wasted).  I know this isn't really how strip mines work but I was looking for a way to quickly increase mining output in an emergency but at a significant cost so it didn't just become the norm.
Title: Re: Debris - Re: Suggestions for 3.3
Post by: Steve Walmsley on January 30, 2009, 10:47:59 AM
Quote from: "jfelten"
Suggestion:  When a ship etc. is destroyed in deep space, in addition to life pods, create some debris.  Perhaps they evaporate (disperse) over time.  It could just float there or be given a small constant velocity, or even slowly be pulled towards the sun.  Maybe allow a freighter or mining ship to recover some mineral content if they intercept debris.  I guess you could just put some floating minerals there to represent the debris to simplify things.  It would be interesting to come across evidence of ancient battles (assuming you don't go with debris evaporating).  If there was a major battle there might be enough debris for reinforcements to rush there to try to recover the debris first.
When a ship is destroyed, it will leave behind a wreck and a life pod. The wreck can be detected by active senors and salvaged by a ship with a salvage module. Wrecks contain minerals and salvaging an alien wreck can also potentially give you technology. Life pods will contain a portion of the crew (a larger portion if you abandon ship instead of it being destroyed) and may contain the commander of the ship as well. They are detected by everyone in the system and last 14 days. If you rescue your own lifepods, you can drop the survivors off at a colony and they will be added to your crewman pool. Any rescued commanders will be placed on the rescuing ship. if you rescue the life pods of alien ships, you can interrogate the crew and any commander and will gain espionage points (not sure if that last part was added for v3.2 or is only in v4.0).

Steve
Title: Full text in fire control pane - Re: Suggestions for 3.3
Post by: jfelten on February 02, 2009, 05:27:50 AM
Individual Unit Details window
Combat Settings tab
Assign Weapons to Selected Fire Control pane

Devise some way to see all the text for entries in that pane.  Either make the pane resizable somehow, or perhaps create mouse-over text for that entry or such.  Currently the way I name things I put the maximum range of the sensor or missile at the end, but that gets cut off here so I can't see it.

Similar problem in the "Selected fire Control (SFC)" pulldown list in the same window.

Also, same window, could the "Max PD Range" box default to the maximum range of the selected fire control above it?  I'm afraid I'm going to make a mental miscalculation here sometime and get my fleet whacked because of it.  If it defaulted, I could just select the anti-missile
fire control from the pick list and hit the "Set Mode" button.  Or at least I would know I could change to a smaller number but not larger.
Title: Murphy and XenoArchaeology
Post by: ZimRathbone on February 02, 2009, 06:57:55 AM
just something that occured to me...

There is a change for the XA team to research out a ruin, but AFAIK, there is no downside to the reactivation of installtions (ie if there are 200 abandoned installations in a ruin, then you will get 200 working installtions (eventually).  The only effect of team skill is how long you will take to get them all.

Being somewhat cynical, and knowing more than a few field archaeologists, there should be a significant change of lower skill teams completly messing up the reactivation process (Oh, you meant DONT touch the  big red Molly button! Whoops! <BOOOOOOM>)

I know of more than one Archeological team who's first reaction to arriving on site is "Who gets to drive the JCB?"  :)

I'd limit the usual catastrophe to just losing a potential installation, but really bad results could mean the loss of more than 1, or damage/destuction to existing installtions, or even loss of the team. More a colour thing than anything else.
Title: Re: Murphy and XenoArchaeology
Post by: welchbloke on February 02, 2009, 07:36:14 AM
Quote from: "ZimRathbone"
just something that occured to me...

There is a change for the XA team to research out a ruin, but AFAIK, there is no downside to the reactivation of installtions (ie if there are 200 abandoned installations in a ruin, then you will get 200 working installtions (eventually).  The only effect of team skill is how long you will take to get them all.

Being somewhat cynical, and knowing more than a few field archaeologists, there should be a significant change of lower skill teams completly messing up the reactivation process (Oh, you meant DONT touch the  big red Molly button! Whoops! <BOOOOOOM>)

I know of more than one Archeological team who's first reaction to arriving on site is "Who gets to drive the JCB?"  :D
Title: Re: Suggestions for 3.3
Post by: IanD on February 03, 2009, 12:33:05 PM
Steve – After the revelations that Mars contains substantially more water than previously thought (http://news.bbc.co.uk/1/hi/sci/tech/6459967.stm (http://news.bbc.co.uk/1/hi/sci/tech/6459967.stm)  http://www.sciam.com/article.cfm?id=red ... rt-massive (http://www.sciam.com/article.cfm?id=red-planet-alert-massive)) shouldn’t the stats for Mars be updated? unfortunately I fear this will not affect the colony cost! but always hopeful.
Regards
Ian
Title: Event log window feature requests - Re: Suggestions for 3.3
Post by: jfelten on February 05, 2009, 07:01:10 AM
Feature requests:  

On the event log window:  

1.  Would it be a simple code change to allow copy/pasting from that window?  

2.  Could the window be made resizable?  

3.  Could the function keys be enabled for that window (to open other Aurora windows, etc.)?  

4.  Add an option for the SM to add a free text entry to the log for a particular empire.  

Thanks
Title: Re: Event log window feature requests - Re: Suggestions for 3.3
Post by: Erik L on February 05, 2009, 12:03:24 PM
Quote from: "jfelten"
Feature requests:  

On the event log window:  

1.  Would it be a simple code change to allow copy/pasting from that window?  

You can output a text file from that window.
Title: Re: Suggestions for 3.3
Post by: Randy on February 05, 2009, 01:03:29 PM
Just a thought-

  There is already a delay for firing and some other commands based on crew training levels.

  Reading about the various battles it occurs to me that for missile armed ships this delay can be entirely eliminated by simply having the missiles fired to a marshalling point before sending the volley to its target.

   I suggest that crew trainging and quality should also affect the time it takes to re-target missiles. Otherwise you can virtually ignore the delay issue for misile races as they can (most of the time) be gotten around just by launching missiles at one target and then switching target with no penalty...
Title: Re: Event log window feature requests - Re: Suggestions for 3.3
Post by: jfelten on February 06, 2009, 05:48:41 AM
Quote from: "Erik Luken"
Quote from: "jfelten"
Feature requests:  

On the event log window:  

1.  Would it be a simple code change to allow copy/pasting from that window?  

You can output a text file from that window.

Yes, but that is a lot more work and slower than just highlighting something and copy/pasting it in to an email to a player.  For ones and twos it isn't an issue but if you start doing it all the time, it gets old.  And the export to text takes awhile once the log gets long.  You can shorten the log of course but maybe you don't want to for some reason.  If it is just a flag Steve can set to allow copy/pasting from that window, it would be nice if he would do that.
Title: On Galactic MAP:
Post by: waresky on February 08, 2009, 11:56:14 AM
Name and Routes COLOR EDITABLE pls,Steve,for more easy printable version (black and white for less expense on laser toner and quickly chomprension)of Galactic Map.

Am love gave a printable version to Galactic map,u know Megatravller "Fleets Operation",and a good printing strategical map are very useful (4 me,obviously,hope r same for all ur friends here:).)
Title: an Useful CLICK...
Post by: waresky on February 11, 2009, 11:00:12 AM
Dear Steve,hope u can understand that am write:

in solar system map,classic,when u hit (clik) on a squadroon,directly on map,it's possible this action OPEN a tas Group window directly?obviously not "left" click but RIGHT click....i think r more useful than check "military" classic windos on left and try to found the right Task Group,then mouse right click and open the window...u understand what am mean?
Title: Re: Suggestions for 3.3
Post by: Larac on February 14, 2009, 11:11:41 AM
Quote from: "IanD"
A simple addition to raise the paranoia of player races, (at least I assume it would be simple).

Have some random fluff for ruins that is given with the first result of the xenologists investigations. E.g.  “These installations appear to have malfunctioned and simply been abandoned” or “this settlement was destroyed by nuclear bombardment”. This may give a player race a reason to increase their military R&D and construction.

If the result could be tied to the condition of the ruin all the better.  E.g. Destroyed Outpost – 70% chance result of some sort of military action, ruined outpost - 50% chance of “bombardment +/- indications of ground combat” etc. You could even solicit the group for suitable fluff.

If you want to be more ambitious, then the type of fluff could affect the security requirements of populations in adjoining systems. But I fear this could be a lot of work for little return.

Regards
Ian

One way to do this, might be to allow the users to edit the fluff areas.

A set of files that they could write up the reports to match the events, for ruins and other items. When a Military action Ruin is called for the sw randomly picks a Ruin Report of Military. Might work well for Special Research and other things as well. So the reports would vary greatly as they do in real life, the info would be the same but how it is presented would be more RPish.

Also with the user base writing the text Steve is not put on the spot to generate all the story stuff.

Another Idea would be to allow a SM to choose a set of reports or add extra info into them, to tell more story elements to the players.
If done randomly a threshold number could be set to limit what info is released, so at Lvl 1 its very vague and hinting, to Lvl 10 Where it give detailed info, the SM just sets the Threshold number as the game is played. At the start it is 0-1, then after a few reports are sent it is increased to 1-2, then 3, and if the players are spreading quickly and start losing contact with lots of ships it jumps to 4-7 and so on.

It would give the SM a great tool for telling the story along with everything else.


I am not sure if this can be done yet, still poking around.
Is there a report that can be generated that lists all major events, discoveries and such for each player of their Empire and what they know happened in the Other Empires.
Spies, ships hidden in system that sort of thing?
This would be nice to export to a set of letter heads from differing departments and send as a pdf to the players.
Again I see the User base making all the extra stuff, just a good way to separate the info into departments from the SW.


Will have more as I learn more.
Great Program, Thank You for the time you have poured in

Lee
Title: MOTHBALLED ships,parking?Not used?
Post by: waresky on February 15, 2009, 10:23:57 AM
Steve,am lost in ur program:)..exist a command link to set an ship on MOTHBALLED situation????
Do u remember Megatraveller "DEPOT" Imperial Solar System,where the impi navy put oldest Colonial and Imperials Fleet,maintain a training range,entire moons dedicated to maintenance mothballed ships and so on..

at moment on Aurora are an similar possibility?
Title: Re: MOTHBALLED ships,parking?Not used?
Post by: Erik L on February 15, 2009, 02:03:37 PM
Quote from: "waresky"
Steve,am lost in ur program:)..exist a command link to set an ship on MOTHBALLED situation????
Do u remember Megatraveller "DEPOT" Imperial Solar System,where the impi navy put oldest Colonial and Imperials Fleet,maintain a training range,entire moons dedicated to maintenance mothballed ships and so on..

at moment on Aurora are an similar possibility?

Ships used to be able to be put into a mothball state. But that was removed in an early 2.x version if I recall. When the maintenance facilities were introduced.
Title: Re: Suggestions for 3.3
Post by: Kurt on February 15, 2009, 11:23:19 PM
Steve -

Something came to light in my latest battle.  I was going through and doing battle prep, assigning weapons to fire controls and assigning targets, and I did something without thinking that kind of messed up my firing plan.  It would have been nice if Aurora told me I screwed up when I did it, rather than informing me after the time advance.  

Basically, I used the "copy Assign" button on the right hand side of the Combat Assignments window to copy the fire control assignments and missile/missile launcher assignments throughout my entire fleet.  This simplifies things greatly, except for one little problem.  I used the first ship on the list as the model, and that ship had the latest and best missiles on board.  When I hit the "Copy Assign" button, that assigned those same missiles to every launcher throughout the fleet, whether or not the ship had those missiles.  Unknown to me, because I wasn't paying attention, severl ships had older missiles, but in spite of the fact that they had zero of the latest missiles in their mags, the latest missiles were assigned to their launchers.  After hitting the time advance I noticed the problem on the Events window and changed the missile assignments as needed.  

This was an oops on my part, but it would be nice if a pop-up came up to tell me that some of the ships didn't have the appropriate missile, rather than assigning a missile that the ship didn't have.  

Kurt
Title: Re: Suggestions for 3.3
Post by: Charlie Beeler on February 16, 2009, 08:24:30 AM
Steve,  

IIRC you've increased turret speeds in v4.0 by 25%.  May I suggest that they be increased to match 4x the tracking speed of the same level beam fire control?  This would provide for PD systems that were an par with the max available fire control for a tech iteration.  Missiles can still be built at the same tech levels that exceed the tracking speeds, but this will give beam turrets a chance.  

In the first couple of levels of beam systems this isn't very noticeable.  But it doesn't take long for even double size fire controls to be so far beyond the turret tracking, without extreme expenditure of mass, as to make then near useless except on large ships.  

I've made this change in my database and so far it does not appear to be unbalancing.
Title: Re: Suggestions for 3.3
Post by: Father Tim on February 17, 2009, 09:24:33 AM
I know it's been mentioned upthread, but as we get closer to a release of 4.0 I just want to reiterate the request for a way to convert Low Tech Infantry and Low Tech Armour units into trans-Newtonian ground units.  Specifically, without losing any accumulated Morale bonuses from training.

I'm torn between
LTI --> Garrison (Cost 25), Mobile Infantry (75), or Assault Infantry (75)
LTA --> Heavy Assault (Cost 125)

and

LTI --> Garrison (25) or Mobile Infantry (75)
LTA --> Heavy Assault (125) or Assault Infantry (50)

but I'd be willing to settle for

LTI --> Garrison
LTA --> Heavy Assault
Title: STEVE,pls separate teh Orders..
Post by: waresky on February 17, 2009, 11:35:33 AM
Steve,are an Boredoom situation on "advance" time with 6hours impulse..EVERY damned 6 hours the "order Completed" FROM CIVILIANS idiots transits and completed orders bore me too..

Pls take some action to DIVIDE the "Orders Completed" FROM Civilians to Governement...PLS,otherwise am set NONE in subpulse..BUT in War time r very vicious this..and not ever r useful information s EVERY 6 hours..
So if u put under CIVILIANS the Orders Completed,am cut completely this info from coming in Event log..and ONLY the VERY useful infos r USEFUL.

U understand? ty v much.
Title: Re: STEVE,pls separate teh Orders..
Post by: Father Tim on February 17, 2009, 06:46:09 PM
Quote from: "waresky"
Steve,are an Boredoom situation on "advance" time with 6hours impulse..EVERY damned 6 hours the "order Completed" FROM CIVILIANS idiots transits and completed orders bore me too..

Pls take some action to DIVIDE the "Orders Completed" FROM Civilians to Governement...PLS,otherwise am set NONE in subpulse..BUT in War time r very vicious this..and not ever r useful information s EVERY 6 hours..
So if u put under CIVILIANS the Orders Completed,am cut completely this info from coming in Event log..and ONLY the VERY useful infos r USEFUL.

U understand? ty v much.

Steve has already fixed the underlying problem of civilian fleets aimlessly going back & forth, spawning an 'Orders Completed' event every single time increment.  And the idea of segregating all civilian 'Orders Completed', 'Orders not Possile', etc. events into a civilian-only event tye (notification of which could then easily be turned off) was rised a while ago, but  I can't remember what the outcome of the discusion was.
Title: Re: Suggestions for 3.3
Post by: jfelten on February 18, 2009, 06:45:41 AM
Quote from: "Kurt"
Steve -

Something came to light in my latest battle.  I was going through and doing battle prep, assigning weapons to fire controls and assigning targets, and I did something without thinking that kind of messed up my firing plan.  It would have been nice if Aurora told me I screwed up when I did it, rather than informing me after the time advance.  

Basically, I used the "copy Assign" button on the right hand side of the Combat Assignments window to copy the fire control assignments and missile/missile launcher assignments throughout my entire fleet.  This simplifies things greatly, except for one little problem.  I used the first ship on the list as the model, and that ship had the latest and best missiles on board.  When I hit the "Copy Assign" button, that assigned those same missiles to every launcher throughout the fleet, whether or not the ship had those missiles.  Unknown to me, because I wasn't paying attention, severl ships had older missiles, but in spite of the fact that they had zero of the latest missiles in their mags, the latest missiles were assigned to their launchers.  After hitting the time advance I noticed the problem on the Events window and changed the missile assignments as needed.  

This was an oops on my part, but it would be nice if a pop-up came up to tell me that some of the ships didn't have the appropriate missile, rather than assigning a missile that the ship didn't have.  

Kurt

How hard would it be to have a ship automatically switch to an available missile?  You could rate they by cost as a rule of thumb and assume the most expensive missile in the magazines that has a warhead (I.e., don't automatically launch pure probe drones) is the next best choice.  That won't always be the best choice but for a default should work fairly well.  Another thought is to rank them by speed or warhead, or some formula based on speed and warhead strength.
Title: Re: Suggestions for 3.3
Post by: Sotak246 on February 20, 2009, 08:45:34 PM
As I have had similar goofs, in missile allocations, usually that one ship I missed loading the newest missisles on. I would like an automatic default for missile assignments. Maybe base it on a formula like jfelten suggested,
Quote
Another thought is to rank them by speed or warhead, or some formula based on speed and warhead strength.
with range also considered.

Mark
Title: Re: Suggestions for 3.3
Post by: Kurt on February 21, 2009, 11:51:53 AM
Steve -

A couple of suggestions for the "Combat Assignments Overview" window, based on my latest battle.

1.  It would be really, really, really nice if the "Assign Contact as a Target" box in the lower-middle-left portion ofthe window either was larger or if there was a scroll bar that would allow me to see text that extends off the right hand side of the box.  Many of the contacts have enough info that they extend past the right side ofthe box, which means that I can't see the entire listing and in particular, I can't see the range to the target.  

2.  It would also be really, really nice if I could select multiple fire controls to assign targets to or to unassign targets.  The standard shift+right click to select a range of fire controls, or cntrl+right click to select multiple fire controls would be nice.  

3.  Finally, it would also be nice to be able to clear all fire control assignments in a task group or individual ship at once, with one button, instead of having to go through and clear each fire control individually.  

Kurt
Title: Re: Suggestions for 3.3
Post by: waresky on February 21, 2009, 12:18:13 PM
Ty Kurt for ur post,am in 2nd Battle in my campaign and the thing to do grew very fast.
u speak very well same my trouble.

subscrive to Steve

really really really be nice:_)
Title: Re: Suggestions for 3.3
Post by: jfelten on February 23, 2009, 05:44:05 AM
Quote from: "Kurt"
Steve -

A couple of suggestions for the "Combat Assignments Overview" window, based on my latest battle.

1.  It would be really, really, really nice if the "Assign Contact as a Target" box in the lower-middle-left portion ofthe window either was larger or if there was a scroll bar that would allow me to see text that extends off the right hand side of the box.  Many of the contacts have enough info that they extend past the right side ofthe box, which means that I can't see the entire listing and in particular, I can't see the range to the target.  

. . .

Kurt

I've only done limited combat testing (30+ years in to the game and as luck would have it still no high tech aliens to fight) but I did notice the same problem and second that it would be nice to have fixed.  If it is hard to make that list box bigger, would it be easy to add the full string to a mouse-over?
Title: Re: Suggestions for 3.3
Post by: Brian Neumann on February 23, 2009, 06:58:40 AM
Quote from: "jfelten"
Quote from: "Kurt"
Steve -

A couple of suggestions for the "Combat Assignments Overview" window, based on my latest battle.

1.  It would be really, really, really nice if the "Assign Contact as a Target" box in the lower-middle-left portion ofthe window either was larger or if there was a scroll bar that would allow me to see text that extends off the right hand side of the box.  Many of the contacts have enough info that they extend past the right side ofthe box, which means that I can't see the entire listing and in particular, I can't see the range to the target.  

. . .

Kurt

I've only done limited combat testing (30+ years in to the game and as luck would have it still no high tech aliens to fight) but I did notice the same problem and second that it would be nice to have fixed.  If it is hard to make that list box bigger, would it be easy to add the full string to a mouse-over?

Ditto for me.  I have run into the problem on several occasions.

Brian
Title: Re: Suggestions for 3.3
Post by: jfelten on February 23, 2009, 07:00:22 AM
Maybe it should be considered a bug and not a suggestion?
Title: Re: Suggestions for 3.3
Post by: Brian Neumann on February 23, 2009, 08:25:55 AM
On the officer assignment screen, could you have the sector commands be listed as sector instead of govenor.  It can be a bit confusing to figure out which govenor is for the planet, and which is for the sector to start with.

Brian
Title: Re: Suggestions for 3.3
Post by: Charlie Beeler on February 23, 2009, 10:06:48 AM
Quote from: "Brian"
On the officer assignment screen, could you have the sector commands be listed as sector instead of govenor.  It can be a bit confusing to figure out which govenor is for the planet, and which is for the sector to start with.

Brian

My short term solution has been to name sectors something other than the planetary default.
Title: Re: Suggestions for 3.3
Post by: simon on February 23, 2009, 11:32:07 AM
Does anyone want to see graphs pie charts and other graphical representation for aurora.I am thinking about graphs and pies to show what is consuming what in the economy,  total planetary/racial population, mineral output consumption, total mineral output etc even if crude it would help. If you feel the same put your hand up and then type what you think show have some pictorial rep.
P.s The tactical intelligene window would be nice if you could compare palnetary emissions engine signatures via some pictorial thingie like a graph. :)
Title: Re: Suggestions for 3.3
Post by: waresky on February 23, 2009, 12:47:30 PM
Hand raised ONE!mine:)
Agree..

And..STEVE...can u prepare an grahpical represntation when an Missile or an beam struck the target?:)..
And when an ship explode? can we LOOK effects?:)
Title: Re: Suggestions for 3.3
Post by: simon on February 24, 2009, 03:15:44 AM
Quote from: "waresky"
Hand raised ONE!mine:)
Agree..

And..STEVE...can u prepare an grahpical represntation when an Missile or an beam struck the target?:)..
And when an ship explode? can we LOOK effects?:)
I do not think 2d displays can do aurora justice, hopefully in the future you can have a usb plug on your head or at least holograms displays to truly enjoy the game.
I was thinking more along the line where number cannot really allow you to understand progress such as month to month economic growth or comparing planetary  emissions and other unwieldy metrics.
Title: Re: Suggestions for 3.3
Post by: simon on February 24, 2009, 03:17:14 AM
Quote from: "waresky"
Hand raised ONE!mine:)
Agree..

And..STEVE...can u prepare an grahpical represntation when an Missile or an beam struck the target?:)..
And when an ship explode? can we LOOK effects?:)
:| I do not think 2d displays can do aurora justice, hopefully in the future you can have a usb plug on your head or at least holograms displays to truly enjoy the game.
I was thinking more along the line where number cannot really allow you to understand progress such as month to month economic growth or comparing planetary  emissions and other unwieldy metrics.
Title: Re: Suggestions for 3.3
Post by: waresky on February 24, 2009, 08:52:07 AM
Am an older (Elder) RolePlayers from 1979 (15 years old) with Traveller..so in my mind r all the universe,r a simple funny words.
:)
Aurora r perfect for me,only am loving an Exagonal Map in Galactic..(one time ive questioning upon,Steve,never show answer)
Title: Re: Suggestions for 3.3
Post by: Erik L on February 24, 2009, 01:07:15 PM
Quote from: "waresky"
Am an older (Elder) RolePlayers from 1979 (15 years old) with Traveller..so in my mind r all the universe,r a simple funny words.
:)
Aurora r perfect for me,only am loving an Exagonal Map in Galactic..(one time ive questioning upon,Steve,never show answer)

I don't think there is much need for a hex map because everything is recorded positionally.

If you are talking about icons for gas giants, etc... that I can see.
Title: Refuel a Colony who lack on SORIUM
Post by: waresky on February 24, 2009, 01:07:46 PM
Steve.
Ive some SOlar system who lack completely on SORIUM on planets surface..BUT are full of them in GAS giants.
1)For a good colony Sorium are strategical,so am build Fuel harvester and put in orbit around the Gas Giant..
BUT
2)FH task group NEED an supplementary COMMAND LINE:"when fuel tanks r FULL,goto Main Planet and unload 90%,then return Gas Giants Orbit"

In this we can setup a very intelligence colonization on far and poor solar systems..otherwise r very difficult manage it.

hope u understand what am try to mean:)
Title: Re: Refuel a Colony who lack on SORIUM
Post by: Erik L on February 24, 2009, 01:09:22 PM
Quote from: "waresky"
Steve.
Ive some SOlar system who lack completely on SORIUM on planets surface..BUT are plenty of them in GAS giants.
1)For a good colony Sorium are strategical,so am build Fuel harvester and put in orbit around the Gas Giant..
BUT
2)FH task group NEED an supplementary COMMAND LINE:"when fuel tanks r FULL,goto Main Planet and unload 90%,then return Gas Giants Orbit"

In this we can setup a very intelligence colonization on far and poor solar systems..otherwise r very difficult manage it.

hope u understand what am try to mean:)

You mean instead of (or in addition to) "Go to nearest colony and unload 90% fuel" have "go to homeworld (or sector capital) and unload 90% fuel"?
Title: Re: Suggestions for 3.3
Post by: waresky on February 24, 2009, 01:11:17 PM
the command "unload 90%..." still exist (am setup FH as "tanker")...BUT we lack a important command line: WHEN this damned FH are full..MOVE her ass AND unload 90% fuel"..

understand?:)
Title: Re: Suggestions for 3.3
Post by: Charlie Beeler on February 24, 2009, 01:56:17 PM
Quote from: "waresky"
the command "unload 90%..." still exist (am setup FH as "tanker")...BUT we lack a important command line: WHEN this damned FH are full..MOVE her ass AND unload 90% fuel"..

understand?:)


Use conditional "when fuel tanks are full"  to execute the unload 90% order.
Title: Re: Suggestions for 3.3
Post by: waresky on February 24, 2009, 02:40:34 PM
oh my..true,ty charl..
hmmm..but when the conditional r be satisfactions..how i can return "automatically" at older position around the gas giant?..hmm..i can give an recurrent order: "Enter orbit "xxx" (and repeat orders automatically?)..
so when Tank Fuel r full..subroutine on..but when tank r unloaded from 90%..ahhh..
AM must try to all
Title: Re: Suggestions for 3.3
Post by: waresky on February 24, 2009, 02:47:54 PM
OK..one of mine FH follow "conditional" and are en route to an Colony..then ive show on command orders..and am show the after:"enter orbit xxx"..hmmm..probably am found a damned automatic refuel colony solutions:)
Ty v much mate
A little trouble..in a Solar System can have more than 1 main colony..SO the conditional orders ("fuel tank full">>"unload 90%..") are TOO generic.

pls implement a conditional more specifically: "Unload at >25 ,or >100 ,or >200million pop Colony..or "Main Colony" or "Spaceport Colony" and so on.
Title: Re: Suggestions for 3.3
Post by: backstab on February 24, 2009, 03:26:31 PM
Scroll bars for the Officers screen would be good.
Title: Re: Suggestions for 3.3
Post by: Sotak246 on February 24, 2009, 09:36:12 PM
In the task force commands you have as a possible command 'detach tankers'.  I would like to see a similar command but for jumpships.  I regularly put unarmored jumpships in my patrol fleets for faster, cheaper travel (assault fleets use specialized warships), but would like a quick way to detach them when they get to their destination.  I have tried using that command and since my jumpships are tankers as well, but for some reason, unless I rename the fleet it forms it will not allow any jump movement.  example:  Patrol A transits a jump point and detaches tankers/jumpships (tanker I), which stays on the jp.  Theoreticaly any ships should be able to transit the jp using that jumpship.  Unfortunatly the game seems to think that since I detached "tankers" then it can't be a jumpship as well and will not allow it to assist in transits.
Mark
Title: MARS update:)
Post by: waresky on February 27, 2009, 11:40:21 PM
Show the real life news,Steve,u can chaange some in Mars geology?

Methane on atmosf.-.-
H2O
...
Title: Re: Suggestions for 3.3
Post by: welchbloke on February 28, 2009, 05:36:55 AM
Quote from: "backstab"
Scroll bars for the Officers screen would be good.
A vote from me for this as well; I believe Steve mentioned he was going add scroll bars to a bunch of windows for the next version?
Title: Re: Suggestions for 3.3
Post by: Brian Neumann on February 28, 2009, 07:16:54 AM
In the officer screen when picking reasearch as the Ability A, can you add the different subfields as options in the ability B field.  I often find myself looking through multiple officers for the reasearch bonus that I want.  At the start of a game it is no big deal, but after 30 years and about 3000 officers it takes a while for each one to show.

I may have already asked for this, if so sorry for the repeat.

Brian
Title: Re: Suggestions for 3.3
Post by: waresky on February 28, 2009, 01:36:50 PM
Quote from: "Brian"
In the officer screen when picking reasearch as the Ability A, can you add the different subfields as options in the ability B field.  I often find myself looking through multiple officers for the reasearch bonus that I want.  At the start of a game it is no big deal, but after 30 years and about 3000 officers it takes a while for each one to show.

I may have already asked for this, if so sorry for the repeat.

Brian
Quote
ive narrow to 2500Officers..and have Ages before am check every damned officers..
And coming some bugs,in Team options...:S srry for Out of topic.But hope steve take some "lite" operation to better performance on Officer "bar"_:)
Title: Re: Suggestions for 3.3
Post by: jfelten on March 11, 2009, 01:41:38 PM
Quote from: "waresky"
ive narrow to 2500Officers..and have Ages before am check every damned officers..
And coming some bugs,in Team options...:S srry for Out of topic.But hope steve take some "lite" operation to better performance on Officer "bar"_:)

Geesh.  25K Officers.  I don't know what Steve is doing in his code but perhaps adding a primary key somewhere would speed things up dramatically.
Title: Re: Suggestions for 3.3
Post by: Kurt on March 28, 2009, 01:44:49 PM
Steve -

I know you just released 4.0b, but after plotting out a major colonial effort for a system four jumps away from Earth, I had an idea.  I have no idea if it would be hard or easy to program, but it sure would make things easier when giving orders.  Would it be possible, when giving movement commands on the task group screen, to change things so that instead of having to give orders like this: "Move to warp point A, transit warp point A, move to warp point B, transit warp point B, move to warp point C, transit warp point C, move to planet D", I could could instead select a destination from a list of my race's populations, and then Aurora would calculate the path from System A to System C, planet D?  I know it might be problematic if there are multiple paths, and pathfinding might be problematic even if there is only one, but giving these movement orders is time consuming, and if it could be streamlined it would help reduce the overhead greatly.

Thanks -

Kurt
Title: Re: Suggestions for 3.3
Post by: SteveAlt on March 28, 2009, 01:54:15 PM
Quote from: "jfelten"
Quote from: "waresky"
ive narrow to 2500Officers..and have Ages before am check every damned officers..
And coming some bugs,in Team options...:S srry for Out of topic.But hope steve take some "lite" operation to better performance on Officer "bar"_:)

Geesh.  25K Officers.  I don't know what Steve is doing in his code but perhaps adding a primary key somewhere would speed things up dramatically.
I have been database programming for 20 years so there are one or two primary keys scattered about. A few foreign ones as well.

Steve
Title: Re: Suggestions for 3.3
Post by: SteveAlt on March 28, 2009, 01:57:49 PM
Quote from: "Kurt"
Steve -

I know you just released 4.0b, but after plotting out a major colonial effort for a system four jumps away from Earth, I had an idea.  I have no idea if it would be hard or easy to program, but it sure would make things easier when giving orders.  Would it be possible, when giving movement commands on the task group screen, to change things so that instead of having to give orders like this: "Move to warp point A, transit warp point A, move to warp point B, transit warp point B, move to warp point C, transit warp point C, move to planet D", I could could instead select a destination from a list of my race's populations, and then Aurora would calculate the path from System A to System C, planet D?  I know it might be problematic if there are multiple paths, and pathfinding might be problematic even if there is only one, but giving these movement orders is time consuming, and if it could be streamlined it would help reduce the overhead greatly.
It is possible, although tricky over longer distances. The civilian and NPR code has to work out the route to various destinations so that could be adapted. It currently has a 4 system max limit though. I agree it would be useful though so I'll add it to my list of important mods.

Steve
Title: Re: Suggestions for 3.3
Post by: SteveAlt on March 28, 2009, 05:21:21 PM
Quote from: "SteveAlt"
Quote from: "Kurt"
Steve -

I know you just released 4.0b, but after plotting out a major colonial effort for a system four jumps away from Earth, I had an idea.  I have no idea if it would be hard or easy to program, but it sure would make things easier when giving orders.  Would it be possible, when giving movement commands on the task group screen, to change things so that instead of having to give orders like this: "Move to warp point A, transit warp point A, move to warp point B, transit warp point B, move to warp point C, transit warp point C, move to planet D", I could could instead select a destination from a list of my race's populations, and then Aurora would calculate the path from System A to System C, planet D?  I know it might be problematic if there are multiple paths, and pathfinding might be problematic even if there is only one, but giving these movement orders is time consuming, and if it could be streamlined it would help reduce the overhead greatly.
It is possible, although tricky over longer distances. The civilian and NPR code has to work out the route to various destinations so that could be adapted. It currently has a 4 system max limit though. I agree it would be useful though so I'll add it to my list of important mods.
This proved easier than I expected. There is now a new System Location Display Option for All Pops on the Fleet window. When this is selected you can see all populations in the list of destinations. As you select one you get the usual list of move options such as Resupply from Colony, Move to, etc. Except in this case it fills in the intervening transits automatically. This will only work for colonies within four jumps that can be reached by the fleet in question. The code is aware of jump gates and jump engines when it works this out. If it can't work out a route or you select a colony further away than four jumps, you will get a popup stating that no route can be found. If you are 5 jumps away just plot the first transit and then use the auto-route for the rest of the trip. When I get chance I will upgrade the route finding code to handle more than 4 jumps.

I could try and restrict the list to only those pops you can reach but that would involve working out the route to every colony before the list is displayed and that would take a while.

Steve