Author Topic: Suggestions for 3.3  (Read 12631 times)

0 Members and 1 Guest are viewing this topic.

Offline jfelten

  • Lieutenant
  • *******
  • j
  • Posts: 187
Re: Suggestions for 3.3
« Reply #45 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.
« Last Edit: January 09, 2009, 04:33:14 AM by jfelten »
 

Offline jfelten

  • Lieutenant
  • *******
  • j
  • Posts: 187
Re: Suggestions for 3.3
« Reply #46 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.
 

Offline Erik L

  • Administrator
  • Admiral of the Fleet
  • *****
  • Posts: 5659
  • Thanked: 377 times
  • Forum Admin
  • Discord Username: icehawke
  • 2020 Supporter 2020 Supporter : Donate for 2020
    2022 Supporter 2022 Supporter : Donate for 2022
    Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2021 Supporter 2021 Supporter : Donate for 2021
Re: Suggestions for 3.3
« Reply #47 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.

Offline ZimRathbone

  • Captain
  • **********
  • Posts: 408
  • Thanked: 30 times
  • Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2023 Supporter 2023 Supporter : Donate for 2023
Re: Suggestions for 3.3
« Reply #48 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
Slàinte,

Mike
 

Offline jfelten

  • Lieutenant
  • *******
  • j
  • Posts: 187
Re: Suggestions for 3.3
« Reply #49 on: January 12, 2009, 06:21:02 AM »
Have the keyboard arrow keys "pan" in the System Map (in addition to the arrow buttons).
 

Offline jfelten

  • Lieutenant
  • *******
  • j
  • Posts: 187
Re: Suggestions for 3.3
« Reply #50 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.
 

Offline IanD

  • Registered
  • Commodore
  • **********
  • Posts: 725
  • Thanked: 20 times
Re: Suggestions for 3.3
« Reply #51 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
IanD
 

Offline welchbloke

  • Vice Admiral
  • **********
  • Posts: 1048
  • Thanked: 10 times
Re: Suggestions for 3.3
« Reply #52 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
Welchbloke
 

Offline jfelten

  • Lieutenant
  • *******
  • j
  • Posts: 187
Re: Suggestions for 3.3
« Reply #53 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.
 

Offline jfelten

  • Lieutenant
  • *******
  • j
  • Posts: 187
Re: Suggestions for 3.3
« Reply #54 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.
 

Offline Hawkeye

  • Silver Supporter
  • Vice Admiral
  • *****
  • Posts: 1059
  • Thanked: 5 times
  • Silver Supporter Silver Supporter : Support the forums with a Silver subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2022 Supporter 2022 Supporter : Donate for 2022
    2023 Supporter 2023 Supporter : Donate for 2023
Re: Suggestions for 3.3
« Reply #55 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
Ralph Hoenig, Germany
 

Offline sloanjh

  • Global Moderator
  • Admiral of the Fleet
  • *****
  • Posts: 2805
  • Thanked: 112 times
  • 2020 Supporter 2020 Supporter : Donate for 2020
    2021 Supporter 2021 Supporter : Donate for 2021
Re: Suggestions for 3.3
« Reply #56 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
 

Offline jfelten

  • Lieutenant
  • *******
  • j
  • Posts: 187
Re: Suggestions for 3.3
« Reply #57 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.
 

Offline Father Tim

  • Vice Admiral
  • **********
  • Posts: 2162
  • Thanked: 531 times
Re: Suggestions for 3.3
« Reply #58 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.
 

Offline Steve Walmsley

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11729
  • Thanked: 20681 times
Re: Suggestions for 3.3
« Reply #59 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